Skip to main content

58  Readiness Gates, Residual Escrow, and Quarantine

58.1 Chapter status

Field	Value
Chapter ID	readiness-gates-residual-escrow-and-quarantine
Part	Part III - Routing, Compression, Representation, and Substrates
Status	conceptual
Manuscript maturity	v0.3 claim-proof program
Last updated	2026-07-26
Primary source records	21 assigned architecture, historical-project, self-improvement, and selective-prediction sources
Claim label	Design rationale
Evidence level	argument
Source queue	primary: rmi, benchmaxxing, scf; supporting includes the passage-reviewed RGS precursor plus architecture, historical-project, and external comparators; connector/recovery: moecot
Source loading state	source notes: rmi, rgs, deterministic_capability_compilation, benchmaxxing, scf, octopus_router, cognitive_loop_closure, moecot, project_theseus_whitepaper, theseus_architecture_gate, theseus_self_evolution_system, cca_project, moecot_manifest_project, beastbrain_project, bugbrain_project, corbens_trainer_project, corbens_best_model_possible_project, ext_darwin_godel_machine_2025, ext_dont_hallucinate_abstain_2024, ext_swe_rebench_v2_2026, precision_contract, regret_engine; raw cache: rmi, rgs, benchmaxxing, scf, octopus_router, cognitive_loop_closure; connector/recovery: moecot
Test state	Existing readiness fixture, Lean, residual-gate, and six-transition lifecycle probes remain. python3 scripts/validate_readiness_check_lifecycle.py additionally accepts one quarantined six-project lineage record and rejects nine mutations covering skipped-as-green, ready-with-failed checks, non-monotone containment, orphaned quarantine, waiver substitution, unknown applicability, pass without evidence, ordinary routing under quarantine, and fixture-based support promotion. It is record discipline only, not deployed quarantine or readiness evidence.

58.2 Drafting guardrail

The readiness-gate layer has exact reviewed mappings across all assigned sources. RGS is a same-author precursor to RMI, not independent corroboration, and the complete authenticated MoECOT connector text is passage-reviewed while runtime artifacts remain unimported. A bounded Project Theseus currentness import did rerun one pre-training architecture gate at exact commit d2343540a17ea3e12760983f653529621fa445f1; the result was YELLOW, with 12 wired, 2 implemented, 5 partial, and 1 frozen phase. That exact observation is implementation-reference currentness only, not model quality, deployment readiness, safety, transfer, or support promotion. The repository also proves finite predicates over authored readiness records; it has not implemented a deployed lifecycle engine.

After routing, readiness determines whether a semantically plausible route is allowed to become ordinary execution. The route can be correct as a match and still fail as a governed choice because evidence is stale, regressions are unresolved, scope is too broad, or residuals need quarantine.

Readiness is therefore an obligation state, not a score. A target is ready only for a scope, authority envelope, freshness window, workload family, and fallback path. Outside that envelope, the same target is unready until a new gate says otherwise.

58.3 Human Reading Path

Concrete lens. The badge baseline carries readiness across a minor version. The lease path binds evidence to the exact executable target and expires on change.

Routing can identify a plausible specialist, but plausibility is not readiness. The readiness gate asks when a route, model, tool, memory packet, procedure, runtime lane, or replacement is allowed to become ordinary execution and when it must stay in shadow, canary, escrow, quarantine, diagnostic use, or review. The gate is where evidence becomes permission, and where missing evidence becomes an explicit operating mode instead of a hidden exception.

Uncertainty should have somewhere to live. If a capability is promising but stale, narrow, risky, or partly unverified, the stack should not either trust it or discard it. It should keep the residual, expiry, fallback path, and next review condition visible until the evidence catches up. That makes improvement less dramatic but more durable: new capability can approach production without being treated as already safe.

Escrow is useful because it lets the system remember promise without spending it as permission.

The gate protects future adoption from present enthusiasm. Quarantine is how the system says maybe without surrendering rigor, memory, fallback, or review.

58.4 Problem

A specialist can be useful without being ready. It can pass a narrow benchmark and still hide residual failures. It can improve on the frontier and regress on the floor. It can be safe in canary and unsafe as default. The stack therefore needs lifecycle states that are stricter than “available” and richer than a single score.

Readiness is the bridge between routing and self-improvement. The router needs to know whether a specialist can be selected. Stable Capability Fields need to know whether an implementation can replace another. Benchmark ratchets need to know whether a result belongs to frontier exploration, regression preservation, or quarantine.

Readiness cannot be treated as a mood or leaderboard position. It is a lifecycle state with evidence, scope, residuals, monitors, and rollback. A candidate may be excellent for research, acceptable for canary, blocked from default, or quarantined after a regression. Those distinctions must be machine-readable before routing or replacement can be trusted.

Within the governed-cognition pattern, the readiness layer owns the routability delta. The shared record pattern becomes a lifecycle gate: a capability may keep its identity while its allowed routes change from draft to shadow, canary, default, diagnostic-only, quarantined, retired, or superseded. Other layers can record evidence and residuals; the readiness layer defines when those records are allowed to change ordinary use.

58.5 Why existing approaches are insufficient

A benchmark score alone cannot decide whether a specialist is ready or whether unresolved residuals are being hidden. Benchmaxxing treats benchmarks as temporary pressure surfaces, not permanent definitions of intelligence. RMI treats residual escrow as a visible tail of unsolved cases. SCF treats qualification as scoped, defeasible, expiring, and tied to a field boundary.

External governance, evaluation, routing, and assurance baselines sharpen that readiness standard. NIST AI RMF (ext_nist_ai_rmf_1_0_2023) and frontier-governance work (ext_frontier_ai_regulation_2023) separate risk framing, assessment, scrutiny, and monitoring; model-evaluation work for extreme risks (ext_model_evaluation_extreme_risks_2023) ties capability and alignment evaluations to deployment decisions; HELM (ext_helm_2022), BIG-bench (ext_bigbench_2022), Dynabench (ext_dynabench_2021), and contamination work (ext_benchmark_contamination_2023) show why benchmark state matters; routing baselines such as ext_expert_choice_routing_2022 and ext_hybrid_llm_2024 expose cost-quality routing pressure; TLA+ (ext_tla_plus_home_docs), PRISM (ext_prism_model_checker_2002), Black-Box Simplex (ext_black_box_simplex_2021), and Copilot (ext_copilot_runtime_monitor_2010) give assurance and monitor vocabulary. Readiness gates compose those pressures into lifecycle records, not an approved deployment result.

Without readiness gates, the architecture confuses motion with progress. A module can improve one visible metric while weakening a hidden invariant. Without residual escrow, promotion erases the cases that should shape the next frontier. Without quarantine, failed or stale modules remain routable through habit.

The missing primitive is a transition record. A lifecycle move should say what changed, which evidence justified the change, which residuals survived it, which regressions were checked, when the gate expires, and which routes are now allowed or blocked.

58.6 Core Claim

[readiness-gates-residual-escrow-and-quarantine.core, label: Design rationale, support: argument] For an exact versioned target, consumer, use, workload family, authority and rights envelope, and evaluation horizon, readiness should issue an expiring routability lease only from independently owned gate evidence, complete per-check state, preserved regression floors, inherited residual custody, allowed and blocked routes, monitoring, rollback and fallback obligations, and review triggers; failed, stale, waived, quarantined, superseded, retired, or lineage-invalidated targets cannot enter ordinary use, and split, merge, retrain, replace, rollback, and retirement transitions must preserve affected descendants, artifacts, effects, and residual owners.

Reader claim. Readiness is an expiring permission for one target and use, not a permanent badge attached to a model name.

Operational rule. Bind every lease to exact version, consumer, workload, authority, gates, regression floors, residuals, allowed routes, monitoring, fallback, rollback, and expiry. Any target change or stale gate blocks ordinary use until rerun; quarantine always carries a working fallback and residual owner.

58.6.1 Worked stale gate: the model changed after qualification

Model version v7 passes its required gates for a read-only coding workload and receives a bounded ordinary-use lease. A tokenizer patch produces version v7.1 without changing the marketing name. The prior functional score still looks relevant, but the target identity and some downstream artifacts changed. Reusing the old lease would detach evidence from the executable target, so v7.1 enters diagnostic-only quarantine until affected gates and regression floors rerun.

The fallback returns traffic to v7; the residual escrow names the tokenizer change, dependent caches, unrerun checks, and owners. If v7.1 later qualifies, it receives a new expiring lease rather than inheriting the old badge. The finite lifecycle rejects stale-gate reuse, ordinary routing from quarantine, missing regression floors, unsupported supersession, and retirement without receipts. These checks preserve readiness state; they do not establish gate adequacy, evaluator independence, natural-workload safety, monitoring efficacy, or deployment merit.

The claim remains at argument support. The assigned sources support the design vocabulary of benchmark lifecycle, residual escrow, lifecycle state, readiness gates, and route validity, but no particular module is claimed to currently pass those gates.

58.6.2 Claim-source mapping status

Appendix C maps this readiness-gate claim to every assigned source. Those mappings support promotion gates, check lifecycle, residual escrow, quarantine, regression-floor preservation, transitive invalidation, archive selection, and selective-prediction calibration, not current readiness of any specific module. The moecot whitepaper connector text is passage-reviewed; the pinned moecot_manifest_project note is local-project architecture context, not runtime reproduction.

Source	What it supports	Review state	Limit
rmi	Mastery thresholds, critical-failure vetoes, residual escrow, benchmark diagnosis, regression preservation, specialist lifecycle, add/split/merge/retire decisions, quarantine, and frontier/floor separation.	passage-reviewed local raw cache	No readiness engine, benchmark run, residual ledger, or prototype inspection exists here.
benchmaxxing	Benchmark lifecycle states, wall diagnosis, benchmark/model ledgers, residual preservation, anti-Goodhart safeguards, contamination checks, transfer checks, and architecture-change discipline.	passage-reviewed local raw cache	No benchmark harness, mutation, holdout, empirical run, or local model/prototype result was produced.
scf	Stable capability fields, implementation identity, append-only evidence registry, scoped/defeasible/expiring qualification, route validation, lifecycle events, incidents, appeals, rollback, and authority ceilings.	passage-reviewed local raw cache	Does not prove production safety, global alignment, evaluator quality, or current reversibility.
octopus_router	Arm cards, local benchmarks, residuals, permission envelopes, domain quarantine, split/merge/retire policies, routing metrics, and arm lifecycle governance.	passage-reviewed local raw cache	No routed-specialist prototype, routing benchmark, quarantine harness, or learned-router evaluation has been run.
cognitive_loop_closure	Verification grades, risk/runtime tiers, monitoring plans, stale-tool retirement, revision discipline, and warnings against premature closure or unsafe automation.	passage-reviewed local raw cache	No local loop-detection, tool-synthesis, monitoring, or retirement automation was executed.
moecot	Readiness gates, benchmark artifacts, promotion blockers, residual tracking, replay, handoff, fail-closed ledgers, and explicit current limitations.	authenticated connector text passage-reviewed	Runtime readiness artifacts, code, logs, benchmark records, and replay records have not been inspected or reproduced.
project_theseus_whitepaper	Residual escrow, benchmark floors, frontier/diagnostic/regression/public-calibration/retired benchmark states, specialist lifecycle, safety-visible gates, and report-first implementation discipline.	passage-reviewed local public-project source	Current machine-readable reports and benchmark ledgers were not rerun or verified from this repo.
theseus_architecture_gate	Pre-training checks for ratchet completeness, router readiness, safety ledger, regression suite, public calibration, residual escrow, bridge benchmarks, procedural tools, routing memory, lifecycle governance, external-inference zero, and the imported static architecture-gate summary verified by ASI-side digest.	passage-reviewed local public-project source plus static import fixture	The reported green snapshot is represented only by the digest-verified fixture in docs/theseus_report_import_slice.md; no clean live Theseus command, current dashboard, or benchmark environment was rerun here.
theseus_self_evolution_system	Intervention ladders, ATTD repo-health gates, guarded teacher edits, architecture experiment governance, outcome ledgers, lifecycle-governed cells, and loop closure into local tools.	passage-reviewed local public-project source	No Theseus scripts, ATTD reports, branch flow, teacher runner, outcome ledger, dashboard endpoint, or autonomous-improvement result was executed.
cca_project	Promotion states, quarantine, rollback, contamination controls, canonical closure authority, and fail-closed benchmark truth contracts.	public-safe pinned-project note	Project training, benchmark, quarantine, and promotion artifacts were not replayed.
moecot_manifest_project	Promotion locality, immutable evidence identities, residuals, replay, holdout separation, fail-closed gates, and growth stops.	public-safe pinned-project note	Promotion, holdout, deployment, and readiness behavior was not rerun.
beastbrain_project	Negative case where interfaces, simulations, feature counts, and checklists coexisted with open compiler, integration, hardware, security, and benchmark gates.	public-safe pinned-project note	Does not establish production readiness, capability, secure autonomy, or live quarantine.
bugbrain_project	Exact skipped-as-green case and the applicability/requiredness/attempt/result/waiver/evidence lifecycle recommendation.	public-safe pinned-project note	Historical reports and current code differ; hardware, bridge, training, and deployment behavior was not reproduced.
corbens_trainer_project	Transitive quarantine and promotion-lease invalidation where a promoted label survived later quarantine of every contributing run.	public-safe pinned-project note	Training, external benchmarks, and end-to-end capability were not reproduced.
corbens_best_model_possible_project	Quarantine, rollback, fallback, and material-postcondition boundaries; named transitions and interfaces may lack durable effect.	public-safe pinned-project note	Does not establish target readiness, autonomous routing, durable transitions, or promotion quality.
ext_darwin_godel_machine_2025	Archive-based self-modifying candidates, compile/edit eligibility, benchmark selection, branching lineage, sandbox limits, and rollback-oriented auditability.	passage-reviewed external comparator	Reported benchmark gains and archive benefits do not establish readiness, monotonic safety, local reproduction, or promotion authority.
ext_dont_hallucinate_abstain_2024	Selective-prediction coverage, calibration, multi-model probing, shared blind spots, and over-refusal risk.	passage-reviewed external comparator	The reported models and collaboration schemes were not reproduced; abstention is not automatic utility or readiness.

58.7 Draft Key Figure: Readiness, Residual, Quarantine Map

Figure 58.1: Draft readiness residual quarantine map.

How to read the readiness-residual figure: Read the figure as a route-permission map, not as a claim that a deployed readiness engine exists. A candidate route, tool, specialist, memory packet, runtime lane, or replacement proposal enters a readiness gate record with field identity, workload scope, fresh evidence, expiry, authority, allowed routes, fallback, rollback path, residual escrow, non-claims, review refs, and next review trigger.

If the envelope is adequate, the target may move to limited allowed use such as shadow, canary, qualified, or default within that envelope. If uncertainty remains, residual escrow preserves inherited failures, blocked obligations, owners, and review conditions. If evidence is missing, expired, authority-mismatched, or hides residuals, quarantine blocks ordinary routing while preserving diagnostic replay only with a visible fallback.

Renaming, wrapping, splitting, merging, retraining, or retiring a target cannot erase failed gates or inherited residuals. The figure is a draft reader aid, not proof of readiness-engine behavior, residual-ledger storage, quarantine enforcement, safety, benchmark performance, support-state movement, or release approval.

58.8 Mechanism

Readiness is the router’s memory of what has earned ordinary use. RMI supplies residual escrow and specialist lifecycle pressure; Benchmaxxing supplies benchmark lifecycle and anti-Goodhart caution; SCF supplies scoped, defeasible, expiring qualification; Octopus Router supplies arm cards and quarantine; Theseus supplies architecture gates and evidence-first self-evolution boundaries. Together they make readiness a governed state, not an informal confidence score.

The readiness gate changes routability, not identity. A specialist can remain the same registered capability while moving from draft to shadow, canary, qualified, default, quarantined, retired, or diagnostic-only. The router consumes a current route permission, while SCF-style qualification preserves the longer-lived capability boundary and its evidence history.

A Readiness Gate Record attaches that state to every module, specialist, tool, field implementation, or runtime lane that can be routed to or promoted. It does not say the target is globally safe or permanently qualified. It says what field identity is involved, what workload family and freshness window apply, what evidence was checked, what residuals survived or were inherited, what routes are allowed or blocked, what state transition is requested, when the gate expires, and what should happen if the gate fails.

A readiness record keeps frontier pressure and floor preservation separate. Frontier evidence says what the target newly handles. Floor evidence says what it must not forget. Residual escrow names the tail that is still outside both.

Within the Developmental Intelligence Loop, this chapter owns the readiness review after quiescent stabilization. It receives one exact candidate together with its curriculum, interaction, prediction, intervention, consolidation, proceduralization, composition, forgetting, regression, stability, cost, and residual records. It may qualify, narrow, quarantine, or retire that candidate; it may not reinterpret training completion as capability or perform the separate authority-gated promotion. This keeps the developmental loop from collapsing production, evaluation, and permission into one self-approving stage.

Readiness also consumes the bounded-liveness obligation from the Security Kernel. Quarantine is a protective routing state, not a terminal answer by itself: each quarantined target needs a custodian, an allowed diagnostic envelope, a review deadline, an ageing signal, and a finite repair, narrow, retain-for-analysis, supersede, or retire route. The gate reports useful throughput, unsafe release, false blocking, latency, human review, compute, recovery, and residual burden on one ledger. Operations takes custody only after a released service enters an incident; it cannot retroactively turn an expired or ownerless readiness lease into permission.

The complete operational lifecycle has eighteen stages:

1. Bind the exact target, field, owner, consumer, use, workload, risk, authority, rights, environment, horizon, and fallback duty.
2. Freeze the readiness policy and per-check catalog before outcome inspection.
3. Collect source, proof, benchmark, canary, runtime, incident, human-review, and reproduction evidence through their existing owners.
4. Validate provenance, freshness, independence, evaluator adequacy, contamination, coverage, uncertainty, and missingness.
5. Keep regression floors, frontier gains, vetoes, calibration, load, cost, and delayed outcomes as separate gate dimensions.
6. Import every open and inherited residual with owner, scope, descendants, artifacts, effects, closure evidence, and next review.
7. Estimate a consumer- and use-specific readiness vector, not one score.
8. Apply prospectively fixed decision and abstention rules to choose a state.
9. Issue an expiring qualification and routability lease.
10. Exercise shadow and canary use through existing execution owners.
11. Retain denials, interventions, effects, counterfactuals, costs, and delayed outcomes through the monitoring window.
12. Quarantine failed, stale, compromised, ambiguous, or invalidated targets.
13. Promote, demote, narrow, widen, rerun, or reject through a new versioned decision with explicit evidence and residual deltas.
14. Propagate qualification and quarantine through dependencies, descendants, routes, caches, artifacts, memories, procedures, and effects.
15. Map predecessor evidence and residuals across split, merge, retrain, replacement, or wrapper changes.
16. Invoke rollback, compensation, route withdrawal, artifact recall, or descendant invalidation through their existing owners.
17. Retire or supersede with terminal receipts, successor or fallback ownership, artifact/effect disposition, and residual custody.
18. Replay the complete decision and compare policies in matched natural and adversarial campaigns with causal ablation, reproduction, and transfer.

flowchart LR
  A["Module or specialist"] --> B["Gate evidence"]
  B --> C["Regression suite"]
  C --> D["Residual escrow"]
  D --> E["Authority and scope check"]
  E --> F{"Promotion allowed?"}
  F -- "yes" --> G["Shadow / canary / qualified / default"]
  F -- "no" --> H["Quarantine / revise / split / retire"]
  G --> I["Lifecycle ledger"]
  H --> I
  I --> J["Monitor window"]
  J --> K["Requalification trigger"]

Reading the readiness gate: The gate changes routability without changing the underlying capability identity. Evidence, regressions, residual escrow, authority, scope, lifecycle state, monitoring, and requalification all have to line up before a module becomes ordinary route material.

Those inputs answer different questions and should not be collapsed into one readiness score. Gate evidence asks what was actually checked. Regression preservation asks what must remain true after change. Residual escrow asks what is still unresolved and who must carry it. A target can improve on new work while failing its old floor, or pass every measured case while a required check was never attempted. The lifecycle must preserve both distinctions before it changes routability.

58.8.1 Learning eligibility is not readiness

The Regret Engine source (regret_engine) inserts one additional separation before this gate. An incident packet may be severe enough for immediate containment, causally linked enough to justify investigation, and still too uncertain for direct learning or ordinary use. Its learning-eligibility matrix therefore routes high-severity/high-confidence defects toward bounded repair, high-severity/ low-confidence cases toward mitigation and evidence escrow, recurrent low-severity defects toward efficient compilation, and low-confidence minor cases toward monitoring or retirement.

Even a learning-eligible repair does not become ready. It arrives with packet clusters, protected capabilities and surplus cases, uncertainty, update-lease scope, tests, monitor window, rollback, and residuals. Readiness alone maps those artifacts into observe-only, shadow, advisory, constrained, residual, canary, qualified, fallback, or quarantine modes. The candidate cannot choose its comparator set, adjudicate its own packet, or promote itself. These are design constraints, not calibrated thresholds or evidence of effective promotion.

The Qualified Competence Envelope from Assurance-Shift Learning (assurance_shift_learning) is one such scoped input. It binds capability version, operating region, natural and probe distributions, evaluator set, time window, coverage, observability, residual risk, known exceptions, and invalidation triggers. Because every field is relative, the envelope can support a narrow route decision without asserting global competence.

Three decisions remain separate: an exception may be informative enough to study, a repair may be eligible to learn from it, and a repaired candidate may be ready for a particular use. None implies the next. Readiness must still apply regression floors, residual escrow, authority, scope, monitoring, rollback, and requalification. The paper proposes this separation but supplies no calibrated threshold or deployment permission.

58.8.2 Check lifecycle and monotone containment

A gate-level state is too coarse unless each contributing check exposes how it reached that state. Every check therefore records applicability, requiredness, attempt, result, waiver, evidence identity, observation time, and expiry. These fields prevent three attractive substitutions: not applicable for not attempted, skipped for passed, and waived for satisfied. A required applicable check can support readiness only when it was attempted, passed, and carries fresh evidence. Unknown applicability is itself a blocker until resolved.

BugBrain supplies the sharpest local negative case: retained green reports counted missing artifact manifests as skipped successes. Corben’s Trainer supplies the downstream failure: claim and candidate records survived after all contributing evidence runs were quarantined. Together they imply that readiness is not merely a row of checks. It is a dependency-sensitive lease. When a required check fails or an upstream artifact becomes stale, quarantined, revoked, or unknown, the promotion lease invalidates and containment must stay the same or tighten.

flowchart LR
  A["Check applicability"] --> B{"Required?"}
  B -- "no / not applicable" --> C["Explicit not-applicable record"]
  B -- "yes" --> D["Attempt + result"]
  D --> E["Evidence identity + observed time + expiry"]
  E --> F{"Fresh passing evidence?"}
  F -- "yes" --> G["Contribute to scoped readiness"]
  F -- "no" --> H["Block or quarantine"]
  H --> I["Owner + affected descendants + disposition"]
  I --> J["Same or tighter route set"]

Reading the check lifecycle: readiness is allowed to strengthen only through fresh passing evidence or narrower scope. Failure, missingness, waiver, expiry, or upstream invalidation routes to a named quarantine closure and cannot add ordinary routes.

The strongest objection is that a detailed lifecycle can still validate the wrong checks. That is correct. Completeness of check metadata does not establish benchmark adequacy, evaluator independence, or real enforcement. The lifecycle is a truthfulness boundary: it stops missing, stale, waived, or quarantined evidence from being mislabeled as green while leaving check quality and deployed containment as explicit residuals.

The earlier deterministic lifecycle probe remains part of that boundary rather than being superseded by the six-project contract. Its recorded result at experiments/readiness_lifecycle_probe/results/2026-07-02-local.json contains six valid synthetic readiness lifecycle transitions plus twelve expected-invalid controls. The newer check-lifecycle fixture narrows a different seam: whether each contributing check can be truthfully promoted and whether dependency invalidation forces monotone containment. Neither synthetic trace demonstrates a deployed readiness engine, live router enforcement, or current module readiness.

Readiness has three inputs. Gate evidence names the source notes, test records, benchmark results, proof artifacts, review records, or operator reports that are allowed to bear on the decision. Regression preservation protects a floor that should not be lost while the frontier moves. Residual escrow keeps named failures, edge cases, uncertainties, and blocked obligations attached to the target even when some narrower promotion is allowed.

Quarantine is not deletion. It is a routing state. A quarantined module can remain available for diagnosis, replay, repair, or restricted review while ordinary routes are blocked. This distinction is what lets the architecture learn from failures without letting failures remain live in the control path.

Residual escrow is not an unstructured backlog or a reputation marker. It is the mechanism that prevents unresolved cases from being laundered away during promotion, merge, split, retirement, or retraining. A residual can be accepted as bounded only when its scope, trigger, owner, and next review condition are named. Inherited residuals are especially important: a renamed, wrapped, split, or merged target must carry old residuals forward unless a separate record retires them.

58.8.3 Residual escrow is an active lifecycle, not a graveyard

Ratcheting Generative Systems gives escrow three legitimate exits. A residual can be reattempted and, after consistent solution under the relevant contract, become a regression item. A recurring cluster can cross a prospectively named recurrence rule and become an active diagnostic or frontier candidate. Or an instrument audit can show that the item is ambiguous, noisy, mislabeled, unsolvable, or otherwise defective, in which case the benchmark item is repaired or retired while its audit history remains visible. Mere age, owner fatigue, a renamed target, or a higher aggregate score is not an exit.

The escrow record therefore needs more than a description of “what remains.” It binds source instrument and run, affected obligation and consumers, failure type and cluster, severity and criticality, evidence, recurrence count and window, reattempt policy, next trigger, current disposition, descendants, owner, review budget, and closure receipt. Reattempts preserve selection lineage so repeated favorable sampling cannot manufacture consistent solution. Recurrence promotion is also claim-scoped: similar surface errors become one cluster only when the evaluator can defend the shared mechanism or obligation.

Escrow receives a protected share of evaluation and review capacity, but the paper’s illustrative frontier/regression/escrow/public-calibration percentages are not defaults. A fixed share can starve a severe tail, reward creation of cheap residuals, or keep an obsolete backlog alive. The budget policy instead responds to severity, critical vetoes, recurrence, uncertainty, information value, consumer exposure, review capacity, frontier opportunity cost, and time-to-expiry. Critical residuals can block routes regardless of allocation; ordinary low-value residuals can remain preserved without dominating the frontier. The governing tension is persistent pressure without either tail erasure or tail obsession.

58.8.4 Runtime modes and residual custody

Deterministic Capability Compilation proposes exact, compiled, shadow, residual, canary, fallback, and quarantine modes as explicit readiness states. A field can be exact on one subdomain, compiled on another, and residualized or blocked elsewhere; one average score cannot erase that partition. Each mode binds applicability, authority, verifier coverage, counterexamples, monitoring, fallback, update lease, expiry, and recovery.

Residual escrow holds uncovered obligations, unexplained improvements, specification disputes, shield exceptions, transfer gaps, verifier unknowns, and irreversible effects. Residual learning may operate only under a bounded policy-update lease and independent shield. Promotion is blocked when the residual dominates the base behavior, the verifier cannot distinguish a material defect, or the fallback and rollback paths have not been exercised.

58.8.5 Precision certificates, expiry, and readmission

A precision-transformed artifact enters readiness through a scoped PrecisionCertificate. The certificate names the source and transformed artifacts, decoder, kernels, runtime, platform, contract, protected slices, evaluation, physical-cost ledger, residual planes, router, fallback, evidence window, and non-claims. Its existence is evidence that a qualification packet was assembled; it is not evidence that the packet was correct or that deployment is authorized.

Precision status	Readiness meaning
CERTIFIED	Every mandatory clause passed using the required evidence class inside the named scope.
PROVISIONAL	Empirical clauses passed, but a required formal, platform, or drift condition is incomplete.
DOMAIN_RESTRICTED	The artifact is admitted only inside a named operating envelope and must escalate outside it.
UNSAT	At least one mandatory or no-tradeoff clause failed.
UNVERIFIED	Evidence is absent, stale, or bound to a different exact artifact or environment.
REVOKED	Later evidence, drift, or implementation change invalidated an earlier status.

These words are machine states with predicates and transitions, not marketing adjectives. CERTIFIED without the contract, domain, evidence class, and validity window is an invalid rendering of the record.

Readiness rejects certificate laundering across a changed model, decoder, kernel, hardware target, runtime, domain, evaluator, threshold, routing policy, or consumer. Drift can narrow the artifact to a residual-only or shadow route, quarantine it, or expire it completely. Revocation propagates to cached decisions, copies, descendants, and deployments that cite the certificate.

Readmission requires the failed or changed predicates to be re-evaluated and the reference fallback to remain reachable. A residual plane that repairs one slice cannot erase a different failure, and an average-quality recovery cannot retire a protected-tail residual. Certificate history stays append-only so the system can explain which deployment relied on which precision policy at the time.

58.9 Interfaces

Readiness decisions pass through the Readiness Gate Record.

The ownership boundary has twelve consumers and producers:

1. Stable Capability Fields owns capability identity and substitution.
2. Routing consumes route permissions but cannot promote or widen them.
3. Benchmark Ratchets and evaluators produce floor, frontier, calibration, and transfer evidence but do not authorize use.
4. Claim Ledgers, Evidence Engineering, and Artifact Graphs own support and lineage; readiness does not promote a book claim.
5. Runtime Adapters, Humans, and Inter-Stack protocols own dispatch and effects.
6. Security, Privacy, Rights, Legal, and Constitutional owners supply ceilings and vetoes.
7. Capability Replacement and Rollback owns restoration, compensation, invalidation, and successor transactions.
8. Procedural Memory, Data Engines, and Learning owners preserve mutable-state lineage whose changes expire qualification.
9. Resource Economics owns capacity, latency, money, compute, human burden, and total-cost policy.
10. Human Collaboration and Tribunal owners supply qualified review, appeal, dispute, override, and residual-custody decisions.
11. Personal Compute Hives and runtime crosswalks supply node and implementation currentness, not readiness by reachability or branding.
12. Release and Publication consume readiness and support as separate inputs and retain independent deployment and public-release authority.

Minimum fields:

• gate_id
• target_id
• target_kind
• field_id
• current_state
• candidate_state
• workload_family
• freshness_window
• evidence_state
• gate_evidence
• floor_evidence
• frontier_evidence
• regression_results
• residual_escrow
• inherited_residuals
• authority_scope
• promotion_blockers
• quarantine_conditions
• allowed_routes
• blocked_routes
• diagnostic_permissions
• fallback_path
• expiry
• decision
• closure_conditions
• review_refs
• next_review_trigger
• non_claims

Routing reads current_state, authority_scope, allowed_routes, blocked_routes, and promotion_blockers. Benchmark ratchets update gate_evidence, regression_results, and residual_escrow. SCF replacement transactions use the record as part of qualification and rollback. Artifact graphs preserve the ledger references so future decisions can distinguish “not tested” from “tested and failed” from “tested in a narrower context.”

The public schema now separates evidence state, floor evidence, frontier evidence, diagnostic permissions, and closure conditions. This keeps canary or diagnostic permission from becoming ordinary route permission and keeps stale or source-reported evidence from being confused with reproduced readiness.

The lifecycle states should be explicit enough for routers and auditors to consume: draft, shadow, canary, qualified, default, diagnostic-only, quarantined, retired, and superseded. The exact names can vary, but ordinary execution must not depend on prose interpretation of a benchmark note.

58.10 Invariants

1. Every decision binds exact target, field, owner, consumer, use, workload, policy, gate, evaluator, evidence, model, tool, environment, authority, rights, cost, and time versions.
2. Capability identity, implementation identity, readiness, route permission, claim support, deployment approval, and public release remain separate.
3. Every required check records applicability, attempt, result, evidence, evaluator, time, expiry, and invalidators; unknown, skipped, waived, unattempted, or expired is never pass.
4. A waiver records who accepted which risk for which scope and time; it cannot substitute for evidence required by a stronger state.
5. Veto, authority, rights, privacy, security, rollback, and residual-custody failures cannot be averaged away.
6. Frontier gain cannot erase floors, failed cases, negative controls, calibration error, unsafe releases, or delayed harm.
7. Readiness is consumer-, use-, workload-, authority-, environment-, and time-specific, never global or permanent.
8. Every stronger state adds fresh evidence or narrows scope; it never gains routes by losing records, renaming the target, or changing denominators.
9. Every residual retains owner, severity, affected scope, descendants, artifacts, effects, closure condition, and next review.
10. Quarantine blocks ordinary routing and permits only explicit diagnostic routes with least authority, containment, fallback, monitoring, expiry, and appeal.
11. Material target, dependency, policy, evaluator, benchmark, authority, rights, environment, workload, or time changes expire qualification.
12. Split, merge, wrapper, retrain, replacement, rollback, and retirement preserve predecessor evidence and residual lineage.
13. Upstream quarantine, revocation, compromise, or invalidation propagates to affected descendants until a new gate establishes recovery.
14. Shadow, canary, diagnostic, and ordinary routes retain denials, interventions, failures, effects, costs, human work, and delayed outcomes.
15. Rollback or compensation readiness requires prospective authority, complete state/effect inventory, tested handles, and explicit non-restorable residuals.
16. Retired and superseded targets cannot regain ordinary routes without new identity-bound qualification and residual migration.
17. Replay reconstructs frozen inputs, checks, state, lease, evidence and residual deltas, and nondeterminism without promising identical outcomes.
18. Readiness language stays inside the exercised target, consumer, use, workload, evaluator, authority, environment, threat, cost, and time envelope.

The strongest operational invariant is negative: a failed readiness predicate must not be converted into a success by renaming the target, changing the benchmark scope, or hiding residuals in prose.

Transition monotonicity over evidence keeps readiness from being laundered. A target can move to a stronger state only by adding adequate gate evidence or by narrowing its permitted scope. It cannot become more routable by losing records.

58.11 Failure modes

1. Score laundering collapses readiness into one benchmark, aggregate, schema, proof, route score, model vote, or source report.
2. Skipped-as-green converts missing, unknown, not-applicable, unattempted, or infrastructure-blocked checks into success.
3. Waiver laundering treats accepted risk as evidence that a property passed.
4. Stale qualification survives a material target, dependency, policy, evaluator, benchmark, authority, rights, environment, workload, or time change.
5. Residual erasure drops failed cases, inherited debt, delayed effects, or closure owners during promotion.
6. Floor laundering reports frontier gain while regressions, vetoes, calibration error, unsafe releases, or cost deterioration are hidden.
7. Selective-readiness laundering counts abstention, fallback, clarification, or refusal as utility while substantive capability remains absent.
8. Evaluator capture lets the target or a shared failure surface certify itself.
9. Authority or rights laundering grants use beyond principal, affected-party, privacy, locality, budget, or approval ceilings.
10. Quarantine theater leaves aliases, descendants, caches, procedures, tools, or wrappers ordinarily routable.
11. Over-quarantine hides useful bounded work and its false-positive, human-burden, latency, and opportunity costs.
12. Lineage laundering renames, wraps, splits, merges, retrains, or replaces a target without inherited evidence and residuals.
13. Recovery theater claims rollback or compensation without complete model, optimizer, scheduler, RNG, cache, artifact, effect, backup, and descendant state.
14. Terminal-state leakage returns retired or superseded targets, credentials, artifacts, memories, routes, or descendants to ordinary use.
15. Load blindness preserves qualification after the operating regime changes.
16. Denominator erasure drops denials, failed canaries, unavailable routes, human repair, retries, delayed harms, residuals, and non-events.
17. Replay theater omits nondeterminism, interventions, effects, invalidators, cost, lineage, or residual custody.
18. State-of-the-art theater generalizes from finite fixtures, a currentness import, synthetic calibration, or zero unsafe releases with negligible utility.

Premature promotion should create a rollback or quarantine transaction. Residual hiding should create a belief-revision or tribunal-review issue. Regression after merge should preserve the old floor as a regression benchmark. Stale gate reuse should block promotion until the relevant checks are rerun. Over-quarantine should be reviewed because excessive blockage can hide the difference between unsafe execution and safe diagnostic use.

Gate laundering is the readiness failure that defeats quarantine. A target fails readiness under one name, is wrapped or merged under another, and then re-enters ordinary routing without carrying the failed gate and residual escrow forward.

58.12 Minimum Viable Implementation

The minimum implemented surface contains four public schemas, four valid and five invalid readiness/residual scenarios, one quarantined six-project check-lifecycle record and nine invalid mutations, six valid lifecycle transitions and twelve invalid controls, one exact Project Theseus YELLOW currentness import with eight negative controls, bounded calibration failures, two accepted no-promotion readiness/residual transition records, and 28 live family declarations. Seventeen belong to the reachable refinement, eleven legacy countermodels remain load-bearing, and nine projection/summary declarations are physically retired. It exercises record and refusal discipline; it is not a deployed readiness system.

The readiness_gate_record schema validates the shape of that record, including field identity, workload family, freshness window, evidence state, floor evidence, frontier evidence, inherited residuals, allowed and blocked routes, diagnostic permissions, fallback path, expiry, closure conditions, and non-claims. Passing validation leaves module readiness unproved; it gives the book a public, executable contract for what a readiness decision must name before stronger tests exist.

The historical-project packet adds schemas/readiness_check_lifecycle_record.schema.json and python3 scripts/validate_readiness_check_lifecycle.py. One quarantined six-project lineage record makes a skipped required artifact-manifest check, a failed benchmark floor, a not-applicable hardware-root check, an invalidated promotion dependency, tighter routes, quarantine ownership, descendant closure, and rerun disposition explicit. Nine mutations reject skipped-as-green, ready-with-failed checks, non-monotone containment, orphaned quarantine, waiver substitution, unknown applicability labeled pass, pass without evidence, ordinary routing during quarantine, and fixture-based support promotion.

The retained Readiness lifecycle probe at experiments/readiness_lifecycle_probe/results/2026-07-02-local.json still records six valid synthetic readiness lifecycle transitions and twelve expected-invalid controls. Its theorem alignment now points to the reachable refinement rather than the retired fixture-summary bridge.

AsiStackProofs.ReadinessRefinement now has twenty-four reachable-lifecycle declarations and an independent consumer over seven stages, forty routes, and 45/45 rejecting mutations. It proves exact rejection noninterference, arbitrary-run identity and non-authority preservation, batch composition, and absorbing terminal closure in addition to the six-event witness. Eleven legacy countermodels remain bounded; nine definition-unpacking or fixture-summary declarations are retired. The model separates ordinary release, quarantine, terminal closure, support assignment, and external effects while preserving capability and evidence custody. Evaluator quality, live enforcement, residual storage, rollback, recovery, and transfer remain outside the model.

A lifecycle trace should exercise gate semantics while leaving module quality unclaimed: draft to shadow, shadow to canary, canary rejected by inherited residual escrow, quarantined for ordinary routing but allowed for diagnostic replay, and later superseded after regression-floor preservation.

The exact Project Theseus currentness import is another bounded record, not a promotion. At commit d2343540a17ea3e12760983f653529621fa445f1, a clean, no-write replay returned YELLOW over twenty phases: twelve wired, two implemented, five partial, and one frozen. Its own pre-training architecture predicate passed within the gate’s declared training/public-calibration focus. Phase 9 remained externally frozen, five training/behavior phases remained partial, and the live book differed from the imported pin. The import closes only the stale-currentness question for that exact observation; it does not establish model quality, deployment readiness, distributed operation, safety, transfer, support, or release.

58.13 Mature Research Target

Readiness is the lifecycle control plane for every routable or replaceable capability in the stack. It is the mechanism that lets the architecture improve without confusing novelty, benchmark wins, or source-reported success with permission for ordinary use.

Readiness becomes a lifecycle state with evidence, residuals, expiry, allowed routes, blocked routes, and rollback consequences. Draft, shadow, canary, qualified, default, diagnostic-only, quarantined, retired, and superseded states are scoped to field identity, workload family, freshness window, authority envelope, allowed routes, blocked routes, diagnostic permissions, fallback path, and expiry.

Gate evidence, floor evidence, frontier evidence, regression results, inherited residuals, promotion blockers, closure conditions, review refs, and next review triggers remain separate so a module can improve on the frontier without losing the floor. Routers consume ordinary-route permissions, benchmark ratchets update frontier and floor evidence, SCF transactions use readiness records for replacement and rollback, and artifact graphs preserve inherited residuals through rename, wrapper, split, merge, retirement, or retraining.

Unresolved failures become residual escrow, recurring residuals become benchmark candidates, passed canaries become scoped qualification, stale qualifications expire, and unsafe or misleading modules remain available for diagnostic replay without staying in ordinary routing. Premature promotion, residual hiding, untracked regression after merge, stale-gate reuse, over-quarantine, and gate laundering become blocked transitions, rollback transactions, quarantine routes, tribunal issues, or explicit residual records.

This readiness lifecycle is still a design target. Readiness remains at argument until promotion, demotion, quarantine, escrow, stale-gate replay, and reroute traces show that unready capability is contained and that residual burden follows the route instead of disappearing from the ledger.

The argument-exit campaign must use natural and adversarial lifecycle events, not only authored transition packets. It should compare score-only, benchmark-only, static-checklist, confidence-only, human-only, conservative-denial, ordinary MLOps, and full governed policies under matched evidence, authority, resources, evaluator access, retries, and time. Targets should include multiple strong current models, specialists, tools, procedures, human lanes, local and remote runtimes, updates, incidents, load shifts, rights changes, and delayed effects.

The scorecard is joint: useful throughput, unsafe release, false promotion, false quarantine, regression, calibration and coverage, authority and rights violations, rollback and compensation, residual survival, lineage propagation, latency, compute and money, human work, recovery, and total lifecycle cost. Prospectively fixed interventions must remove check completeness, freshness, independent evaluation, floor preservation, residual escrow, selective actions, quarantine, transitive invalidation, load awareness, rollback readiness, and terminal closure one at a time. A mechanism remains an argument if its predicted failure signature does not appear. Any claimed benefit must survive independent implementation and evaluation plus transfer across models, tasks, tools, organizations, rights regimes, threats, capacity states, lifecycle events, and time.

58.14 Codex test plan

Test	Purpose	Status
Readiness gate fixture validation	Check that the readiness fixture matches the public schema and declares target, field identity, lifecycle states, workload family, freshness window, evidence, regression results, residual escrow, inherited residuals, authority, route permissions, blockers, quarantine conditions, fallback, expiry, decision, reviews, next trigger, and non-claims.	implemented by protocol validation; validated locally
Readiness gate promotion predicate	Check that promoted decisions require all required gates to pass.	implemented in AsiStackProofs.ReadinessGates; checked by Lean build
Quarantine ordinary-route predicate	Check that quarantined targets cannot be selected for ordinary execution routes.	implemented in AsiStackProofs.ReadinessGates; checked by Lean build
Failed-gate promotion negative case	Reject promoted readiness decisions when all required gates have not passed.	implemented; passes via Lean negative case; no gate-quality or deployment-readiness claim
Accepted stronger-transition negative case	Reject accepted stronger readiness transitions when fresh gate evidence, residual escrow, fallback path, or expiry records are missing.	implemented; passes via Lean negative case; no lifecycle-engine behavior claim
Quarantine route-boundary negative case	Reject quarantined targets that are selected for ordinary routing or selected for diagnostic routing without a fallback path.	implemented; passes via Lean negative case; no live route-enforcement claim
Stale-gate reuse negative case	Reject promoted reuse of expired or architecture-stale gates when rerun and residual records are missing.	implemented; passes via Lean negative case; no rerun execution or current-readiness claim
Readiness lifecycle transition proof	Check that finite readiness lifecycle transitions stay on candidate/shadow/canary/qualified/default/quarantine/superseded/retired paths and reject default, quarantine, supersession, or retirement transitions without the required evidence, residual escrow, fallback, expiry, regression, authority, route, receipt, or supersession records.	implemented in AsiStackProofs.ReadinessGates; finite transition records only
Readiness transition enforcement test	Check that a target cannot enter a stronger state unless the gate decision permits it in an executable lifecycle harness.	implemented by readiness/residual gate harness for synthetic canary, default, quarantine, and expired-rerun scenarios; deployed readiness engine not run
Residual escrow integrity test	Check that residuals remain attached after canary or promotion decisions.	implemented by readiness/residual gate harness for route residual obligations and inherited residual custody; residual-ledger storage not run
Quarantine routing harness test	Check that quarantined targets are unavailable for ordinary routing but remain visible for diagnosis.	implemented by readiness/residual gate harness for blocked selected routes and preserved fallback routes; live quarantine routing not run
Historical-project readiness check lifecycle	Check applicability, requiredness, attempt, result, waiver, evidence identity, expiry, invalidating dependencies, monotone containment, quarantine ownership, descendant closure, and route blocking against nine mutations.	implemented by python3 scripts/validate_readiness_check_lifecycle.py; one quarantined six-project fixture only, no deployed readiness or support-state promotion
Readiness candidate-to-terminal refinement	Check exact capability/evidence custody through shadow, canary, qualification, default, transitive quarantine, revocation-aware terminal closure, and separate release/quarantine/effect accounting.	implemented in AsiStackProofs.ReadinessRefinement and python3 scripts/validate_readiness_refinement.py; exact 24-theorem surface, arbitrary-run custody and non-authority, batch composition, absorbing terminal state, three exact suites, seven stages, 40 routes, 45/45 mutations; no evaluator adequacy, calibration, natural usefulness, effect-complete rollback, deployed quarantine/revocation, transfer, or support claim

Fixture-shape validation, finite predicates, three rejecting harness families, the exact YELLOW currentness import, and bounded calibration results are implemented. Remaining tests require a deployed lifecycle checker, live residual ledger, natural benchmark and canary campaign, independent evaluator, transitive quarantine enforcement, effect-complete rollback and compensation, terminal-state governance, runtime replay, and heterogeneous transfer.

The P4/M5 held-out campaign adds one narrow causal policy result. Among 15 admitted outputs on a fixed 16-task local corpus, full governance released 9 useful and 0 unsafe candidates, while the candidate’s self-release baseline released none. Removing evidence freshness admitted one additional useful-unsafe candidate; the residualized partial-recovery task remained non-released. This supports only the non-core claim that the frozen readiness policy and its freshness gate changed release behavior on this exact corpus. It does not calibrate a deployed gate, establish prevalence, prove residual custody, or validate effect-complete rollback. The chapter core therefore remains argument.

58.14.1 Formalization hooks

Tag	Module	Target	Status
lean:readiness.gates.operational_invariant	AsiStackProofs.ReadinessRefinement	Every finite run through the reachable readiness lifecycle preserves exact capability, implementation, model-state, workload, baseline, evaluator, policy, authority, consumer, fallback, and residual custody; rejected events preserve exact state, event batches compose, terminal closure is absorbing, and support or external effects remain unassigned.	implemented
lean:readiness.gates.failure_blocks_promotion	AsiStackProofs.ReadinessRefinement	Missing workload, baseline, evaluator, non-claims, fresh shadow evidence, regression floor, residual escrow, fallback, rollback, monitoring, canary outcome accounting, independent evaluation, transfer, delayed outcomes, transitive quarantine, route blocking, or terminal revocation custody blocks lifecycle progress.	implemented
lean:readiness.gates.lifecycle_probe_bridge	AsiStackProofs.ReadinessRefinement	The independent consumer recompiles the exact twenty-four-theorem surface while preserving three exact readiness suites, all forty lifecycle routes, the six-receipt terminal witness, and forty-five rejecting identity, gate, replay, and authority-leak mutations without assigning support or external effects.	implemented

These proof hooks now resolve to a reachable seven-stage lifecycle plus an independent consumer. Twenty-four refinement declarations and eleven retained legacy countermodels remain live; nine definition-unpacking or fixture-summary declarations are retired. This classification prevents theorem count or the bridge from standing in for semantic breadth, executable correspondence, or empirical validity. They do not prove benchmark quality, evaluator adequacy, residual storage, transition execution, live routing enforcement, rollback, terminal governance, MoECOT replay, current module readiness, or transfer.

The refinement is adequate only for exact finite readiness-record routing: capability and evidence identity, stage ordering, failed-event preservation, quarantine, revocation, and acknowledged terminal closure. A defaultReady route is not a calibrated estimate, a safety case, release authority, or proof that deployment is useful, recoverable, or socially legitimate.

58.15 Realization-Relative Qualification

Readiness evaluates a concrete realization, not an abstract lesson. The same lesson realized as a memory, tool, model delta, evaluator, or institutional rule creates different test, authority, expiry, rollback, and descendant obligations. The Adaptive Commit Boundary supplies that locus-specific commitment profile; readiness issues a qualification lease only for the exact artifact, scope, environment, dependencies, and authority that were tested.

Material evidence, implementation, dependency, environment, threat, or authority change invalidates the affected lease. Requalification is a new decision. Residual escrow must retain descendants and external reliance that cannot be removed merely by restoring the parent artifact.

58.16 Source crosswalk

Source ID	Title	Layer	Planned use	Readiness
rmi	Ratcheting Modular Intelligence	capability_ratchet	Benchmark pressure, residual escrow, verified modular capability, regression preservation.	source note available; local raw cache available
benchmaxxing	Benchmaxxing: The Performance Ratchet	benchmarks_evidence	Benchmarks as pressure surfaces, saturation -> regression, harder frontier, anti-Goodhart safeguards.	source note available; local raw cache available
scf	Stable Capability Fields	governance_recursive_self_improvement	Use public release v1.0 when available. Stable boundaries, replacement, bounded authority, recoverable evolution.	source note available; local raw cache available
octopus_router	Octopus Router Architecture	routing_modular_intelligence	Lightweight head/router with dynamically loaded specialist arms and local boundaries.	source note available; local raw cache available
cognitive_loop_closure	Cognitive Loop Closure	procedural_memory	Repeated cognition should become procedural memory / verified tools.	source note available; local raw cache available
moecot	MoECOT-Agent Architecture Whitepaper	implementation_reference	Concrete implementation evidence: governed low-parameter multi-core runtime, readiness gates, ledgers, replay.	source note available; connector or recovery required
project_theseus_whitepaper	Project Theseus Whitepaper	report_first_rmi_prototype	Local-first report-driven RMI implementation reference: SymLiquid, SparkStream, Octopus Router, residual escrow, self-evolution gates, Hive runtime, observability.	source note available
theseus_architecture_gate	Theseus Architecture Gate	readiness_gate_governance	Pre-training readiness gate covering ratchet completeness, router readiness, safety ledger, residual escrow, bridge benchmarks, procedural tools, routing memory, lifecycle governance, and external-inference zero.	source note available
theseus_self_evolution_system	Theseus Self-Evolution System	recursive_self_improvement_governance	Evidence-first self-evolution lane with intervention ladder, ATTD repo-health gate, guarded teacher self-edit, architecture experiment governance, loop closure, and outcome ledger.	source note available
cca_project	Compiled Cognitive Architecture project	historical_project_lineage	Promotion, quarantine, rollback, closure authority, and fail-closed benchmark gates.	source note available
moecot_manifest_project	MoECOT Manifest compiler-era project	historical_project_lineage	Promotion locality, evidence identity, residuals, holdouts, and growth guards.	source note available
beastbrain_project	BeastBrain historical AI system project	historical_project_negative_case	Readiness-overclaim boundary between interfaces/checklists and open implementation gates.	source note available
bugbrain_project	BugBrain bare-metal neuro-symbolic intelligence project	historical_project_negative_case	Skipped-as-green reports and explicit check-lifecycle fields.	source note available
corbens_trainer_project	Corben’s Trainer epistemic training and evaluation control plane	historical_project_negative_case	Transitive quarantine and stale promotion-lease invalidation.	source note available
corbens_best_model_possible_project	Corben’s Best Model Possible recurrent-model and mechanism laboratory	historical_project_negative_case	Material postconditions, quarantine, rollback, and interface-without-effect.	source note available
ext_darwin_godel_machine_2025	Darwin Godel Machine	empirical_recursive_agent_improvement	External comparator for archive-based self-modifying candidates, benchmark selection, sandboxing, and human oversight.	source note available

The readiness sources support gate state, per-check lifecycle, residual escrow, regression preservation, transitive invalidation, quarantine, archive selection, and selective-prediction calibration. All seventeen assignments have an exact reviewed mapping. The Project Theseus lane now has both an older static digest-verified report fixture and one exact YELLOW currentness replay at commit d2343540; neither establishes deployment readiness or model quality. The six-project fixture adds negative-case record discipline only. The book still has not run a deployed readiness engine, live residual ledger, production quarantine route, effect-complete rollback, current MoECOT runtime replay, or natural multi-model readiness campaign.

58.16.1 Manifest source assignment reconciliation

These rows keep Readiness Gates, Residual Escrow, and Quarantine’s manifest assignments visible at their recorded review boundary. Passage review does not establish local reproduction, performance, safety, deployment, or support-state movement.

Source	Intake role	Boundary
rgs	Passage-reviewed comparator: Ratcheting Generative Systems. Supplies residual escrow as an active lifecycle: periodic reattempt, consistently solved promotion to regression, recurring-cluster promotion to diagnosis/frontier work, defective-item repair or retirement, and a protected but non-dominating evaluation budget. It also supplies subgroup floors and critical-failure vetoes around ordinary mastery graduation.	Conceptual precursor in the same author-side lineage as RMI, not independent confirmation. No residual store, recurrence classifier, reattempt scheduler, budget allocator, readiness engine, benchmark run, or promotion decision has been implemented or measured. No local implementation, reproduction, performance, safety, deployment, support-state, or ASI result is established by this reconciliation row.
deterministic_capability_compilation	Passage-reviewed Corben architecture source: Deterministic Capability Compilation: A Capability-Preserving Ladder from Executable Scaffolds to Governed Adaptive Agents. Corben-authored July 2026 architecture and research program for compiling executable scaffolds into contract-bound experts and linked Neural Capability Objects while retaining semantic obligation mass balance, candidate-specific translation validation, fallback, residual escrow, authority ceilings, reification, and effect-complete recovery. Existing chapters are upgraded first; no foundry implementation, learned-capability result, preservation result, safety result, SOTA result, AGI, ASI, or support-state promotion is inferred.	No local implementation, reproduction, performance, safety, deployment, support-state, or ASI result is established by this reconciliation row.
ext_dont_hallucinate_abstain_2024	Passage-reviewed comparator: Don’t Hallucinate, Abstain: Identifying LLM Knowledge Gaps via Multi-LLM Collaboration. Supports measuring abstention with coverage, accuracy, calibration, and useful response behavior while treating self-reflection and model agreement as fallible evidence.	The ACL models, prompts, domains, collaboration schemes, and reported gains were not reproduced; the local single-model router is not an independent multi-model panel. No local implementation, reproduction, performance, safety, deployment, support-state, or ASI result is established by this reconciliation row.
ext_swe_rebench_v2_2026	Passage-reviewed comparator: SWE-rebench V2: Language-Agnostic SWE Task Collection at Scale. Adds concrete instrument-failure gates for missing images, broken setup, parser drift, implicit naming, external context, test coupling, emulation cost, and failed positive controls.	A failed instrument closes the denominator and cannot be laundered into negative evidence about a model, mechanism, or governance architecture. No local implementation, reproduction, performance, safety, deployment, support-state, or ASI result is established by this reconciliation row.
precision_contract	Metadata-first comparator: The Precision Contract: A Functional Rate–Distortion Theory for Behavior-Preserving Neural Computation. Corben-authored July 2026 theoretical and systems paper replacing universal per-weight precision questions with a contract-relative functional rate-distortion problem over complete executable descriptions. It proposes representation canonicalization, protected-behavior contracts, precision fields, progressive base/residual encoding, dynamic routing, full physical and assurance-cost accounting, a Functional Precision Compiler, and scoped precision certificates. Existing chapters are upgraded first; no universal bit bound, implemented compiler, preserved-behavior result, efficiency result, certificate validity, support promotion, SOTA, AGI, or ASI claim is inferred.	No passage-level source claim, local implementation, reproduction, safety, performance, deployment, support-state, or ASI result is established by this reconciliation row.
regret_engine	Passage-reviewed Corben architecture source: The Regret Engine: Governed Counterfactual Learning Signals for Continual Adaptation, Prospective Risk Control, and Self-Correction in Artificial Agents. Corben-authored August 2026 conceptual architecture and research program for decision-time-fair Governed Counterfactual Regret, immutable Decision Capsules, admissible comparator contracts, sparse Regret Tensors, append-only Regret Packets, prospective regret control, regret-aware replay, regret-to-rule compilation, three update clocks, root-cause adjudication, and bounded update leases. Existing chapters are upgraded first; no implementation, experiment, reproduction, causal-identification result, formal proof, safety result, support transition, SOTA, AGI, or ASI is inferred.	The bibliography and Markdown figure companions were not supplied; the DOCX embeds its visual material. All propositions, algorithms, experiments, and architecture claims remain proposed rather than independently validated. No local implementation, reproduction, performance, safety, deployment, support-state, or ASI result is established by this reconciliation row.
assurance_shift_learning	Passage-reviewed comparator: When Success Stops Teaching: Assurance-Shift Learning and Governed Residual Boundary Learning for Mature AI Systems. Adds the Qualified Competence Envelope as a scoped readiness input and reinforces that learning eligibility, local competence evidence, and deployment readiness are separate decisions.	The envelope is evaluator- and distribution-relative; it is neither a complete competence map nor calibrated deployment permission. No local implementation, reproduction, performance, safety, deployment, support-state, or ASI result is established by this reconciliation row.
adjudicated_persistence	Passage-reviewed comparator: Adjudicated Persistence: Governing the Transition from Experience to Durable Structure in Adaptive Systems. Adds realization-relative qualification leases, commitment-aware evidence obligations, material-change invalidation, and residual closure before broader admission.	Conceptual author framework and benchmark proposal; no local implementation, empirical result, independently checked proof, safety result, or support movement. No local implementation, reproduction, performance, safety, deployment, support-state, or ASI result is established by this reconciliation row.

58.17 Post-v2.1 readiness calibration

The governed program shows why “safe” and “ready” cannot be synonyms: it eliminated registered unsafe releases but released only 2/36 useful candidates and missed the rollback threshold. The routing program adds a second calibration warning. A learned policy reached 59/60 correct routes and activated fallback, abstention, and clarification, yet every one of 360 substantive generated candidates was wrong. A readiness gate must therefore separate route correctness, useful non-answer behavior, substantive answer utility, and rollback completeness. RD-02 closes at its narrow activation criterion; the broader routing and production-readiness residuals remain.

The post-v2.3 residual-pressure campaign failed one layer earlier. Across six scenarios and four pressure conditions, zero of 24 calls emitted a parseable final decision, route, or reopen trigger; residual identifiers appeared only inside capped reasoning text (23 unclosed blocks and one closed block without a final object). A readiness gate must not treat that hidden fragment as public escrow or quarantine routing. The campaign remains a no_change record, and pressure robustness is not estimable until a prospectively specified replication produces admissible final decisions.

The M8 Campaign 4 repair then made three prospectively versioned sacrificial attempts. Its terminal v3 decision path correctly separated release eligibility on 6/6 cases, retained all required residual IDs, released 3/3 clean controls, and produced zero sacrificial false reassurance. Readiness still could not admit the instrument: every defect-case extractor used undeclared route retain and omitted requested-check IDs, so only 3/6 extraction objects met the frozen schema floor. The fifteen-task heldout remained sealed. This is the exact readiness lesson: a correct stop/release boundary cannot compensate for a malformed handoff to verification, capacity allocation, ownership, or reopening. No residual-honesty, verifier-capacity, or readiness-support claim moved.

Source	Title	Use and boundary
ext_dont_hallucinate_abstain_2024	Don’t Hallucinate, Abstain	Selective-prediction comparator for abstention utility and calibration; not evidence that the local router is calibrated beyond its frozen workload.

58.18 Summary

Readiness is the stack’s refusal to confuse availability with qualification. Gates decide when a module can move from experiment to route, residual escrow keeps unsolved cases alive, and quarantine turns failure into governed learning rather than hidden state.

The strongest current evidence is bounded and mostly negative. Three synthetic harness families reject malformed promotion, check-lifecycle, and state-transition records; 28 live family declarations plus the independent forty-route consumer establish only their finite encoded consequences; one exact Project Theseus replay observed a YELLOW pre-training architecture gate with partial and frozen phases; post-v2.1 released 2/36 useful candidates while missing its rollback threshold and produced zero correct substantive candidates in the ambiguous routing workload; and post-v2.3 produced zero admissible final readiness decisions under residual pressure. The three-version Campaign 4 repair additionally reached promising sacrificial eligibility and residual-recall values but failed its terminal consumer schema and opened no heldout outcomes. These results sharpen what readiness must reject. They do not show that the proposed lifecycle improves useful safe operation.

Readiness turns modular intelligence into a lifecycle discipline: promote only with evidence, preserve the floor, expose the tail, and keep unsafe or stale routes out of ordinary execution. A concrete runtime reference must then record enough detail for this routing and readiness discipline to become operational evidence.

That runtime reference must publish the same evidence shape the gate expects: route decisions, specialist states, replay links, benchmark or regression records, residuals, and promotion blockers.

A readiness decision should still be understandable after the module changes names. If evidence, residuals, scope, expiry, descendants, artifacts, effects, and quarantine permissions do not survive that change, the lifecycle layer is not yet governing routability.

58.19 Evidence reconciliation (2026-07-16)

The invariant protocol, field meanings, and inference limits are stated once in Living Book Methodology. This packet contains only the chapter-specific projection; its authoritative per-atom rows are the readiness-gates-residual-escrow-and-quarantine slice of experiments/claim_family_terminal_coverage/results/result.json.

The core remains blocked after full attempt at argument support. The strongest family attempt was Ambiguous routing and deliberation confirmatory campaign. Its exact boundary is: Mixed bounded routing effect with unsafe outputs and no support promotion; no general router, deliberation, or transfer claim. Across 74 atoms, the terminal ledger records 74 blocked_after_full_attempt.

Chapter-specific field	Value
Family / atom denominator	CF-05 / 74 atoms
Terminal dispositions	74 blocked_after_full_attempt
Core	readiness-gates-residual-escrow-and-quarantine.core: blocked_after_full_attempt at argument
Core attempted / missing lanes	causal, empirical, executable, formal, source-synthesis / normative, transfer
Attempted local lanes	causal, empirical, executable, formal, source-synthesis
Missing or unproved lanes	normative, transfer
Strongest family bundle	Ambiguous routing and deliberation confirmatory campaign (natural_work): A 32-task held-out real-model workload across eight tracks, four ingress modes, eight routing arms, and four stopping arms.
Negative controls	17 active control mutations; five disposition mutations; 15 preserved extra-compute harms; wrong-fast-path and unsafe-release accounting.
Accepted transitions	v1_0_pilot.readiness_residual.no_change
Maximum inference	Mixed bounded routing effect with unsafe outputs and no support promotion; no general router, deliberation, or transfer claim.
Reproduction / next burden	Replay scripts/validate_p4_m6_routing_deliberation.py and scripts/validate_claim_family_terminal_program.py; fill the named atom-specific lanes under a new prospective protocol.

58.20 Handoff

Readiness gates define what evidence a module owes before ordinary routing, and the Routing Heads chapter now carries the MoECOT runtime crosswalk for the records a concrete orchestrator would have to emit. Personal Compute Hives and Federated Edge Intelligence moves the next concern from runtime packet shape to substrate: where route decisions, specialist work, ledgers, replay hooks, residuals, and approvals may run without confusing reachable devices for authorized devices.