09 — Dependency Truth / Callgraph Review (SUPERTRACK I)

Context: FIX6 proved natively that pg_depend/pg_rewrite record no PL/pgSQL function call-edges (func_to_func = 0); v_qt001_callgraph_unclassified_fail_guard blocks and regex was demoted to diagnostic with v_qt001_callgraph_no_regex_authority_guard proving (via pg_depend) that no authoritative guard derives from regex. This is the hardest constraint FIX7 must respect.

#	Requirement	Design answer	Verdict
I.1	Does not pretend pg_depend sees PL/pgSQL body calls	design uses an external analyzer + manifest, not pg_depend, for call truth	PASS (intent) — the design correctly does NOT claim native callgraph; this is the right lesson from FIX6
I.2	Unknown dependency fails	FIX6 unclassified → BLOCK; FIX7 "deterministic authority-scope closure" + analyzer contract	INTENT-OK; FIX7 fail-closed-on-unknown rule not concretely restated → NEEDS_CLARIFICATION
I.3	External static-analysis manifest is sealed if used	"analyzer contract and manifest-bounded dynamic SQL"; "manifest-driven … vectors" sealed (10,02)	INTENT-OK; the analyzer's seal/quorum/signing and how its manifest is bound to live function bodies are not specified
I.4	Runtime role cannot edit dependency truth	runtime zero DML on manifests; owner-only (02)	INTENT-OK (target); LIVE-FAIL — app role owns control tables today
I.5	Dynamic SQL requires manifest-bound + runtime OID checks	"dynamic SQL allowed only when manifest-bound and runtime OID-checked" (10, checkpoint)	INTENT-OK (good, concrete-ish principle); the OID-check predicate not written
I.6	No regex/source-text proof as final authority	FIX6 demoted regex to diagnostic; FIX7 "analyzer contract"	NEEDS_CLARIFICATION — must confirm analyzer output is sealed evidence, not a live source-text scan acting as authority

The core risk: analyzer trust + staleness

Because PG cannot natively express the callgraph, FIX7 necessarily relies on an external static analyzer to produce the dependency/callgraph manifest. This shifts the trust boundary outside PG (legitimately — see doc 03 C.7). The unspecified, load-bearing questions are:

1. Who runs the analyzer and how is its output sealed? (quorum-signed like other manifests? content-addressed against the analyzed function source?)
2. Staleness binding: how does the system guarantee the analyzer manifest corresponds to the current function bodies? If a function body changes after analysis, the sealed callgraph is stale. There must be a binding (e.g. hash of pg_get_functiondef of every node) that invalidates the manifest when any body changes — analogous to the control-epoch but for code. This is not specified.
3. manifest-bounded dynamic SQL + runtime OID check is the right containment for EXECUTE, but the actual OID-check predicate (resolve identifier → OID → assert ∈ sealed manifest before EXECUTE) is not written.

These are exactly the holes that, if left to T1, would be guessed differently from Codex's intent.

Dependency/callgraph verdict

No fake callgraph proof in the design intent — the design correctly refuses to claim native pg_depend call truth (PASS on I.1) and routes call truth through a sealed analyzer + OID-checked dynamic SQL. But the analyzer's seal/quorum/staleness-binding and the OID-check predicate are unspecified, and the runtime cannot-edit guarantee is live-false until cutover. → PASS(I.1) + NEEDS_CLARIFICATION(rest). Required correction: specify the analyzer trust model, its source-hash staleness binding, the unknown-node fail-closed rule, and the dynamic-SQL OID-check predicate.