02 - The ACTIVE_AUTHORITY_APPROVAL_ENVELOPE

Location and shape

A machine-readable fenced YAML block in doc 00 §Active-authority approval envelope, wrapped in <!-- ENVELOPE:EXCLUDE-BEGIN --> / <!-- ENVELOPE:EXCLUDE-END --> sentinels (so it is excluded from doc 00's own content hash — no self-reference). The SEALED copy of record is recorded by Codex in the recheck-5 checkpoint (the immutable anchor that the live doc-00 envelope is checked against).

Required fields (all present)

blueprint_id · envelope_state (STAGED_PENDING_CODEX_RECHECK_5 → SEALED at recheck-5) · approved_status · approval_epoch · approved_by_role · approved_at_utc · required_by_recheck_checkpoint · approved_by_recheck_checkpoint · next_required_recheck_on_change: true · digest_algorithm · active_corpus_membership_sha256 · marker_fence_registry_sha256 · superseded_boundary_sha256 · guard_set_revision · guard_set_sha256 · envelope_manifest_sha256 · active_corpus[] of {document_id, doc_status, active_section_id_or_range, kb_revision, normalized_active_content_sha256, full_document_sha256} · superseded_non_authority[].

What is pinned now vs sealed at the Codex recheck

field	now (recheck-4 patch)	recheck-5 seal
active_corpus membership (which docs)	real doc_ids + recheck-4-patched kb_revisions	Codex re-pins exact revisions
active_corpus_membership_sha256	916d6e11027ff466ffd4f0ae0f66b15c314fb89601b70ecdb7261ce463c03b87 (computed now, stable)	re-verified
per-doc normalized_active_content_sha256 / full_document_sha256	SEAL_AT_CODEX_RECHECK_5	Codex computes over approved content
marker_fence_registry_sha256 / superseded_boundary_sha256 / guard_set_sha256 / envelope_manifest_sha256	SEAL_AT_CODEX_RECHECK_5	Codex computes
approval_epoch / approved_by_role / approved_at_utc / approved_by_recheck_checkpoint / envelope_state=SEALED	pending	Codex sets at PASS

Why per-document content hashes seal at the approval event (not now)

A content hash of the approved corpus can only be computed over the corpus as approved, which finalizes at the approval event. If T1 pre-wrote "approved" SHA-256 values before Codex approved, that would be self-fabricated authority — exactly the disguised-authority anti-pattern this entire FIX7 chain (and Codex) polices. So:

• T1 authors the envelope STAGED, pins the real current revisions + the now-stable membership hash, and specifies a deterministic, reproducible computation.
• The approving authority (Codex) computes and seals the per-document hashes at recheck-5 PASS and records the sealed envelope in the recheck-5 checkpoint.
• The guards then verify the live corpus against that sealed envelope at authoring time.

This keeps the authority seal with the approver and still gives Codex a fully-specified, executable content-addressing mechanism (not prose).

Determinism proof (this pass, not prose)

• shasum -a 256 is available and deterministic (verified).
• Rehearsal: printf '%s' 'FIX7-ACTIVE-AUTHORITY-ENVELOPE-REHEARSAL-v1' | shasum -a 256 = f6b773f80308260d5668f8dcfa41a318e2e05375d3e1b59615da7b393be1e7b0.
• Real corpus-membership address (the canonical ascending doc_id list, LF-terminated) = 916d6e11027ff466ffd4f0ae0f66b15c314fb89601b70ecdb7261ce463c03b87. This alone already detects any missing/extra ACTIVE doc.

Normalization spec (so anyone reproduces the same digest)

per-document digest = SHA-256 of the exact UTF-8 bytes the KB returns for get_document_for_rewrite(document_id) at the pinned kb_revision, with the single transformation of removing the bytes between <!-- ENVELOPE:EXCLUDE-BEGIN --> and <!-- ENVELOPE:EXCLUDE-END --> inclusive (present only in the two self-referential hosts: doc 00 and the blueprint checkpoint). LF line endings; no other normalization. The KB revision is the primary drift signal (any edit increments it); the content SHA-256 is the content-level backstop.

Self-reference handling (the hole I proactively closed)

The envelope sits in doc 00's EXCLUDE region, so editing the envelope block does NOT change doc 00's pinned content hash. That alone would leave the envelope itself editable post-seal. It is closed by: (a) the SEALED copy of record lives in the Codex recheck-5 checkpoint (Codex-authored, not T1/Directus-editable); (b) envelope_manifest_sha256 is in the G-ACTIVE-AUTHORITY-HASH-MATCH set, so the live doc-00 envelope must equal the checkpoint-sealed envelope. Editing the live envelope → manifest hash diverges from the sealed anchor → ACTIVE_AUTHORITY_ENVELOPE_MISMATCH. See doc 06 scenario 11.