KB-4164

RS5B-CLOSEOUT-PATCH1 02 — Dependency-Safe Rollback Contract C1–C7 — 2026-06-21

12 min read Revision 1
rs5b-closeout-patch1dependency-safe-rollbackrollback-invariantsversioned-supersessioncarrier-c1-c7registration-hold2026-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_ABSENT when 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_REJECTED short-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_operation value 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 with rollback_ref (I8); no C2 mutation required (I9).

C2 — effect_identity / authorization_binding_digest schema

  • Allowed rollback: schema version supersession — introduce a successor protocol_version; old protocol_version packets remain readable and verifiable under their original schema.
  • Forbidden: mutate the meaning of old digest fields; remove effect_identity from a historical binding (would re-trigger AUTHORIZATION_BINDING_MISSING_EFFECT retroactively and violate Job A).
  • Postcondition: old envelopes verify under their old version (I4 — no silent reinterpretation); historical effect_identity/authorization_binding_digest values 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_identity values that hashed canonical_artifact_hash stay 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.

Back to Knowledge Hub knowledge/dev/laws-new/reports/rs5b-closeout-patch1/02-dependency-safe-rollback-contract-c1-c7-2026-06-21.md