04 — Registry-Driven Axis Source Binding

v_rp_axis_source_binding externalizes the per-axis source contract that was previously implicit in v1's UNION ALL literals. is_registry_backed is derived live from axis_registry (LEFT JOIN), not declared.

axis	governance_class	source_view	node_key	count_col	children_source	substrate_resolver	registry_backed	synthetic	status
AX-BASE	synthetic_native_pivot	v_registries_pivot_node_contract	node_code	count_value	child_pivot_codes	final_substrate_ref	false	true	NATIVE_PIVOT
AX-TOPIC	candidate_registered	v_registries_pivot_axis_surface	node_code	count_value	(self)	substrate_ref	true	false	CANDIDATE
AX-PROCESS	candidate_registered	wf_process_candidate (+workflows+jobcut)	candidate_code	member_count	wf_process_candidate_member	fn_process_node_substrate	true	false	CANDIDATE
AX-TRIGGER	synthetic_census	v_ax_trigger_surface	node_code	members	v_trigger_universe_census	v_trigger_universe_census	false	true	SYNTHETIC_CANDIDATE
AX-PXT	synthetic_ledger	v_process_trigger_actionability_ledger	gap_code	object_count	(ledger)	(ledger)	false	true	SYNTHETIC_DERIVED

Findings

• 2/5 axes registry-backed (AX-PROCESS, AX-TOPIC) — both pull node_source/substrate_resolver from axis_registry and are echoed as registry_node_source / registry_substrate_resolver.
• 3/5 synthetic (AX-BASE, AX-TRIGGER, AX-PXT) — not in axis_registry; their binding now lives in declarative metadata rather than buried in v1 SQL.
• Each row carries owner_blocker + next_action (e.g. AX-PROCESS → president_vote_PROC_OWN, AX-TRIGGER → register_axis_then_owner).

Safety / form

Implemented as a view (not a table) to guarantee birth-free. Productionizing as a base table (so new axes are added by row) is a clean next step but requires owner sign-off; the view contract is identical and apply-ready. Adding a new axis still also needs the v1 UNION generator to be replaced (see Phase 5/9) — the binding alone is necessary but not yet sufficient for true auto-scale.