07 — Birth / Collection Cross-Check

Mission §4 birth/collection objects, verified live.

Objects (live)

• birth_registry live = 959,372 (first pass: 954,161). 🔧 first pass stale — append-heavy (system_issues + entity_labels + registry_changelog firehose). The stored meta_catalog CAT-023 record_count = 959,372 agrees with live (count_b 943,726 = LỆCH on the recompute side, not the stored side). Lesson: birth_registry is a moving target; cite via pivot/CAT, never a frozen literal.
• fn_pre_birth_check(p_collection,p_code,p_name,p_dot_origin) — 5 checks (managed-in-meta_catalog; non-empty _dot_origin; code regex ^[A-Z]+-[0-9]+$; name not dup; code not dup). Carried from first pass + prior G1 dress-rehearsals (fn_pre_birth_check 5/5 PASS, BEGIN..ROLLBACK). Definition not re-read this pass; high prior confidence.
• fn_birth_gate() — SOFT gate, app.birth_gate_mode default warning; kill switch app.bypass_birth_gate. Carried.
• meta_catalog (169) = SoT "list of lists" with denormalized counts. Verified 169 live. CAT rows point at registries (CAT-006/CAT-DOT→dot_tools, CAT-023→birth_registry, CAT-007→pages, roll-ups CAT-ALL/MOL/CMP/MAT).
• collection_registry (168), table_registry (21) (UI table-def registry, NOT data SoT), entity_species (42) — all verified.

Birth/collection completeness verdict (mission Q7)

Complete and live. The birth gate + meta_catalog + collection_registry + entity_species chain is the reference implementation of a living list (first pass doc 07 #13 / doc 10). Re-confirmed. Any new registry/list must be born through this chain (Đ0-G + Đ36 + Đ29 4-attr + Đ32 approval) — raw-creating a registry table is the "đẻ rơi" (orphan birth) anti-pattern, per the prior SuperBundle candidate-registry reports.

Reference-table / config-table pattern — ANTI-FORGETTING ADDITION

The first pass did not surface the S165-KB pattern explicitly:

"Reference tables thay CHECK, config tables thay hardcode, PG triggers enforce tại cổng vào." — 8 reference tables (4 Đ35, 3 Đ36, 1 Đ28) + config tables (dot_config, collection_config).

This is a reusable governance capability: instead of hardcoded CHECK constraints / whitelists, the system uses reference tables (add a value = INSERT, 0 deploy) + config tables (behavior tunable without code) + PG triggers enforcing at the gate. Live evidence already in the inventory: dot_config, dot_domain_rules (67), kg_constraint_config, collection_field_standards (11), field_type_equivalences (4).

Why it matters for official lists: when an official list needs new allowed values, statuses, or tiers, the reuse path is INSERT into the reference/config table, not a schema change or a hardcoded enum. This pattern should be the default for list-vocabulary growth. → REUSE (capability now explicitly logged so it is not re-invented as "we need a new settings system").

Verdict

Birth/collection: VERIFIED LIVE, REUSE. One stale literal corrected (birth_registry 959,372). One reusable pattern (reference/config-table anti-hardcode, S165-KB) added to the ledger.