05 — Discovery v6 + Policy (Workstream D)

5 v6 views LIVE (additive, reversible, generic)

1. v_process_discovery_agent_api_endpoint_status — per agent_api DOT: endpoint_status ∈ {no_contract, endpoint_missing, endpoint_staged, endpoint_bound}. Today: pilot pair = endpoint_missing, other 10 KG agent_api DOTs = no_contract.
2. v_process_discovery_endpoint_binding_status — per candidate rollup: binding_status ∈ {no_contracts, all_missing, partial_binding, all_bound}. dot:kg = all_missing (2 contracts, 0 endpoints).
3. v_process_discovery_candidate_status_v6 — candidate_status_v5 + endpoint dimension. A plan_only_tested candidate becomes dry_run_ready only when ≥1 endpoint is bound. Live: dot:kg = plan_only_tested (endpoint still missing); job:cut = verified_candidate.
4. v_process_discovery_birth_readiness_v6 — birth_readiness_v5 + endpoint dimension; agent_api candidates = blocked_endpoint_missing until bound; job:cut = verified_pending_owner.
5. v_process_discovery_auto_workflow_policy_gaps — admission-policy gate per candidate (see below).

Status vocabulary (matches macro §8)

endpoint_missing · endpoint_staged · endpoint_bound · plan_only_tested · dry_run_ready · dry_run_observed · owner_missing · event_inactive · verified_candidate · birth_ready. No fake verified anywhere; candidate_status_v6 never invents a rung the evidence doesn't support.

Admission policy (the ladder, encoded as gates)

v_process_discovery_auto_workflow_policy_gaps evaluates every candidate against ordered gates and reports the first failing one as policy_state + an exact next_required_action:

gate	meaning
gate_component_graph	member_count ≥ 2 (else not_a_process)
gate_correlation	run-level correlation across components
gate_endpoint	for agent_api candidates: ≥1 endpoint bound
gate_dry_run_observation	≥1 DRY_RUN observation
gate_real_run_observation	≥1 REAL_RUN observation
gate_owner	governance owner assigned

Live read-back (17 candidates): 8 not_a_process; 8 gap_no_correlation_model (incl. dot:kg — it also fails endpoint + dry-run gates, but correlation is the earliest); 1 gap_no_owner (job:cut → "assign governance owner, then birth"). Order is deliberate: a candidate must earn correlation before runtime, runtime before verification, verification before owner, owner before birth.

Policy: candidate → verified → birth-ready (the rule)

A candidate may move:

• structural_candidate → simulated_observed: a SIMULATED_DRY_RUN observation exists (no real invocation).
• → dry_run_observed: a real no-mutation invocation produced a DRY_RUN observation (requires a bound endpoint for agent_api candidates).
• → real_run_observed: a REAL_RUN with a shared process_run_id across components.
• → verified_candidate: real runtime + cross-component correlation (current verified logic; only job:cut qualifies).
• → birth_ready: verified and owner assigned. No step may be skipped; SIMULATED never counts as DRY_RUN; the verified set is computed by existing verified_candidates_v3 logic, never hand-set.

Note on RO timeout

The deep candidate_status_v6/_v5 chain can hit the RO 5s statement_timeout; it resolves instantly via RW/app role. Perf note, not correctness. The shallow v6 views (endpoint_status, endpoint_binding_status, auto_workflow_policy_gaps) query fast.

Completion

v6 surface + admission policy LIVE and proven.