08 — KG / dot-kg Readiness Rescoring (Workstream G)

8.1 Rescore after inventory fix + runtime hardening (live v_process_discovery_birth_readiness_v2)

candidate	members	real runtime	correlation	conf	class
job:cut	8	✓	✓	100	verified_candidate
dot:kg	36	✗	✗	50	runtime_missing
dot:nrm	11	✗	✗	50	runtime_missing
dot:kb	3	✗	✗	50	runtime_missing
dot:doc	3	✗	✗	50	runtime_missing
dot:gov	2	✗	✗	30	structural_weak
others	1–34	✗	✗	≤10	not_a_process

8.2 dot:kg classification (overlay flags)

PROC-CAND:dot:kg — class runtime_missing, gate BLOCKED_NEEDS_RUNTIME_AND_CORRELATION, conf 50.

• structural_only: ✓ (18 producers = start, 18 verifiers = end, 18/18 complete pairs)
• runtime_missing: ✓ (0 real executions; last_executed backfill ignored)
• correlation_missing: ✓ (no process_run_id/correlation_id across DOTs)
• event_missing: ✓ (process.* events declared but inactive)
• owner_missing: ✓ (governance_object_ownership empty system-wide)
• verified_candidate: ✗ · birth_ready: ✗

8.3 Score of the 18 producer/verifier pairs

All 18 KG pairs are structurally complete (pair_complete=true): each has its on-demand producer and its cron/dual verifier, and paired_dot is set on both halves. Structurally this is the strongest DOT family in the system — the embedded double-check (verifier audits producer) is present on every pair. What is missing is identical across all 18: no real run, no shared correlation_id, no active event.

8.4 Smallest path to verify ONE pair

1. Apply process_run_observation substrate (doc 04).
2. Dry-run one KG pair through the wrapper (doc 06), producing a real (non-dry-run) execution if/when owner permits live run; or at minimum a dry-run that proves the wiring.
3. The pair's two component rows share one correlation_id → v_process_discovery_correlation_gaps closes for that pair → with real runtime, v_process_discovery_verified_candidates admits it. That is the entire distance from runtime_missing to verified_candidate.

8.5 One process or ten?

Ten process definitions at birth, not one blob. The KG family is 10 distinct law processes (A–J), each a producer→verifier pair-cluster with its own inputs/outputs. Birthing one "dot:kg" process would erase that structure and make health/ownership/SLA un-assignable per law. Recommendation unchanged and reinforced by the pair data: keep dot:kg a candidate; at birth, split into the 10 law processes; register the KG owner first.

8.6 What remains to reach verified_candidate

Runtime (real run logged) + correlation (shared process_run_id) + active process.* events + registered owner. Inventory blind spot and runtime-signal correctness — the two things this macro could fix without owner/runtime — are done. Everything left is owner-gated (ownership, birth admission) or requires enabling actual DOT execution.