The Cookwala Protocol: Missions, Context and Swarm Coordination

Status: experimental profile. Not part of Cookwala Core. See CORE.md section 10 for what is normative today.

Status: architecture vision, draft 0.1 (2026-10-03). It builds on the existing Cookwala specs (recipes, sessions, advice, profiles, market, relief) and defines the layer that ties them together.

0. The idea in one paragraph #

A cooking robot shouldn't ask "give me a recipe". It should send a Mission: a signed, privacy-scoped, self-describing document that carries everything relevant to the request:

• who it is: health, firmware, patches, licenses, subscriptions, warranty, insurance, recalls, standing with its maker;
• what it's allowed to do: cook only, or also clean, fetch, open the door, serve; which rooms, stairs, hard NOs, when to ask a human;
• the world it's in: layout, appliances, other robots and devices, pets, kids, guests, workers, light, Wi-Fi, construction, schedules;
• who it serves and how: tastes, culture, rituals, health, medications, budget, shopping habits, feedback history;
• what it remembers: past incidents, conflicts, lessons.

Providers (AI planners, grocers, delivery, device makers, monitors, orchestrators) then pass the Mission along. Each one adds what it knows and signs what it did, until the document is "ready enough". The robot verifies it and executes the resulting living plan, writing progress, deviations and lessons back into the same document. It adapts like a good human cook, and better, when reality changes.

Multiplied across millions of kitchens, restaurants, factories and relief kitchens, and aggregated anonymously, those Missions become the world's most accurate signal of what food is actually needed, where and when. Farms, stores, logistics, cities, the WFP and the WHO can then produce, move and plan to near-exact need, with much less waste.

1. The core concept: the Mission document #

A Mission is to cooking what a container is to shipping: one standard box that any participant can handle without knowing what's inside the other compartments.

Mission
├── header        id, type, created, originator (robot DID), owner (DID), jurisdiction, spec version
├── intent        the goal in structured form + natural language ("dinner for 5 at 19:30, halal, low budget")
│                 + commander's intent: what matters most if the plan breaks
├── mandate       what the robot may do, where, with whom, escalation rules, hard NOs, caution level
├── context       facets: typed, sourced, timestamped, confidence-scored claims about self, household,
│                 space, devices, health, commerce, service, history (see §4)
├── credentials   verifiable proofs: robot identity, owner, subscriptions, warranties, licenses, insurance
├── routing       preferred providers / orchestrators, allowed hops, forwarding permissions, budgets, deadlines
├── contributions append-only: each provider's additions (plans, quotes, data, monitors), signed
├── readiness     the "definition of ready": what must be present and true before execution
├── plan          the living plan: tasks, contingencies, invariants, checkpoints, monitors (see §7)
├── execution     progress, telemetry pointers, deviations, decisions, human interactions
├── outcome       result, consumption, waste, feedback, lessons, incidents
└── ledger        hash-chained, multi-party signatures over every state change (see §5)

Properties:

Relation to existing Cookwala specs: a Mission wraps an AdviceRequest/Response, a Session, OrderIntents, TeamPlans and so on. They become typed contributions inside one envelope. Profiles become facets.

2. Design principles (how it survives the next 20 years of AI) #

1. Narrow waist. Like IP for the internet, the core is tiny and very stable: envelope, identity, signatures, facets, capability tokens, states and safety invariants. Everything else (facet types, plan formats, AI capabilities, provider types) lives above it as versioned, namespaced, negotiable extensions. The core changes rarely; the edges evolve daily.
2. Specify outcomes, not methods. Contracts state what must be true (postconditions, invariants, acceptance tests, food-safety limits), not how to achieve them. Smarter AIs can then find better methods without changing the standard.
3. Separate intelligence from safety. A small, verifiable safety kernel (rules, interlocks, invariants, CCPs, escalation) sits between any intelligence (local model, cloud AI, future superintelligence) and the physical world. Intelligence can be swapped freely; the kernel only gets stricter. This is aviation's envelope protection applied to kitchens.
4. Graduated autonomy. Explicit Cookwala Autonomy Levels (§13) tie what a robot may do unsupervised to verified competence, the way the SAE levels do for cars.
5. Semantic and AI-native. Facets have JSON-LD contexts and natural-language summaries. Interfaces are intent-based, not brittle RPCs. Agents negotiate capabilities.
6. Negotiation everywhere. Versions, profiles, facets, plan formats, payment terms, SLAs: parties declare what they support and agree, like TLS cipher or HTTP content negotiation.
7. Local-first, cloud-optional, offline-capable. Missions are created and executed at the edge. Providers are consulted when available, with graceful degradation to on-device reasoning and cached knowledge. There's a delay-tolerant mode for low connectivity (store-and-forward, SMS/USSD bridges, mesh).
8. Privacy by architecture. Raw household data stays home. Providers get minimum-necessary views, derived constraints, or zero-knowledge answers.
9. Decentralized by default. No central command is needed. Optional orchestrators are a service, not a dependency (§8, nature).
10. Everything learns, nothing forgets badly. Outcomes, incidents and lessons feed learning at three speeds (§9). The history is auditable, while personal data stays deletable (crypto-shredding).
11. Conformance by behavior. Implementations are judged by public test suites and benchmarks (CookBench), not by code, so any AI, robot or vendor can compete on quality.
12. Open and royalty-free, with neutral governance that can outlive any company.

3. Layered architecture #

 L6  Planet & public good   demand signals · supply/logistics/city planning · relief allocation · public-health insights
 L5  Learning               outcomes · incident "immunity" · playbook updates · federated & private aggregation
 L4  Plan & execution       mission plan (HTN / behavior trees) · contingencies · invariants · checkpoints · monitors
 L3  Coordination           routing: direct · chain · orchestrated · swarm · readiness convergence · negotiation
 L2  Context                facet registry · situational model · digital twin of the space · memory
 L1  Mission envelope       document structure · states · contributions · views · summaries
 L0  Trust                  DIDs · verifiable credentials · capability tokens · consent · signatures · ledger
 ─── cross-cutting ───      Safety kernel · Privacy · Security · Economics (metering, payment, SLAs) · Governance

4. The context model: facets #

Everything you listed, and much you didn't, is a facet: a typed claim about the world.

{
  "facet": "cw.facet.device.status",
  "subject": "appliance:fridge-1",
  "value": { "doorSeal": "leaking", "coldSpot": "shelf-2-left", "fillPct": 85 },
  "summary": "Fridge door seal leaks; shelf 2 left is colder; 85% full.",
  "source": { "kind": "robot_observation", "actor": "robot:neo-1", "evidence": ["frame:8812"] },
  "observedAt": "2026-10-03T17:40:00Z",
  "validFor": "P7D",
  "confidence": 0.8,
  "privacy": "household",
  "consent": ["owner"]
}

Every facet has the same anatomy: type, subject, value, NL summary, source (declared by the owner, observed by the robot, reported by a device, or inferred by AI), time, freshness (TTL), confidence, privacy class and consent. So any party can judge how much to trust it and whether it's still true. This is the pheromone-evaporation idea from §8.

4.1 Facet families (registry seed) #

You also mentioned the long tail: when to clean floors and dishes, interruptions, stove left on or turned off mid-cook, milk or cheese spoiled after sitting out. These aren't facets. They're policies and contingencies in the plan layer (§7) plus playbooks in the knowledge layer (already started in knowledge/playbooks.json).

4.2 Where facets come from #

• Declared by owners and household members in onboarding and over time.
• Observed by the robot, with evidence (frames, sensor logs) kept locally.
• Reported by devices and services (appliance status, recall feeds, delivery status).
• Inferred by AI, always marked inferred with confidence, never treated as fact for safety decisions.
• Expiring: every facet has freshness. Stale facets trigger re-observation instead of blind trust.

5. Trust: identity, authority, consent, ledger #

6. Privacy and minimum disclosure #

The context you described is the most intimate data a home has: layouts, schedules, when nobody's home, children, health and medications. In the wrong hands it's a burglary plan and a profiling tool. So:

• Views, not copies: each provider gets a computed view with only the facets its role needs, encrypted to its key. A grocer sees "deliver 2 kg halal chicken between 17:00 and 18:00 to the door; robot will receive". It never sees the family schedule.
• Derived constraints instead of raw data: "no robot movement in hallway 15:00–15:30" instead of "the kids come home at 15:00". "Avoid grapefruit" instead of the medication name.
• On-device answers for the most sensitive reasoning (health, medications, children). Providers can be asked zero-knowledge-style questions ("is ingredient X compatible with the household's constraints?" → yes/no).
• Privacy classes on every facet (public, household, sensitive, secret), enforced by the robot's disclosure engine. Children's data and security data (layouts, absences) default to secret.
• Anti-profiling rules: economic level, religion and culture are owner-declared preferences used only to serve the household. Providers must not use them for price discrimination or anything else (a conformance rule, audited).
• Aggregation with formal privacy (k-anonymity thresholds, differential privacy) before any data leaves the home for planet-scale signals (§10).

7. Plan and execution: a living plan with judgment #

7.1 Mission command #

Military doctrine learned long ago that detailed orders break on contact with reality, so you give the intent too ("feed the family a warm halal dinner by 19:30; safety first; budget matters"). The Mission plan carries:

• Intent: the goal and its priorities.
• Plan: a hierarchy of tasks (HTN / behavior tree):
  • environment prep (clear sink and range, wash and dry dishes, fetch pots, rice and oil, cutting board on the counter);
  • recipe execution (the Cookwala process graph);
  • serving (reminders, table setting, delivery to seats or rooms);
  • cleanup;
  • leftovers and storage.
• Constraints and invariants: things that must always hold (stove never left on unattended; CCPs met; no hot items within child reach; pet-toxic foods never left accessible).
• Contingencies: "if X then Y" policies attached to tasks or global (spill, drop, interruption, missing item, device failure, power or gas cut, spoilage).
• Freedom of action: what the robot may change on its own, and what needs asking.

7.2 Priority stack (applies at every decision) #

1. Human life and safety: choking, burns, fire, falls, medical emergencies, children.
2. Animal safety.
3. Food safety.
4. Property and equipment.
5. Mandate and household rules.
6. Mission goals: time, quality, cost, waste.

A higher priority preempts a lower one. A child crying near spilled hot liquid preempts the sauce.

7.3 Interrupts, checkpoints and resume #

• Every task declares whether it's pausable, its safe-pause state (heat to hold or off, lid on, knife down) and its resume conditions (food-safety timers: how long can it pause before the food must be discarded or re-heated?).
• An interruption (an owner calls the robot elsewhere, a kid needs help, the dog knocks something over) goes safe-pause → handle → re-plan → resume. If the resume window has expired, the robot runs a playbook: re-heat, salvage, discard, or switch dish.
• Stove watchdog: any heat source on with no active cooking task, or an unexpected off (outage, someone turned it off), triggers immediate reconciliation with the playbooks.
• Spoilage watch: perishables carry time-temperature budgets. Exceeding them (milk left out) triggers discard plus an inventory update and a reorder suggestion.

7.4 Monitors and multi-party execution #

Plans name monitors: a smart pot reporting temperature, a delivery provider reporting ETA, a remote AI watching the cooking from frames, a smoke detector, a family member's phone. The robot subscribes to them (Cookwala event bus) and writes their signals into the Mission. Fleets (restaurants, weddings, factories, relief kitchens) use the same model with more actors and leases (team_plan, contract-net).

7.5 Failure, salvage and switching #

Every plan declares:

• Retry policies per task: how many times, with what variation.
• Non-retryable conditions: food safety, human risk.
• Failure thresholds: when the mission counts as failed.
• Salvage paths: repurpose intermediates, swap the dish using what's available (recover, repurpose, cook_from).
• Escalation ladder: robot → household → orchestrator → maker support → emergency services.

The robot can also re-open the Mission (send an amendment) for new guidance, rather than start over.

7.6 Many opinions, one decision: assessments and reconciliation #

Providers (and groups of providers that share capabilities) don't just add facts. They add assessments: estimates and judgments with uncertainty, evidence, assumptions and method (mission.schema.json#/$defs/Assessment). Several can cover the same topic:

• energy the plan will take on this robot model with this battery health;
• duration;
• cost;
• whether a substitution is safe;
• whether milk has spoiled.

They may agree, refine or disagree, and every assessment records which one it responds to and why.

A reconciler (the robot by default, or a chosen agent, orchestrator, quorum or human) fuses them under per-topic reconcile rules:

• Strategies: conservative, calibration-weighted, evidence priority (measurement > historical stats > physics model > vendor spec > LLM judgment), Bayesian fusion, median, quorum, debate-then-decide, or ask a human.
• Safety bias: for feasibility and safety topics, decide on the cautious quantile (e.g. energy need at p90).
• Conflict detection: spread above a threshold triggers a rebuttal round. The reconciler asks the dissenting provider to re-estimate with the facets it missed, or asks the robot to measure, before deciding.
• Consequences: the result drives decisions. For example: battery need at p90 is 60%, but only 43% is usable above the 15% reserve, so dock for 25 minutes during the passive rice-steaming step. If the dock window slips, hand fluffing and plating to the parent or the other robot, then resume for serving. Other outcomes are "charge to full first" (if time allows), "notify the owner" or "change the dish".
• Learning: after the Mission, closure.calibration scores each assessment against the actual value (was it inside its interval? how large was the error?). Reconcilers weight providers by verified calibration, not by claims. Good estimators earn influence; bad ones lose it. This is the protocol's version of bees recruiting to the scouts whose dances proved right.

Worked example: examples/mission/home-dinner.json (as-1…as-3, rc-1, d-6, d-7).

8. Learning from nature: decentralized harmony #

Takeaway: orchestrators are allowed, but the system must work without them. With local rules (thresholds, quorum, stigmergic marks, evaporation, immunity) the swarm stays coherent, recovers from failures and keeps improving.

9. Learning at three speeds #

Learning uses federated learning and differential privacy where models are trained on household data. Every learned change still passes the safety kernel and CookBench before rollout.

10. Planet scale: from millions of Missions to near-exact supply #

1. Demand signals: each hub derives forward-looking ingredient demand from planned Missions (meal plans, standing orders, events). It aggregates and anonymizes it (k-anonymity, differential privacy, region/time buckets) and publishes it to opt-in demand exchanges that grocers, wholesalers, farms, logistics firms and city planners subscribe to.
2. Supply signals back: surplus, seasonality, prices, carbon and shortages flow back into planners. Recipes get demand-shaped toward what's abundant (a glut of tomatoes → more tomato dishes this week), which closes the loop.
3. Logistics: known delivery windows and volumes allow pooled routes and off-peak slots, and give cities visibility into traffic and curb use.
4. Packaging and waste: exact quantities, bulk and reusable container protocols, predictable waste pickup volumes.
5. Production planning: farms and processors plan planting and slaughter against real forward demand.

Caveat (nature again): a perfectly lean supply chain is fragile (just-in-time systems broke during the pandemic). The standard should help planners keep deliberate buffers and strategic reserves, sized from the same signals. Ecosystems that survive keep some redundancy.

11. Ending hunger and improving public health #

Built on the relief layer (relief.schema.json, MISSION.md) and HEALTH.md:

• Food organizations (e.g. WFP-style programs): Missions at kitchen scale, needs at program scale, pledges from anyone, allocation across kitchens. Robot kitchens add capacity; low-tech guided mode covers places without robots. Consumption-vs-waste ratios are measured per meal and published.
• Health organizations (e.g. WHO-style programs):
  • publish policy packs and flows (sodium reduction, fortification, diabetes-friendly menus, child nutrition), which hubs and kitchens adopt;
  • receive privacy-protected aggregate outcomes (dietary patterns, adherence, nutrient coverage) to plan campaigns;
  • extend the standard with their own facets, knowledge packs and reports.
• Low-resource settings: offline-first hubs, delay-tolerant sync, SMS/voice interfaces in local languages, solar and fuel-efficient methods, local-ingredient recipes (World Cuisines), and free tooling.
• Learning network: every relief kitchen's outcomes improve every other kitchen's plans, at machine speed, across borders.

12. What else must be covered (beyond your notes) #

13. Cookwala Autonomy Levels (trust that grows with evidence) #

Levels are per robot × household × mission type, recorded as credentials, and can be lowered automatically after incidents.

14. How this fits Cookwala today and what to build next #

Next concrete artifacts:

1. schemas/mission.schema.json: envelope, header, intent, mandate, facet, credential refs, routing, contribution, readiness, plan (HTN/BT nodes, invariants, contingencies, checkpoints, monitors), execution, outcome, ledger entry.
2. vocab/facets.json: the facet registry seed from §4.1 (≈150 facet types with privacy defaults).
3. schemas/capability-token.schema.json + ledger entry format (hash chain, signatures, anchoring).
4. Disclosure-engine spec: views per provider role, privacy classes, derived-constraint transforms.
5. Mission examples: home dinner with pets and kids; restaurant fleet; wedding; relief kitchen; school lunch boxes; all with interruptions and recoveries.
6. CookBench additions: interruption and resume, conflicting instructions, prompt-injection, pet/child safety, recall handling.
7. RFC-0001 "Mission envelope" for public comment.

14a. Related documents #

• Mission schema: mission.schema.json; worked example: examples/mission/home-dinner.json
• Decisions, commitments, budgets, degraded operation: DECISIONS.md
• Recipe format that plugs into Missions: RECIPE-FORMAT.md
• Prior art, parallels and novelty: PRIOR-ART.md

15. Decisions for you #

1. Ledger anchoring: a transparency log only (simpler, cheaper), or also anchor to a public blockchain for legal timestamping?
2. Default autonomy ceiling for the first release (recommended: CA2).
3. Demand exchange: run by cookwala.ai, by partners, or only as a protocol for others to operate?
4. Who to invite first to the steering group: one robot maker, one food bank or humanitarian program, one grocer, one privacy expert, one food-safety expert.