LOOP CLOSURE — The Pod Rule

Status: v2.0 — command-center authored. The rule that generates the meta-layers, the staffing ratio it implies, and the self-knowledge discipline that audits it.

1. The six functions

For any operating class X, X's loop is closed when six functions exist around it and none of them is a human:

A class missing any of the six 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 pod principle (ML): every corner of the system is its own self-sustaining pod — a function plus its six closure functions — managed by increasingly collective self-sustaining pods all the way up the chain. A pod ships whole: commissioning a worker without its closure functions is commissioning an open loop (corpus/COMMISSIONING.md).

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.

2. The ratio

Let N = operating classes, k = workers per class, r = fraction of classes with a live incident (diagnosis/proposal/trial) 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 60–70% of headcount), never below ≈1:1.

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.

3. Monitoring — memory and comparison

Gating is already staffed (the paired orienters ARE the gates). Monitoring adds what gates lack — memory over time:

• Quality-Meter (one per class): turns gate verdicts *and post-publication outcome records* into a recomputable time series. Any published score can be regenerated by a third party from ledger entries; no score without a ledger trail.
• Drift-Sentinel (one per class): compares the live series against the baseline frozen at the class's last commit; alarms on declared threshold crossings only. A sentinel that alarms on judgment fails; one that misses a crossed threshold fails. Silence is recorded (heartbeat), not assumed.
• Verdict Spot-Checker (one per deployment): the judges get judged — re-runs a consequence-scaled sample of any orienter's verdicts and checks they reproduce. Strictly dumber than what it checks: re-run-and-compare.
• The Ledger (substrate): the single append-only record of verdicts and outcomes every meter and sentinel computes over (specs/LEDGER.md). Workers communicate by verdicts through it, never shared memory. It is the termination point of the who-watches-the-watchers regress: the thing that cannot be argued with, only read.

4. Improvement — change with proof

When a sentinel alarms:

1. Fault-Diagnoser localizes the cause to a named component with a reproduction — running it exhibits the failure; holding the component fixed while varying others does not. Binary, executable, no appeal to plausibility.
2. Change-Proposer generates candidate changes, each carrying the exact edit, a predicted metric delta, a pre-declared trial sample size and win margin, and a rollback. A proposal that cannot lose is rejected unread.
3. Trial-Verifier runs champion against challenger on recorded outcomes. Sample size and margin were declared before the trial; a verdict whose margin was chosen after seeing results is void. On commit: new baseline to the sentinel; the paired orienter enforcing the old standard is **retired and replaced, never patched in place**. On reject: rollback executed. On statistical indistinguishability at saturation for a high-consequence change: DEADLOCK → the escalation ladder.

Only diagnosis and proposal are smart. Verification only counts. The improvement layer also executes organizational growth and apoptosis — through this same machinery.

No change to a directive, standard, or model assignment commits without passing this path. Hand-tuning is what v1 did; v2 measures.

5. Self-knowledge — the organization knows itself

A dedicated layer answers four questions no work-product metric answers: what is this organization (census, wiring), is its machinery functioning (loops firing, verdicts landing, capabilities still demonstrable), is it one system or a pile of features (duplication, orphans, contradictory standards, staleness, wiring drift), and is its self-account true (does the improvement layer actually improve anything).

Every class in the layer is built from four dumb primitives only — counting, set reconciliation, timestamp arithmetic, and known-answer probing — so a checker strictly dumber than the class can verify its output mechanically. The layer produces findings, never actions: nothing here retires, rewires, or repairs; every finding routes to the improvement layer's normal gated path. Observing without acting is what makes it safe to run wide and cheap.

Core classes (full specs in corpus/BLUEPRINT.md): census-keeper, wiring-mapper, loop-closure-auditor (marks every loop CLOSED/OPEN against the six-function enumeration), loop-pulse-checker (closed loops actually fire), verdict-uptake-auditor (verdicts land — every failing verdict gets an action record or a reasoned dismissal), capability ledger + prober (claims re-demonstrated by known-answer probes through the normal path), duplication-detector, orphan-detector, standards-consistency-checker, wiring-drift-auditor (declared vs observed), improvement-outcome-scorer + efficacy-tallier (every improvement commit scored HELPED / NEUTRAL / HURT at a fixed horizon — the difference between self-improvement and self-churn is these two workers), death-condition-auditor, staleness-watcher, condition-compiler (the layer's own compressed report), translation-reconciler (every ML input maps to exactly one committed verdict, reconciled by set arithmetic).

The regress terminator — canaries. The Canary-Planter plants synthetic faults, untagged, in the live record stream — a fake orphan, a duplicate signature, a stalled loop, a stale timestamp, a HURT improvement commit — and checks the corresponding detector flags each within its cycle. Detectors cannot tell canaries from real faults; an out-of-band exclusion registry filters them from findings post-hoc. A watcher that misses its canary is broken, whatever else it reports. The planted answer key is the dumbest possible test of a watcher, which is why the regress ends here. The Coverage-Reconciler then verifies by set arithmetic that the layer sees the whole organization and itself — every self-knowledge class is in the census, has a loop, and received a canary last cycle. Blind spots become findings.

6. Retirement — apoptosis

Every worker carries a declared, mechanically-evaluable death condition, audited dumbly (death-condition-auditor). Standard conditions: paired partner retired; exploration closed; output unconsumed for N review periods; standard-version superseded; mission decommissioned. Removing capacity is more dangerous than adding it — retirement demands stronger evidence than creation. Two exceptions are permanent by construction: silent-failure detectors are never retired on silence (a conservation auditor finding nothing is indistinguishable from being needed — retirement requires subject-completion, and any quiet-based cadence demotion must keep catching planted canaries), and the ledger dies only with the deployment.