01 — QT-001 / QT-002 Definition

Canonical source

knowledge/ops/processes/birth-process-v1.md (v1.0, 2026-03-21, S157 Birth Registry Law-aligned). Re-read in full on 2026-05-25 for this audit.

QT-001 — "Nhập khai sinh" (Backfill — for entities that already exist)

Purpose: bring entities created before birth_registry was operative into the registry. Runs once per collection, then the collection transitions to QT-002 going forward.

5 steps:

1. Preflight. Collection in species_collection_map? Collection in collection_registry with governance_role='governed'? Birth trigger wired? If any "no" → STOP.
2. Count first. A = SELECT COUNT(*) FROM <collection>; B = SELECT COUNT(*) FROM birth_registry WHERE collection_name = '<collection>'. Gap = A − B. If 0 → done.
3. Backfill. Run dot-birth-backfill --collection=<collection> which iterates source rows, checks birth_registry, INSERTs missing rows with (entity_code, collection_name, species_code auto-resolved from mapping, _dot_origin, born_at).
4. Confirm. Recount B'. If B' = A → match ✅; otherwise investigate orphans (legacy O-2).
5. Inspect. Run dot-inspect-pen on the new rows.

Risk: temporary orphan (between count and backfill).

QT-002 — "Khai trước sinh sau" (Birth-first — for new entities)

Purpose: a new entity CANNOT exist without a prior birth record. Applies to every DOT tool that creates a governed entity from now on.

5 steps:

1. Species check. Collection in species_collection_map? species_code valid in entity_species? Otherwise STOP with error.
2. Birth FIRST. Generate entity_code = PREFIX-NNN (next sequence). INSERT into birth_registry with (entity_code, collection_name, auto species, auto composition_level, dot_origin=DOT name, born_at=now(), governance_role='governed'). Keep birth_id.
3. Entity AFTER. INSERT into source collection with code = entity_code from step 2 and _dot_origin. If INSERT fails → ROLLBACK the birth row to avoid phantoms.
4. Match check. Both rows exist? ✅ otherwise immediate error.
5. Inspect auto. Birth trigger fires (ON CONFLICT DO NOTHING); inspect_pen set if validation passes.

Risk: temporary phantom (if step 3 fails); mitigated by step-3 rollback.

Comparison table

	QT-001 (Backfill)	QT-002 (Birth-first)
When	Once per collection, for pre-existing data	Every new-entity creation, from now on
Order	Entity exists → birth record	Birth record → entity
Risk	Temporary orphan	Temporary phantom
Mitigation	Step-4 gap check	Step-3 rollback
DOT tool	dot-birth-backfill	All entity-creating DOTs (dot-content-*, dot-schema-*, …)
Lifetime	One-shot per collection	Permanent

Live verification of QT-001 mechanism

fn_birth_registry_auto() (PG function, retrieved live on 2026-05-25) implements an automatic QT-001-equivalent path when wired as an AFTER INSERT trigger on a catalog table:

-- abbreviated
v_row_json := to_jsonb(NEW);
v_entity_code := v_row_json->>TG_ARGV[0];   -- e.g. 'code'
IF v_entity_code IS NULL OR '' THEN
  v_entity_code := TG_TABLE_NAME || '::' || (v_row_json->>'id');
END IF;
IF EXISTS (... birth_registry ...) THEN RETURN NEW;   -- idempotent skip
v_dot_origin := COALESCE(NEW._dot_origin, 'PG:trg_birth_' || TG_TABLE_NAME);
SELECT species + composition_level FROM species_collection_map JOIN entity_species;
SELECT governance_role FROM collection_registry WHERE collection_name = TG_TABLE_NAME;
INSERT INTO birth_registry (...) ON CONFLICT (entity_code) DO NOTHING;

This auto-birth fires on entity_species, collection_registry, and species_collection_map INSERTs (28 functional triggers inventoried — see 02-live-birth-pipeline-survey).

Case 3 — Catalog Auto-Birth / Readiness Governance Registration

knowledge/dev/laws/dieu44-trien-khai/design/12c-iu0-pack2a-birth-process-classification.md (2026-05-04, re-read full) formally distinguishes a third case for when only catalog rows are being created without underlying data entities being created or backfilled:

"Không phải QT-001, không phải QT-002. Pack 2A là case thứ 3: Readiness Governance Registration."

Criterion	QT-001	QT-002	Case 3 (Pack 2A / NVSZ Macro A)
Entity already exists?	Yes (data rows)	No	Table exists, ≥0 data rows
Need to backfill birth?	Yes	No	No — registry trigger chain auto-births the catalog row itself
Create new entity?	No	Yes	No — only register existing table into catalog
governance_role	governed	governed	governed
species mapping	required	required	required (NVSZ has it: SPE-NVS)

For Case 3, the auto-birth happens on the catalog row (e.g. COL-IUS-001 in collection_registry), not on data rows in the underlying table. Data-row birth, if/when needed, is a separate QT-001 or QT-002 problem for that specific table.

Mandatory flow for new governed collections in 2026-05

A new governed collection registered in 2026-05 follows Case 3 (Catalog Auto-Birth) for the catalog row, then chooses QT-002 going forward for any new data rows inside that collection (or QT-001 once if pre-existing data rows are imported in bulk).

NVSZ Macro A registered two collections (iu_staging_record, iu_staging_payload) → Case 3 applies for the catalog rows. The 3 + 4 proof rows that ended up inside the staging tables are NOT governed entities at the data-row level — staging-tier data is intentionally non-governed (its purpose is to be consumed/rejected/expired, not to be birthed). So there is no QT-001 or QT-002 obligation on staging-row data.