06 - Codex Detached Seal Anchor Contract

(Codex recheck-5 blocker E.) Codex flagged that calling the Codex checkpoint an "immutable anchor" is not enough: it was not bound to an explicit immutable revision/hash/signature or an equivalent detached owner seal. A copy of record trusted merely by path/name is a mutable-authority path.

The model: a Codex-authored detached seal

The SEALED copy of record is a CODEX_DETACHED_SEAL fenced-YAML block authored by Codex in the recheck-6 checkpoint (the value of approved_by_recheck_checkpoint). It is an approval record, not trusted by path/name. Required fields:

CODEX_DETACHED_SEAL:
  seal_version: <set by Codex>
  sealed_by: Codex
  sealed_at_utc: <set by Codex>
  sealed_envelope_manifest_sha256: <FIX7_ACTIVE_AUTHORITY_ENVELOPE_MANIFEST_V1 over the approved envelope>
  sealed_active_corpus_sha256: <FIX7_ACTIVE_AUTHORITY_CORPUS_V1>
  sealed_active_membership_hash: f2bda8effc7be19b54722828126b82d7d2d48bee5e5e5dc0c8f347ce210fe251
  parent_checkpoint_id: <recheck-5 checkpoint id>
  report_documents:               # id + revision + content hash where feasible
    - { id: <doc>, kb_revision: <n>, content_sha256: <hash> }
  seal_report_checkpoint_content_sha256: <hash of the recheck-6 seal report/checkpoint, if feasible>
  canonical_encoding_version: FIX7-CANON-V1
  any_change_requires_new_recheck: true
  signature: <crypto signature>   # OR:
  signature_not_available_in_current_tooling: true
  detached_seal_sha256: <FIX7_CODEX_DETACHED_SEAL_V1 over the above, excluding this field>

Compensating fail-closed rule (no cryptographic signature)

The current KB/MCP tooling does not provide a cryptographic signature. The contract states this explicitly (signature_not_available_in_current_tooling: true) and substitutes a compensating fail-closed rule. Approval authority then rests on:

1. Codex authorship — the recheck checkpoint is authored by Codex (the design/approval owner), not T1/Directus-editable;
2. revision + content SHA-256 pin — the Codex checkpoint is pinned by its KB revision and content SHA-256, recorded in the live envelope's detached_seal_anchor (codex_checkpoint_kb_revision, codex_checkpoint_content_sha256);
3. MCP read-back — at the authoring-entry gate the Codex checkpoint is read back via MCP and its live revision + content SHA-256 are compared to the pinned values; and
4. mismatch guard — any later change to the Codex checkpoint (revision increment or content-hash change), or live envelope_manifest_sha256 != sealed_envelope_manifest_sha256, → ACTIVE_AUTHORITY_DETACHED_SEAL_MISMATCH → fail closed → new Codex recheck (G-CODEX-DETACHED-SEAL-ANCHOR).

"Any change to Codex checkpoint content after seal requires a new recheck" is therefore enforced, not just stated.

Seal timing and who writes what

• T1 (now): STAGES the contract in the live envelope with SEAL_AT_CODEX_RECHECK_6 placeholders for every sealed value, and specifies the byte-exact encoding so Codex's computation is deterministic. T1 does not pre-write the sealed hashes — doing so would be self-fabricated authority.
• Codex (recheck 6): computes every aggregate by FIX7-CANON-V1, populates the detached seal, flips envelope_state to SEALED, sets the approval metadata, and publishes the complete sealed envelope. T1's ask to Codex for this is enumerated in blueprint doc 12 (asks 8–14).

Why this is not a runtime hash contract

The detached seal anchors a construction-document (the blueprint being authored from). It adds no runtime authority surface, readiness gate, #20 column, catalog family, or eighth top-level runtime hash contract (H01..H07 stay 7). It is a build-time integrity artifact, consistent with Codex's INVARIANTS_BOUNDARY_FINAL_ACCEPTED.