Landing Time: Multi-Dish Kitchen Engine

A voice-first multi-dish kitchen scheduling engine using backward CPM to coordinate shared ovens, burners, and live delays so every dish lands hot and synchronized.

Comment

🍳 Inspiration

Cooking dinner for family or friends should feel like a celebration, but in reality, preparing a multi-dish meal is a high-stress, resource-constrained distributed system:

  • Shared Physical Appliances: A roast chicken and smashed potatoes share a single oven cavity at 425°F; asparagus and pan gravy compete for 4 stovetop burners.
  • Limited Cook Attention: You cannot whisk a delicate pan gravy, carve poultry, and monitor skillet sear simultaneously.
  • Cross-Dish Precedence: True pan gravy deglazing physically depends on warm pan drippings from a rested roast chicken.

Conventional cooking apps treat recipes as isolated, static instructions. Traditional timer apps are disconnected countdown clocks that don't talk to each other. When your roast chicken needs 12 extra minutes in the oven, conventional timers let your roasted potatoes get soggy and your vegetables get cold on the counter.

We built Landing Time to solve this fundamentally: by modeling dinner as a unified Directed Acyclic Graph (DAG) and applying Backward Critical Path Method (CPM) scheduling so every dish arrives at the table concurrently hot and synchronized at the exact requested serving moment.

🚀 What It Does

Landing Time is a voice-first kitchen mission control system built for Alexa+ and smart kitchen displays (Echo Show):

  1. Target-Driven Backward CPM Planning: The user simply speaks: "Alexa, plan dinner for 7:30 PM: roast chicken, crispy smashed potatoes, and sautéed asparagus with pan gravy." The engine analyzes durations and dependencies, verifies thermal compatibility (Oven Rule of 25), calculates the 70-minute makespan, and schedules the exact prep trigger at 6:20 PM.

  2. Live Coordinated Cockpit & Multi-Track Timeline: A high-visibility dashboard displays the single active directive for the cook's hands, circular SVG countdown timers, physical appliance state matrices (Oven + 4 Burners), and a live interactive Gantt timeline.

  3. Shock-Absorber Delay Recovery: When the cook reports that the chicken needs 12 more minutes in the oven, Landing Time doesn't let dinner slide 12 minutes late. It applies deterministic culinary recovery rules:

    • Compresses chicken rest from 15m to 10m (safe USDA moisture floor, recovering 5 minutes).
    • Holds crispy potatoes in a ventilated 170°F warming zone so moisture doesn't compromise crunchy starch lattices.
    • Shifts unstarted asparagus sauté by +7m so it finishes sizzling right as the bird finishes resting.
    • Dynamically reschedules dinner from 7:30 PM to 7:37 PM (absorbing 5 of the 12 delayed minutes) and displays comparison ghost tracks before the cook confirms.

  4. Dynamic AI Pantry Substitutions: When the cook is missing heavy cream, Google Gemini 2.5 Flash formulates a culinary chemistry substitution (whole milk + melted butter emulsion with a +2m simmer adjustment), absorbs the timing difference within the schedule float slack (0 min net landing drift), and automatically appends heavy cream to the persistent restock checklist.

  5. Synchronized Landing & Plating: All dishes finish within a tight 2-minute spread with hands-free plating checklists and audit history logs.

📐 The Mathematics: Backward Critical Path Scheduling

Landing Time models the kitchen as a Directed Acyclic Graph (G = (V, E)), where vertices (V) represent culinary tasks and directed edges (E) represent dependency precedence.

1. Forward Pass (Earliest Times & Makespan)

For each task (i) in topological order: $$ES_i = \max_{p \in \text{Pred}(i)} (EF_p) \quad \text{where } ES_{\text{root}} = 0$$ $$EF_i = ES_i + D_i$$ The total meal makespan (M) is the maximum earliest finish across all terminal tasks: $$M = \max_{t \in \text{Terminal}} (EF_t)$$

2. Backward Pass (Target Anchoring)

Given target serving time (T_{\text{serve}}), we compute the backward master start time: $$T_{\text{start}} = T_{\text{serve}} - M$$ Then compute Latest Finish ((LF)) and Latest Start ((LS)): $$LF_i = \begin{cases} M & \text{if } i \in \text{Terminal} \ \min_{s \in \text{Succ}(i)} (LS_s) & \text{otherwise} \end{cases}$$ $$LS_i = LF_i - D_i$$

3. Float Slack & Shock-Absorber Replanning

Total float determines schedule flexibility: $$\text{TF}_i = LS_i - ES_i$$

  • Critical Path: Tasks where (\text{TF}_i = 0). Delays immediately push the serving deadline unless absorbed.
  • Delay Absorption: When task (k) experiences delay (\Delta_k), the engine absorbs delay using resting window compression: $$D'{\text{rest}} = \max(D{\text{min_rest}}, \, D_{\text{rest}} - \Delta_k)$$ $$\text{Seconds Recovered} = D_{\text{rest}} - D'{\text{rest}}$$ $$\Delta{\text{net}} = \max(0, \, \Delta_k - \text{Seconds Recovered})$$ $$T'{\text{serve}} = T{\text{serve}} + \Delta_{\text{net}}$$

This deterministic math runs in 0.032 milliseconds for typical 10-node meals and under 1 millisecond for 500 nodes.

🛠 How We Built It

  • Kiro Crew Multi-Agent Development: We orchestrated the project using Kiro Crew, the qualifying AWS developer tool, establishing two specialized agent roles:
    • SchedulerArchitect: Specified and verified the CPM DAG math, Kahn's cycle detection, and shock-absorber invariants (.kiro/specs/landing-time-engine.spec.json).
    • McpProtocolSpecialist: Specified the Streamable HTTP transport and 2025-11-25 MCP tool schemas (.kiro/specs/mcp-streamable-transport.spec.json).
  • Self-Hosted Model Context Protocol (MCP) Server: Built with @modelcontextprotocol/sdk (spec version 2025-11-25) over Streamable HTTP on /mcp. Exposes 6 core tools (plan_meal, get_what_now, complete_step, report_delay, substitute, resume_plan) with SSE event streaming.
  • Local-First SQLite Engine: Powered by better-sqlite3 in Write-Ahead Logging (WAL) mode storing complete session graphs, proposal snapshots, and restock lists at data/landing_time.db.
  • Zero-Latency Execution: The critical path calculation runs with zero external LLM dependencies, guaranteeing instant sub-millisecond voice updates. Google Gemini 2.5 Flash is invoked asynchronously for unstructured recipe parsing and ingredient chemistry substitutions with safety rate limits (15 RPM) and 24h caching.
  • Hands-Free Frontend: React 19, Tailwind CSS, Motion animations, browser-native Web Speech API (webkitSpeechRecognition & speechSynthesis), and a docked Judge Demo Bar (?demo=true).

🧗 Challenges We Faced

  1. Modeling Cross-Dish Precedence in Isolated Recipes: Conventional recipe scrapers have no concept of inter-dish dependencies. We designed a unified recipe task graph schema where terminal drippings from poultry resting dynamically bind to gravy deglazing steps across dish boundaries.
  2. Deterministic Time Guarantee on Voice Hardware: Real cooks cannot wait 4 seconds for an LLM to generate text when checking if potatoes should enter the oven. We enforced a strict separation of concerns: deterministic operations research for all timing math (< 1ms) and generative AI exclusively for creative edge cases (substitutions).
  3. MCP Streamable HTTP in Express ESM: The 2025-11-25 MCP specification introduced Streamable HTTP to replace legacy stdio. Adapting the Node transport options inside Express required custom session UUID generators and SSE header handlers to comply with Alexa+ protocol contracts.

💡 What We Learned

  • Kiro Crew's Spec-Driven Methodology: Partitioning the codebase into explicit agent roles with verifiable requirements (REQ-001 to REQ-004) eliminated architectural drift and made extracting our open-source scheduling engine effortless.
  • Industrial Operations Research Belongs in the Kitchen: Critical Path Method algorithms developed in the 1950s for industrial engineering solve the everyday home kitchen coordination problem with mathematical precision.
  • Thorough Test Automation: Writing 83 automated unit, integration, and UI tests gave us complete confidence to refactor and optimize performance without breaking protocol compliance.

Built With

Share this project:

Updates

Submission history