The Living Force knows when something is broken. It does not know when something is wrong.
The difference: broken means the service is down, the port is closed, the health check fails. Wrong means the goodnight automation ran, the lights turned off, the dashboard says “all clear” — but the front door never locked. The family sleeps with an unlocked door. The watchdog saw nothing, because the watchdog checks L2 and the failure was L4.
An arxiv paper landed in March 2026 (2603.25697): a framework that had autonomously merged 1,094 pull requests across two production systems with zero regressions. Not code generation — specification-driven verification. AI agents exercising a product as power users at 1,000x human cadence, fixing what breaks, proving the fixes against ground truth the implementer cannot fake, and measuring drift so the system never gets worse. They called it the Kitchen Loop.
Reading it felt like finding the blueprint for the thing we’d been building by hand. Sanctum now has a checked-in Kitchen Loop surface: canonical spec and canary YAML, a tribunal model, a six-phase runner, pause gates, and an end-to-end harness proving both a healthy cycle and a forced canary escape. No longer a roadmap paragraph — an audited subsystem with a nightly LaunchAgent. The remaining work is expanding coverage, not inventing the mechanism.
The Kitchen Loop rests on four concepts. Each has a Sanctum analog, partial or absent.
1. Specification Surface
An enumerable matrix of everything the system claims to do. Not “we support Tuya lights” but “we support 55 Tuya lights across 12 rooms, each responding to 6 automation triggers, with cloud and local fallback paths.” Every cell in the matrix is a testable claim. Sanctum’s instance.yaml defines what runs. A spec surface defines what works.
2. As a User x1000
AI agents exercise the product as a power user would — systematically exhausting coverage, not closing tickets. Foundation tier (30%) validates happy paths. Composition tier (50%) tests feature combinations — the seams where individual passing tests coexist with combinatorial failures. Frontier tier (20%) deliberately attempts things out of scope to identify the next valuable capability.
3. Unbeatable Tests
Four-layer verification where each layer catches what the one below misses. L1: it compiles. L2: it runs. L3: the output parses. L4: the actual state changed correctly. The innovation is the integration mandate — passing L1-L3 means nothing if nobody attempted L4. Sanctum’s Living Force checks “is the service alive?” but not “did the user-visible action produce the correct end-to-end state change?”
4. Drift Control
Continuous quality measurement with automated pause gates. Not just “did this change break something?” but “are things getting worse over time?” Five gates: regression failure, canary escape, drift threshold, backpressure, and starvation. The system stops itself before humans need to.
The Living Force is not starting from zero. The core Kitchen Loop scaffolding is checked in and mechanically verified:
| Kitchen Loop | Sanctum Today | Gap |
|---|---|---|
| Regression Oracle | ~/.sanctum/scripts/run_kitchen_loop.py writes an oracle artifact every cycle | Coverage depth is still modest compared to the full haus surface. |
| Multi-Model Tribunal | Checked-in kitchenloop-tribunal.yaml defines proposer, challenger, grounding, blind opening rounds, and kill gates | The current tribunal is modeled and audited, not yet wired into every critical council workflow. |
| Pause Gates | Canary escape and pause behavior are mechanically proven in test-sanctum-kitchen-loop.sh | Drift, starvation, and backpressure are modeled, but their inputs are still synthetic in this workspace slice. |
| Spec Surface | sanctum-spec-surface.yaml defines dimensions, valid combinations, and declared scenarios | The current scenario set is credible, not exhaustive. |
| Self-Healing | Code Forge plus the six-phase loop now formalize a closed execution path | The loop currently writes proposals and tribunal records rather than patching live systems autonomously. |
| Night Deployment | kitchenloop.yaml encodes the 02:00-05:00 window; the com.sanctum.kitchen-loop LaunchAgent fires it nightly at 02:30 | Productized rollout beyond this Mini remains a later concern. |
The gap is no longer formalization — it’s breadth. The nervous system exists; it just needs more of the haus wired into it.
This is the highest-value integration point. Sanctum manages a sprawling matrix of devices, services, agents, and automations. Today we know they’re running; we don’t systematically verify they’re working together.
The spec surface expresses Sanctum’s claims as a testable matrix:
# sanctum-spec-surface.yaml — identifiers verbatim from the checked-in filedimensions: services: - home_assistant - sanctum_proxy - denchclaw_gateway - living_force_watchdog - council_mlx - force_flow - xtts
integrations: - tuya_cloud # 55 lights - ecobee_homekit # 4 sensors - ring_cameras # 4 cameras - sonos_bridge # 10 speakers - firewalla_api # Router control - alarmo # Alarm panel
actions: - turn_on - turn_off - set_value - trigger_automation - query_state - failover
failure_modes: - cloud_dropout # Tuya API goes away - bridge_down # bridge100 severed - container_restart # HA Docker restarts - agent_timeout # LLM provider slow - memory_divergence # Mem0 vs Vault mismatchCross-product: 7 services x 6 integrations x 6 actions x 5 failure modes = 1,260 testable claims (the count run_kitchen_loop.py plan reports today). Not all combinations are valid — Alarmo has no set_value for Tuya lights — but the matrix forces you to declare which cells matter and which don’t. The cells you skip are the ones that bite you at 4 AM.
The Living Force currently operates at L2 — services running and responding. The Kitchen Loop’s L4 verification checks that the actual state changed correctly:
| Layer | What It Checks | Sanctum Example |
|---|---|---|
| L1 Compile | Config is valid | instance.yaml parses, plist generates, manifests validate |
| L2 Execute | Service responds | Health endpoint returns 200, port is open |
| L3 Parse | Output is structured | HA API returns valid entity states, proxy returns valid JSON |
| L4 State Delta | Reality changed | ”Turn on living room lights” → Tuya API confirms state=on, HA entity updated, dashboard reflects change, memory logs event — all within 30 seconds |
L4 is where the March 22 bridge100 failure would have been caught before a human in his underwear. The watchdog said “all clear” because it was checking L2 (ports open) without checking L4 (can services actually reach each other).
Implementing L4 for Sanctum means:
The paper introduces a four-tier canary system that injects known-bad inputs to verify the quality gates catch them. It maps directly to Sanctum’s agent council:
| Tier | Definition | Sanctum Application |
|---|---|---|
| 1: Obviously Bad | Errors any gate should catch | Mundi recommends spending when budget is exceeded. Windu approves a firewall rule that opens all ports. |
| 2: Shadow | Stale or low-novelty data | Jocasta reports a CVE that was patched two weeks ago. Qui-Gon recommends restarting a service that was decommissioned. |
| 3: Adversarial | Real data, wrong conclusion | Cilghal correlates a temperature spike with HVAC failure when it was actually a sunny afternoon. |
| 4: Mixed | Partially correct | Tommy’s weather briefing has correct temperature but wrong precipitation forecast. |
Tiers 1-3 are checked in today as kitchenloop-canaries.yaml, each trap declaring its expected reviewer and verdict; Tier 4 (partially-correct) remains a paper concept we haven’t yet codified. Council Sessions already catch some of these through inter-agent debate — the canary file turns “caught it that one time” into a measurement that fires every cycle. A Tier 1 escape — an obviously bad recommendation making it through council — trips the pause gate and pages Force Flow. The paper achieved zero Tier 1 escapes across 163 iterations. That’s the target, and you only keep a number like that by checking it nightly.
The paper found debates between instances of the same model family converge to groupthink fast. Three heterogeneous models (Gemini, GPT/Codex, Claude) produced genuine perspective diversity. The Council took this to heart in April 2026: every routed seat runs a different model family by default, privacy-critical seats kept on the haus’s own hardware. The live assignment renders from src/data/council-roster.json (regenerated from ~/.openclaw/openclaw.json and ~/.sanctum/sanctum-proxy/config.yaml on the Mini) — no model name is pinned here, so a champion swap never silently rots this page:
| Agent | Logical model | Provider | Resolved model |
|---|---|---|---|
| Yoda | council-tiered/council-max-thinking | Claude Max bridge (local) | claude-fable-5 |
| Ki-Adi-Mundi | council-tiered/council-finance | Local | grok-4.5 |
| Qui-Gon | council-tiered/council-code | sanctum-mlx-devstral (local, mTLS) | Devstral-Small-2-24B-Instruct-2512-4bit |
| Windu | council-tiered/council-spacial | Local | gemini-3.1-pro-preview |
| Cilghal | council-tiered/council-heretic | Local | qwen3.6-27b-4bit-champion-ablated |
| Jocasta | council-crm | sanctum-mlx (local, mTLS) | qwen3.6-27b-4bit |
| Mon Mothma | council-brain | Claude Max bridge (local) | claude-opus-5 |
openclaw.json + sanctum-proxy/config.yaml at 2026-08-09T22:23:46Z. Every Jedi falls back to the
local Qwen tier if their primary path fails. Refresh via pnpm refresh:council.
See (Neuro)diversity is Paramount for the doctrine and The Smart Router for the routing-layer mechanics.
The Kitchen Loop’s tribunal pattern below remains the right escalation for critical decisions — architectural changes, security policy updates, deployment approvals — where you want adversarial roles (proposer / challenger / arbiter) on top of the already-heterogeneous default routing:
# kitchenloop-tribunal.yaml — checked intribunal: critical_decisions: consensus_required: 2_of_3 blind_opening_round: true # no participant sees another's open kill_gate: true # an explicit "do not build" must be argued participants: - model: claude-opus # primary reasoning role: proposer - model: gemini-pro # alternative perspective role: challenger - model: local-council # no cloud dependency role: groundingThe paper’s key finding: blind opening rounds eliminate first-speaker anchoring, explicit kill gates prevent universal-action bias. Both are already encoded above — the open work is wiring it into every critical council workflow, not designing it.
Sanctum’s four-layer memory system (Working → Mem0 → Memory Vault → Neo4j) is a drift risk the paper’s framework was designed to catch. Over time:
Kitchen Loop drift control applies here as five gates:
The Kitchen Loop runs a continuous six-phase cycle. Here’s how each phase maps to Sanctum:
┌─────────────────────────────────────────────────┐│ BACKLOG (15 min) ││ Evaluate spec surface coverage gaps. ││ Which Sanctum claims haven't been tested? │├─────────────────────────────────────────────────┤│ IDEATE (15-45 min) ││ Exercise a scenario as a real user would. ││ "Turn on all lights, arm the haus, check ││ cameras, trigger goodnight automation." ││ Document what breaks — structured experience ││ reports, not unit tests. │├─────────────────────────────────────────────────┤│ TRIAGE (5-10 min) ││ Convert findings to prioritized tickets. ││ Deduplicate against known issues. ││ Reopen tickets whose fixes didn't hold. │├─────────────────────────────────────────────────┤│ EXECUTE (30-60 min) ││ Fix top-N tickets in isolated worktrees. ││ Code-Forge skill handles implementation. ││ Night window constraints apply. │├─────────────────────────────────────────────────┤│ POLISH (10-90 min) ││ UAT gate: fresh evaluator with no context ││ verifies the fix from user perspective. ││ Tribunal review for critical changes. ││ Merge or route back as new ticket. │├─────────────────────────────────────────────────┤│ REGRESS (40-150 min) ││ Run regression oracle against full spec ││ surface. Measure drift. Update metrics. ││ Promote patterns to durable memory. ││ Pause if quality gates fail. │└─────────────────────────────────────────────────┘The REGRESS phase is where the Kitchen Loop diverges most from current Sanctum operations. Fire drills run monthly and test infrastructure resilience; the regression oracle runs every iteration and tests functional correctness — both necessary. Fire drills ask “can the system survive failure?” The oracle answers “does the system do what it claims?”
The current checked-in implementation lives in the audited workspace slice:
sanctum-spec-surface.yaml — dimensions, valid combinations, and declared scenarios.kitchenloop-canaries.yaml — Tier 1-3 traps with their expected reviewers and verdicts.kitchenloop-tribunal.yaml — proposer, challenger, grounding, blind rounds, and kill gates.run_kitchen_loop.py — writes backlog, ideate, triage, execute, polish, regress, and durable-memory artifacts into an isolated state directory.test-sanctum-kitchen-loop.sh — proves both the healthy cycle and the forced canary-escape path.sanctumctl kitchen-loop {validate|plan|run} — the operator surface, the same CLI as the rest of the audit.com.sanctum.kitchen-loop LaunchAgent fires ~/.sanctum/scripts/sanctum-kitchen-loop-nightly.sh once per night at 02:30 ET (inside the configured 02:00-05:00 night window per kitchenloop.yaml). State lands at ~/.sanctum/state/kitchen-loop/YYYY-MM-DD/ with a latest/ symlink; runs older than 30 days are pruned. Paused cycles (canary escape, regression failure, drift, backpressure, starvation) emit a critical Force Flow notify so the operator sees them in the morning briefing. Kill-switch is touch ~/.sanctum/state/kitchen-loop-disabled.What remains is expansion, not existence: deeper L4 state deltas, broader scenario coverage, tighter attachment to the live haushold runtime.
The Living Force was born from a failure at 4 AM. It built an immune system — reactive, dependency-aware, self-healing. The Kitchen Loop adds a nervous system — proactive, specification-driven, self-testing. The immune system asks “is something broken?” The nervous system asks “does everything work the way we promised?”
Together, they close the gap between “the service is running” and “the haus is actually doing what the family expects it to do.” Which is, if you think about it, the only question that matters.
github.com/0xagentkitchen/kitchenloop (MIT license)instance.yaml single source of truth