RS-TKT-0A-PATCH1 · 05 — NVSZ Taxonomy & Ledger Normalization Patch (P5)

Lane: RS-TKT-0A-PATCH1 · Date: 2026-06-21 Gate: REGISTRATION_HOLD · REGISTRATION_CAN_PROCEED = NO · 0 runtime mutations (KB writes only) Authority: NON_AUTHORITY · may_gate=false · decision_effect=NONE · design-only

Supersedes: 05 §1.2 (bare numeric escrow taxonomy) and 05 §2 "accept-either-and-warn" as a final identity. The NVSZ architecture is otherwise retained (Codex: safe; not REJECT_NVSZ_UNSAFE).

---

1. The defect (Codex P5)

Two validator exit taxonomies (escrow vs root-provisioning) used overlapping bare numbers (e.g. "invented root" = escrow 9 but root-validator 4; "missing field" = escrow 3 but root-validator 6), and two ledger filenames (HASH_MANIFEST.txt vs hash_manifest.sha256) created two possible canonical packet identities. Bare numbers and "accept either and warn" are not acceptable as a final design.

2. Namespaced exit codes (no bare numbers in final design)

Every exit code carries its validator namespace. No bare numeric exit code may appear in the final design.

Escrow validator (canonical for run-evidence record validation):

ESCROW_E2  absent
ESCROW_E3  pointer/schema missing field
ESCROW_E4  no regeneration command
ESCROW_E5  raw-log-in-vector-KB
ESCROW_E6  local-claims-authority
ESCROW_E7  byte-exact mismatch
ESCROW_E8  secret token → quarantine
ESCROW_E9  invented root

Root-provisioning validator (separate namespace; root acceptance only):

ROOT_E4   invented root (agent-designated)
ROOT_E6   pointer field missing
ROOT_E10  path traversal
ROOT_E11  symlink escape
ROOT_E12  prod/permission violation
ROOT_E13  fold-apply-while-T1-active

The two namespaces are named, distinct, and never conflated. TKT-L3-NVSZ (see 02) emits the ESCROW_E* code; root acceptance (Phase 3) emits the ROOT_E* code.

3. Canonical ledger filename

Canonical for ALL new packets:  hash_manifest.sha256

• New packets MUST use hash_manifest.sha256.
• packet_tree.sha256 = sha256(hash_manifest.sha256).

Legacy migration (not a dual canonical identity)

HASH_MANIFEST.txt may be accepted ONLY as legacy MIGRATION INPUT.
It MUST be normalized to hash_manifest.sha256 BEFORE packet_tree.sha256 is computed.
"Accept-either-and-warn" is NOT allowed as final canonical identity.

So a legacy packet is first normalized (rename/rewrite the ledger to hash_manifest.sha256 deterministically), and the tree pin is computed over the normalized name. There is exactly one canonical identity per packet. This supersedes 05 §2's "accept either and warn" (which is downgraded to a transient migration step, never the final identity).

4. MCB gating clarification

MCB-2 (two NVSZ taxonomies)   — MUST close before Phase-1 design ACCEPTANCE. (closed here by namespacing)
MCB-3 (ledger filename)        — MUST close before Phase-1 design ACCEPTANCE. (closed here by canonical name + normalize-before-pin)
MCB-5 (NON_VECTOR_ROOT undesignated) — does NOT block Phase 1; blocks Phase 3 and any real escrow acceptance. Owner/operator-only; never invent (ESCROW_E9 / ROOT_E4).

5. What is unchanged

• Raw logs stay out of vector KB; KB holds summary + hash + pointer + regen only.
• No root is designated here; nvsz_root.designated=false in all records.
• The escrow record schema and the self-verifying packet skeleton from 05 are retained, with the ledger filename now canonical and exit codes now namespaced.