RS5B-CLOSEOUT-PATCH1 02 — Dependency-Safe Rollback Contract C1–C7 — 2026-06-21
RS5B-CLOSEOUT-PATCH1 02 — Dependency-Safe Rollback Contract C1–C7 — 2026-06-21
Scope: close Codex HOLD §5 / §11.1–§11.2 (residuals R1–R6). Replace the destructive "drop/disable" rollback language in closeout file 06 with a dependency-safe rollback contract: versioned supersession / retire-with-history / compatibility / compensating transition — never destructive deletion.
Gate: REGISTRATION_HOLD · REGISTRATION_CAN_PROCEED = NO · 0 mutations (design-only). Defining a rollback contract authorizes no rollback execution (invariant I10).
This file does not reopen Job A. It corrects only the per-carrier rollback semantics that Codex rejected.
1. Why "present rollback" is not "valid rollback"
Closeout file 06 gave every carrier a one-line rollback, and closeout file 05 R6 / file 07 XBI-7 accepted any carrier that had such a line. Codex §5 (final ¶): "R6 and XBI-7 only test whether a rollback plan is present. They do not reject a destructive, dependency-unsafe, or history-erasing plan." Therefore a plan that says "drop the vocabulary contract" passed the old gate while being exactly the action that orphans every C2 effect that referenced it.
PATCH1 inverts the burden: a rollback is valid only if it provably preserves the invariants below. "Deletion is not rollback" (Codex §13 Permanent declaration). A present-but-destructive plan is rejected (file 04 oracle) before any PASS is reachable.
2. Mandatory rollback invariants (every carrier, conjunctive)
A rollback is valid only if it preserves all of:
- I1 — Stable identity. Existing IDs referenced by C2 / audit / prior decisions remain resolvable after rollback. (Violation ⇒
ROLLBACK_DELETES_REFERENCED_IDENTITY.) - I2 — Historical evidence. Prior hashes, owner/scope facts, approval evidence, policy refs, and vocabulary values remain readable for historical effects. (Violation ⇒
ROLLBACK_ERASES_HISTORY.) - I3 — Reference integrity. No existing reference edge becomes dangling/orphaned. (Violation ⇒
ROLLBACK_ORPHANS_DEPENDENCY.) - I4 — Semantic immutability. The interpretation of a prior envelope does not silently change. (Violation ⇒
ROLLBACK_CHANGES_HISTORICAL_SEMANTICS.) - I5 — Authority non-weakening. Rollback cannot reduce approval / quorum / owner / policy requirements for already-bound effects. (Violation ⇒
ROLLBACK_WEAKENS_AUTHORITY.) - I6 — Forward fail-closed. New use of a retired/superseded carrier value must fail unless an explicit successor transition exists. (Violation ⇒ used together with
ROLLBACK_SUCCESSOR_RULE_ABSENTwhen no successor; a rollback that silently lets new use of a retired value succeed is not fail-closed.) - I7 — Reversibility / compensating transition. Rollback must be versioned supersession, soft-disable, retire-with-successor, or compensating transition — never destructive deletion. (Violation ⇒
ROLLBACK_SUCCESSOR_RULE_ABSENT/ROLLBACK_DELETES_REFERENCED_IDENTITY.) - I8 — Auditability. The rollback action itself has an audit record and a
rollback_ref. (Violation ⇒ROLLBACK_AUDIT_TRAIL_ABSENT.) - I9 — Locality. Rolling back one carrier cannot require silent mutation of another carrier. (Violation ⇒
ROLLBACK_NOT_LOCAL.) - I10 — No runtime permission. Defining the rollback contract does not authorize executing the rollback. A rollback execution is a separate, separately-authorized runtime act under its own gate (Gate B / a later P3-grade gate) and the global
RUNTIME_MUTATION_REJECTEDshort-circuit (file 04 RBP-0) applies to any rollback write observed in design/review.
Necessary-not-sufficient. Satisfying I1–I10 yields only ROLLBACK_CONTRACT_VALID_FOR_REVIEW (file 04 RBP-PASS) — a design-review property, not runtime permission, not permission to execute rollback, not P2 authorization.
3. Allowed vs forbidden rollback pattern, per carrier
For each carrier: allowed rollback (the only contract-valid pattern), forbidden (what Codex rejected), postcondition (the invariant-derived guarantee that must hold after rollback). Carrier identities (C1–C7) are the file-06 carriers; PATCH1 changes only their rollback lines.
C1 — canonical_operation vocabulary contract
- Allowed rollback: retire a vocabulary version or operation value by marking it superseded/retired; keep the old value resolvable; add a successor mapping if a replacement value exists.
- Forbidden: drop/disable the vocabulary contract or value if any C2 / effect / digest references it (the old file-06 line "drop/disable the vocabulary contract" is superseded — file 07 row 1).
- Postcondition: every historical effect that hashed a retired
canonical_operationvalue still resolves (I1, I2); the reference edge C1→C2 stays intact (I3); new use of a retired value is fail-closed unless a successor policy maps it (I6); change is versioned (I7); rollback recorded withrollback_ref(I8); no C2 mutation required (I9).
C2 — effect_identity / authorization_binding_digest schema
- Allowed rollback: schema version supersession — introduce a successor
protocol_version; oldprotocol_versionpackets remain readable and verifiable under their original schema. - Forbidden: mutate the meaning of old digest fields; remove
effect_identityfrom a historical binding (would re-triggerAUTHORIZATION_BINDING_MISSING_EFFECTretroactively and violate Job A). - Postcondition: old envelopes verify under their old version (I4 — no silent reinterpretation); historical
effect_identity/authorization_binding_digestvalues stay resolvable (I1, I2); new packets use the successor (I6, I7); local to C2 (I9).
C3 — owner / scope binding carrier
- Allowed rollback: revoke or supersede the owner/scope row by setting a status and a successor/ref, preserving the row identity and its audit trail.
- Forbidden: delete an owner/scope row referenced by a binding, audit record, or prior decision (the old file-06 line "revoke/drop a single ownership row independently" — the "drop" branch — is superseded; revocation ≠ deletion, Codex §5.2; file 07 row 2).
- Postcondition: historical bindings still identify the prior owner/scope (I1, I2, I3); future authority is fail-closed if the row is revoked (I5 — authority can only be removed-going-forward, never retroactively granted or weakened); the audit edge C3→history is preserved (I2, I8); local (I9).
C4 — artifact hash carrier
- Allowed rollback: mark the hash record superseded / invalid-for-new-use; preserve the hash record for reproducibility.
- Forbidden: drop a hash record referenced by
effect_identity/ audit / authorization packet (old file-06 line "drop a hash record" — superseded; file 07 row 3). - Postcondition: old artifact proof remains reproducible (I2);
effect_identityvalues that hashedcanonical_artifact_hashstay resolvable (I1); new use follows the successor hash and is fail-closed against a retired hash (I6); local to C4 (I9); recorded (I8).
C5 — U3 / status / audit policy references
- Allowed rollback: policy version supersession; preserve the prior policy text/ref; new use requires the successor; old C2 references resolve to the preserved prior policy.
- Forbidden: disable/delete a referenced policy without a compatibility/supersession rule (old file-06 line "disable one policy reference" — superseded; Codex §5.4; file 07 row 4).
- Postcondition: old C2 references (
u3_head_policy_ref/status_policy_ref/audit_policy_ref) remain interpretable (I3, I4); prior policy readable (I2); successor governs new use (I6, I7); local (I9).
C6 — replay / nonce carrier
- Allowed rollback: retire the nonce policy version or issuer; preserve consumed-nonce and replay-decision audit records.
- Forbidden: delete nonce history or reset the replay surface (a reset would make a previously consumed nonce reusable — an authority/safety regression). The old file-06 line "disable the replay surface without touching effect identity" is superseded to this preserve-history form (file 07 — C6 row).
- Postcondition: old replay decisions remain auditable (I2, I8); no nonce reuse becomes possible after rollback (I5 — replay protection may not weaken); local to C6 (I9); versioned (I7).
C7 — approval / quorum / principal carrier (presence governed by approval_mode, file 05)
- Allowed rollback: retire/supersede the approval policy / principal-resolution version; preserve approval evidence for old effects.
- Forbidden: disable approval-as-a-check in a way that retroactively weakens old approval-required envelopes or erases prior approval evidence (old file-06 line "disable approval-as-a-check" — superseded; Codex §5.5; file 07 row 5).
- Postcondition: old approval-required effects still require their original evidence (I5 — no retroactive weakening); prior approval evidence stays readable (I2); the new policy mode is explicit and applies forward only (I4, I6); the audit edge C7→history is preserved (I8); local (I9). C7's existence is conditional on
approval_mode(file 05); its rollback, when C7 exists, obeys this row.
4. Mapping invariants → carriers (coverage matrix)
| Invariant | C1 | C2 | C3 | C4 | C5 | C6 | C7 |
|---|---|---|---|---|---|---|---|
| I1 stable identity | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| I2 historical evidence | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| I3 reference integrity | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| I4 semantic immutability | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| I5 authority non-weakening | — | — | ✔ | — | — | ✔ | ✔ |
| I6 forward fail-closed | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| I7 versioned/compensating | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| I8 auditability | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| I9 locality | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| I10 no runtime permission | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
(I5 is marked only where the carrier carries an authority requirement that could be weakened — C3 owner authority, C6 replay protection, C7 approval requirement. For C1/C2/C4/C5 the authority-non-weakening obligation is discharged transitively because their rollback cannot alter the authority fields of a historical authorization_binding_digest — those live in C3/C6/C7.)
5. LEGO boundary preserved
Each carrier's rollback is still a separate LEGO action: born/tested/changed/rolled-back/joined separately (file 06 §1 retained). PATCH1 adds dependency-safety without merging carriers — invariant I9 (locality) explicitly forbids a rollback that requires silent mutation of another carrier, which is precisely the mega-registry collapse the LEGO rule forbids. No mega-registry / mega-graph / mega-birth pipeline is introduced. LEGO_BOUNDARY_HELD.
6. Boundary attestation
This file changes no runtime state, creates no carrier, executes no rollback, and clears no blocker. It defines the rollback contract; execution is separately authorized and out of scope (I10). REGISTRATION_HOLD retained.