11 - SUPERTRACK K — PG-First / Native / Driven Final Scan

Verdict: PG_NATIVE_DRIVEN_NEEDS_CORRECTION

Consistent with my prior K verdict. Every subsystem is genuinely PG-native; the residual is completeness, not a hosted-hardcode FAIL.

Scan results

• Truth lives in PG — VERIFIED (runtime truth, identity, policy, thresholds, evidence, hashes, epoch, privileges are PG rows/objects).
• Enforcement uses PG roles/ownership/FK/CHECK/constraints/functions/views — VERIFIED (owner qt001_cp_owner; typed domains; PK/UNIQUE/FK RESTRICT NOT DEFERRABLE; structural CHECK; partial unique indexes; one-active indexes; SECURITY DEFINER pinned-search_path entrypoints; seal/activation locks on control_epoch then tables).
• Behavior is manifest/rule-driven — VERIFIED (generic engines read sealed rows; thresholds/operands/quorum/families are data).
• Functions do not embed policy decisions — VERIFIED (fn_assert_catalog_family, fn_assert_typed_operand, generic rule evaluator: no CASE on codes, no family/type/threshold literals; values resolved from sealed IDs).
• Readiness is exact-set and sealed — PARTIALLY VERIFIED. The exact-set seal over the 27 manifest children + catalog is sound. But the FULL "exact-set sealed readiness" claim is not yet provable because (a) the runtime instance/result tables consumed by H04/H05/H06 are undefined (RP-01), and (b) the retention authority surface is uncounted (RP-02), and (c) catalog-contract coverage is unguaranteed (RP-04). Until the complete authority surface set is enumerated and exact-set sealed, "exact-set sealed" is asserted but not fully closed.
• Writer/apply path forced through control-plane — VERIFIED in design (owner SECURITY DEFINER entrypoints; PUBLIC/Directus EXECUTE revoked; gateway/writer_repoint manifests; fail_closed boolean as data).
• Directus cannot mutate authority after cutover — VERIFIED (CP-07 path A; SELECT-only; authority-zero smoke evidence).
• Readiness blocked before cutover — VERIFIED (readiness false until read-smoke + authority-zero evidence fresh/hash-bound; epoch increments keep readiness false).
• No UI/app/manual state affects eligibility — VERIFIED for the manifest/contract layer; to be re-confirmed once instance/evidence tables (RP-01) are defined so the full eligibility input set is PG-sealed (e.g., dashboard export as a guarded, sealed input not a mutable app artifact).

Why NEEDS_CORRECTION (not VERIFIED, not PG_HOSTED_HARDCODE_RISK)

The architecture HOSTS no hardcode — it is the strongest PG-native model in this series. But two PG-native CLAIMS cannot be fully proven from the current package: "exact-set sealed readiness" (needs the complete sealed surface set — RP-01/RP-02/RP-04) and the structural guarantee that no operational value is read from item_payload (RP-05). These are corrections to complete the PG-native proof, not evidence of hosted hardcode.

Conclusion

PG_NATIVE_DRIVEN_NEEDS_CORRECTION — close RP-01, RP-02, RP-04, RP-05 to reach PG_NATIVE_DRIVEN_VERIFIED.