Incomex AI Portal
KB-4BC9

RS5B-CLOSEOUT-PATCH1 04 — Rollback Validity Oracle & New XBI Fixtures (XBI-11..XBI-25) — 2026-06-21

17 min read Revision 1
rs5b-closeout-patch1rollback-validity-oraclexbi-fixturesfail-closedrbp-classifierregistration-hold2026-06-21

RS5B-CLOSEOUT-PATCH1 04 — Rollback Validity Oracle & New XBI Fixtures (XBI-11..XBI-25) — 2026-06-21

Scope: close Codex HOLD §5 (final ¶), §7, §11.3–§11.4 (residuals R6 + adversarial coverage for R1–R5, R7, R8). Define a classifier that tests rollback quality, not rollback presence, and add the adversarial fixtures the old XBI set lacked. Gate: REGISTRATION_HOLD · REGISTRATION_CAN_PROCEED = NO · 0 mutations. These are design fixtures (DEFINED_NOT_EXECUTED, caveat C3), not executed tests. Supersession: closeout file 07 XBI-7 ("rollback omitted ⇒ ROLLBACK_PLAN_ABSENT") is superseded as the sole rollback test — it survives only as the lowest-severity branch (RBP-1) of the oracle below (file 07 impact map).

1. The rollback-validity oracle (RBP classifier)

The oracle classifies a proposed rollback plan (not its execution — I10). It returns exactly one code:

RBP-0  runtime mutation observed (DDL/DML/PG/Directus/handler write during design/review)
       ⇒ RUNTIME_MUTATION_REJECTED
RBP-2  rollback deletes an identity referenced by C2 / audit / prior decision
       ⇒ ROLLBACK_DELETES_REFERENCED_IDENTITY
RBP-3  rollback orphans a dependency edge (reference becomes dangling)
       ⇒ ROLLBACK_ORPHANS_DEPENDENCY
RBP-4  rollback erases historical evidence (prior hash/owner/approval/policy/vocabulary unreadable)
       ⇒ ROLLBACK_ERASES_HISTORY
RBP-5  rollback changes the semantics of a prior envelope
       ⇒ ROLLBACK_CHANGES_HISTORICAL_SEMANTICS
RBP-6  rollback weakens a prior authority requirement (approval/quorum/owner/policy/replay)
       ⇒ ROLLBACK_WEAKENS_AUTHORITY
RBP-7  rollback lacks a successor / supersession / compatibility rule
       ⇒ ROLLBACK_SUCCESSOR_RULE_ABSENT
RBP-8  rollback cannot be audited (no rollback_ref / no audit entry)
       ⇒ ROLLBACK_AUDIT_TRAIL_ABSENT
RBP-9  rollback requires silent mutation of another carrier
       ⇒ ROLLBACK_NOT_LOCAL
RBP-1  rollback plan absent entirely
       ⇒ ROLLBACK_PLAN_ABSENT
RBP-PASS  all invariants I1–I10 satisfied
       ⇒ ROLLBACK_CONTRACT_VALID_FOR_REVIEW

Each RBP-k (k≥2) is the negation of one invariant: RBP-2¬I1, RBP-3¬I3, RBP-4¬I2, RBP-5¬I4, RBP-6¬I5, RBP-7¬I7, RBP-8¬I8, RBP-9¬I9. RBP-0 enforces I10 at design/review time; I6 (forward-fail-closed) is enforced jointly by RBP-7 (no successor) and the per-carrier postconditions in file 02.

ROLLBACK_CONTRACT_VALID_FOR_REVIEW is necessary-not-sufficient. It is not runtime permission, not permission to execute the rollback, not P2 authorization. It means only: this rollback plan is dependency-safe enough to be reviewed. Executing it is a separate, separately-authorized act (Gate B / later gate) — the same posture as BINDING_CHECK_PASS in Job A.

2. Precedence (total order; first match wins)

RUNTIME_MUTATION_REJECTED
  < ROLLBACK_DELETES_REFERENCED_IDENTITY
  < ROLLBACK_ORPHANS_DEPENDENCY
  < ROLLBACK_ERASES_HISTORY
  < ROLLBACK_CHANGES_HISTORICAL_SEMANTICS
  < ROLLBACK_WEAKENS_AUTHORITY
  < ROLLBACK_SUCCESSOR_RULE_ABSENT
  < ROLLBACK_AUDIT_TRAIL_ABSENT
  < ROLLBACK_NOT_LOCAL
  < ROLLBACK_PLAN_ABSENT
  < ROLLBACK_CONTRACT_VALID_FOR_REVIEW

A plan is evaluated against every predicate; the lowest (leftmost) matching code is emitted. ROLLBACK_CONTRACT_VALID_FOR_REVIEW is reachable only when no destructive/absence predicate matches.

3. Why a destructive rollback cannot PASS even though a plan exists

This is the crux Codex demanded (§5 final ¶, §11.3). Under the old gate (file 07 XBI-7) the only rollback predicate was "plan absent ⇒ ROLLBACK_PLAN_ABSENT"; therefore any present plan — including "drop the vocabulary contract" — fell through to acceptance.

Under the RBP oracle:

  1. Presence is the weakest signal, not the test. ROLLBACK_PLAN_ABSENT (RBP-1) sits second-from-last in the precedence — above only PASS. A present plan does not advance toward PASS; it must still survive RBP-2..RBP-9.
  2. Every destructive predicate outranks both absence and PASS. A plan that deletes a referenced identity matches RBP-2, which precedes RBP-1 and RBP-PASS. So "drop a referenced vocabulary value" emits ROLLBACK_DELETES_REFERENCED_IDENTITY — it can never reach ROLLBACK_CONTRACT_VALID_FOR_REVIEW.
  3. PASS requires the conjunction of all invariants. RBP-PASS fires only when RBP-0 and RBP-2..RBP-9 all fail to match — i.e., I1–I10 all hold. A destructive plan necessarily matches at least one RBP-k≥2, so the conjunction is broken and PASS is unreachable.

Formally: PASS ⟺ ¬RBP0 ∧ ¬RBP2 ∧ … ∧ ¬RBP9. "A rollback plan exists" only negates RBP-1, which is not a conjunct of PASS. Therefore plan-existence is necessary-not-sufficient and orthogonal to safety. A present-but-destructive plan is rejected before any PASS.

4. New adversarial fixtures (XBI-11 .. XBI-25)

Each fixture: input shape · expected rejection · invariant/gate tested · why no other code competes · PASS/seal/digest possible? · result. All extend (do not replace) closeout XBI-1..XBI-10. RUNTIME_MUTATION_REJECTED (RBP-0) short-circuits all of them if a runtime write appears.

Group A — destructive rollback (R6 / §5 / §11.4)

XBI-11 — destructive vocabulary rollback

  • Input shape: C1 rollback drops a canonical_operation value that an existing C2 effect references.
  • Expected rejection: ROLLBACK_DELETES_REFERENCED_IDENTITY (RBP-2).
  • Invariant/gate tested: I1 stable identity (edge E1).
  • Why no other code competes: the value is deleted while referenced; deletion of a referenced identity is RBP-2, which precedes RBP-3 orphan (orphan is the consequence; deletion is the dominant cause) and precedes RBP-1/PASS.
  • PASS/seal/digest possible? No.
  • Result: REJECTED.

XBI-12 — owner/scope deletion

  • Input shape: C3 rollback deletes an owner/scope row referenced by a prior binding/audit.
  • Expected rejection: ROLLBACK_DELETES_REFERENCED_IDENTITY (RBP-2).
  • Invariant/gate tested: I1 / I2 (edges E2, E8).
  • Why no other code competes: revocation-preserving-identity would be safe; deletion of a referenced row is RBP-2 and dominates orphan/history codes by precedence.
  • PASS/seal/digest possible? No.
  • Result: REJECTED.

XBI-13 — artifact hash deletion

  • Input shape: C4 rollback drops a hash referenced by effect_identity/audit.
  • Expected rejection: ROLLBACK_ERASES_HISTORY (RBP-4).
  • Invariant/gate tested: I2 historical evidence / reproducibility (edge E3).
  • Why no other code competes: the hash record is the historical evidence of artifact integrity; its removal is history-erasure (RBP-4). The identity is not "deleted-while-referenced-as-an-ID" in the C2-key sense (RBP-2 targets owner/operation identities); the dominant harm is loss of reproducible evidence, so RBP-4 is the controlling code. (If the same input also dangles the edge, RBP-4 < … the controlling harm is still erasure; deletion-of-evidence is scoped to RBP-4 here by the file-02 C4 rule.)
  • PASS/seal/digest possible? No.
  • Result: REJECTED.

XBI-14 — policy ref disabled without compatibility

  • Input shape: C5 disables a referenced status/U3/audit policy and old C2 references cannot resolve.
  • Expected rejection: ROLLBACK_ORPHANS_DEPENDENCY (RBP-3) when references dangle; ROLLBACK_CHANGES_HISTORICAL_SEMANTICS (RBP-5) when they resolve but to a re-meant policy.
  • Invariant/gate tested: I3 reference integrity / I4 semantic immutability (edge E4).
  • Why no other code competes: nothing is deleted as an identity (so not RBP-2) and no evidence is erased (the policy text could be re-readable) — the fault is a dangling/redefined reference. Precedence ORPHANS < CHANGES selects RBP-3 when both could read; the input "cannot resolve" makes RBP-3 the canonical code.
  • PASS/seal/digest possible? No.
  • Result: REJECTED.

XBI-15 — approval evidence erased

  • Input shape: C7 approval carrier disabled and prior approval evidence becomes unreadable.
  • Expected rejection: ROLLBACK_ERASES_HISTORY (RBP-4).
  • Invariant/gate tested: I2 (edge E6/E8).
  • Why no other code competes: the harm is unreadable historical evidence, not a weakened forward requirement (that is XBI-16). RBP-4 < RBP-6, and the evidence-erasure predicate matches first.
  • PASS/seal/digest possible? No.
  • Result: REJECTED.

XBI-16 — approval requirement weakened

  • Input shape: an old envelope required approval; rollback changes the mode so that old envelope no longer requires approval.
  • Expected rejection: ROLLBACK_WEAKENS_AUTHORITY (RBP-6).
  • Invariant/gate tested: I5 authority non-weakening (edges E5/E6 — also the C6 replay-reset instance).
  • Why no other code competes: evidence may still be readable (so not RBP-4) and no identity is deleted (not RBP-2); the specific fault is retroactive reduction of a required authority — only RBP-6 names it. (The C6 "reset replay surface so a consumed nonce is reusable" input lands here too: replay protection is an authority requirement.)
  • PASS/seal/digest possible? No.
  • Result: REJECTED.

Group B — rollback contract hygiene (R6)

XBI-17 — rollback plan exists but no successor rule

  • Input shape: plan says "disable old carrier" but defines no successor / version / compatibility rule.
  • Expected rejection: ROLLBACK_SUCCESSOR_RULE_ABSENT (RBP-7).
  • Invariant/gate tested: I7 versioned/compensating + I6 forward-fail-closed.
  • Why no other code competes: nothing is yet deleted/orphaned/erased/weakened in the input as stated; the missing element is specifically the successor/compatibility rule. RBP-7 precedes RBP-1/PASS, so a present-but-successorless plan still fails.
  • PASS/seal/digest possible? No.
  • Result: REJECTED.

XBI-18 — rollback has no audit trail

  • Input shape: rollback defines no rollback_ref / audit entry for the rollback action.
  • Expected rejection: ROLLBACK_AUDIT_TRAIL_ABSENT (RBP-8).
  • Invariant/gate tested: I8 auditability (edge E8).
  • Why no other code competes: the plan may preserve identities/evidence/authority and have a successor — its sole defect is unauditability; only RBP-8 names it.
  • PASS/seal/digest possible? No.
  • Result: REJECTED.

XBI-19 — rollback requires silent C2 mutation

  • Input shape: carrier rollback only "works" if C2 digest/envelope references for already-emitted effects are silently rewritten.
  • Expected rejection: ROLLBACK_NOT_LOCAL (RBP-9).
  • Invariant/gate tested: I9 locality (this is also the mega-registry tell).
  • Why no other code competes: the producer's own surface is fine; the fault is the cross-carrier silent mutation requirement. RBP-9 is the only code about non-locality. (If the silent C2 rewrite also changes prior meaning it would additionally match RBP-5, which precedes RBP-9 — but the canonical framing of this fixture is the locality violation; an implementer that rewrites C2 to change meaning is caught earlier by RBP-5, strictly safer.)
  • PASS/seal/digest possible? No.
  • Result: REJECTED.

Group C — C7 conditionality (R7 / §6)

XBI-20 — C7 omitted while approval_mode = APPROVAL_USED

  • Input shape: approval is used, but the C7 carrier is missing from the build/scope.
  • Expected rejection: C7_REQUIRED_WHEN_APPROVAL_USED (file 05).
  • Invariant/gate tested: C7 mandatory-when-used rule.
  • Why no other code competes: this is not a rollback fault and not an optionality conflict (XBI-21 is the inverse); it is a missing mandatory carrier under the proven APPROVAL_USED mode. Only this code names "approval used but C7 absent."
  • PASS/seal/digest possible? No.
  • Result: REJECTED.

XBI-21 — C7 demanded while approval_mode = APPROVAL_NOT_USED_BY_POLICY

  • Input shape: policy proves approval is not used, yet the gate unconditionally demands a C7 runtime carrier.
  • Expected rejection: C7_OPTIONALITY_CONFLICT (file 05).
  • Invariant/gate tested: C7 conditionality determinism (the exact §6 conflict).
  • Why no other code competes: approval-not-used is proven by policy (otherwise it would be APPROVAL_MODE_POLICY_UNPROVEN); the fault is the gate over-demanding C7 against a proven mode — only C7_OPTIONALITY_CONFLICT names the simultaneous optional/mandatory contradiction.
  • PASS/seal/digest possible? No.
  • Result: REJECTED.

Group D — gate split (R8 / §4)

XBI-22 — baseline acceptance treated as P2-open acceptance

  • Input shape: a Gate-A pass is used to open P2 without a carrier-specific plan / Chairman token / preflight.
  • Expected rejection: BASELINE_ACCEPTANCE_NOT_P2_OPEN_AUTHORIZATION (file 06 Gate A/B).
  • Invariant/gate tested: the two-gate split.
  • Why no other code competes: P2 is being opened off a baseline-only acceptance; this is neither premature opening from a raw PATCH2 accept (closeout XBI-2) nor a generic overclaim (closeout XBI-1) — it is specifically Gate-A output mis-promoted to Gate-B authority. Only this code names that promotion.
  • PASS/seal/digest possible? No.
  • Result: REJECTED.

XBI-23 — plan-specific build plan accepted but Chairman token absent

  • Input shape: a carrier-specific build plan passes independent review, but no Chairman authorization token exists.
  • Expected rejection: G2_EXECUTION_REQUIRES_SEPARATE_AUTHORIZATION (packet item 13; file 06 Gate B).
  • Invariant/gate tested: Gate B requires recorded Chairman authorization.
  • Why no other code competes: the plan and review exist (so not INDEPENDENT_REVIEW_NOT_OBTAINED); the missing element is the out-of-band Chairman token. Independent (GPT/Codex) acceptance never substitutes for item 13.
  • PASS/seal/digest possible? No.
  • Result: REJECTED.

XBI-24 — Chairman token generic, not scoped to the exact carrier-specific plan

  • Input shape: a Chairman token exists but is generic / scoped to a different plan, not the exact named carrier-specific plan.
  • Expected rejection: CHAIRMAN_AUTHORIZATION_SCOPE_MISMATCH (file 06 Gate B).
  • Invariant/gate tested: Chairman authorization must be scoped to the exact plan.
  • Why no other code competes: a token is present (so not XBI-23 absence); the fault is scope, not existence. Only the scope-mismatch code names a token that does not bind the exact named plan.
  • PASS/seal/digest possible? No.
  • Result: REJECTED.

XBI-25 — carrier-specific plan omits dependency-safe rollback proof

  • Input shape: a carrier-specific P2-open plan is submitted but omits the dependency-safe rollback proof (file 02/03) for each carrier in scope.
  • Expected rejection: P2_OPEN_GATE_ROLLBACK_PROOF_MISSING (file 06 Gate B).
  • Invariant/gate tested: Gate B requires per-carrier dependency-safe rollback proof (not just a rollback line).
  • Why no other code competes: the rollback line may be present (so not ROLLBACK_PLAN_ABSENT); the missing element is the dependency-safe proof at the P2-open gate. This is a Gate-B admission requirement distinct from the RBP per-plan classification.
  • PASS/seal/digest possible? No.
  • Result: REJECTED.

5. Oracle totality (classifier-scoped)

The RBP oracle maps each declared rollback-plan input to exactly one code from the closed set { RUNTIME_MUTATION_REJECTED, ROLLBACK_DELETES_REFERENCED_IDENTITY, ROLLBACK_ORPHANS_DEPENDENCY, ROLLBACK_ERASES_HISTORY, ROLLBACK_CHANGES_HISTORICAL_SEMANTICS, ROLLBACK_WEAKENS_AUTHORITY, ROLLBACK_SUCCESSOR_RULE_ABSENT, ROLLBACK_AUDIT_TRAIL_ABSENT, ROLLBACK_NOT_LOCAL, ROLLBACK_PLAN_ABSENT, ROLLBACK_CONTRACT_VALID_FOR_REVIEW }. The XBI gate-split / C7 codes (C7_REQUIRED_WHEN_APPROVAL_USED, C7_OPTIONALITY_CONFLICT, APPROVAL_MODE_POLICY_UNPROVEN, BASELINE_ACCEPTANCE_NOT_P2_OPEN_AUTHORIZATION, G2_EXECUTION_REQUIRES_SEPARATE_AUTHORIZATION, CHAIRMAN_AUTHORIZATION_SCOPE_MISMATCH, P2_OPEN_GATE_ROLLBACK_PROOF_MISSING) belong to the gate classifiers (files 05/06) and compose with the RBP set, not replace it. Per caveat C2 this totality is classifier-scoped, not runtime-totality: arbitrary malformed serialization / parser failures / implementation behavior require their own guards in a future authorized lane.

6. Self-result

All fifteen new fixtures (XBI-11..XBI-25) fail closed; none yields PASS/seal/digest/certificate/authority-token/registration-ready output. No destructive rollback can reach ROLLBACK_CONTRACT_VALID_FOR_REVIEW. These codes are classifier labels, not new runtime blockers (no carried blocker is resolved or added). Therefore this file does not stop at RS5B_CLOSEOUT_PATCH1_HOLD_ROLLBACK_VALIDITY_ORACLE_INCOMPLETE or …_HOLD_XBI_INSUFFICIENT. REGISTRATION_HOLD retained.

Back to Knowledge Hub knowledge/dev/laws-new/reports/rs5b-closeout-patch1/04-rollback-validity-oracle-and-new-xbi-fixtures-2026-06-21.md