05 — Birth Gate WARNING Triage

The warning

Two collection_registry rows have _dot_origin = 'SUSPECT:D36-Macro-A':

• id 190 (COL-IUS-001, iu_staging_record)
• id 191 (COL-IUS-002, iu_staging_payload)

Their birth_registry rows inherit the same dot_origin = 'SUSPECT:D36-Macro-A'. The SPE-NVS row in entity_species does NOT carry the prefix (its origin is the clean D36-Macro-A), because entity_species lacks the validator trigger that produces SUSPECT — a real asymmetry, not specific to NVSZ.

Root cause (live evidence)

fn_validate_dot_origin (BEFORE INSERT/UPDATE OF _dot_origin on collection_registry):

-- TODO TD-411: move to dot_origin_whitelist table for meta-driven whitelist
_whitelist constant text[] := ARRAY['DIRECTUS', 'LEGACY', 'MIGRATION'];
...
IF NEW._dot_origin = ANY(_whitelist) THEN RETURN NEW; END IF;
IF NEW._dot_origin LIKE 'SUSPECT:%' THEN RETURN NEW; END IF;
dot_code := split_part(NEW._dot_origin, '|', 1);
IF NOT EXISTS (SELECT 1 FROM dot_tools WHERE code = dot_code) THEN
  NEW._dot_origin := 'SUSPECT:' || NEW._dot_origin;
END IF;

dot_tools has 309 rows, none named D36-Macro-A. D36-Macro-A is a macro label, not a DOT tool code; macros are layers above DOT tools and were never registered in dot_tools (no historical macro has been). The function therefore prepends SUSPECT: and returns the modified row. It never blocks the INSERT.

Severity assessment

• The trigger does not raise EXCEPTION, does not modify any other field, does not affect downstream auto-birth.
• The fn_birth_registry_auto AFTER INSERT trigger reads the (now SUSPECT:-prefixed) _dot_origin verbatim, copies it into birth_registry.dot_origin. So the prefix propagates one hop but stops there.
• coverage_status='BIRTH_REQUIRED' on the catalog rows is independent of the SUSPECT prefix; it is set by fn_collection_onboarding_soft_gate based on coverage fields, and reflects "this row exists but is not yet certified," not "this row is suspect."
• certified=false on the birth records is the normal initial state — certification flips via fn_birth_auto_certify on UPDATE once inspection stamps land.

Severity: SOFT WARNING. Not blocking, not destructive, not invalid.

Accepted-pattern evidence

Live birth_registry rows with dot_origin LIKE 'SUSPECT:%' (top 10 by born_at DESC):

entity_code	born_at
COL-IUS-001	2026-05-25
COL-IUS-002	2026-05-25
DOT-IU-CUTTER-VERIFY	2026-05-15
DOT-IU-CUTTER	2026-05-15
table_registry::21	2026-05-08
tbl_event_outbox	2026-05-08
DOT-TAC-LABEL-FORMAT-VERIFY	2026-04-27
DOT-TAC-LABEL-FACET-VERIFY	2026-04-27
DOT-TAC-LABEL-VERIFY	2026-04-27
DOT-TAC-VECTOR-VERIFY	2026-04-27

This pattern dates back at least to April 2026. Multiple DOT tool registrations (DOT-IU-CUTTER, DOT-TAC-LABEL-*, DOT-TAC-VECTOR-VERIFY) and table registrations (tbl_event_outbox, table_registry::21) carry the SUSPECT prefix — and the system has continued to operate against them. None of these have been rolled back or reapplied to clear the prefix; they have been treated as audit annotations.

Conclusion: the SUSPECT prefix is an accepted historical pattern, not a defect localized to NVSZ.

Why the prefix exists at all (intent)

fn_validate_dot_origin was originally designed (S157 era, per Birth Registry Law Điều 0-G) as a defense-in-depth provenance check: any catalog row created without a verifiable DOT tool origin gets a visible audit marker so reviewers can later decide whether to (a) register the missing DOT tool and clear the prefix, or (b) document an exception. The TODO TD-411 comment confirms the intent was always to externalize the whitelist into a real table so non-DOT origins (macros, legacy, migration scripts) can be declaratively classified.

Triage outcome

Question	Answer
Is the SUSPECT warning blocking?	No
Is it harmless?	Yes — soft annotation, no downstream impact
Is it a governance defect specific to NVSZ?	No — same pattern applied to 4+ historical rows under accepted use
Is it an accepted pattern?	YES (evidence above)
Does it need to be cleared for NVSZ to be considered complete?	NO. Cleared status would be a nicety, not a requirement
Is there a known canonical fix?	YES — TD-411 (dot_origin_whitelist table), pre-existing TODO in function body

Options if the warning needs to be cleared (none required by this audit)

Three independent options, in increasing order of system impact:

Option A — One-shot UPDATE (minimal):

1. Add a dot_tools row for D36-Macro-A (or use category macro-label and register D36-Macro-A under it).
2. UPDATE the 2 collection_registry rows: SET _dot_origin = REPLACE(_dot_origin, 'SUSPECT:', ''). This triggers fn_validate_dot_origin on UPDATE, which sees the now-registered code and keeps it clean. Note: the birth_registry rows would still carry the old dot_origin = 'SUSPECT:D36-Macro-A' — a follow-up UPDATE on birth_registry would be needed (and would fire trg_birth_auto_certify and trg_birth_change_flag_matrix).

Option B — Family registration (better): Register a macro-label category in dot_tools with members D36-Macro-A, D36-Macro-B, … so all future D36 macros pass the validator natively. Same UPDATE cleanup as Option A.

Option C — Land TD-411 (canonical): Implement dot_origin_whitelist as a real table. Refactor fn_validate_dot_origin to query it. Categorize legacy/migration/macro/dot-tool origins declaratively. This benefits ALL macros and clears the TD-411 TODO. Largest scope, best long-term value.

Recommendation: defer all three. None is required for NVSZ to be considered governance-complete. If a follow-up macro chooses to act, Option B + C combined is the right move. Option A is the smallest, safest no-design-change cleanup if a future operator decides to clean the audit trail for NVSZ specifically.

What the BG-LU / BG-UV gates do (for context)

tac_birth_gate_config has 11 BG-LU/BG-UV rows enabled at modes block/warn. These are separate from the fn_validate_dot_origin chain — they live inside fn_birth_gate (BEFORE INSERT trigger). They check structural invariants like:

• BG-LU-02..06 (block, "Hard invariant"): structural law-unit constraints.
• BG-UV-01..06 (mostly block, some warn for quality): unit-version constraints.

These are designed for information_unit / unit_version rows specifically; their interaction with collection_registry INSERTs is via the fn_birth_gate function's logic (not retrieved in this audit because it is not the source of the SUSPECT prefix and not the question). For NVSZ catalog INSERTs they passed without raising any block — evidenced by the fact that the INSERT succeeded.