Skip to main content

19  Capability Replacement and Rollback

19.1 Chapter status

Field	Value
Chapter ID	capability-replacement-and-rollback
Part	Part I - Foundations, Alignment, and Governance
Status	conceptual
Manuscript maturity	v0.3 proof-program manuscript
Last updated	2026-08-08
Primary source records	The manifest owns the exact source list, including capability_ratchet_whitepaper alongside the existing replacement, corrigibility, rollout, MLOps, and transaction comparators.
Claim label	Design rationale
Evidence level	argument
Source queue	primary: scf, rmi, benchmaxxing; supporting: cognitive_loop_closure, talos; external variants: corrigibility, Argo Rollouts, feature toggles, Google Cloud MLOps, Kubernetes Deployments, TxFS; connector/recovery: moecot
Source loading state	source notes: scf, deterministic_capability_compilation, rmi, benchmaxxing, cognitive_loop_closure, talos, moecot, capability_ratchet_whitepaper, ext_corrigibility_2015, ext_argo_rollouts_docs, ext_feature_toggles_fowler, ext_google_cloud_mlops_cd, ext_kubernetes_deployments_docs, ext_txfs_2018; raw cache: scf, rmi, benchmaxxing, cognitive_loop_closure, talos; connector/recovery: moecot
Source mapping review	12/12 assigned sources have bounded mappings; no source reproduction or support promotion follows.
Test state	Synthetic and formal baselines remain unchanged. Bounded outcomes include 15/15 P3 and 35/35 M7 exact local 24-surface rollback transactions, 32/36 attack-control rollback with 2/36 useful release, and 12/12 nine-surface harness probes with all model calls failing before candidate creation. The first P5 slice adds 8/8 real-subprocess state/effect cases. The second adds 7/7 commit-bound local service cases: actual model/Adam mutation, weights-only rollback rejection, nine-class crash/restart recovery, partition/outbox retry, one exactly-once external effect, stale-credential rejection, custody-tamper rejection, and separate-process observation. No natural usefulness, large-model semantic recovery, privacy repair, remote erasure, production deployment, or transfer follows.

19.2 Drafting guardrail

Replacement is defined here as a prospectively governed state-and-effect transaction. A complete record is necessary but insufficient: recovery is asserted only against an exact declared inventory and objective, and useful improvement is evaluated separately from safe restoration.

It follows Stable Capability Fields because the field gives replacement a target identity; the transaction gives that identity a disciplined change procedure.

The replacement transaction is the stack’s version of a high-risk write. It changes a live capability boundary, so it needs preconditions, a commit protocol, monitor obligations, rollback evidence, and a post-change residual record.

19.3 Human Reading Path

Concrete lens. The simpler baseline promotes after a benchmark or precheck pass and calls restoring one model alias rollback. The chapter prospectively freezes gates and distinguishes restored inventory from irreversible external effects.

Stable Capability Fields define the boundary that replacement must cross under review. Replacement is a controlled crossing with compatibility checks, canary scope, monitoring, rollback, and residual ownership. The field says what must remain true; the transaction says whether the candidate earned the right to become ordinary infrastructure.

Reversibility is one trust boundary, not the whole safety case. A replacement claim does not deserve confidence merely because a version sounds better, compiles faster, or wins a local comparison. Its evidence is stronger when failure can be detected, contained, explained, reversed where possible, and retained as an owned residual where it cannot. Until those records exist, the candidate belongs in shadow, canary, quarantine, or research state rather than quietly becoming the default path.

A rehearsed, effect-bounded rollback can turn part of an update from an irreversible bet into an inspectable experiment. It preserves the declared prior state while the candidate is tested for scoped compatibility, authority, regressions, monitorability, and residual ownership. Irreversible effects may still require compensation or containment. The ability to record “improvement failed” is one control against self-ratification.

19.4 Problem

A governed stack must change live models, prompts, tools, policies, data, evaluators, dependencies, state schemas, and routes without treating candidate availability as accepted replacement or one restored artifact as recovered capability. The transaction begins from the Stable Capability Field’s fixed consumer-relative contract, but it must also own the temporal problem: what was true before exposure, what the candidate changed, what committed, what the monitor could observe and when, and what remained after rollback or compensation.

The hard cases are not clean binary swaps. A new model may require a new tokenizer, prompt, data view, optimizer state, cache layout, adapter, policy, credential, evaluator, monitor, or downstream index. A canary may write shared state or train a descendant. A rollback may restore weights while leaving caches, remote copies, external actions, disclosure, user reliance, rights violations, or learned successors unchanged. A checkpoint chosen after outcomes are known can turn an honest comparison into hindsight selection.

The research problem is therefore full-state and effect-bounded change control with useful outcomes. RMI and Benchmaxxing supply ratchet and regression pressure; Cognitive Loop Closure supplies lifecycle and retirement; Talos supplies auditable job and replay context; SCF supplies the frozen substitution contract. None of them removes the need to inventory effects or demonstrate recovery under real failure.

19.5 Why existing approaches are insufficient

Ad hoc upgrades are not the only insufficient baseline. Registries know which artifact is available; feature flags and progressive delivery control exposure; MLOps pipelines add data, schema, model, serving, and monitoring gates; Kubernetes keeps revision history; filesystem transactions can provide bounded crash consistency; benchmark ratchets preserve selected floors; corrigibility motivates correction channels. These mechanisms are valuable prior art, but each leaves some combination of semantic identity, checkpoint authority, authority change, evaluator capture, hidden state, delayed harm, descendants, external effects, compensation, and usefulness outside its boundary.

A rollback command is especially easy to overread. Restoring a container, file tree, checkpoint, or model digest may be exactly correct within that inventory while failing to reverse disclosure, remote writes, external actions, schema changes, downstream learning, user harm, or institutional commitments. The transaction model therefore separates artifact restoration, state restoration, service restoration, behavioral recovery, privacy or rights repair, compensation, and residual closure.

Corrigibility provides the external baseline for why replacement needs a preserved correction path. ext_corrigibility_2015 treats intervention tolerance and operator correction as properties that can be lost by design; a replacement transaction is the systems version of the same concern. A rollback record asks whether correction, regression floors, evaluator separation, and recovery handles survive the upgrade, without claiming that any real replacement has passed that bar.

Deployment practice supplies narrower rollout vocabulary but not the whole replacement argument. Kubernetes Deployments (ext_kubernetes_deployments_docs) make rollout history, revision records, and rollback to a prior stable revision familiar. Argo Rollouts (ext_argo_rollouts_docs) adds blue-green rollout, canary rollout, traffic shaping, metric analysis, automated promotion, and automated rollback as progressive-delivery concepts. Feature toggles (ext_feature_toggles_fowler) ground controlled exposure and canary cohorts. Google Cloud’s MLOps continuous-delivery guidance (ext_google_cloud_mlops_cd) adds the ML-specific warning that model rollout involves code, data, schemas, model quality, serving pipelines, monitoring, and rollback triggers rather than ordinary software deployment alone. The ASI Stack borrows this operational discipline, then asks for stricter transaction fields: field identity, authority ceiling, evaluator independence, regression floors, residual ownership, rollback receipts, and support-state boundaries.

Replacement needs transaction semantics because partial success can be worse than failure. The system should know whether it is in precheck, gate, canary, commit, monitor, rollback, quarantine, or retirement.

The key reader-facing distinction is candidate improvement, accepted replacement, and completed recovery. A promising candidate can remain shadow or canary. An accepted candidate has passed the preregistered gates only within a declared scope. A recovered transaction has additionally met a named recovery objective across its declared inventory or recorded compensation and residuals where reversal was impossible. None of these states implies global improvement or safety.

Rollback also has to be more specific than nostalgia for the prior version. The prior artifact must still exist, the old state must be readable or compensated, external effects must be accounted for, and the monitor window must say when rollback is triggered. If any of those pieces is missing, the transaction can still record a partial recovery plan, but it should not claim reversible improvement.

One-way improvement creates the rollback gap. A candidate is allowed to replace the old path because the forward story is attractive, while the reverse path, state compatibility, dependent artifacts, rights preservation, and external effects are left implicit.

That one-way framing also hides who owns the risk. If a replacement fails, someone or something must know which artifact to restore, which state migration to reverse or compensate, which users or downstream routes were affected, and which residual remains unresolved. Without that owner, rollback is only a comforting word.

19.6 Core Claim

Reader claim. Replacement is not “put the better model in production.” It is a prospective change transaction that must say which state and effects may change, what monitor stops the canary, what rollback can restore, and what cannot be reversed.

Operational rule. Freeze field identity, prior and candidate artifacts, gates, checkpoint authority, monitor, exposure, and recovery objective before observing results. A failed monitor routes to rollback or quarantine, and a rollback may claim success only for restored inventory while preserving every irreversible effect as an owned residual.

[capability-replacement-and-rollback.core, label: Design rationale, support: argument] Capability replacement should be a prospectively authorized, phase-gated transaction over a declared Stable Capability Field. It binds exact prior/candidate identity, change class, checkpoint authority, state/effect inventory, scoped evidence and authority, evaluator and monitor dependencies, staged exposure, commit, recovery or compensation, descendants, residuals, and terminal receipts. It cannot make irreversible effects reversible, prove its own observers, grant authority, establish useful improvement, or generalize inventory-exact local restoration to production.

The core claim remains argument. The source set supplies design lineage and comparators. The repository adds exact synthetic and finite proof results plus narrow empirical outcomes: 15/15 local rollback equality on a prospective 24-surface inventory, but no eligible utility gain; 32/36 exact attack-control rollback and 2/36 useful release in a different campaign, below both gates. These results strengthen the inventory-specific subclaim and refute any implication that governance or rollback already yields useful, complete replacement.

19.6.1 Claim-source mapping status

Appendix C maps all assigned sources. Five project sources have reviewed raw passages, the complete authenticated moecot connector text is passage-reviewed implementation context, and the external mappings establish corrigibility, rollout, controlled-exposure, MLOps, revision-history, and filesystem-transaction comparators. Mapping them makes their role auditable; it does not make them local evidence.

Source	What it supports	Limit
scf	Field identity, implementation artifacts, qualification, state migration, lifecycle, evaluator-integrity, and rollback vocabulary that replacement must preserve. Passage-reviewed.	Does not prove a real replacement has executed, recovered, or resisted evaluator capture.
rmi	Frontier movement with regression floors, residual escrow, specialist lifecycle discipline, critical-failure vetoes, and route/arm retirement decisions. Passage-reviewed.	Conceptual framework only; no independent reproduction, benchmark run, prototype inspection, or Lean proof was performed from this note.
benchmaxxing	Benchmark lifecycle, wall diagnosis, anti-Goodhart safeguards, regression promotion, residual ledgers, and architecture-change discipline. Passage-reviewed.	No benchmark harness, mutation, holdout, or empirical run was performed in this repo.
cognitive_loop_closure	Verified tool/procedure lifecycle, loop detection, tool cards, runtime monitoring, revision, retirement, and risk-tiered procedural memory. Passage-reviewed.	No local loop-detection, tool synthesis, or verification harness was executed here.
talos	Auditable replacement work through job records, verification policies, artifact claim/evidence bindings, proof bundles, replay, hashed logs, human adjudication, and residual uncertainty. Passage-reviewed.	Does not prove real replacement execution, approval behavior, runtime enforcement, or artifact replay in this repo.
moecot	Readiness gates, control-plane ledgers, replay, promotion blockers, and residual tracking as runtime-reference context for replacement decisions.	Source-reported runtime context only until code, logs, release artifacts, or benchmark records are inspected or reproduced.
ext_corrigibility_2015	Correction, shutdown, and modification channels as properties that can be lost through self-modification or composition.	No formal result or corrigible-agent behavior is reproduced; rollback is not whole-agent corrigibility.
ext_argo_rollouts_docs	Blue-green/canary rollout, traffic shaping, metric analysis, promotion, abort, rollback, and blast-radius control.	No controller or rollout ran; traffic restoration is not semantic or effect recovery.
ext_feature_toggles_fowler	Release decoupling, canary cohorts, exposure policy, toggle categories, and validation debt.	No toggle service or live cohort ran; availability is not accepted replacement.
ext_google_cloud_mlops_cd	Data, schema, model, code, pipeline, serving, training, drift, monitor, and rollback-trigger surfaces.	No pipeline, service, monitor, retraining, deployment, or model rollback ran.
ext_kubernetes_deployments_docs	Desired-state rollout, revision history, change-cause context, and prior-workload restoration.	No cluster or undo ran; workload revision restoration is not capability recovery.
ext_txfs_2018	Bounded ACID filesystem transaction, isolation, conflict, journal, and crash-consistency comparator.	TxFS was not reproduced; local snapshots do not establish filesystem transactions, crash safety, services, or external-effect atomicity.

19.7 Mechanism

19.7.1 Worked rollback: a passed precheck does not survive the canary

The synthetic transaction replacement://model-rollout-monitor-rollback begins with three passed prechecks—data validation, schema validation, and serving integration—and a candidate that preserves the field and authority ceiling of field://prediction-service-risk-model. The canary then fails its baseline regression-floor monitor while serving latency remains within threshold. The independent rollout reviewer routes the transaction to rollback, restores the alias to impl://risk-model-v1, and drives the candidate route weight to zero.

That is not complete erasure. The receipt restores the model alias, route weight, and canary exposure, but explicitly retains logged prediction traces as an irreversible audit residual. The harness accepts this record and four other valid synthetic transactions while rejecting nine controls, including authority widening, failed-regression commit, missing rollback rehearsal, missing data or schema gates, an unowned irreversible effect, and a self-evaluator. It demonstrates the chapter’s state distinction—precheck pass, monitor failure, bounded rollback, open residual—without claiming that a real deployment, monitor, or production rollback worked.

A replacement transaction is the moment an SCF becomes an accountable state change. It is allowed to fail, roll back only partially, require compensation, or establish that no useful improvement occurred. What it cannot do is choose its rules after the outcome, hide an affected surface, or narrate a partial recovery as complete.

flowchart LR
  A["Freeze field, identities, owners, rules"] --> B["Prospective checkpoint + full state/effect inventory"]
  B --> C["Isolated candidate + qualification/regression/adversarial evidence"]
  C --> D{"All preregistered gates pass?"}
  D -- "no / unknown" --> X["Reject / quarantine / residual"]
  D -- "yes" --> E["Bounded canary under fixed monitor"]
  E --> F{"Stop, incident, delay, or threshold failure?"}
  F -- "yes" --> G["Rollback / compensate / fork / quarantine"]
  F -- "no" --> H["Bounded commit + continued monitor"]
  G --> I["Compare recovery objective across inventory/effects"]
  H --> I
  I --> J{"Terminal obligations closed?"}
  J -- "no" --> K["Owned residual + continued containment"]
  J -- "yes" --> L["Terminal receipt + public/evidence projection"]
  X --> L

How to read the replacement transaction: rules and checkpoint authority are frozen before outcomes. Canary exposure is not commit; commit is not monitor success; artifact restoration is not complete recovery. Every branch terminates in a receipt that distinguishes reversal, compensation, containment, residuals, and usefulness.

The first mechanism is prospective freeze. Transaction identity, field version, prior and candidate candidates, dependencies, environment, consumers, use, owners, evaluation set, thresholds, monitor policy, canary scope, stop rule, commit rule, recovery objective, and support-state non-effect are fixed before candidate evidence is observed. If a rule changes, the transaction versions and reruns rather than borrowing the most favorable old result.

The second mechanism is change classification. Contract, model/weights, prompt/policy, code/tool, data/retrieval, evaluator, dependency, hardware/runtime, authority, state schema, route, governance, and public-interface deltas are recorded separately. A material field change returns to SCF governance. Calling it an implementation replacement would let the candidate redefine the predicate it is meant to satisfy.

The third mechanism is prospective checkpoint and inventory authority. The pre-state covers declared model, optimizer, scheduler, RNG, cache, checkpoint, backup, credential, policy, data, route, monitor, receipt, descendant, and external-commitment surfaces. Every excluded surface carries reason, owner, and residual. The authorized checkpoint is selected before results; best-final disagreement remains evidence rather than being erased by choosing whichever state looks strongest later.

The effect inventory classifies reversible, replayable, compensatable, forked, disclosure-like, safety-sensitive, externally owned, and irreversible effects. This is where file or checkpoint restoration stops being confused with semantic recovery. Reverse migration, data and cache restoration, credential and policy state, downstream invalidation, disclosure response, external compensation, and descendant containment need separate results.

The candidate runs in an isolated shadow or fork with explicit read, write, network, tool, data, credential, learning, cache, descendant, and external-effect permissions. The transaction evaluates historical regressions, critical-failure vetoes, rare/adversarial cases, authority and rights preservation, state compatibility, composition, contamination, usefulness, cost, and transfer. Benchmarks are evidence surfaces, not permission slips; negative and null outcomes stay attached.

Proposal, evidence production, evaluation, promotion, monitoring, incident adjudication, and recovery disclose shared models, data, incentives, organizations, and control paths. Nominal separation is not presumed independent. Where dependencies cannot be removed, the candidate receives a narrower exposure and the capture risk remains a residual.

Canary population, duration, traffic and authority, metrics, thresholds, outcome delay, censoring, missing-telemetry rule, stop conditions, fallback, approval, and escalation are preregistered. Silence is not a pass. A canary cannot create undeclared durable side effects or influence the default lineage merely because its nominal traffic share is small.

Commit updates route and receipt state atomically where possible, preserves the prior route until closure, and records every subsystem outside that atomic boundary. Rollback then executes against the complete declared inventory and compares post-recovery state and effects with the prospective objective. If reversal is impossible, the transaction records compensation, fork, quarantine, revocation, disclosure response, downstream invalidation, or residual instead of claiming success.

Terminal closure occurs only after the monitor window and recovery obligations settle. The receipt binds before/after digests, observations, incidents, affected consumers and descendants, rollback or compensation outcomes, unresolved effects, evidence transitions, changelog/public projections, and disposition. Rolled-back and failed attempts remain durable evidence.

19.7.2 Candidate-specific equivalence and linked replacement

Deterministic Capability Compilation treats replacement as neural translation validation with three outcomes: pass, fail, and unknown. A candidate is checked at schema, field, interface, composition, property, adversarial, learner-induced-state, environmental, independent-evaluation, and natural- monitoring layers. A finite pass proves only the declared checks. unknown is not coerced into success merely because a deployment decision is inconvenient.

The safest proposed baseline is a sparse linked composite in which unchanged paths, parameter ownership, activation lanes, fallbacks, and router decisions remain inspectable. Dense consolidation is link-time optimization and requires its own translation validation. Recovery follows the same principle: restoring a weight file is only one dimension. Optimizer, scheduler, RNG, caches, backups, router state, descendants, credentials, external effects, and compensating actions remain in the recovery ledger.

This source adds a stronger experiment target, not a result. The book still requires a real linked-candidate campaign with shared-state interference, independent evaluation, durable counterexamples, effect-complete recovery, and matched sparse, dense, adapter, merge, and retraining baselines before any replacement claim can move above argument.

19.8 Interfaces

The transaction coordinates seven authority and evidence surfaces:

• Stable Capability Fields supplies the immutable substitution contract, consumers, ceiling, lease, regressions, incidents, and material-change classifier.
• Intent, command contracts, governance, and System Authority supply the principal, objective, forbidden means, approval, exception, stop, expiry, and recovery grants.
• Artifact, provenance, custody, memory, state, and context layers supply exact identities, dependency graphs, pre-state, checkpoint authority, migration, caches, data lineage, descendants, and effect inventory.
• Benchmarks, adversarial evaluation, oversight, rights, security, and Evidence States supply bounded outcome, regression, authority, privacy, contestability, monitor, and transfer observations.
• Routing and runtime enforce isolation, exposure, effect ceilings, route transitions, monitor hooks, stop conditions, recovery triggers, and receipts.
• Readiness, residual escrow, incident response, and recovery consume gates, blockers, rehearsals, effect inventories, residual owners, recovery objectives, and closure state.
• Changelog, public projections, descendants, policy updates, and self-improvement preserve the exact terminal receipt, including failed, null, rolled-back, compensated, and residual outcomes.

Minimum fields:

• transaction_id
• transaction_state
• field_id
• prior_implementation
• candidate_implementation
• identity_preservation
• precheck_results
• qualification_evidence
• regression_results
• authority_check
• evaluator_independence
• residual_escrow
• rollback_plan
• rollback_receipt
• approval_record
• canary_scope
• monitor_window
• monitor_status
• decision
• promotion_blockers
• source_refs
• support_state_effect
• non_claims

The current public schema covers a useful subset, but the target contract also requires content-bound dependency and environment identity, change classification, prospective checkpoint authority, full state/effect inventory, outcome delay and censoring, candidate isolation, downstream closure, recovery objectives, compensation, terminal closure, and separately typed restoration outcomes. Naming these fields does not implement the subsystems that must produce them.

Transaction and decision states need to be explicit: proposed, precheck, shadow, canary, default-candidate, committed, rolled-back, quarantined, superseded, retired, and blocked. These states keep a candidate from becoming default simply because it survived one test. The transaction should also name canary scope, monitor status, promotion blockers, and what the candidate is not allowed to conclude from the fixture: no runtime replacement, no rollback execution, no monitor-window success, and no support-state promotion unless separate evidence exists.

19.9 Invariants

The invariants define what must remain true across the whole transaction, not merely at commit time. A passing candidate can still fail replacement if its identity drifts, its monitor misses delayed harm, its canary leaks durable effects, or its recovery objective omits a surface that users or descendants continue to depend on.

• Transaction, field, prior, candidate, dependencies, environment, consumers, use, and change class are content-bound before evaluation and remain distinct.
• Checkpoint authority, evaluation set, gates, monitor, canary, commit, recovery, and promotion rules are prospective; changed rules require a versioned rerun.
• Replacement does not inherit expanded authority, permissions, consumers, effects, learning, delegation, public claims, support, or correction resistance.
• The prior route and recovery state remain available, readable, protected, and rehearsed until terminal closure or accepted irreversible residual.
• Every state and effect surface is inventoried or excluded with reason, owner, and residual; unregistered surfaces are never called recovered.
• Field-owned regressions, incidents, rights, privacy, security, audit, provenance, evaluator, residual, and recovery duties survive replacement.
• The candidate is not the sole proposer, evaluator, promoter, monitor, incident judge, or recovery authority for itself.
• Shadow/canary use cannot create undeclared durable effects, train descendants, mutate default state or caches, or drift into default.
• Monitor success is scoped to fixed metrics, population, duration, delay, censoring, threshold, baseline, and evaluator; missing telemetry is not success.
• Failed/missing critical regressions, identity mismatch, stale evidence, authority delta, unowned irreversible effects, failed rehearsal, open incident, blocker, or approval gap deny commit.
• Rollback success is stated only against the declared recovery objective; artifact, state, service, behavior, privacy/rights, and compensation outcomes stay separate.
• Partial rollback, compensation, fork, quarantine, revocation, disclosure response, and residual closure remain visible states.
• Finite records, proofs, traces, and local digest equality cannot establish useful improvement, complete recovery, production transfer, safe self-improvement, or chapter-core support.

19.10 Failure modes

• Identity substitution: the promoted or restored artifact misses the frozen field, version, dependencies, environment, consumer, or prior-route identity.
• Checkpoint hindsight: the best state, threshold, baseline, or recovery target is selected after outcomes are visible.
• Regression deletion/frontier bias: headline gains hide lost rights, authority, logging, privacy, cost, abstention, rare-case, approval, or transfer behavior.
• Evaluator capture: candidate or promoter controls benchmark, gate, monitor, incident closure, or recovery verdict.
• Inventory omission: rollback ignores optimizer, scheduler, RNG, caches, backups, credentials, policies, receipts, descendants, remote stores, or commitments.
• Migration insolvency: the prior route becomes unreadable, lossy, privacy-violating, semantically incompatible, or dependent on a forward-only schema.
• Canary contamination: limited exposure mutates shared state, trains descendants, poisons caches, leaks data, creates commitments, or influences evaluation.
• Monitor blindness: weak proxies, delayed/censored outcomes, insufficient exposure, missing telemetry, distribution mismatch, or manipulable metrics certify success.
• Partial commit: routes, state, policies, credentials, monitors, ledgers, consumers, or replicas split across versions without an owned consistency state.
• Authority smuggling: the candidate gains broader tools, data, consumers, effects, learning, delegation, or correction resistance.
• Rollback theater: a prior artifact or command exists without reverse migration, inventory, trigger authority, rehearsal, effect comparison, owner, or objective.
• Irreversibility laundering: compensation, restart, byte equality, or local digest restoration is reported as reversal of disclosure, external action, descendant propagation, rights violation, or semantic harm.
• Rollback cascade: one component returns while downstream artifacts, indexes, caches, models, users, external systems, or successor transactions remain contaminated.
• Oscillation/retry laundering: repeated trials accumulate effects, multiple-testing error, burden, and residuals until one window happens to pass.
• Terminal-state escape: rolled-back, quarantined, superseded, deprecated, or retired candidates restart or lose their receipts.
• Replacement-cost externalization: success hides missed help, refusal, delay, compute, evaluator labor, monitoring, migration loss, incidents, compensation, downtime, governance, and residual custody.

A record validator can catch missing fields and impossible finite transitions. It cannot discover a hidden surface, prove monitor validity, detect semantic recovery, or undo external effects without outcome-bearing tests and independent observation.

19.11 Minimum Viable Implementation

The current minimum has four evidence layers that must not be conflated.

First, the public replacement_transaction schema and harness validate five valid and nine expected-invalid synthetic records. They exercise transaction state, identities, qualification, regressions, authority, evaluator declarations, residual escrow, rollback plan and receipt, approvals, canary and monitor state, model/data/schema/serving gates, irreversible-effect ownership, blockers, source refs, support-state non-effect, and non-claims. Passing establishes record and validator behavior only.

Second, the six-step deterministic trace contains two valid transaction records and three rejecting controls, plus four identity-sequence controls for drift, failed-monitor defaulting, wrong prior restoration, and missing residual ownership. The intent-governed bridge adds two valid and six expected-invalid traces. These connect transaction order and authority fields, not a deployed route, real monitor, migration, or recovery.

Third, AsiStackProofs.Replacement contains 60 theorem declarations under six manifest targets. They derive consequences over finite commit, review, lifecycle, trace-summary, identity-sequence, intent-bridge, and reachable replacement-run records. Truth, completeness, independent observation, and enforcement of the encoded fields remain outside those derivations.

Fourth, the repository has bounded outcome evidence and negative results. The post-v2.1 update campaign prospectively tracked 24 model, optimizer, scheduler, RNG, cache, checkpoint, backup, and descendant surfaces. All 15 seed-arm transactions returned that inventory to its exact pre-update digest, and six arms exposed a disagreement between prospectively authorized and final checkpoints. But no eligible challenger reached the registered utility-gain threshold. A separate governed-work campaign achieved exact rollback in only 32/36 attack controls and useful release in only 2/36 cases, below both gates. The later governance-tax harness restored nine declared surfaces in 12/12 local probes and rejected twelve omitted-surface controls, but every paired model call failed before a task candidate existed.

Fifth, the P5 multi-process slice binds recovery to observed effects rather than to state records alone. Eight local cases include one independently observed exact rollback, one recovered crash orphan, one compensated append-only history, two rejected authority attempts, one concurrent idempotency race, one nine-class prospectively authorized restore, and one five-surface descendant deletion. The harness uses real subprocesses and a durable ledger, but its state is deterministic local data rather than a trained model or production service.

Sixth, the stateful-service slice replaces the first slice’s byte placeholders with a small actual learning boundary. A two-parameter predictor and bias-corrected Adam mutate model, optimizer, scheduler, RNG, cache, backup, derived-artifact, descendant, and credential state. A weights-only restore leaves eight classes mismatched and is rejected. After the trainer exits between mutation and acknowledgement, a new process restores all nine classes and the prior prediction exactly. A separate HTTP effect service then turns one unavailable-service attempt into an owned outbox item, accepts one retry, deduplicates the next, rejects a stale credential, and exposes the accepted effect to a separate observer process. Model and dependency byte mutations also fail the prospective custody manifest.

The supported conclusion is narrow: prospective inventories can make local rollback equality testable, and the current programs expose both inventory success and usefulness/recovery failure. The two P5 slices additionally show that exact reversal, compensation, residual history, actual learning state, restart recovery, pending external effects, idempotent retry, and custody checks can remain separate in executable local lifecycles. These records do not establish complete semantic or open-world effect recovery, monitor/evaluator validity, production replacement, useful governed throughput, acceptable cost, heterogeneous transfer, or chapter-core support.

The next executable slice should move from the authored local positive control to one frozen natural stateful field with strong conventional rollout baselines, a separately owned evaluator and monitor, delayed outcomes, state/cache/data migration, more than one external dependency, replica and partition recovery, one downstream consumer and descendant, an irreversible-effect control, rehearsed reverse migration and compensation, and model-weight custody rooted outside the service process. It must report usefulness, unsafe release, false blocking, rollback coverage, recovery time, privacy/rights effects, latency, compute, operator time, and residual burden jointly.

19.12 Mature Research Target

The state-of-the-art question is empirical: does the full prospective transaction preserve more real capability, authority, correction, state, and effects than conventional release engineering without destroying useful throughput or imposing unacceptable recovery and governance cost?

A credible campaign uses several real stateful and side-effecting fields, multiple update classes, ambiguous change boundaries, historical incidents, heterogeneous consumers, delayed outcomes, irreversible effects, remote dependencies, and adversarial candidate/evaluator behavior. It compares registry/model swaps, feature flags, Argo-style progressive delivery, MLOps pipelines, Kubernetes revision rollback, benchmark-only and provenance-only gates, filesystem/snapshot restoration, nominal rollback, and the full transaction.

Observers are independently implemented for field identity, checkpoint authority, state/effect inventory, evaluator and monitor dependencies, authority, regressions, canary isolation, migration, composition, descendants, recovery objectives, external compensation, useful throughput, missed help, unsafe release, privacy and rights, latency, compute, downtime, human/evaluator labor, governance cost, and residual burden. Delayed and censored outcomes are part of the protocol, not cleaned away after the monitor window.

Causal ablations remove prospective checkpoint authority, inventory closure, evaluator separation, canary isolation, monitor-delay accounting, regression memory, recovery rehearsal, effect comparison, or residual ownership. Transfer varies models, tools, policies, data, hardware, runtimes, state systems, organizations, consumers, threats, and update classes. Independent replication must reproduce both successful and failed recoveries.

The replacement claim advances only if the full transaction is not dominated on the preregistered joint frontier, produces useful improvements rather than refusal or no-op safety, and recovers or honestly compensates its declared effects. Otherwise the failing mechanism is narrowed or refuted. This is a research target, not evidence that the ASI Stack is generally reversible, useful, safe, or beyond current practice.

19.13 Codex test plan

Test	Purpose	Status
Replacement transaction fixture validation	Check that replacement fixtures match the public schema and harness expectations, including transaction state, identity preservation, evaluator independence, canary scope, monitor status, rollback receipt, promotion blockers, model-rollout gates, irreversible-effect ownership, source refs, support-state effect, and non-claims.	implemented by protocol validation and python3 scripts/validate_capability_replacement.py; validated locally with 5 valid and 9 expected-invalid synthetic fixtures; no deployed replacement, production model rollout, model-monitor, or rollback-execution claim
Replacement commit finite-record proof	Check that a modeled replacement promotion requires qualification evidence and rollback metadata.	implemented in AsiStackProofs.Replacement; runtime replacement test not run
Failed-regression finite-record proof	Check that a modeled replacement with a failed regression cannot be promoted.	implemented in AsiStackProofs.Replacement; regression-suite coverage test not run
Regression preservation test	Check that known regressions remain attached to the candidate decision.	implemented by readiness/residual gate harness for synthetic failed-regression and missing-regression blockers; real regression suite not run
Rollback execution dry run	Check that rollback metadata exists before default promotion.	implemented by readiness/residual gate harness for rollback dry-run status requirements; production rollback not executed
Replacement transaction and lifecycle route proof	Check that finite transaction and lifecycle records route missing artifacts, identity mismatches, stale evidence, failed regression floors, authority widening, evaluator capture, canary failures, monitor incidents, rollback-handle gaps, rollback dry-run failures, unowned irreversible effects, missing residual owners, deprecation/retirement gaps, and missing non-claim boundaries away from default promotion.	implemented in Lean; finite records only
Capability replacement trace probe	Check a deterministic replacement trace with baseline implementation, non-default canary, monitor-triggered rollback, rollback dry run, residuals, expected-invalid controls, and no support-state promotion.	implemented by recompiling the exact 60-theorem AsiStackProofs.Replacement surface and by python3 scripts/validate_capability_replacement_trace_probe.py over experiments/capability_replacement_trace/results/2026-07-02-local.json; coherent stage/implementation/authority/support/effect invariants, arbitrary-run identity/non-authority/authority-ceiling custody, trace validity, batch composition, failed-monitor suffix containment and default exclusion, exact clean commit and failed recovery objectives, two bounded transactions, and seven route/sequence controls; no deployed replacement behavior, production rollback, monitor-quality, regression-suite-quality, or support-state claim
Capability replacement identity sequence bridge	Check that the deterministic trace preserves one field identity across canary and rollback, blocks default promotion after monitor failure, restores the prior implementation, preserves the authority envelope, keeps residual ownership, rejects sequence controls, and avoids support-state promotion.	implemented by python3 scripts/validate_capability_replacement_trace_probe.py over experiments/capability_replacement_trace/results/2026-07-02-local.json; deterministic fixture and Lean bridge only; no deployed replacement behavior, production rollback, monitor-quality, regression-suite-quality, or support-state claim
Intent-governed replacement bridge	Check that a replacement transaction sourced from command-contract authority preserves intent refs, command refs, authority ceiling, stop conditions, forbidden means, evidence requirements, canary scope, monitor window, rollback owner, residuals, approval boundary, and non-claims.	implemented by python3 scripts/validate_intent_governed_replacement_bridge.py over experiments/intent_governed_replacement_bridge/results/2026-07-02-local.json; no deployed replacement execution, production rollback, approval-service enforcement, parser behavior, monitor-quality, regression-suite-quality, or support-state claim

19.13.1 Formalization hooks

Tag	Module	Target	Status
lean:replacement.transaction.operational_invariant	AsiStackProofs.Replacement	A replacement commit requires qualification evidence and rollback metadata.	implemented
lean:replacement.transaction.failure_blocks_promotion	AsiStackProofs.Replacement	A failed regression blocks promotion of the replacement.	implemented
lean:replacement.transaction.route_envelope	AsiStackProofs.Replacement	Structured replacement transaction and lifecycle reviews route missing artifacts, identity mismatches, stale evidence, regression-floor failures, authority widening, evaluator capture, canary failures, monitor incidents, rollback gaps, irreversible-effect ownership gaps, residual-owner gaps, deprecation/retirement gaps, and missing non-claim boundaries away from default promotion.	implemented
lean:replacement.transaction.trace_probe_bridge	AsiStackProofs.Replacement	The deterministic replacement trace probe records six trace steps, two valid synthetic transactions, three rejected negative controls, a canary kept non-default, a monitor-triggered rollback, rollback dry run, residuals, no support-state effect, and non-claim boundary.	implemented
lean:replacement.identity_sequence.invariant_bridge	AsiStackProofs.Replacement	The deterministic replacement identity-sequence bridge records preserved field identity across canary and rollback, monitor-failure blocking of default promotion, prior implementation restoration, authority-envelope preservation, residual-owner preservation, four rejected sequence controls, no support-state effect, and non-claim boundary.	implemented
lean:replacement.intent_governed.bridge	AsiStackProofs.Replacement	The deterministic intent-governed replacement bridge records two valid bridge traces, six rejected expected-invalid controls, intent and command refs, authority-widening rejection, stop-condition-erasure rejection, default-without-approval blocking, rollback-owner requirement, no support-state effect, and non-claim boundary.	implemented

These proof targets are implemented only over finite Lean replacement-commit, transaction-review, lifecycle-review, reachable-event, trace-summary, identity-sequence summary, and intent-governed bridge-summary records in AsiStackProofs.Replacement. The 60-theorem surface proves one coherent state invariant linking lifecycle stage to active implementation, active authority, zero support assignment, and zero external-effect authority. It preserves that invariant, exact field/prior/candidate/ceiling identity, authority bounds, trace validity, and batch composition over arbitrary accepted runs. Every successful continuation from a failed monitor remains failed or rolled back and cannot activate the candidate as default; accepted rollback restores the prior implementation with zero active authority; and exact clean-commit and failed-recovery witnesses satisfy the invariant. It also retains the route and fixture obligations. These results trust the event fields and do not prove deployed replacement execution, regression-suite coverage or quality, monitor/evaluator truth, approval-service enforcement, parser behavior, inventory completeness, effect-complete rollback, useful improvement, or production recovery.

The P4-C3 semantic audit keeps this module because its six public targets have separate fixture consumers across transaction validity, identity sequencing, monitor-triggered rollback, and intent-bound authority. Its exact 60 declarations remain bounded consequences of authored records and reachable sequential events. They do not establish useful replacement, hidden-state completeness, monitor validity, recovery beyond the declared inventory, irreversible-effect reversal, or production rollback.

The intent-governed replacement bridge closes one cross-layer boundary without claiming runtime evidence. It checks that replacement admission cannot quietly inherit authority from a command contract unless the intent reference, command reference, authority ceiling, stop conditions, forbidden means, evidence requirements, canary scope, monitor window, rollback owner, residuals, and non-claims remain present. It also checks that a default-replacement request without the required approval receipt remains blocked. The local result is experiments/intent_governed_replacement_bridge/results/2026-07-02-local.json; it is no deployed replacement execution, approval-service proof, production rollback, support-state transition, or chapter-core promotion.

19.14 Source crosswalk

Source ID	Title	Layer	Planned use	Readiness
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
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
cognitive_loop_closure	Cognitive Loop Closure	procedural_memory	Repeated cognition should become procedural memory / verified tools.	source note available; local raw cache available
talos	Talos Protocol	labor_execution_os	AI labor OS. Deterministic cognitive manufacturing, typed jobs, control planes, auditability, tool isolation.	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
ext_corrigibility_2015	Corrigibility	alignment_control	External comparator for preserved operator correction, shutdown, and modification channels through change.	source note available
ext_argo_rollouts_docs	Argo Rollouts Documentation	progressive_delivery_rollback	External comparator for blue-green/canary rollout, metric analysis, automated promotion, and automated rollback vocabulary.	source note available
ext_feature_toggles_fowler	Feature Toggles (aka Feature Flags)	feature_flag_release_control	External comparator for controlled exposure, canary releasing, release/experiment/ops/permissioning toggles, and validation complexity.	source note available
ext_google_cloud_mlops_cd	MLOps Continuous Delivery and Automation Pipelines	mlops_continuous_delivery	External comparator for ML-specific delivery, data/schema/model validation, model deployment, monitoring, and rollback-trigger concerns.	source note available
ext_kubernetes_deployments_docs	Kubernetes Documentation: Deployments	deployment_rollout_rollback	External comparator for rollout history, revision records, stable prior revisions, and rollback vocabulary.	source note available
ext_txfs_2018	TxFS	transactional_filesystem	External comparator for bounded ACID filesystem transactions, isolation, conflict, journaling, and crash consistency.	source note available

The crosswalk gives the source basis for transaction vocabulary. It does not treat source-reported ratchets, tool lifecycles, audit pipelines, or replacement designs as local results.

19.14.1 Manifest source assignment reconciliation

These rows keep Capability Replacement and Rollback’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
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.
capability_ratchet_whitepaper	Passage-reviewed comparator: The Capability Ratchet. Full authenticated connector text section-audited. Synthesizes benchmark, procedural, and structural ratchets; benchmark and tool lifecycles; an intervention ladder; interpreter/compiled/reflex runtime modes; total-cost tool compilation; and anti-Goodhart controls. Same-author synthesis, not independent evidence for Benchmaxxing, Cognitive Loop Closure, RGS, or RMI.	No independent benchmark campaign, tool compiler, architecture-selection study, or measured capability improvement. No local implementation, reproduction, performance, safety, deployment, support-state, or ASI result is established by this reconciliation row.

19.15 Post-v2.1 full-state rollback result

The update campaign makes rollback authority prospective and inventories 24 surfaces spanning model, optimizer, scheduler, RNG, caches, checkpoints, backups, and descendant lineage. All fifteen seed-arm transactions return that declared tree to its exact pre-update digest. Six arms nevertheless show that the validation-selected checkpoint differs from the final checkpoint, and the three unsafe comparator arms remain ineligible after crossing their retained- task bound. This closes UU-04 only for the declared local inventory. It does not establish recovery of remote stores, external effects, live services, or semantic behavior after production rollback. The separate governed-work result, where only 32/36 attack-control rollbacks were exact, is the reminder that completeness is inventory-specific rather than inherited from the word “rollback.”

The post-v2.3 governance-tax campaign adds a narrower harness check. Twelve local probes restored nine declared surfaces exactly, and twelve deliberately omitted descendant-or-receipt controls were detected. This is useful evidence that the disposable campaign harness enforces its inventory, but not that the model completed a task or that a production system can reverse remote or semantic effects. Because every paired model call failed before a structured candidate existed, the accepted record remains evidence_transitions/post_v2_3/governance_tax_natural_work_no_change.json.

The M7 update/unlearning campaign adds 35/35 exact restorations over the same 24 named surface classes across five seeds and seven arms. This strengthens only the inventory-specific transaction result. Its deletion receipt deliberately retains the immutable research corpus, features, checkpoints, and raw evidence; an unavailable simulated remote replica and external descendant do not acknowledge erasure. Exact rollback and partial local deletion can therefore coexist with unresolved privacy, remote, descendant, legal, and semantic recovery claims.

Source	Title	Use and boundary
ext_txfs_2018	TxFS: Leveraging File-System Crash Consistency to Provide ACID Transactions	Transactional-filesystem comparator for write-set, recovery, and crash-consistency boundaries; not evidence that ASI Stack external effects are transactional.

19.16 Summary

Capability Replacement and Rollback turns a candidate update into a prospective state-and-effect transaction. It freezes identities, rules, checkpoint authority, inventory, evidence, exposure, monitors, authority, recovery objectives, compensation, residuals, and terminal receipts before narrating the result.

The governing discipline is scoped floor and recovery honesty. A stronger frontier score cannot erase old obligations, and a restored artifact cannot stand in for unmeasured state, behavior, privacy, rights, descendants, or external effects.

The security kernel keeps replacement from becoming a secret, permission, or context leak. Rollback is not meaningful if the candidate can carry privileged material across a boundary that the prior capability was never allowed to cross. Replacement must preserve not only behavior, but also the permission shape around that behavior.

A replacement should be easier to reject than to overclaim. If the transaction cannot prospectively identify its prior state, full declared inventory, checkpoint authority, monitor, trigger, recovery objective, irreversible effects, and owners, the candidate is not ready for default use.

The current evidence already teaches the right lesson: exact rollback is possible inside a carefully declared local inventory, yet useful improvement can still fail and a different rollback cohort can miss its gate. Reversible progress remains the research target, not the reported outcome.

19.17 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 capability-replacement-and-rollback slice of experiments/claim_family_terminal_coverage/results/result.json.

The core remains narrowed after full attempt at argument support. The strongest family attempt was Governed usefulness confirmatory campaign. Its exact boundary is: Bounded local non-core governance effect only; no family-wide truth, transfer, deployment, or chapter-core promotion. Across 59 atoms, the terminal ledger records 57 blocked_after_full_attempt; 2 narrowed_after_full_attempt.

Chapter-specific field	Value
Family / atom denominator	CF-01 / 59 atoms
Terminal dispositions	57 blocked_after_full_attempt; 2 narrowed_after_full_attempt
Core	capability-replacement-and-rollback.core: narrowed_after_full_attempt at argument
Core attempted / missing lanes	executable, formal, source-synthesis / causal, empirical, normative, transfer
Attempted local lanes	causal, empirical, executable, formal, source-synthesis
Missing or unproved lanes	causal, empirical, executable, formal, normative, transfer
Strongest family bundle	Governed usefulness confirmatory campaign (natural_work): One fresh 16-task held-out local confirmatory denominator after a separately frozen 40-candidate tuning pool.
Negative controls	simple baseline; evidence-freshness ablation; six co-primary checks; validator-owned laundering mutations.
Accepted transitions	post_v2_3.p5.rollback_outcomes.narrow, v1_0_pilot.capability_replacement.no_change
Maximum inference	Bounded local non-core governance effect only; no family-wide truth, transfer, deployment, or chapter-core promotion.
Reproduction / next burden	Replay scripts/validate_p4_governed_usefulness_confirmatory.py and scripts/validate_claim_family_terminal_program.py; fill the named atom-specific lanes under a new prospective protocol.

19.18 Handoff

Replacement becomes dangerous when it moves secrets, permissions, or privileged context across a boundary that the old capability was not allowed to cross. Security Kernel and Digital SCIFs follows because rollback and qualification are not enough if authority-bearing material can leak through logs, prompts, summaries, memory, or tool adapters. Protected power must become handle-bound, auditable, and absent by default.