07 — RP/UI Runtime Observation Impact (Workstream F)

Patch-ready only. No Nuxt deploy, no Nuxt math, no fake verified badge. All values come from PostgreSQL views; the UI renders, it does not compute.

Fields to surface (per candidate, from v_process_discovery_candidate_status_v3 / birth_readiness_v3 / runtime_observed)

field	source column
runtime_status	candidate_status_v3 (structural/simulated/dry_run/real/verified)
correlation_status	has_cross_component_correlation (v2) OR obs_correlation_ids ≥ 1
evidence_type	best_evidence_type (REAL_RUN/DRY_RUN/SIMULATED_DRY_RUN/BACKFILLED_EVIDENCE/NULL)
last_observed_at	runtime_observed.last_observed_at
process_run_id	latest process_run_observation.process_run_id for candidate
component_count	runtime_observed.component_count
component_status_summary	runtime_observed.component_status_summary
event_status	event_missing → "events inactive"
verified_status	membership in verified_candidates_v3 (badge ONLY if real)

Badge rule (anti-fake)

• Green "verified" badge only when candidate_status_v3='verified_candidate' or birth_ready.
• simulated_observed / dry_run_observed render a distinct non-promoting chip ("simulated — wiring proof") so no one mistakes it for runtime. Today only job:cut earns the verified badge; dot:kg shows the simulated chip.

Route / API packet (h3 handlers, additive; consume views, no math)

• GET /process-discovery/runtime-observed → v_process_discovery_runtime_observed
• GET /process-discovery/candidate/:code/runtime → row from v_process_discovery_candidate_status_v3 for :code
• GET /process-discovery/candidate/:code/components → process_component_observation rows for the candidate's latest run
• GET /process-discovery/birth-readiness-v3 → v_process_discovery_birth_readiness_v3

Deploy gating

Operator-gated Nuxt rebuild (UI src outside the MCP read allowlist). This doc is the handoff packet; nothing was deployed.