FIX7 Authority Closure — P7 Codex Re-seal Request (rev2)

• Date: 2026-06-10 · Lane: FIX7 authority-seal contract executable macro · rev2 closes Codex AS-P4.
• Authority of THIS doc: request only. P7 is the Codex/authority act of pinning the canonicalizer SSOT (rev3 after P-EXT-1→rev2, P-EXT-2→rev3) as the authoritative canonicalizer_sha256/canonicalizer_revision. T1 does not and cannot perform it.
• Executable artifact schema (new in rev2): P7 is a seal document with a byte-exact digest (authority_seal_pin_sha256), authored via authority_seal_encoder.py seal_p7(); schema in authority-seal-encoder-spec.md §5. A prose-only pin is rejected (SEAL_PROSE_ONLY_PIN_REJECTED). This removes the prior AS-P4 defect (no exact schema/encoding).

1. P7 fixed roster (AS-P4)

Domain tag FIX7_AUTHORITY_SEAL_PIN_V1; output authority_seal_pin_sha256; fields in this exact order:

#	field	value/source	actor
1	schema_version (FIX7-AUTHORITY-SEAL-V1)	const	contract
2	node_id (P7)	const	contract
3	pinned_canonicalizer_document_id	…/canonicalizer-fix7-canon-v1-ssot.md	engineering
4	pinned_canonicalizer_revision	3	engineering
5	pinned_canonicalizer_utf8_bytes	38756	engineering
6	pinned_canonicalizer_sha256	49c386a9b9666c09786fc4f89bc79776b6046eaee6f4da6d8537d2c753b734d0 (= N2)	engineering
7	pinned_packet_v3_tree_sha256	b95df0a5d2f41f80bea0cef8621c1f8bb0f6b49a40175116418494ed4141ca6d	engineering
8	codex_report_document	report document_id@revision	Codex
9	codex_checkpoint_document	checkpoint document_id@revision	Codex
10	envelope_manifest_sha256	N7	from N7
11	detached_seal_sha256	N8	from N8
12	approval_event_id	A1	Codex
13	pin_scope (CANDIDATE_TO_AUTHORITATIVE_PIN_BLUEPRINT_ONLY)	const	contract

• Dependency direction (acyclic): P7 → N2,N7,N8. P7 FOLLOWS N7 and N8; nothing depends back on P7 (proven has_cycle(EDGES) = False). The pinned rev3 identity (N2) + Packet V3 tree are leaf data inputs available before N7, which is why Codex's "P7/N2 → N7" candidate-input note does not require the final pin to precede N7.
• Nature: primary form is the computed digest above. Alternative enacted rule (if Codex prefers the checkpoint to be the pin): pin = codex_checkpoint_document document_id@revision + its governed content SHA-256 — also byte-exact, no prose.
• verify_pin() recomputes P7; mutating the pinned canonicalizer hash or Packet V3 tree changes the digest ⇒ verify FAIL (proven in the test-vector report).

2. Supporting evidence set (for Codex to hash/confirm at seal time)

• Packet V3: root knowledge/dev/laws/tool-kiem-thu/packets/fix7-codex-recheck-9-2026-06-10/, tree b95df0a5…ca6d.
• Codex V3 report …/codex-fix7-blueprint-recheck-9-v3-blackbox-cli-oracle-rerun-and-seal-review-2026-06-10/00-readme-first.md (rev1); checkpoint …/checkpoint-codex-fix7-blueprint-recheck-9-v3-blackbox-cli-oracle-rerun-and-seal-review-2026-06-10.md (rev1).
• Blocker ledger knowledge/dev/laws/tool-kiem-thu/checkpoints/fix7-recheck9-remaining-authority-blocker-ledger-2026-06-10.md (rev5).

3. Requested Codex action

1. Fresh-fetch the SSOT at revision 3 via governed MCP; recompute SHA-256 over full content bytes; confirm == 49c386a9…b734d0 and 38756 bytes.
2. After N7 and N8 are authored, run seal_p7() over the §1 roster → authority_seal_pin_sha256. That digest + revision 3 IS the authoritative canonicalizer_sha256/canonicalizer_revision pin (P7).
3. Record the P7 seal event and the report/checkpoint document ids used.

4. Explicit statement

The values above remain candidates until Codex authors the P7 seal via seal_p7(). T1 asserts reproducibility and a byte-exact schema, not authority. No prose-only pin is acceptable.