02 · Generator / Auto-Scale Risk

Live self-assessment (the system grades itself NEEDS_REGISTRYIZATION)

v_rp_registry_driven_readiness_scorecard (1 row, live):

field	value
axes_total	5
axes_registry_backed	2 (AX-PROCESS, AX-TOPIC)
axes_synthetic	3 (AX-BASE, AX-PXT, AX-TRIGGER)
hardcoded_union_branches_v1	7
nodes_requiring_view_edit	58 / 87
pct_axes_registry_backed	40.0
pct_literals_live_or_matching	80.0
pct_invariant_pass	97.7
invariant_verdict	FULL_POPULATION_HAS_FAILS
readiness_verdict	NEEDS_REGISTRYIZATION
auto_scale_note	"PARTIAL — binding metadata externalized; adding a new axis still needs v1 UNION edit until a dynamic generator/table replaces v1"

Q: Does the generator design actually reduce hardcode? — Partially, honestly labelled

T1 externalized axis binding into v_rp_axis_source_binding (5 rows) and built v_rp_universal_node_ui_contract_registry_driven (87-row parity, carries requires_view_edit + is_registry_backed + reliability fields). This is real progress: the binding metadata is now declared and queryable, and the scorecard computes the hardcode debt rather than hiding it. Credit: no false "auto-scale solved" claim.

Q: Is new-axis addition possible through binding metadata? — NO for synthetic axes (58 nodes) — P1

• requires_view_edit: 29 false / 58 true. The 29 covered = AX-PROCESS (22) + AX-TOPIC (7), the 2 registry-backed axes. The 58 = the 3 synthetic axes (AX-BASE 39 + AX-PXT 12 + AX-TRIGGER 7).
• is_registry_backed: AX-PROCESS=true, AX-TOPIC=true; AX-BASE / AX-PXT / AX-TRIGGER = false.
• So adding a new registry-backed-class axis is metadata-driven; adding any synthetic/derived axis (or a new source class) still needs a hand-written UNION branch + route literal + substrate clause. The scorecard's own auto_scale_note says exactly this.

Q: What still requires a view edit? — the 7-branch v1 UNION

v_rp_universal_node_ui_contract remains a 7-way hardcoded UNION of axis-code literals with inline route prefixes and a special-cased job:cut branch. _current rides this chain (doc 01 R-binding). The registry-driven view is a parallel artifact — it is not what _current resolves to. STEP 6 of the prior T2 backlog (fn_rp_axis_nodes() + v_rp_universal_node_base iterating axis_registry, retiring v1) is NOT delivered.

Q: What remains impossible in pure SQL/view form? — P2 (architecture honesty)

A view cannot ALTER TABLE/seed axis_registry, and the 3 synthetic axes are derived structures (AX-BASE from pivots, AX-PXT cross-product, AX-TRIGGER census) whose "binding" is a query shape, not a single source table. A pure-view generator can iterate registry rows for table-backed axes; the derived axes need either (a) per-axis resolver functions registered in metadata, or (b) acceptance that they stay declared-and-labelled (DERIVED), never independently officialized. This is a design decision for T1, not a bug — but it must be stated, or "no-hardcode" will be over-claimed.

Q: Risk of replacing one hardcoded UNION with another hidden hardcode? — REAL — P1 watch-item

v_rp_universal_node_ui_contract_registry_driven still enumerates the 3 synthetic axes internally (it has to, to reach 87-row parity). If the next macro repoints _current to the registry-driven view believing "UNION killed," it will:

1. Drop or mis-cover the 58 synthetic-axis nodes (they are requires_view_edit=true precisely because the generator can't yet produce them), and/or
2. Move the hardcode from the v1 UNION into the registry-driven view's synthetic branches — same hardcode, new file.

Binding rule (P1): do NOT repoint _current → registry_driven until registry_driven produces all 87 nodes with requires_view_edit=false. Until then _current → reliability is the correct (if hardcoded-topology) bind, and the autoscale claim must read PARTIAL.

Auto-scale verdict

PARTIAL / NEEDS_REGISTRYIZATION. Counting/census layer auto-scales (pivots, adapters, census). Rendering/contract layer does not for synthetic axes (58/87). The generator externalizes metadata but does not yet eliminate the UNION. T1-fixable without authority, but not done; the absent T1 checkpoint is exactly this work.