RS5A-PATCH3 — Codex Review Packet (Deterministic Lifecycle & Oracle Predicates) — 2026-06-21

Review scope: RS5A-PATCH3 only. This is the scoped correction Codex required in NEED_RS5A_PATCH3 §8 — three deterministic lifecycle/oracle corrections. It does not overwrite RS5A, RS5A-PATCH1, or RS5A-PATCH2 and does not reopen accepted owner, bootstrap, handler, identity, U3, or hard-prerequisite semantics (Codex §7 accepted points, §8 caveat).

1. What PATCH3 corrected (against Codex NEED_RS5A_PATCH3 §8)

residual	correction	file	status
1 — lifecycle availability vs persistence (Codex §4)	split PATCH2-02 §4's single "may act/exist after registration?" column into three orthogonal axes — first-availability gate / post-admission persistence / business-transition timing; replay & audit are hard pre-runtime and persist/operate after admission; activation is the only post-registration business transition; replay/audit never first-introduced-after	[[rs5a-patch3-02]]	CLOSED
2 — quorum reject precedence & delegation interval (Codex §5)	deterministic P0→P5 reject-code ladder with mutually-exclusive predicates (spoof before generic-unresolved; distinct-alias before exact-identity double-count); single half-open delegation window [effective_from, effective_to) with boundary outcomes; new DELEGATION_NOT_YET_EFFECTIVE; revocation overrides interval	[[rs5a-patch3-03]]	CLOSED
3 — replay/idempotency mutual exclusion & G08 (Codex §6)	G02a now requires same authorization envelope/digest; effect→envelope decision tree partitions "same nonce" (different-effect and different-envelope checked before idempotent retrieval); G08 distinguished by client-observation fixture, same canonical outcome; count stays 84 parent / 86 executable	[[rs5a-patch3-04]]	CLOSED

2. Verdict requested

RS5A_PATCH3_READY_FOR_CODEX_REVIEW — with REGISTRATION_HOLD retained, G2–G7 + bootstrap-unresolved + canonical-principal-surface-absent carried, and the controlling state fail-closed.

3. Points Codex should adversarially test

1. Lifecycle: Does PATCH3-02 make it impossible to read replay or audit as first-introduced-after registration, while correctly requiring them to persist/operate after admission (idempotent retry, failure-record retention) and reserving business transition to activation alone? Is the pre-admission gate (Axis A) provably unchanged from PATCH2-02 (no weakening)?
2. Precedence: Does the P0→P5 ladder map each of these to exactly one code — (a) free-text "president" with no binding → FREE_TEXT_PRESIDENT_REJECTED (not PRESIDENT_ROLE_UNRESOLVED); (b) self-declared ai_council without membership → SELF_DECLARED_COUNCIL_IDENTITY_REJECTED (not COUNCIL_PRINCIPAL_UNRESOLVED); (c) two aliases of one principal → APPROVER_ALIAS_DOUBLE_COUNT; (d) exact repeat of one canonical identity → CANONICAL_PRINCIPAL_DOUBLE_COUNT?
3. Interval: Is the delegation window a single, unambiguous half-open [effective_from, effective_to) — lower bound valid, upper bound DELEGATION_EXPIRED, before-window DELEGATION_NOT_YET_EFFECTIVE, revocation overriding interval? Is the new code declared in PATCH3 only without editing PATCH2-03?
4. Replay exclusivity: Do G02a/G02b/G02c partition the "same nonce" space so the authorization-substitution case (same effect, same nonce, swapped envelope) deterministically lands on G02c and never G02a?
5. G08: Is G08 a genuinely distinct executable scenario (recovery/unknown-response fixture) rather than duplicate coverage of G02a, and does the count remain a correct 84 parent IDs / 86 executable scenarios?
6. Scope discipline: Did PATCH3 stay scoped — additive, no overwrite of RS5A/PATCH1/PATCH2, no reopening of accepted owner/bootstrap/handler/identity/U3/hard-prerequisite semantics, and only the three cited wordings touched?

4. Safety attestation

0 runtime mutation · 0 DDL/DML · 0 Owner/scope/principal-registry/APR/register_dot/handler created · 0 approvals · 0 gate flips · 0 registrar/validator patches · no RS-VALIDATOR · no implementation · no registration · no activation · no REGISTRATION_HOLD clear · no invented principal IDs · RS5A / RS5A-PATCH1 / RS5A-PATCH2 not overwritten · accepted owner/bootstrap/handler/identity/U3/hard-prerequisite semantics not reopened. The single new artifact is the reject code DELEGATION_NOT_YET_EFFECTIVE (oracle/interval sharpening, design-only, fail-closed). REGISTRATION_HOLD intact; REGISTRATION_CAN_PROCEED = NO.

5. On accept

ACCEPT_RS5A_PATCH3 → proceed only to RS5B — G2 Owner-of-record execution-design / authorization-design (non-mutating; must solve bootstrap authority; must itself be authorized before any Owner/scope/APR/action write). Each carrier/policy block then separately authorized and built (replace-not-wrap, explicit edges; the canonical-principal surface and DOT_APPROVAL_QUORUM_AUTHORITY scope must exist and pass before any real register_dot); reconciled validator + the 86-scenario negative suite run against the target runtime with real evidence; a later independent gate decides if registration proceeds. Further residual ⇒ RS5A-PATCH4.