THE POD ANATOMY — pods all the way up

The pods principle (ML, 2026-07-20): every corner of the system is its own little self-sustaining pod — a function plus everything needed to gate it, measure it, detect its drift, diagnose it, improve it, and verify the improvement — managed by increasingly collective self-sustaining pods all the way up the chain. No orphan functions. No open loops. An open loop drains its missing work to the human; the design goal is a human who is informed always, required almost never. ↳ system/SYSTEM.md:39

The exploded pod — one generator, six closure functions

For any operating class X, X's loop is closed when six functions exist around it and none of them is a human. Two of the six are smart templates (diagnose, propose); four are dumb templates (gate, measure, detect, verify) instantiated per class from a shared library — arithmetic over the ledger. This is why the tower gets dumber going up, and why closure is cheap in compute even when it is expensive in headcount. ↳ system/corpus/LOOP-CLOSURE.md:7

1 GATE
Is this output acceptable?
Staffed by the operating layer: the generator's paired orienter IS the gate — dumb, binary, per-artifact (e.g. the beat writer's fact-checker and voice scanners).
script / DeepSeek-tier — as dumb as possible
2 MEASURE
Is quality a recomputable series over time?
Staffed by the monitoring layer: Quality-Meter (one per operating class) — Gate verdicts + outcome records → recomputable quality series per class. ↳ system/corpus/BLUEPRINT.md:110
script — arithmetic over the ledger
3 DRIFT-DETECT
Has it decayed vs the baseline frozen at last commit?
Staffed by the monitoring layer: Drift-Sentinel (one per operating class) — Alarms on declared threshold crossings vs the baseline frozen at last commit; heartbeats on silence. ↳ system/corpus/BLUEPRINT.md:111
script — threshold comparison; alarms, never judges
↻
THE GENERATOR
e.g. a beat writer — the function the pod exists to sustain. It proposes; everything around it gates, measures, watches, diagnoses, improves, and verifies. A worker is the durable unit: skill reference + one job + earned reference + wired channels.
generator GLM 5.2 / DeepSeek V4 Flash tier
↻
4 DIAGNOSE
Why does it fail — named component, with a reproduction?
Staffed by the improvement layer: Fault-Diagnoser (per incident) — Alarm → cause localized to a named component, with a reproduction that reproduces. ↳ system/corpus/BLUEPRINT.md:118
smart — GLM-tier, on-demand only
5 PROPOSE
What change would fix it — with a falsifiable predicted effect?
Staffed by the improvement layer: Change-Proposer (per diagnosis) — Diagnosis → candidate changes, each with exact edit, falsifiable predicted delta, pre-declared trial size/margin, rollback. ↳ system/corpus/BLUEPRINT.md:119
smart — GLM-tier, on-demand only
6 VERIFY
Did the change actually help?
Staffed by the improvement layer: Trial-Verifier (per trial, serialized per class) — Champion vs challenger on recorded outcomes; pre-registered or void; commits cross the commit boundary; indistinguishable-at-saturation on high-tier → DEADLOCK → ladder. ↳ system/corpus/BLUEPRINT.md:120
dumb — script; only counts, pre-registered or void

Also watching from outside the pod: the Verdict Spot-Checker (one per deployment) — Re-runs consequence-scaled samples of orienter verdicts; checks they reproduce — the judges get judged — by something strictly dumber than what it checks. ↳ system/corpus/BLUEPRINT.md:112

The ratio — what closure costs

Let N = operating classes, k = workers per class, r = fraction of classes with a live incident at any moment. Closure requires kN gates, 2N persistent meters+sentinels, 3rN on-demand improvement instances, plus a few per-deployment singletons:

M ≈ kN + (2+3r)N + 4  →  meta:operating ≈ 2:1

Meta is 60–70% of headcount, never below ≈1:1.

The v1 retrodiction — 90:30 = blind. The v1 prototype ran ~90 operating / ~30 meta — one sixth of what closure requires — and the shortfall landed exactly where the math predicts: gates and meters existed; sentinels, diagnosers, pre-registered verifiers, and efficacy metrics did not. Such a system is good at doing and at measuring success, and unable to know whether it is working, whether its self-optimization works, or whether it is coherent. That was the v1 diagnosis, observed in production.

Policy (ML, locked): design to 2:1; treat as fluid upward to 3–4:1 — whatever full closure costs. The ratio is headcount, not cost: the added staff are overwhelmingly scripts and cheap-model template instances, so cost stays operating-dominant regardless. ↳ system/corpus/LOOP-CLOSURE.md:36

Open loops drain to the human

A class missing any of the six functions has an open loop, and open loops drain to the human: whatever the missing function would have done becomes ML's work. This is the precise mechanism behind “the system needs constant babysitting” — it isn't temperament, it's un-staffed functions, and it is countable. The Loop-Closure-Auditor (SK-3) marks every loop CLOSED/OPEN against the six-function enumeration; unclosable loops escalate. ↳ system/corpus/LOOP-CLOSURE.md:21

Recursion — how pods nest

worker
one function, one job — the durable unit
⊂
pod
the function + its six closure functions
⊂
layer
operating / monitoring / improvement / self-knowledge / funnel — each itself watched (the layer sees everything, including itself)
⊂
organization
managed by increasingly collective pods; apex at the top, below every law

A pod ships whole — the commissioning rule: commissioning a worker without its closure functions is commissioning an open loop. Before any worker exists: reuse-check, fit diagnosis, a supporting-cast plan (its pod), and all four channels wired — an unwired worker is not commissioned. The meta-layers themselves are pods: the self-knowledge layer audits its own coverage by set arithmetic (Coverage-Reconciler, SK-17), and the Canary-Planter's planted answer key is where the who-watches-the-watchers regress terminates. ↳ system/corpus/LOOP-CLOSURE.md:26 ↳ system/corpus/COMMISSIONING.md:40