05 — Readiness Exact-Set Denominator Review (SUPERTRACK E)

#	Requirement	Design answer	Verdict
E.1	Expected gate set is sealed	"required sets … SHA-256 exact-set manifest rows" (00); "Sealed manifests are append-only" (02)	INTENT-OK; manifest schema + seal coverage not specified → NEEDS_CLARIFICATION
E.2	Missing gate fails	Implied by exact-set + count-match (FIX6 readiness v9 lineage)	NEEDS_CLARIFICATION — FIX7 readiness derivation rule not written
E.3	Extra gate fails	Exact-set membership comparison implies this	NEEDS_CLARIFICATION — not concretely stated for FIX7
E.4	NULL gate fails	FIX6 established NULL-strict count-match; FIX7 inherits but does not restate	NEEDS_CLARIFICATION
E.5	Deleted failing gate cannot green readiness	Runtime role zero DML on manifest; only quorum activation changes the set	INTENT-OK; but live Directus can DELETE (proven) → LIVE-FAIL until cutover
E.6	Manifest activation requires quorum	"exact active activation-policy quorum, independent principals" (02)	INTENT-OK; N and independence criteria not specified → NEEDS_CLARIFICATION
E.7	Activated manifest is hash-bound	Activation envelope "binding old/new hashes … artifact read-back" (02)	INTENT-OK; envelope schema not specified
E.8	Runtime role cannot mutate denominator	"Directus/PUBLIC/runtime roles have no control mutation" (02)	INTENT-OK (target); LIVE-FAIL today — Directus owns + can DELETE

Analysis — is there a mutable-denominator bypass?

In the target design: no, by construction — the denominator is a sealed, append-only, owner-only manifest; runtime roles have zero DML; the only path to change the expected set is a quorum-signed, hash-bound activation with read-back. That is the correct architecture and directly answers the FIX6 mutable-denominator concern.

As written: unverifiable. The macro asks me to confirm "missing gate fails / extra gate fails / NULL gate fails / deleted failing gate cannot green readiness." None of these can be confirmed because the FIX7 readiness function, the gate-manifest schema, and the count-derivation rule do not exist in the docs. The required correction is a concrete readiness spec stating: denominator = count(sealed_active_gate_manifest); ready ⇔ count(passing_gate_results) = count(manifest) AND no NULL result AND result_set keys ≡ manifest keys (exact-set, both directions); and that the gate-result source and the manifest are different sealed objects the runtime cannot write.

Live today: there IS a mutable-denominator path — Directus owns the gate/signoff tables and holds DELETE. This is precisely the bypass E.5/E.8 warn against. It is contained only by (a) the present global block (signoff=0 → readiness red) and (b) the future operator cutover. Until cutover, a readiness gate that asserts "control-plane is owned by qt001_cp_owner and Directus has no write" must itself be part of the sealed denominator and must fail. FIX7 does not concretely specify this gate.

Readiness exact-set verdict

NO mutable-denominator bypass in the design intent; a mutable-denominator path EXISTS live until owner cutover; and the FIX7 readiness denominator is not concretely specified. → NEEDS_CLARIFICATION (spec) + must remain BLOCKED (live). Contributes to DESIGN_BLOCKED_REQUIRES_CODEX_UPDATE.