06 — Readiness v5 (no literals, no false green)

Design

v_qt001_apply_readiness_dashboard_v5 has 12 gates, every one derived from a guard view — no literal allow/deny, no fixed count, no collection list. SSOT gates (7): rule_engine_fail_closed, parity_not_authority, plan_fingerprint_complete, exact_signoff_logic, hardcode_guard_v3, disguised_hardcode_detector, writer_governance_wired. APPLY gates (5): plan_bound_signoff_present, tier_permits_apply, owner_execute_permit_valid, permit_run_keyset_present, scale_safe.

The previously-literal keyset gate is now a derived existence check (count of pg_proc matching qt001.*(keyset|resume|watermark) > 0); the previously-fixed BLOCKED dashboard text is computed (CASE on bool_and(ready)). v_qt001_apply_readiness_guard_v5 aggregates: overall_ready = bool_and(ready); ssot_ready; apply_ready; computed_status; computed_reason.

Live state (must remain BLOCKED)

overall_ready=false; ssot_ready=true (7/7 green); apply_ready=false (0/5 green). computed_status=BLOCKED. The green path is impossible today because it requires real future-layer facts: an exact plan-bound external SAFE signoff for every candidate, a tier with apply_allowed=true, an open scoped owner execute permit, a permit/run/keyset/resume layer, and scale-safe — none of which a literal can fake. Readiness can only turn green when those layers genuinely exist.