RS5A-PATCH3-02 — Lifecycle Availability / Persistence / Business-Transition Separation — 2026-06-21

Macro: RS5A-PATCH3 · Residual R1-lifecycle · Deliverable: 02 of 6 (+index +rollup +codex-packet). Class: scoped semantic-closure correction. Additive. Does NOT overwrite RS5A, RS5A-PATCH1, or RS5A-PATCH2. The PATCH2 files remain at revision 1 for audit; this file authors the corrected lifecycle wording that supersedes only PATCH2-02 §4's single combined column "may act/exist AFTER runtime registration?". Supersedes (narrow): PATCH2-02 §4 column header "may act/exist AFTER runtime registration?" and its no cells. Preserves in full: PATCH2-02 §2 ten-scope classification, §3 sequencing statements, and the accepted rule that replay/audit are hard pre-runtime prerequisites and activation is the only post-registration-capable scope (Codex §4 PASS-on-classification, §7.2/§7.3 accepted). Gate carried: REGISTRATION_HOLD · REGISTRATION_CAN_PROCEED = NO · 0 mutations.

1. The defect (Codex §4, §3 scope-taxonomy PARTIAL, §9.1)

PATCH2-02 correctly classified the ten scopes by first availability (eight hard pre-runtime prerequisites + one hard pre-runtime approval/quorum + one post-registration-capable activation) and correctly forbade any wording that lets replay or audit be first introduced after runtime registration. Codex accepted that classification.

But PATCH2-02 §4 collapsed two different lifecycle questions into one column — "may act/exist AFTER runtime registration?" — and marked it no for all nine pre-runtime scopes. That single answer is false as written:

• A prerequisite that must exist before admission normally persists after admission.
• Replay must answer post-commit retries / idempotent prior-decision retrieval (exactly the accepted G02a/G08 behavior).
• Audit, authority, hash, U3, and status surfaces must remain available after admission for verification and lifecycle integrity.

"Must already exist before" does not mean "must cease to exist or act after." The no cell conflated first-introduced-after (which is forbidden for replay/audit) with persists/operates-after (which is required for every prerequisite). This is the only blocking contradiction; the pre-admission gate itself is sound and is not weakened here.

2. The fix — three orthogonal lifecycle questions (never one column)

Every scope is now classified on three independent axes. A scope's answers on the three axes are unrelated; collapsing any two of them re-introduces the PATCH2-02 §4 defect.

• A — First-availability gate: Must the surface already exist and pass before real register_dot admission? This is the pre-admission gate (accepted, unchanged).
• B — Post-admission persistence / operation: Must the surface remain available and continue operating after admission, as required by its own contract? (verification, idempotent retry, audit retention, lifecycle integrity).
• C — Business-transition timing: May the scope's primary governed business action occur after an inert draft registration? Only activation answers yes.

Decisive distinction (machine-unambiguous):

concept	meaning	who	allowed?
first-introduced-after	the surface does not exist before admission and is created only after runtime registration	replay, audit	FORBIDDEN (carried from PATCH2-02 §3)
persists/operates-after	the surface existed and passed before admission, and remains available + keeps enforcing its contract after admission	every pre-runtime prerequisite (Axis B = yes)	REQUIRED
business-transition-after	the scope's primary governed business action (draft → active) begins after inert registration	activation only (Axis C = yes)	ALLOWED, activation only, never inherited

Axis B = yes is not a relaxation of the gate. A surface can only persist/operate after admission because it already passed the Axis A gate before admission. Persistence presupposes pre-existence; it never substitutes for it.

3. Three-axis classification table (replaces PATCH2-02 §4)

scope	class	A. first-availability before real register_dot?	B. persists / operates after admission?	C. business transition after inert registration?
DOT_REGISTRAR_CONTRACT	A pre-runtime	YES	yes — contract stays binding on every later admission	no
DOT_REGISTRATION_AUTHORITY	A pre-runtime	YES	yes — re-evaluated per effect; remains for verification / lifecycle integrity	no
DOT_ARTIFACT_ADMISSION	A pre-runtime	YES	yes — admitted artifact bytes/hash remain verifiable	no
DOT_HASH_CARRIER	A pre-runtime	YES	yes — authoritative hash persists for verification + lifecycle integrity	no
DOT_HEAD_UNIQUENESS (U3)	A pre-runtime	YES	yes — current-head invariant continuously enforced after admission	no
DOT_STATUS_DOMAIN	A pre-runtime	YES	yes — status vocabulary continuously enforced after admission	no
DOT_REPLAY_SURFACE	A pre-runtime	YES	yes — must answer post-commit idempotent retry / prior-decision retrieval (G02a, G08)	none / not activation
DOT_AUDIT_SINK	A pre-runtime	YES	yes — failure-record verification, forensic record, lifecycle audit	none
DOT_APPROVAL_QUORUM_AUTHORITY	B pre-runtime approval	YES	yes — quorum decision remains provable / re-verifiable for lifecycle integrity	no
DOT_ACTIVATION_AUTHORITY	C post-registration-capable	not required for the inert draft write	n/a as a pre-admission prerequisite	YES — the only scope whose primary governed transition (draft → active / notify) may begin after inert registration, under its own separate head, MUST_NOT_IMPLICIT_INHERIT from DOT_REGISTRATION_AUTHORITY

Column A is identical to PATCH2-02 §4's accepted "must EXIST and PASS before real register_dot?" column (no weakening). Columns B and C replace the single defective "may act/exist AFTER runtime registration?" column.

4. Replay and audit — explicit lifecycle statements

1. DOT_REPLAY_SURFACE: first-availability = before admission (hard pre-runtime; accepted, unchanged). Post-admission operation = yes — it must remain available to answer idempotent retry / prior-decision retrieval for an already-admitted effect (G02a known-response retry, G08 unknown-response recovery; see [[rs5a-patch3-04]]). Business transition = none / not activation. Answering a retry is not a new business action and not activation.
2. DOT_AUDIT_SINK: first-availability = before admission (hard pre-runtime; accepted, unchanged). Post-admission persistence = yes — failure records and forensic/lifecycle audit must remain available and continue to be written (failure-only, per the Phase-4 contract; no success audit). Business transition = none.
3. Artifact-hash / U3 / status / authority / approval: first-availability = before admission. Persistence = yes — for verification and lifecycle integrity. Business transition = no.
4. DOT_ACTIVATION_AUTHORITY: first-availability for register_dot = not required for the inert draft write. Business transition = draft → active may occur after inert registration under separate authority, never inherited from DOT_REGISTRATION_AUTHORITY. Activation is the only post-registration business transition.

5. Canonical lifecycle wording (authoritative; supersedes the §4 no cells)

Pre-runtime prerequisite surfaces (the eight Class-A scopes and the one Class-B approval scope) MUST already exist and pass before real register_dot admission, AND MUST remain available and continue enforcing their contracts after admission as those contracts require. Activation is the only post-registration business transition. No prerequisite surface — least of all replay or audit — may be first introduced after runtime registration.

Forbidden wording (must never appear in any successor file):

• ✗ "pre-runtime surfaces may not exist or act after registration" (this was the PATCH2-02 §4 defect).
• ✗ "replay/audit can be introduced after registration" (forbidden by PATCH2-02 §3, carried).
• ✗ any phrase that marks a pre-runtime prerequisite as not-persisting after admission.

Required wording: the canonical block above, or an equivalent that keeps Axes A, B, C separate.

6. Consistency with accepted semantics (not reopened)

This file is fully consistent with the accepted PATCH1-02 eleven-conjunctive-runtime-prerequisite graph and the accepted PATCH2-02 §2/§3 classification. It only splits one over-collapsed column into the three lifecycle axes it always implied. It does not reopen the prerequisite graph, the owner/bootstrap state, the handler replacement, U1/U2/U3 identity semantics, or the pre-admission gate. MUST_NOT_IMPLICIT_INHERIT (DOT_REGISTRATION_AUTHORITY ↛ DOT_ACTIVATION_AUTHORITY) is carried unchanged. No scope row, surface, or runtime artifact is created.

7. Status

LIFECYCLE_SEPARATION_FINALIZED — first-availability, post-admission persistence, and business-transition timing are three orthogonal axes; replay/audit are hard pre-runtime and persist/operate after admission; activation is the only post-registration business transition; no wording permits any prerequisite to be first introduced after registration. R1-lifecycle residual CLOSED. …LIFECYCLE_PERSISTENCE_AMBIGUOUS HOLD condition does not apply. The pre-admission gate is preserved, not weakened.