10 — Final GO/NO-GO for RP DOT Cleanup

DECISION: NO-GO (continue the pause)

RP DOT cleanup — specifically dot-pivot-update registration and apply_composition_fixes.sh --commit — remains paused. Rationale: the GPT decision required that any systemic hole be hardened before continuing DOT registration/cleanup, and this audit found live, decisive holes (G1, G2, G4, G7, G8). Continuing now would proceed on the false premise that "the system catches mistakes" — it does not. The minimum precondition to reconsider is patch 1 (row-level orphan/phantom detection) live (doc 09).

Nuance: the lawful registration path itself is not broken; registering dot-pivot-update via dot-dot-register would fire auto-birth. But registration neither places it under (absent) row-level orphan detection nor under (inert) governance onboarding, so it must wait behind the hardening.

---

The 12 required answers

1. Is automatic birth live for all relevant object families, or only some? Only some. Live for collections registered in collection_registry/species_collection_map that carry a birth trigger (~100+ tables, 1.1M rows). Not for unregistered tables or filesystem artifacts.
2. Are there object families that can appear without birth? Yes — (a) unregistered tables (dot_iu_command_catalog, 54 rows); (b) filesystem DOT scripts (dot-pivot-update + others); (c) rows inserted before a collection's trigger existed (22 pivot_definitions).
3. If an object appears without birth, is it automatically detected as orphan/unborn? Mostly no. Row-level missing-birth has no live detector (the live "orphan" metric measures metadata completeness). Collection-level missing-trigger is detected only if the collection is registered and the idle scan runs. dot_iu_command_catalog and filesystem files escape entirely.
4. Is detection immediate, scheduled, manual, or absent? Row-level: absent. Collection-level: manual/intermittent (last 2026-05-25, not scheduled). Birth gate: immediate but advisory.
5. Is DOT file creation covered by birth? No — birth is DB-row-triggered; a file creates no row.
6. Is DOT registry creation covered by birth? Yes — INSERT into dot_tools fires auto-birth (+ advisory gate).
7. Is dot-pivot-update a valid DOT, staged file, orphan, phantom, or invisible? Unregistered/staged file — currently invisible/unmanaged; not a valid DOT; not flagged as orphan. (doc 07)
8. Is governance onboarding after birth live for DOT/governance objects? No — inert (ospa=0, candidates=0); and the model is collection-granular, so individual DOTs are never onboarding objects.
9. If a born governance object lacks an owner, does it appear as a governance gap? Only if it is one of the 35 registered governed collections. Individual born DOTs do not. (The dot_tools collection itself is in the 210-gap.)
10. Does the system satisfy "cố ý làm nhầm cũng không có cơ hội"? No.
11. If not, where exactly is the hole? (a) unregistered tables invisible on all axes (dot_iu_command_catalog); (b) row-level missing-birth has no detector; (c) filesystem artifacts uncovered, no reconciler; (d) birth gate advisory + owner-bypassable; (e) governance onboarding inert + wrong granularity; (f) scanners registered but unscheduled.
12. What is the safe path before continuing RP DOT cleanup? Path E+C+D (doc 09): build row-level orphan/phantom detection (patch 1) and a filesystem reconciler (patch 2), schedule the scanners (patch 3), then reconsider; keep RP cleanup paused and dot-pivot-update as a staged file under the temporary guardrails.

---

Verdict summary

• Birth automation: LIVE for row creation on registered collections (G0); enforcement advisory (G1).
• Orphan/unborn detection: ABSENT at row level; metadata-metric only; scanners idle (G2/G8).
• Governance onboarding: INERT + collection-granular (G3/G9).
• Bypass resistance: WEAK — advisory gate, owner bypass, unregistered/file paths open (G1/G4/G7).
• dot-pivot-update: invisible/unmanaged staged file (G4).
• Target "no silent path": NOT met.
• RP DOT cleanup: NO-GO pending hardening.

Remaining blockers

1. Owner-go to apply additive hardening DDL (patches 1–3).
2. Human L2/L4 ratification (ospa≥1) for governance onboarding activation (blocks only the governance layer; unchanged across the line).
3. Decision on DOT governance granularity (row vs collection).

Next macro

BIRTH_ORPHAN_DETECTION_HARDENING_ROW_LEVEL_AND_FILESYSTEM (doc 09).