04 — Classification Verdict

Verdict

Technically valid via Case 3 (Catalog Auto-Birth / Readiness Governance Registration). Governance-order nonconforming because the Birth Execution Plan was authored retrospectively, after substrate apply. No rollback. No reapply. Documentation reconciliation only, plus an optional 2-step SUSPECT: prefix cleanup as a future fix phase.

Why "valid"

The trigger chain on collection_registry and entity_species IS the canonical auto-birth mechanism for catalog rows. It is wired live, fires on every INSERT, idempotent via ON CONFLICT DO NOTHING, resolves species and governance from the live registries. (See report 02 §"Auto-birth function body".)
Macro A's INSERT into collection_registry and entity_species is exactly the contract this chain expects. No bypass, no superuser borrow, no manual INSERT INTO birth_registry — the birth_registry rows were produced by the registry trigger itself.
Species, governance, and vector policy are all set correctly. SPE-NVS is governed with vector_eligible=false in kg_metadata; both COL-IUS rows have governance_role='governed'; both have sidecar collection_registry_vector_policy rows blocking vector and semantic search per D36 Rule N1.
There are no orphan or half-born objects (report 03 §"Orphan / half-born check").
The Birth Gate did not block. tac_birth_gate_config shows the relevant block-mode gates (BG-LU-02..06, BG-UV-01..06) passed; the warn-mode gates raised quality warnings (length/provenance) that do not block. The three new D36-specific gates were added by Macro A itself (one ON as panic gate, two intentionally OFF as carry-forward).

Why NOT QT-001 strictly

QT-001 is for entities that already exist as data rows and need backfill into birth_registry after the fact. The NVSZ catalog rows (SPE-NVS, COL-IUS-001, COL-IUS-002) did not pre-exist Macro A — they were created by Macro A. So this isn't backfill.

However, the mechanism used (registry trigger chain auto-firing fn_birth_registry_auto) is functionally identical to the QT-001 backfill DOT (dot-birth-backfill) — both produce birth_registry rows automatically when a governed entity appears. So Macro A used the auto-equivalent-of-QT-001 mechanism for the catalog-row tier.

Why NOT QT-002 strictly

QT-002 requires the birth record to be created BEFORE the entity row, with the entity row carrying the entity_code produced by the birth-registry INSERT. Macro A's flow is the reverse: the catalog row was INSERTed first, then the AFTER INSERT trigger created the birth record. So the temporal ordering is QT-001-style, not QT-002.

If we wanted strict QT-002 for catalog rows, a DOT tool would have to (a) reserve COL-IUS-001 in birth_registry first, (b) then INSERT into collection_registry with that fixed code, (c) rollback the birth row on INSERT failure. The current gen_code_collection_registry BEFORE INSERT trigger and ON CONFLICT-safe AFTER INSERT trigger short-circuit this by generating + birthing in one transaction. This is intentional and accepted system design for catalog rows.

Why Case 3 (Readiness Governance Registration)

design/12c-iu0-pack2a-birth-process-classification.md formally defines Case 3 as the path for:

creating catalog metadata for a (newly-created or pre-existing) physical table,
where the catalog row is the governed entity (governance lives at the catalog tier),
and the table's data rows are separately governed under QT-001/QT-002 if and only if they are governed-tier data.

NVSZ Macro A fits Case 3 exactly:

iu_staging_record and iu_staging_payload are new physical tables.
They were registered into collection_registry (catalog rows = governed catalog entities, born via auto-trigger).
Their data rows are staging-tier (non-governed at the row level by design — consumed/rejected/expired lifecycle), so QT-001/QT-002 do not apply to staging-row content.

Why "governance-order nonconforming"

[[feedback-birth-execution-plan-hard-gate-precedes-apply]] (2026-05-25, established mid-Macro-A) requires the Birth Execution Plan to be authored before any DDL when the Collection Birth Hard Gate is invoked. Macro A applied substrate first, then wrote the plan retrospectively under user pressure. The plan's content turned out consistent with live evidence (the macro PARTIAL_WITH_EXACT_GAP report documents this), but the order violated the gate.

This is a process violation, not a substrate violation. The substrate is internally consistent. The retroactive plan satisfies the documentation requirement but cannot reverse the order in which artifacts were produced.

Should NVSZ Macro A be rolled back?

No. Rollback or reapply is unjustified because:

The substrate is technically valid and correctly registered.
Auto-birth produced the right records.
The only governance signal (SUSPECT:) is a soft warning that any future macro raising the same DOT-origin pattern would also trigger — rolling back NVSZ wouldn't change the underlying validation rule.
The proof rows in staging tables demonstrate the boundary behaviour (consume/reject) the macro claimed.

Should the birth pipeline itself be fixed?

Not for NVSZ's sake. The pipeline works as designed. The TD-411 follow-up (move fn_validate_dot_origin whitelist into a dot_origin_whitelist table) is an independent improvement that benefits all macros, not just D36. It is a candidate for a later macro, not a NVSZ blocker.

Final answers to prompt §"PRIMARY QUESTIONS"

#	Question	Answer
1	Live definition of QT-001 / QT-002	QT-001 = backfill for pre-existing entities; QT-002 = birth-before-entity for new entities. Confirmed via `ops/processes/birth-process-v1.md` re-read + `fn_birth_registry_auto` source.
2	Mandatory flow for new governed collections in 2026-05	Case 3 (Catalog Auto-Birth) for the catalog row; QT-002 going forward for any governed-tier data rows inside the collection (or one-shot QT-001 if importing legacy data).
3	Does the system auto-birth records after object creation?	YES. `fn_birth_registry_auto` is wired as AFTER INSERT trigger on `entity_species`, `collection_registry`, `species_collection_map`. Fires automatically, idempotent.
4	Is auto-birth a valid QT-001 path or a safety net?	Valid auto-equivalent-of-QT-001 path for catalog rows. It is the canonical mechanism the system uses to satisfy Birth Registry Law Điều 0-G for catalog entities. Not a safety net — it is the primary path.
5	How did NVSZ Macro A objects get birth records?	Trigger (registry side effect). Not direct DML, not DOT tool, not manual backfill.
6	Are NVSZ objects fully registered in entity_species / collection_registry / species_collection_map / birth_registry / DOT catalog / retention policy / vector policy sidecar?	All 6 governance registries: YES. DOT catalog: `D36-Macro-A` is not a DOT tool code (it is a macro label) — that's correct, no DOT catalog row was expected for it. Retention policy specifically for `iu_auto_instantiate_event_log` exists but NVSZ-specific retention is a deferred carry-forward, not a NVSZ governance defect.
7	Orphan or half-born objects?	NONE.
8	Is Birth Gate WARNING on COL-IUS-001/002 harmless / accepted / defect?	Accepted pattern. See report 05.
9	Should NVSZ Macro A be classified as: (a) valid QT-001 retro, (b) invalid because it should have been QT-002, (c) technically valid but governance-order nonconforming, (d) requiring rollback/reapply, (e) requiring documentation-only reconciliation?	(c) technically valid but governance-order nonconforming + (e) documentation reconciliation. Not (a) because it's Case 3 not QT-001. Not (b) because QT-002 was not the right path for catalog rows. Not (d) because nothing substantive is wrong.
10	Does the birth pipeline itself need a fix?	NO for NVSZ. Optional independent improvement: TD-411 (`dot_origin_whitelist` table) — beneficial but not blocking.