05 - Blueprint Checkpoint Authority Classification

(Codex recheck-5 blocker D.) Codex flagged a contradiction: the blueprint checkpoint (checkpoint-t1-fix7-existing-system-refactor-execution-blueprint-2026-06-08.md) was described as a self-referential host / ACTIVE, but it is not in active_corpus, and no checkpoint EXCLUDE envelope existed. Either it is load-bearing authority (then it must be an envelope member with revision/hash + EXCLUDE handling) or it is not (then it must be classified non-authority and no guard or package may rely on it).

T1's decision: NON_AUTHORITY_INDEX (DERIVED_STATUS / REPORT_ONLY)

The blueprint checkpoint is a derived status mirror of the blueprint — it summarizes the gate chain and current status. It is not a source of authoring authority: the authoring corpus is the 10 ACTIVE numbered docs, and authoring readiness is decided by the SEALED envelope + the Codex detached seal. So the checkpoint is classified:

DOC_STATUS: NON_AUTHORITY_INDEX (DERIVED_STATUS / REPORT_ONLY)

with the explicit properties:

• not an ACTIVE_AUTHORITY member (absent from active_corpus, absent from the membership hash);
• not a self-host (no ENVELOPE:EXCLUDE region; the sole self-host is doc 00);
• consumed by no guard or package as authority.

Why not make it an envelope member (the alternative)

Making the checkpoint a second self-host would mean a second EXCLUDE region, a second exclude-region content hash, and a second tamper surface — more mechanism for a document that carries no authoring authority. The cleaner resolution is to remove it from the load-bearing set entirely. This matches what the checkpoint actually is: a human-facing status index.

Enforcement (so the classification is real, not just a label)

• The doc 00 §Active-authority boundary states the checkpoint is a derived NON_AUTHORITY_INDEX (REPORT_ONLY), not a member, not a self-host, consumed by no guard/package as authority.
• G-ACTIVE-AUTHORITY-SCOPE already rejects taking the active classification from anything other than the sealed envelope; it would reject any attempt to derive authority from the checkpoint.
• doc 07 (package split) states no package consumes the checkpoint as authority; authoring readiness is the sealed envelope + the detached seal only.
• Self-audit test 9 (doc 08): change the blueprint checkpoint only → no effect on authoring authority (correct, by design), and any attempt to use it as authority → rejected.

Consistency check

If the checkpoint were ever used to decide authoring readiness, the rule is: it must then be in the envelope or the detached seal. It is in neither, and no guard/package relies on it — so the classification is consistent with "if not in the envelope, no guard or package may rely on it as authority." The blueprint checkpoint's own DOC_STATUS marker was re-marked accordingly; its internal SUPERSEDED_NON_AUTHORITY fences remain as audit trail.