Auto-Birth / Governance System Audit — Tool-Kiem-Thu Objects

• Date: 2026-06-10 · Macro: Birth/Governance Onboarding + Auto-Governance Audit · Codex: NO · Production mutation: NO
• Method: KB-first then PG/Directus read-only. First-hand query_pg probes against DB directus + two delegated read-only recons. Article 13 + 14 in force.
• Verdict: AUTO_SYSTEM_PARTIAL. A mature, live, trigger-driven birth/governance system EXISTS, but its detection boundary is "is the object already a row in a governed Directus/PG collection?". The Tool-Kiem-Thu objects are predominantly external (GitHub repo, OS-level container/Python tool, seccomp files, file-based packets/catalog, KB markdown), so they are not auto-detected / not auto-governed. No fake-green: where I cannot prove detection, it is marked NOT_EVIDENCED.

1. The native auto-system that EXISTS (evidence)

KB laws/processes:

• knowledge/dev/architecture/birth-registry-law.md — "ĐIỀU 0-G: LUẬT KHAI SINH / Birth Registry Law v1.0" (S157). Principle: infrastructure must be able to count everything that will be born.
• knowledge/ops/processes/birth-process-v1.md — "QUY TRÌNH KHAI SINH v1.0" (QT-001 backfill, QT-002 birth-first): "no registration → no birth → not countable", applies to "every DOT tool that creates/imports a governed entity".
• knowledge/dev/architecture/species-taxonomy-complete.md — Species Taxonomy v1.2.
• One-Roof Governance pack — defines 3 orphan detectors: birth-orphan (bottom-up), governance-orphan (OWNER_GAP), anarchic-object ("vô chính phủ"). Status: DESIGN; agencies GOV-MOW/MOT/MOIT/MOUT still draft.

PG surfaces (DB directus, schema public — incomex_metadata/workflow hold ZERO governance tables):

• birth_registry — central "sổ khai sinh", ~1.2M rows / 39 species. Columns incl. entity_code, collection_name, species_code, born_at, status, certified, owner, canonical_address, jsonb_profile, dot_origin, inspect_pen/stamp/gate.
• entity_species (taxonomy), species_collection_map (species→native collection; 60 mappings, ALL Directus/PG collections), tac_birth_gate_config (14 birth-gate checkers).
• governance_registry (agencies), governance_object_ownership (EMPTY, 0 rows — object-level ownership designed-not-populated), governance_candidate_object (scanner landing table), plus governance_audit_log, qt001_*_registry.
• Orphan views: v_birth_orphan (scans exactly 5 collections: dot_tools, pivot_definitions, entity_species, collection_registry, dot_iu_command_catalog), v_governance_object_inventory, wf_orphan_digest, etc. — all operate over already-registered rows.
• Mechanism: PG row triggers trg_birth_<collection> (~28 confirmed via dot_origin, e.g. PG:trg_birth_knowledge_documents, PG:trg_birth_dot_tools). Plus Directus [WATCHDOG]/[DOT-REG] flows. The [AUTO-ID] Directus flows are inactive.

2. First-hand probes run by this macro (evidence)

Probe (DB directus)	Result	Meaning
birth_registry WHERE address/code ~ tool-kiem-thu / ip_dot_inspector	0	No project object is birthed.
birth_registry kdocs WHERE address ~ tool-kiem-thu (total/certified/owned)	0 / 0 / 0	No tool-kiem-thu KB doc is bound by address; none certified/owned.
birth_registry kdocs jsonb_profile/entity_code ~ kiem	0	Not bound by profile either.
species_collection_map species ~ repo/github/file/container/sandbox/packet/ci/seccomp/image	only species→entity_species	No species exists for any external-object kind.
birth_registry kdocs recent 8 rows	ids knowledge_documents::8002..8009, born 2026-06-10 02:45–02:49, species ai_support, status=born, certified=false, owner=null, canonical_address=null	KB-doc auto-birth FIRES, but uncertified/unowned and not bindable to a specific doc (no address/title).

3. Should-detect vs did-detect (per object class)

Object class	Should auto-detect?	Auto-detected?	Where	Label/species	Lifecycle/owner assigned	Verdict
GitHub repo (tool-kiem-thu-ci)	Yes (ideally)	NO	—	none	none	NOT_GOVERNED — no GitHub sensor, no species mapping
Python tool (ip_dot_inspector)	Yes	NO	—	dot_tool only if INSERTed as dot_tools row	none	NOT_GOVERNED — a file in a repo is not a dot_tools row; v_birth_orphan can only flag existing rows, not a never-inserted tool
Sandbox/seccomp/container artifacts	Yes	NO	—	none	none	NOT_GOVERNED — no species
Governed packet / named-query catalog (file)	Conditional	NO as file; YES if stored as context_pack_manifest/dot_iu_command_catalog rows	native collections	manifest/command species	would auto-birth if rows	ORPHAN as file; governable if natively stored (deferred)
KB markdown report	Yes	PARTIAL	knowledge_documents collection (PG) IF ingested	ai_support	born, certified=false/owner=null/address=null	BORN-UNCERTIFIED, not bindable to specific doc → counted-but-not-governed
New Directus/PG object (collection/field)	Yes	YES	birth_registry via trg_birth_*	per species_collection_map	born + gate-checked	GOVERNED — but none of this project's objects are such rows
New labels/species/statuses	Yes	NO	—	not in entity_species	none	NOT_GOVERNED — taxonomy gap

4. What it failed to detect / detected incorrectly

• Failed to detect (missed): the repo, the tool, the guard/test harnesses, seccomp profiles, Dockerfiles, the governed packet file, the named-query catalog, the new species/statuses, every Phase2/3/B4′/B7 evidence artifact that lives only in GitHub//tmp/the agent-data KB store. Expected detection path: a row in a governed collection; actual: none exists.
• Detected incorrectly / incompletely: KB docs reaching knowledge_documents are born certified=false, owner=null, canonical_address=null — i.e. registered but mis/under-classified: no owner, no certification, address NULL so the row cannot be traced back to the markdown it represents. This is a relationship+lifecycle+owner defect, not a clean detection.
• No duplicate/shadow-SSOT created by the auto-system for these objects (it simply did not see them).

5. Root-cause map (per Track-8 taxonomy)

Gap	Root cause	Evidence	Blocks Phase5/pilot?
Repo/tool/seccomp/container invisible	DISCOVERY_GAP — no scanner/sensor reads GitHub or the OS filesystem	no GitHub/FS species, no trigger	Does not block Phase 5 (offline) or controlled pilot directly, but leaves runtime venue ungoverned
No species for external object kinds	TAXONOMY_GAP	species_collection_map has none	Blocks clean governance, not execution
KB doc born uncertified/unowned/no-address	OWNER_GAP + LIFECYCLE_GAP + RELATIONSHIP_GAP	rows 8002–8009 certified=false/owner=null/address=null	No
Object-level ownership designed not populated	REGISTRY_GAP / AUTOMATION_RUNTIME_GAP	governance_object_ownership 0 rows; agencies draft	No
Named-query catalog has no governed home	REGISTRY_GAP	provisional-non-authority (B7-EXP-1)	Blocks catalog promotion only
Anarchic-object detector not operational	AUTOMATION_RUNTIME_GAP / DESIGN_GAP	One-Roof agencies draft	No
Agent (this macro) cannot insert birth rows	PERMISSION_GAP (by design — read-only role; prohibited to mutate)	query_pg READ ONLY	No — onboarding done at KB level instead
Whether tool-kiem-thu docs reached knowledge_documents	EVIDENCE_GAP — address NULL so binding unprovable	probe = 0 by address	No

6. Honest conclusion

The org HAS a real auto-birth/governance system; it works for objects that become rows in governed native collections. Tool-Kiem-Thu's deliverables are mostly external/file-based, so for them the auto-system is PARTIAL → effectively NONE (one degraded path: KB-doc auto-birth, uncertified/unowned/unbound). This macro therefore performs active KB-level onboarding (the object registry) and raises action-ready blockers for the production-registry insertion that only the owner/authority can perform. No claim that the auto-system governed these objects is made; the opposite is proven.