04 — Live Governance Onboarding / Coverage Audit (read-only)

1. The substrate EXISTS (corrects the 2026-06-01 "ABSENT" framing)

All onboarding tables/views are present in prod directus: governance_object_ownership, governance_responsibility_scope, governance_candidate_object, governance_candidate_state, candidate_scan_run, governance_ruleset, gov_worker_cursor, v_governance_object_inventory, v_governance_object_containment, v_object_owner_gap, event_pending. (Design docs 31/32/34 called candidate_state "ABSENT/SB-10"; it was built in the later phase-1 / release-engineering work.)

2. …but it is INERT

governance_object_ownership   0
governance_responsibility_scope 6
governance_candidate_object   0
governance_candidate_state    0
candidate_scan_run            0
governance_ruleset            0
gov_worker_cursor             0
event_pending                 0
v_governance_object_inventory 35
v_governance_object_containment 35
v_object_owner_gap            210

• Finding GO-1: ownership=0 ⇒ ospa=0 ⇒ rollout NO-GO (unchanged from the whole governance line). No candidate has ever been scanned (scan_run=0), no ruleset is loaded (ruleset=0), no worker cursor advances (cursor=0), nothing is queued to emit (event_pending=0). The birth→governance handoff worker (design doc 32) is not running.

3. The model is COLLECTION-granular — not object/DOT-granular

v_governance_object_inventory is defined as:

SELECT 'collection' AS object_type, collection_name AS object_ref,
       governance_role IN ('governed','locked') AS requires_owner,
       coverage_status='BIRTH_REQUIRED' AS born
FROM collection_registry
WHERE governance_role='governed' AND coverage_status='BIRTH_REQUIRED';
-- → 35 rows, all object_type='collection', born=true, requires_owner=true

v_object_owner_gap = inventory × active scopes (6) LEFT JOIN effective owner WHERE owner IS NULL → 210 = 35 collections × 6 scopes, all ownerless.

• Finding GO-2 (structural): governance objects are collections, never individual DOTs/pivots/rows. Therefore:
  • A newly born DOT (a row in dot_tools) never enters governance inventory — only registering a new governed collection changes the inventory. (Answers audit Q36 = NO.)
  • A born, ownerless DOT never appears as a governance gap — the gap is per-collection-per-scope. (Answers Q37 = NO for DOT-level; the dot_tools collection itself is COL-107, in inventory, ownerless, part of the 210.)
• Finding GO-3: so even if onboarding were activated, "governance onboarding for a new DOT" is a category mismatch with the live model. The mission's premise ("a DOT is a governance object → must satisfy governance onboarding") is not how the live layer is built — it governs the dot_tools collection, not each DOT.

4. Would a born governance object be detected as covered/gap automatically?

• No automatic path. Nothing reads birth_registry (1.1M rows) into candidate state. v_object_owner_gap is a static view over 35 curated collections, not fed by birth. Detection of a new governance object depends on a human/dot adding it to collection_registry as governed+BIRTH_REQUIRED, then on the (inert) ownership layer being activated.

5. Where the file-only DOT artifact appears in governance

• Nowhere. dot-pivot-update is not a collection, not a dot_tools row, not a birth row. It is outside inventory, containment, gap, candidate, and ownership entirely.

6. Verdict

Governance onboarding is built but inert (G3/G9) and collection-granular, so it neither onboards individual born objects nor exposes a per-object gap. The only live "hard gap" it exposes is the 210 collection-ownership gap, which is itself gated closed (ospa=0).