08 — Canonical Hash Review (SUPERTRACK H)

#	Requirement	Design answer	Verdict
H.1	SHA-256, or staged operator requirement if extension missing	"sealed SHA-256 exact-set manifests" (00, both checkpoints)	NEEDS_CLARIFICATION — SHA-256 named, but pgcrypto/digest() availability is never addressed, and there is no "if extension missing, stage as operator install" clause
H.2	No MD5	SHA-256 specified; no MD5 mentioned	INTENT-OK — but note prior stages used normalized-md5 for the gateway fingerprint; FIX7 must confirm MD5 is fully retired from authoritative hashing
H.3	No delimiter concatenation	"content-addressed"; FIX6 used canonical/pg_depend-proven hashing	INTENT-OK; canonicalization method not specified
H.4	Canonical JSONB or stable ordered rows	not specified in FIX7 docs	NEEDS_CLARIFICATION — no statement of jsonb_build/ordered-row canonicalization
H.5	Domain-separated hash components	"manifest-driven hash … vectors"; "hash components" are manifest rows (00,10)	INTENT-OK; domain-separation tags not specified
H.6	NULL critical field fails	FIX6 lineage NULL-strict ('NULL' token, not 0); FIX7 not restated	NEEDS_CLARIFICATION
H.7	Reordering does not change hash	implied by canonical ordering (H.4) — but H.4 unspecified	NEEDS_CLARIFICATION (depends on H.4)
H.8	Changing any control input changes hash	FIX6 lineage: composite fingerprint sensitivity-tested per component; FIX7 "manifest-driven hash vectors"	INTENT-OK; FIX7 component list + sensitivity tests not written
H.9	Signoff affects control-state hash, not plan-content hash	FIX6 fixed-point: v_qt001_plan_content_hash (pg_depend-proven EXCLUDES signoff) vs v_qt001_control_state_hash; design separates the two	INTENT-OK (this is the strongest, most concrete part — inherited fixed-point)

Analysis

The separation of plan-content hash from control-state hash (H.9) is the one hash property that is concretely grounded, via the FIX6 fixed-point the design inherits — adding a signoff updates control-state but not plan-content, breaking the fingerprint/signoff loop. Good.

Everything else is named but not specified, and H.1 is a genuine open dependency: the design asserts SHA-256 without confirming the hashing primitive exists. In PostgreSQL, SHA-256 needs pgcrypto (digest(x,'sha256')) or encode(sha256(bytea),'hex') on PG14+ (sha256() is a built-in from PG11 as sha256(bytea) — availability must be verified on the actual server). If the chosen primitive is unavailable, FIX7 must stage it as an operator-gated extension install (a privileged action), not silently fall back to MD5. The macro's SUPERTRACK H.1 explicitly requires this be addressed; it is not.

Canonical hash verdict

No ambiguous hash is intended (SHA-256, domain-separated, content/plan vs control-state separation), and the plan-vs-control-state separation is concretely sound. But the hashing primitive/extension dependency (H.1) is unaddressed and the canonicalization rules (H.4/H.6/H.7) are unspecified for FIX7. → NEEDS_CLARIFICATION. Required correction: state the exact primitive + extension prerequisite (with operator-install staging if missing), the canonical-JSONB/ordered-row method, NULL-strict rule, the domain-separation tags, and the full component list with sensitivity tests.