07 — Discovery Views v2 (Workstream F) — LIVE

8 additive read-only views committed (incl. the inventory fix from doc 03). v1 views untouched. Birth-free (1,158,148 before==after), rehearsed BEGIN/ROLLBACK net-zero, DROP-reversible (01_views_v2_rollback.sql).

7.1 The views

view	rows (live)	purpose
v_axis_process_inventory_v2	46	inventory fix — on-demand producers visible, pair-grouped, no inflation (doc 03)
v_process_discovery_evidence_graph_v2	113	hardened runtime: runtime_real from real run rows, NOT last_executed; adds last_executed_backfill, in_process_inventory_v1/v2
v_process_discovery_candidates_v2	17	regroup on hardened runtime; members_with_runtime_real, members_backfill_only, members_orphaned_v2
v_process_discovery_runtime_gaps	17	per candidate: RUNTIME_PRESENT / RUNTIME_MISSING_BACKFILL_ONLY / RUNTIME_MISSING_NO_LOGS
v_process_discovery_correlation_gaps	17	has_cross_component_correlation + correlation_source; counts system-wide event correlation rows
v_process_discovery_dot_family_pairs	43	producer/verifier pairing coverage per pair_group (pair_complete)
v_process_discovery_verified_candidates	1	candidates meeting the verified bar (real runtime + correlation + start + end)
v_process_discovery_birth_readiness_v2	17	v2 class + birth_gate_status_v2 + event_missing/owner_missing overlays

7.2 The two correctness fixes over v1

1. Runtime hardening. v1 evidence graph: has_runtime_evidence = (last_executed IS NOT NULL). Proven wrong — last_executed is a backfill (1 distinct ts, usage_count=0). v2: runtime_real = EXISTS(real run row) via dot_iu_command_run(by command_name)/job_queue.finished_at; last_executed surfaced as last_executed_backfill and excluded from scoring. Live effect: runtime_real is true for exactly 6 rows (the real job:cut steps) and 0 DOTs; last_executed_backfill is true for 0 DOTs in the discovery universe (the 157 backfilled tools are non-underscore, out of universe). No candidate is mis-scored today, and the signal is now correct for tomorrow.
2. Correlation generalised. v1 granted correlation only to candidate_kind='job'. v2 keeps that real path (job_queue.run_id) and documents the generic future path (process_run_observation.process_run_id), so DOT candidates have an honest gap (correlation_source = process_run_observation (NOT YET PROVISIONED)) instead of a structural impossibility.

7.3 v1 ↔ v2 comparison (live)

candidate	v1 band	v1 conf	v2 class	v2 conf
job:cut	verified_candidate	90	verified_candidate	100
dot:kg	strong_candidate_structural	50	runtime_missing	50
dot:nrm	strong_candidate_structural	50	runtime_missing	50
dot:kb	strong_candidate_structural	50	runtime_missing	50
dot:doc	strong_candidate_structural	50	runtime_missing	50
dot:gov	weak_candidate	30	structural_weak	30
(others)	weak/not_a_process	≤10	not_a_process	≤10

v2 renames the band to name the missing evidence (runtime_missing vs the vaguer strong_candidate_structural) and separates structural candidates from runtime-verified ones — which is the whole point: the engine can now say why a process is not verified.

7.4 Safety / not-done

• Additive only; no pivot_definitions insert (no unretirable births / no unratified equations); RP surfacing stays report-only (doc 09).
• One performance note: birth_readiness_v2 uses nested EXISTS over evidence_graph_v2 (which itself probes inventory_v2 via a LIKE on member_components) and can exceed the 5s RO statement timeout on an ORDER BY full scan; it returns fine via the RW psql channel. A v2.1 could materialise in_process_inventory_v2 as a join to remove the LIKE. Noted, not silently shipped.