11 - SUPERTRACK K — Refined-Proposal Hardcode / PG-Native-Driven / No-Guess Check

Design-level consistency check on the refined proposals themselves (do the refinements, if implemented as written, introduce any violation?).

1. Does any refined proposal introduce hardcode?

NO. Every numeric/policy value is a sealed manifest/catalog field: retention interval/capacity → storage_class fields (RP-02); thresholds unchanged (CP-05); freshness → sealed max_age fields (RP-01 signoff via signoff_requirement_manifest.max_age_seconds, RP-08 read-contract max_age); structural literals → structural_literal_class family (RP-04). No adapter literal is proposed.

2. Does any refined proposal create a new uncounted authority surface?

NO. RP-02 → #05 (or explicit counted #28), RP-03 → #20, RP-04 → code_catalog root, RP-05 input-contract → code_catalog/operator manifest, RP-08 → #21. RP-01 tables are explicitly NON-authority runtime evidence (owner/append-only/hash-bound/exact-set), not authority surfaces. Net new authority surfaces = 0 (or +1 counted if Codex picks RP-02 option ii, with all "27" statements updated).

3. Does any refined proposal rely on Directus-editable authority?

NO. Every authority/evidence object is owner qt001_cp_owner; Directus retains only SELECT on business base tables (CP-07 path A). RP-01 evidence tables, RP-02 storage_class, RP-03 authority_scope, RP-04 catalog, RP-07 FK — all owner-only, no Directus DML.

4. Does any refined proposal use regex/source-text as FINAL authority?

NO. RP-03 verification reads pg_constraint/pg_index (PG STRUCTURAL catalogs = authoritative truth, not source text). RP-04/RP-05 SA15 source scans are used to BLOCK (fail-closed), never to GRANT readiness; they sit over hash-bound source. Authority always resolves from sealed rows + PG catalog truth.

5. Does any refined proposal break PG-first/native/driven?

NO. Truth stays in PG; enforcement uses roles/ownership/FK/CHECK/UNIQUE/index/triggers/functions over sealed rows + pg_catalog; behavior stays manifest/catalog-driven; generic guards derive pass/blocked (no authored verdicts). RP-01 even strengthens PG-driven by making runtime facts first-class PG evidence.

6. Does any refined proposal create scale risk?

NO. RP-01 high-volume tables are time-partitioned with sealed retention (RP-02); readiness reads sealed manifest rows + bounded fact sets, not 100M-object scans; hashing remains over bounded manifest/control-plane payloads; the dependency/authority-scope manifests stay control-plane-scoped (re-affirmed). Partition maintenance is Level-B operator-gated reading sealed fields. Consistent with prior FEASIBILITY_SCALE_VERIFIED; runtime scale evidence remains operator-gated/pending.

7. Does any refined proposal require implementation guessing?

NO. Each RP gives exact tables/columns/FK targets/hash inclusion/gate impact/verification. RP-01 offers a defined path A (byte-level) OR an explicit path B (downscope + mandatory re-audit binding columns into the hash maps) — both eliminate guessing. The expected-constraint catalog (RP-03), family set (RP-04), and FK (RP-07) are fully specified.

Verdicts

• ZERO_HARDCODE_REFINED_PROPOSALS_PASS
• PG_NATIVE_DRIVEN_REFINED_PROPOSALS_PASS
• NO_GUESS_REFINED_PROPOSALS_PASS

Residual notes for Codex (not violations)

• RP-02: prefer option (i) storage_class fields to keep the "27" invariant; if option (ii), update every "exactly 27" statement and the HASH_COMPONENT denominator.
• RP-03: choose the extra-unknown-constraint policy (default FAIL fail-closed; quarantine only for benign non-authority index types).
• RP-05: recommend an explicit named bypass vector "hidden-policy-in-catalog-payload" in the ACTIVE BYPASS_VECTOR set so the control is also gate-visible.