FIX7 Authority Closure — Owner Decision Packet

• Date: 2026-06-10 · Audience: OWNER (concise, decision-ready)
• Authority of THIS doc: options only. T1 prepared options; T1 does NOT choose, approve, or seal.

1. What has PASSED (Codex Recheck-9 V3, 2026-06-10)

• Final Codex status: CODEX_RECHECK_9_V3_AUTHORITY_BLOCKED — engineering PASS, Article 13 PASS, Article 14 PASS, no hardcode/disguised-hardcode defect.
• Packet V3 (tree b95df0a5…ca6d, 32 files) survived Codex's own fresh-fetch rerun (13 gates exit 0) and Codex's replay of its V2 laundering attack (rejected fail-closed).
• Canonicalizer rev3 candidate independently verified: revision 3, 38756 bytes, SHA-256 49c386a9b9666c09786fc4f89bc79776b6046eaee6f4da6d8537d2c753b734d0.
• Codex's own words: the packet is "technically seal-ready"; remaining blockers "do not require T1 engineering repair."

2. What has NOT been authorized yet

• N7 approval event (no sealed inputs exist).
• N8 detached seal (Codex-only; not authored).
• P7 authoritative pin of rev3 (still candidate).
• Blueprint approval (your standing do-not-approve covered it; your 2026-06-10 authorization lifted it ONLY for closure-packet preparation and routing).
• FIX7 implementation (explicitly out of scope of your 2026-06-10 authorization until after Codex/authority seal).

3. Owner authorization already on record (basis of this packet)

OWNER_AUTHORIZATION_FIX7_AUTHORITY_CLOSURE_AND_SEAL_ONLY_2026_06_10 authorized exactly: (1) prepare this closure packet; (2) assemble N7 inputs; (3) prepare N8 request; (4) prepare P7 request; (5) route to Codex/authority for seal decision; (6) prepare the next implementation macro AFTER a Codex/authority pass. It explicitly does NOT permit production mutation, REAL_RUN, QT001, permit/activation/repoint/cutover, registries-pivot, auto-birth repair, implementation before seal, T1 self-approval, or fabricated seals.

4. What you must decide next

Option	Meaning	Consequence
1. Keep do-not-approve (beyond the closure lane)	Status quo	Packet and rev3 candidate preserved unchanged; no seal, no implementation
2. Authorize Codex/authority seal only	Supply approval-event inputs (A1–A5 in the N7 envelope) and let Codex author N7/N8/P7	Blueprint becomes sealed; implementation still NOT authorized
3. Also authorize FIX7 implementation planning after seal	T1 drafts the implementation macro (paper only)	No mutation occurs; you review the macro before any execution
4. Authorize the implementation macro with explicit no-production gates	T1 executes the implementation lane under the precondition checklist	Every mutation gated + rollback-verified; REAL_RUN/QT001/cutover still require separate approval

Options are cumulative (2 ⊂ 3 ⊂ 4). T1 recommendation is not given here — this is an authority decision.

5. Risks and boundaries

• If sealed (2): the rev3 hash/revision becomes the authoritative pin; later SSOT edits would require a new re-seal cycle. No runtime risk — sealing mutates nothing in production.
• If implementation is authorized (4): risk moves to the implementation lane; the precondition checklist (fix7-implementation-precondition-checklist.md) makes rollback, gating, and forbidden actions explicit. Production stays untouched until each gate is separately passed.
• Structural limit (disclosed by Codex V3 §6): a packet cannot self-defend against total rewrite-and-republish; the governed KB hashes + Codex fresh-fetch rerun are the external backstop.
• Residual tooling gap (R9-B5-RES): no server-side digest endpoint; Codex ruled client-side governed-MCP byte proof sufficient. Optional hardening, non-blocking.

6. Explicit non-authorization list (unchanged regardless of option)

No production mutation · no PG/Directus/registry/system_issues mutation · no REAL_RUN · no QT001 apply · no permit issuance · no activation · no repoint · no cutover · no registries-pivot resumption · no auto-birth repair · no T1 self-approval · no fabricated N7/N8/P7 seal.