03 — Live Orphan / Unborn Detection Audit (read-only)

1. What "orphan detection" actually computes today

The 3 live orphan triggers (trg_refresh_orphan_dot/col/species on dot_tools/collection_registry/entity_species) call fn_refresh_orphan_*, e.g.:

-- fn_refresh_orphan_dot()
UPDATE meta_catalog SET orphan_count = (
  SELECT COUNT(*) FROM dot_tools
  WHERE status IN ('active','published')
    AND (description IS NULL OR description='' OR category IS NULL OR category='')
), last_scan_date=NOW() WHERE code='CAT-DOT';

• Finding O-1 (CRITICAL — semantic mismatch): the live "orphan" metric = rows missing description/category (incomplete metadata), NOT rows missing a birth record. Evidence: meta_catalog:

CAT-DOT (virtual) orphan_count = 140   ← DOTs missing desc/category
CAT-006 dot_tools         orphan_count = 0
CAT-024 pivot_definitions orphan_count = 0   ← yet 22 pivots are unborn!

The metric reports 0 orphans for pivot_definitions while 22/37 pivot rows have no birth record. The law's orphan definition (governed entity LEFT JOIN birth_registry … WHERE birth IS NULL) is not implemented as a live view or metric anywhere. (No v_*orphan*/v_all_governed_entities/v_*unborn* exists — catalog scan returned only candidate tables + v_iu_core_retention_candidates.)

2. Registered scanners (Đ33 §11.6) — exist but unscheduled

DOT-095 dot-orphan-scan       domain birth.orphan          cron NULL  partial
DOT-115 dot-orphan-scanner    domain birth.orphan          cron NULL  partial
DOT-116 dot-misclass-scanner  domain classification.species cron NULL partial
DOT-317 dot-sync-orphan-scan  domain monitoring            cron 0 5 * * *

• Finding O-2 (G8): the law-mandated DOT-ORPHAN-SCANNER (daily 2AM) and DOT-MISCLASS-SCANNER (weekly) have cron_schedule = NULL and coverage_status='partial'. cron.job (pg_cron) does not exist in this DB; dot_run_log does not exist. So scheduling, if any, is OS-cron only — and the registry's own NULL schedule + partial coverage indicate they are not actively scanning.
• There is no dedicated scheduled DOT-SCHEMA-SCANNER; the 68 dot-schema-* rows are DDL ensure/diff/snapshot helpers (all cron NULL), not a drift scanner. (Also: duplicate registration — both DOT-0xx and DOT_SCHEMA_* codes for the same scripts = registry data-quality debt.)

3. The collection-level onboarding scanner (the closest real detector)

fn_birth_onboarding_full_scan() (SECURITY DEFINER) is a genuine gap scanner over collection_registry, emitting 11 gap types incl. MISSING_ACCEPTED_BIRTH_TRIGGER (BIRTH_REQUIRED∩IN_SCOPE collection lacking an AFTER-INSERT birth trigger), MISSING_PHYSICAL_TABLE, MISSING_SPECIES_MAPPING, BIRTH_REGISTRY_RECURSIVE_RISK. It logs via fn_b3f1_log_collection_onboarding_gap → system_issues (issue_type='collection_onboarding_gap', source dot-soft-gate-collection-onboarding).

• Finding O-3 (two structural limits):
  1. Collection granularity — it checks whether a collection has a trigger, never whether each row has a birth record. So the 22 unborn pivot rows and 283 phantom dot rows are invisible to it.
  2. Registry-bounded — it iterates collection_registry only. A table not registered there is never even a candidate to flag.
• Finding O-4 (intermittent, not scheduled): system_issues shows it last produced gaps 2026-05-25 (soft-gate, 6 issues) and a fullscan-HC finding on 2026-05-25; the older dot-collection-health onboarding pass was 2026-05-04 (339 issues). Today is 2026-06-03 → 9+ days idle. The "soft-gate" name confirms advisory, not blocking.

4. THE SMOKING GUN — dot_iu_command_catalog

dot_iu_command_catalog: 54 rows
  in collection_registry   = 0
  in species_collection_map= 0
  in meta_catalog          = 0
  triggers                 = 0
  birth rows               = 0

• Finding O-5 (decisive): an object family (54 rows) exists in production outside every axis of the control system — no birth trigger (so no auto-birth), no collection_registry row (so invisible to the onboarding scanner), no species map, no meta_catalog, no orphan metric. It is the live proof that an object can exist with no birth, no orphan label, and no onboarding — exactly the systemic hole the GPT decision asked us to find.

5. Provenance-violation detector is BROKEN

fn_rule_birth_violations() (intended to flag rows missing _dot_origin/date_created) throws a syntax error on the live schema: a managed collection without either column produces CASE ELSE NULL END (empty CASE):

ERROR: syntax error at or near "ELSE" … fn_rule_birth_violations() line 38

• Finding O-6 (G6): this detector currently cannot run at all → another detection path is dead.

6. Verdict

Row-level missing-birth (orphan) detection is ABSENT; the live "orphan" signal is a different (metadata) metric; the collection-level scanner is registry-bounded, collection-granular, and idle; unregistered tables and filesystem artifacts are wholly invisible.