05 — C1 Manifest/Resolver Freeze and Hash Proof — 2026-06-22
05 — C1 MANIFEST / RESOLVER FREEZE + HASH PROOF — 2026-06-22
1. What can be done vs what cannot
A canonical serialization profile (cser-v1: RFC-8785-style sorted keys, UTF-8 NFC, explicit null) is pinned from PATCH2 with a real sample digest 2ab1f90bc57322438186f967613290824c704664d516ca3feec96f01eb99e650. Over a candidate value set, a digest is recomputable on paper. But this is not an authority-frozen, registered manifest, for three reasons proven live:
2. Resolver authority is not wired
apr_action_types (14 active) and process_axis_action_vocabulary (12) join to 0 rows on action code — different namespaces (APR uses create_item, authorize_build_step; PAV uses APPROVE_BIRTH_ADMISSION). The PATCH2-corrected design (R_C1 over apr_action_types' own columns) is a design; there is no registered resolver function (DOT_C1_VOCAB_BUILD/VERIFY) to execute it (file 03). (E5, prior R8)
3. No registered artifact to bind the hash to
A frozen manifest must live as a registered artifact (a DOT_C1_* contract's expected_output_schema/value snapshot, or a governed manifest row). Those objects do not exist and cannot be created (no write/DDL channel). A hash computed in a report is not "frozen" — nothing governed pins it, and the next reviewer cannot read it back from a contract.
4. Negative cases (would-reject by design, not executable)
extra value · missing value · renamed value · wrong version · unapproved source · hash mismatch — each is a defined reject in the PATCH2 verifier spec, but none is executable because the verifier function/contract is absent. Absence of an executor ≠ demonstrated rejection.
5. Status
Manifest/resolver/hash: design-only; not an authority-frozen, registered, recomputable-from-runtime artifact. Partial closure (paper hash) does not satisfy the readiness criterion. Gap remains.