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

STATUS: HOLD REVIEW VERDICT: NEED_RS5A_PATCH3 Stop state: RS5A_PATCH2_NEEDS_PATCH3 · SCOPE_TAXONOMY_STILL_AMBIGUOUS · GOV_COUNCIL_PRINCIPAL_IDENTITY_INSUFFICIENT · TEST_ORACLE_COUNT_AMBIGUOUS Registration gate: REGISTRATION_HOLD REGISTRATION_CAN_PROCEED = NO Evidence mode: NO_CODEX_LIVE_READ — PATCH2 is a KB contract-only review; no runtime proof is claimed or required.

1. Source Register

Codex read directly from AgentData KB:

1. Prior Codex RS5A-PATCH1 HOLD report, revision 1, complete readback.
2. RS5A-PATCH2 rollup and index.
3. RS5A-PATCH2-01 through RS5A-PATCH2-05.
4. RS5A-PATCH2 Codex review packet.
5. Metadata/readback for PATCH1-02, PATCH1-04, and PATCH1-06; all remained revision 1.
6. Operating Rules SSOT (knowledge/dev/ssot/vps/vps-operating-rules.md, version 1.0 returned by direct search) and Constitution (knowledge/dev/laws/constitution.md, v4.6.3 returned by direct search).

All eight target PATCH2 documents were read complete and untruncated at revision 1. No local prose was used as package evidence.

2. Package Completeness

PASS. The package contains eight required documents: one rollup plus seven files under knowledge/dev/laws-new/reports/rs5a-patch2/ (index, 01–05, Codex packet). AgentData returned count=7, truncated=false for the directory, and the rollup exists separately. No file was missing, empty, or truncated.

The referenced PATCH1 documents remain revision 1. PATCH2 is additive and did not overwrite RS5A or PATCH1.

3. Closure Map Assessment

Residual	Assessment	Reason
Scope taxonomy	PARTIAL — NOT CLOSED	Creation/admission timing is corrected, but the final table says pre-runtime scopes may not “act/exist” after registration, which is false for persistent replay/audit and other prerequisite surfaces.
GOV-COUNCIL principal identity	PARTIAL — NOT CLOSED	Canonical fields and anti-double-count rules are present, but overlapping reject conditions have no deterministic precedence and the delegation interval boundary is ambiguous.
Test oracle/count	PARTIAL — NOT CLOSED	Codes, aliases, and 84/86 arithmetic are corrected, but G02a is not mutually exclusive from G02c because it omits “same authorization envelope.”

PATCH2 closes the original wording defects substantially, but its CLOSED claims are stronger than the actual machine-executable contract. A narrowly scoped PATCH3 is required.

4. Scope Taxonomy Assessment

PASS on pre-admission classification; NEEDS PATCH on lifecycle semantics. PATCH2-02 correctly defines:

• eight hard pre-runtime prerequisite scopes;
• one hard pre-runtime approval/quorum scope;
• one activation scope whose governed transition occurs after inert registration;
• replay and failure audit must exist and pass before any real register_dot.

No controlling text again permits replay or audit to be first introduced after runtime registration. The old generic “deferrable” bucket is removed.

The blocking contradiction is PATCH2-02 §4's column “may act/exist AFTER runtime registration?”, marked no for all nine pre-runtime scopes. A prerequisite that must exist before registration normally persists afterward. Replay must handle post-commit retries/idempotent retrieval; audit, authority, hash, U3, and status surfaces must remain available for verification and lifecycle integrity. “Must already exist before” does not mean “must cease to exist or act after.” The decision packet repeats that activation is the only scope that may act after registration, conflicting with G02a/G08 post-commit replay behavior.

PATCH3 must distinguish:

1. First-availability gate: replay/audit and all pre-runtime prerequisites must already exist and pass before admission.
2. Persistence/operation: prerequisite surfaces must remain available after admission; replay may answer retries and policy/audit surfaces may continue enforcing their contracts.
3. Business transition timing: activation is the only scope whose primary governed business transition (draft → active) may begin after inert registration.

Replace “may act/exist after = no” with separate, unambiguous columns. This correction must not weaken the pre-runtime gate.

5. GOV-COUNCIL Principal Identity Assessment

PASS on required fields; NEEDS PATCH on deterministic rejection semantics. PATCH2-03 correctly requires canonical_principal_id, canonical president/council slots, GOV-COUNCIL membership, authoritative resolution, scoped delegation, effective window, and revocation state. It forbids free-text president authority, self-declared council identity, and alias/delegation double counting. The surface is REQUIRED_NOT_PRESENT, no principal is invented, and all decisions fail closed today.

The following reject conditions overlap:

• a free-text president with no authoritative role binding satisfies both FREE_TEXT_PRESIDENT_REJECTED and PRESIDENT_ROLE_UNRESOLVED;
• self-declared council identity with no canonical principal satisfies both SELF_DECLARED_COUNCIL_IDENTITY_REJECTED and COUNCIL_PRINCIPAL_UNRESOLVED;
• two aliases resolving to one principal satisfy both APPROVER_ALIAS_DOUBLE_COUNT and CANONICAL_PRINCIPAL_DOUBLE_COUNT.

PATCH2-04 expects one specific code for A11/A12/F07/F08, but PATCH2-03 does not define precedence. An implementation can therefore be contract-compliant while returning a different code from the oracle.

PATCH3 must provide deterministic precedence or mutually exclusive predicates. Recommended rule: specific spoof/alias codes precede generic unresolved/double-count codes; exact repeated canonical identity uses CANONICAL_PRINCIPAL_DOUBLE_COUNT, while distinct aliases/delegations resolving to the same identity use APPROVER_ALIAS_DOUBLE_COUNT.

The delegation interval must also use one precise convention. PATCH2 writes [effective_from,effective_to] but requires the vote “strictly inside.” Use a single half-open interval such as [effective_from,effective_to) and define boundary outcomes.

6. Test Oracle and Count Assessment

PASS on canonical aliases/count; NEEDS PATCH on scenario exclusivity. PATCH2-04 now has one canonical outcome column, marks aliases documentation_alias_only, and correctly declares 84 parent IDs / 86 executable scenarios with 84 − 1 + 3 = 86. The identity-case mappings are explicit and the suite remains DEFINED_NOT_EXECUTED.

G02 predicates are not mutually exclusive:

• G02a: same effect + same nonce, already committed → idempotent retrieval;
• G02c: same nonce + changed authorization envelope → rejection.

A retry with the same effect and nonce but a changed authorization envelope satisfies both as written. That is exactly the authorization-substitution case the split must reject.

PATCH3 must define:

• G02a: same effect, same nonce, same canonical authorization envelope/digest, prior durable decision → IDEMPOTENT_PRIOR_DECISION_RETRIEVAL;
• G02b: same nonce, different effect → NONCE_REUSE_DIFFERENT_EFFECT;
• G02c: same nonce, same effect, different authorization envelope/digest → NONCE_REUSE_AUTHORIZATION_MISMATCH.

If G08 remains a separate executable scenario, its fixture/trigger must be distinguished from G02a (for example known-response exact retry versus recovery after unknown response) while retaining the same canonical outcome. Otherwise it is duplicate coverage rather than a distinct executable scenario and the 86-scenario claim must be adjusted.

The component label “78 unaffected” should also be corrected because A11/A12/F07/F08 were re-canonicalized; this does not change the arithmetic.

7. Accepted Points

1. Complete, additive eight-file package.
2. Replay and audit are hard pre-admission prerequisites.
3. Activation is separated from the prerequisite-creation gate.
4. Canonical principal, role-slot, body-membership, delegation, and revocation requirements.
5. No free-text president, self-declared council identity, or alias double-counting.
6. One canonical oracle outcome column; aliases are documentation-only.
7. Correct 84-parent / 86-executable arithmetic, subject to distinct scenario fixtures.
8. No runtime surface, scope, principal, APR, action, handler, or registration was created.
9. Bootstrap, handler, U1/U2/U3, and prerequisite-graph semantics were not reopened.

8. Required PATCH3 and Caveats

The single scoped RS5A-PATCH3 item is deterministic lifecycle and oracle predicates:

1. Separate “must exist before” from “persists/acts after”; preserve replay/audit pre-admission gating while allowing required post-admission operation.
2. Define reject-code precedence/mutual exclusion and a precise delegation interval.
3. Make G02a/b/c mutually exclusive and distinguish G08's fixture if it remains a separate scenario.

PATCH3 should modify only PATCH2-02, PATCH2-03, PATCH2-04, and their closure/rollup/index/decision/Codex summaries. It must not reopen accepted owner, bootstrap, handler, identity, U3, or hard-prerequisite semantics.

9. Rejected or Overclaimed Points

1. Rejected: pre-runtime replay/audit and other prerequisite surfaces may not exist or act after registration.
2. Rejected: canonical reject semantics are deterministic without precedence for overlapping predicates.
3. Rejected: G02a and G02c are distinct scenarios as currently written.
4. Not accepted as execution evidence: the 86 scenarios remain defined, not executed.
5. Not claimed: any runtime state was independently verified by Codex.

10. Sequencing, Gate, and Three Declarations

Sequence remains:

1. Produce and re-review the narrow RS5A-PATCH3 corrections in §8.
2. Only after acceptance, proceed to RS5B Owner-of-record execution-design / authorization-design.
3. RS5B remains non-mutating unless separately authorized later.

REGISTRATION_HOLD remains active. REGISTRATION_CAN_PROCEED = NO. No Owner, scope, principal registry, APR, register_dot, handler, validator, registration, or activation operation is authorized.

• Permanent: lifecycle timing, canonical rejection precedence, and mutually exclusive replay predicates remove recurring semantic drift.
• Mistake-resistant: one input maps to one result; prerequisite availability cannot be confused with post-admission persistence.
• Automatic: this review executes nothing; future automation is acceptable only after these predicates are machine-enforced and verified with real suite output.

OR/TD update: not applicable because this is an independent read-only review with no implementation or runtime change. The official Codex report is the sole artifact.

11. Final Verdict

VERDICT: NEED_RS5A_PATCH3

PATCH2 closes the requested surface-level corrections but still permits contradictory lifecycle interpretation and non-deterministic oracle outcomes. These are material at a final technical gate and must not flow into RS5B as controlling requirements.

Single next step: RS5A-PATCH3 limited to the deterministic lifecycle/oracle corrections in §8.

DO NOT IMPLEMENT: Confirmed. No runtime mutation, DDL/DML, Owner row, scope row, principal registry, APR, register_dot, approval, handler, registrar/validator patch, RS-VALIDATOR, registration, activation, technical implementation, or blocker resolution was performed or authorized.