RS5A-PATCH2 — Codex Review Packet (Semantic-Closure Precision) — 2026-06-21

Review scope: RS5A-PATCH2 only. This is the scoped correction Codex required in NEED_RS5A_PATCH2 §10 — three semantic-closure corrections. It does not overwrite RS5A or RS5A-PATCH1 and does not reopen accepted RS4A/PATCH2 identity, U3, handler, bootstrap, or prerequisite-graph semantics (Codex §9 accepted points).

1. What PATCH2 corrected (against Codex NEED_RS5A_PATCH2 §10)

residual	correction	file	status
1 — scope taxonomy contradiction	deleted the post-registration "deferrable" bucket; re-classified as 8 hard pre-runtime prerequisite + 1 approval/quorum + 1 post-registration-capable activation; replay/audit are hard pre-runtime; activation is the only post-registration-capable scope	[[rs5a-patch2-02]]	CLOSED
2 — GOV-COUNCIL canonical principal identity	canonical principal/role-slot/voting-body contract; authoritative president binding (no text-match); distinct council principals; no alias/delegation double-count; valid scoped delegation; self-declared council and free-text president rejected; design-only, fail-closed	[[rs5a-patch2-03]]	CLOSED
3 — test oracle alias/count	one canonical outcome per executable scenario; aliases documentation-only; 84 parent IDs / 86 executable scenarios	[[rs5a-patch2-04]]	CLOSED

2. Verdict requested

RS5A_PATCH2_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. Does the final taxonomy ([[rs5a-patch2-02]]) make it impossible to read replay or audit as post-registration / deferrable, while still allowing activation to follow inert registration?
2. Is the canonical principal contract ([[rs5a-patch2-03]]) sufficient to defeat: (a) a free-text "president" approver, (b) two aliases/delegations of one principal counting twice, (c) a self-declared ai_council vote with no body membership, (d) a delegation that is out-of-scope, expired, or revoked?
3. Is the canonical-principal surface correctly marked REQUIRED_NOT_PRESENT and fail-closed, with no invented principal IDs and no scope/registry/row created?
4. Does each executable scenario ([[rs5a-patch2-04]]) carry exactly one canonical outcome, with aliases marked documentation_alias_only and never accepted?
5. Is the count unambiguous — 84 parent IDs / 86 executable scenarios — with G02a/G02b/G02c enumerated and the arithmetic shown?
6. Did PATCH2 stay scoped — no overwrite of RS5A/PATCH1, no reopening of accepted identity/U3/handler/bootstrap/prerequisite-graph semantics?

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 broad-approval silent use · no invented principal IDs · RS5A and RS5A-PATCH1 not overwritten · RS4A/PATCH2 identity, U3, handler, bootstrap, prerequisite-graph semantics not reopened. REGISTRATION_HOLD intact; REGISTRATION_CAN_PROCEED = NO.

5. On accept

ACCEPT_RS5A_PATCH2 → 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-PATCH3.