RS5A — Codex Review Packet (G2 Owner-of-record Decision) — 2026-06-21

Review scope: RS5A only. Do not re-review accepted RS4A / PATCH1 / PATCH2 parts (effect-identity business-only, authorization-binding-separated, U3 current-head, Phase-4 no-success-audit, PX2 registry, count=111). RS5A is the single next step Codex authorised in ACCEPT_RS4A_PATCH2: the G2 Owner-of-record decision dossier (not execution).

1. What RS5A claims

claim	where	self-verdict
authority state freshly reconstructed from live substrate (not reports)	[[rs5a-02]]	LIVE, 0 writes
Owner ≠ caller/operator/free-text/Directus/validator/registrar	[[rs5a-03]]	proven w/ live counter-examples
9 registrar object scopes, separable LEGO, no mega-owner	[[rs5a-04]] / [[rs5a-11]]	boundary held
candidate Owner surface proven; no head bound	[[rs5a-05]]	SURFACE_PROVEN + NO_ACCOUNTABLE_HEAD_BOUND
register_dot action contract v1 (not created)	[[rs5a-06]]	REQUIRED_NOT_PRESENT
authority envelope v1 binds PATCH2 digest, authority out of U1	[[rs5a-07]]	ENVELOPE_V1_DEFINED
quorum bodies read; binding insufficient	[[rs5a-08]]	SEMANTICS_READ + BINDING_INSUFFICIENT
84 negative authority tests, defined-not-executed	[[rs5a-09]]	all mandatory fail-opens covered
options A/B/C + recommendation (B)	[[rs5a-10]]	no execution
consolidated decision packet	[[rs5a-12]]	G2_OWNER_DECISION_READY_FOR_CODEX_REVIEW

2. Verdict requested

G2_OWNER_DECISION_READY_FOR_CODEX_REVIEW with REGISTRATION_HOLD retained and the controlling sub-state fail-closed (no owner ⇒ no register_dot).

3. Points Codex should adversarially test

1. Is the candidate-surface claim honest? (governance_registry codes are governance objects, not persons — RS5A treats them as candidate heads requiring an ownership binding; is that the right reading?)
2. Is keeping authority out of U1 actually preserved in the envelope ([[rs5a-07]] §1 partition)?
3. Are the quorum binding gaps (effect/artifact/identity) correctly classified as necessary-not-sufficient rather than "quorum broken"?
4. Does Option B over-reach by proposing a 3-head split, or is concentration (Option A) the safer default for the decision?
5. Any negative case that should be a hard DB constraint vs a registrar guard vs future-surface? (layer assignments V/R/A/F)
6. Is REGISTER_DOT_ACTION_REQUIRED_NOT_PRESENT correctly kept as a HOLD rather than silently designing around it?

4. What RS5A did NOT do (safety attestation)

0 runtime mutation · 0 DDL/DML · 0 Owner rows · 0 APR · 0 register_dot · 0 approvals · 0 gate flips · 0 registrar/validator patches · no RS-VALIDATOR opened · no implementation · no registration · no activation · no reopening of accepted parts · no mega-system. REGISTRATION_HOLD intact.

5. On accept

Codex ACCEPT_RS5A → the Owner-of-record performs the G2 designation (recommended Option B) → per-block hardening (scope authoring, register_dot action, artifact-hash carrier, audit sink, U3 surface, status CHECK) + RS-VALIDATOR sequenced after, not bundled. Residual defects ⇒ RS5A-PATCH1.