KB-5345

T1 FIX7 Design Verification - 03 PG First Native Driven (SUPERTRACK C)

5 min read Revision 1
QT001FIX7T1pg-firstpg-nativepg-drivensupertrack-c

03 — PG-First / Native / Driven Review (SUPERTRACK C)

Concrete answers (per the corrected design as written), not theoretical.

C.1 Source of truth for policy

Sealed typed policy manifest rows executed by a generic PG interpreter (00, 10, 11). Concretely: the manifest table, its row schema, the operator-primitive vocabulary and the typed-fact adapters are not yet specified. So the source is PG-resident by design, but the contract is undefined.

C.2 Source of truth for readiness denominator

A sealed exact-set gate manifest (SHA-256), changeable only via quorum activation; runtime roles have zero DML on it (00, 02). Denominator-derivation rule (count-match, NULL-strict) not yet written for FIX7 (inherited from FIX6 readiness v9). → see doc 05.

C.3 Source of truth for signoff identity

FK-bound principal/reviewer manifest + content-addressed evidence (10). Today the live qt001_independent_review_signoff is Directus-owned and Directus-writable (INSERT/DELETE confirmed) → current source of truth is spoofable; FIX7 fixes this only after owner cutover.

C.4 Source of truth for capability evidence

Behavioral test result + operational evidence rows under controlled ownership, with verifier identity (11, 10); not function-existence, not free-text. Measurement/threshold schema undefined. Live qt001_capability_operational_evidence=0 → capability correctly 0/3 today.

C.5 Source of truth for dependency / callgraph truth

A sealed analyzer/static-analysis manifest (because native pg_depend has no func-to-func edges — FIX6 proved func_to_func=0), plus manifest-bounded dynamic SQL with runtime OID checks (10, 02). Analyzer seal/quorum/staleness binding undefined. → doc 09.

C.6 What is enforced by PG roles / constraints / functions?

By design (target state): NOLOGIN owner owns authority; Directus/PUBLIC/runtime get no control mutation and no direct protected-target DML; manifests append-only; FK principal/action/tier contracts; control-epoch lock; secure (definer) functions are the only mutation path. Live today: none of this is enforced — Directus owns the tables and can INSERT/DELETE signoff and INSERT capability evidence. Enforcement is entirely future/operator-gated.

C.7 What remains outside PG and why?

The Level-B DOT/migration pipeline and operator approval (privileged deployment), and the static analyzer (callgraph truth, because PG can't natively express PL/pgSQL call edges). These are legitimately outside PG; the design's requirement that the analyzer output be sealed and that deployment go only through the owner-credentialed pipeline is the right containment — but the seal/approval representation is unspecified.

C.8 Does any UI/app/doc/manual state affect eligibility?

Target design: no (Directus read-only; manual inventory replaced by deterministic closure). Live today: yes — Directus (the app/UI role) owns and can mutate the control plane, so app-layer state still affects eligibility until cutover. This is the single largest live gap.

Classification

  • PG_FIRST: INTENT-PASS / LIVE-FAIL. Truth is queried in PG, but the app role still owns and can change enforcement objects (same condition Codex flagged as PG_HOSTED_HARDCODE_REMAINS in FIX4/FIX5). FIX7 fixes this only after operator cutover.
  • PG_NATIVE: INTENT-PASS / NEEDS_CLARIFICATION. Constraints/FK/role boundaries are the intended mechanism (an improvement over source-text scans), but the constraint/FK/role DDL is not specified, and callgraph truth is necessarily external (analyzer).
  • PG_DRIVEN: INTENT-PASS / NEEDS_CLARIFICATION. Manifest-driven generic engines are the intent; the manifests/engines are not yet authored, so "driven by data not literals" is unproven.
  • PG_HOSTED_HARDCODE_RISK: PRESENT until owner/ACL cutover. Live ownership shows the same hosted-control risk; readiness must stay BLOCKED until cutover + fresh evidence + audit.

Net: the design targets full PG-first/native/driven, but as written it is not yet demonstrable, and the live system is still PG-hosted-with-app-owned-control. Confirm only after Codex publishes concrete specs and the operator completes cutover.

Back to Knowledge Hub knowledge/dev/reports/architecture/t1-fix7-design-deep-verification-before-implementation-2026-06-07/03-pg-first-native-driven-review.md