06 — RP Coverage After Candidates

Source of truth: v_ax_process_rp_visibility_after_candidate_stage (live).

Coverage math (entrypoint / object level)

metric	value	denom	note
universe_total_entrypoints	453	453	unchanged (373 DB defs + 80 host-unmanaged)
db_managed_definitions	373	453	DB-managed; official AX-PROCESS RP still owner-gated
host_orphan_objects_triaged	143	143	was 0 disposed → now 143 disposed
host_candidate_visible	69	143	mapped to a candidate/component RP can list
host_not_process	40	143	OS-level / shared-lib / noise
host_owner_gated	11	143	docker runtime services
host_needs_review	23	143	dot/bin reconcile, throttled DB jobs, infra config
official_ax_process_rp_assigned	0	453	NO axis_assignment written — owner/canon gated
candidate_clusters_populated	17	143	anti-explosion
new_process_candidates	6	19	genuinely new managed processes

Official vs candidate visibility — stated plainly

• Official RP visible: still 0 / 453. No process was assigned to AX-PROCESS canon. This is honest and unchanged — official assignment is owner-gated.
• Candidate / classified visibility: 0 → 453. Every entrypoint in the universe now has a disposition: 373 DB defs are DB-managed (owner-gated for official RP), and all 143 host orphan objects are candidate-visible (69), not-a-process (40), owner-gated (11), or needs-review (23).

The meaningful lift

Before: "scanner found 453 entrypoints + 143 orphans, but RP shows 0 and nobody knows what they are." After: "RP can render a 17-node AX-PROCESS candidate layer; every orphan object is triaged to a disposition; 6 candidates are birth-ready pending owner." The blocker moved from no candidate layer → owner ratification of an existing, evidence-backed candidate layer.