09 — Registryization Generator Design

Problem

The v1 universal contract is a hand-edited 7-leg UNION ALL across 5 axes. Adding/changing an axis means editing the view — requires_view_edit=58/87 (the 3 synthetic axes). Goal: move from view-bound hardcode to binding-driven generation.

Generator inputs (already externalized in v_rp_axis_source_binding)

Per axis: source_view, node_key_column, count_column, children_source, substrate_resolver, reliability_source, is_registry_backed, is_synthetic. All 5 bindings are complete (source_view + node_key + count_column non-null) → generator can emit a leg for every axis.

axis	source_view	node_key	count	class
AX-BASE	v_registries_pivot_node_contract	node_code	count_value	synthetic_native_pivot
AX-PROCESS	wf_process_candidate	candidate_code	member_count	candidate_registered
AX-PXT	v_process_trigger_actionability_ledger	gap_code	object_count	synthetic_ledger
AX-TOPIC	v_registries_pivot_axis_surface	node_code	count_value	candidate_registered
AX-TRIGGER	v_ax_trigger_surface	node_code	members	synthetic_census

Output contract

A generated CREATE OR REPLACE VIEW v_rp_universal_node_ui_contract_generated assembled as one SELECT … FROM <source_view> leg per binding, UNION ALL-joined.

Form chosen

SQL-only, function-based, preview — fn_rp_generate_universal_contract_sql() returns the generated SQL text (it does not execute it). This avoids unsafe dynamic SQL (no EXECUTE), keeps apply as an explicit operator/owner step, and lets a human diff the generated SQL against the hand-built v1 before any replacement. Adding a new axis = inserting a binding row, then re-running the function. See 10 for the prototype + emitted SQL.