02 — Auto-Scale Readiness

Score: Auto-scale readiness = 38/100. The architecture aspires to registry-driven scaling (axis_registry, axis_assignment, source adapters exist), but the render path is not registry-driven — the universal contract hardcodes axes (finding H1). So most "new item" cases require a view edit before they appear.

Legend: AUTO_COVERED / COVERED_IF_REGISTERED / REQUIRES_VIEW_EDIT / REQUIRES_UI_EDIT / NOT_COVERED / UNKNOWN.

Per future-item-type verdict

New axis → REQUIRES_VIEW_EDIT (worst case)

Adding a row to axis_registry does not surface in the UI. v_rp_universal_node_ui_contract is a hardcoded UNION (H1) that does not read axis_registry. A genuinely new axis requires: (a) a new UNION branch in the contract, (b) a new route literal (H2), (c) a substrate resolver clause in fn_rp_node_substrate, (d) likely a proof-matrix branch. This is the core auto-scale failure. Today AX-TOPIC/AX-PROCESS are in the registry yet still appear only because they were hand-wired into the UNION — proving the registry is decorative for rendering.

New pivot (AX-BASE) → AUTO_COVERED

AX-BASE is sourced from v_registries_pivot_node_contract, which is driven by pivot_definitions. A new pivot row flows through to the contract automatically (count_status pivot_backed). This branch is the good pattern — registry-driven. Caveat: a new pivot with count_value>1 and no final_substrate_ref will show NEEDS_GROUPING with no grouping rule → silent leaf-without-substrate until a grouping/substrate mapping is added.

New source adapter → COVERED_IF_REGISTERED (for known classes) / NOT_COVERED (new class)

The 16 wired sources (workflow_discovery_source_registry) flow through fn_dot_wf_*_v2 census. A new source of an existing class (another crontab host, another DB fn family) is COVERED_IF_REGISTERED. A new source class (e.g. a message-queue scanner, a new container runtime, an external SaaS cron) is NOT_COVERED until a bespoke adapter + snapshot table + census clause is built — exactly the gap the 6-adapter phase had to close manually.

New DOT → COVERED_IF_REGISTERED

A new DOT in dot_tools (309 today) is counted by the census fns and appears in process-coverage proof. But it lands as an orphan/candidate, not RP-visible-official, until owner-gated. Visibility yes; governance no.

New trigger → COVERED_IF_REGISTERED (DB) / NOT_COVERED (host)

v_trigger_universe_census (525) auto-counts DB/dot triggers. Host triggers (crontab/systemd/OS, ~77) are excluded from the 525 universe and tracked only in v_trigger_host_unmanaged_census — a new host cron does NOT join the canonical trigger count automatically. AX-TRIGGER is not in axis_registry, so a new trigger never becomes official without the whole AX-TRIGGER canon.

New workflow/process → COVERED_IF_REGISTERED

Lands in wf_process_candidate (orphan remediation), surfaces in AX-PROCESS candidate branch with governance_status=UNGOVERNED_CANDIDATE / BLOCKED_OWNER. Visible as candidate; never official without president vote. The special-cased job:cut literal branch (H3) means the second verified process won't get the "sole verified" treatment — needs the branch generalized.

New topic → COVERED_IF_REGISTERED

axis_assignment (topic:* from iu_metadata_tag) drives v_registries_pivot_axis_surface → AX-TOPIC branch. A new topic tag flows in as a candidate node. But AX-TOPIC itself is CANDIDATE; topic nodes stay ungoverned until owner law-ratification + GOV-COUNCIL.

New document / IU → AUTO_COVERED (count) / NOT_COVERED (as a node)

Counted in base pivots (PIV-311 IU, PIV-313 system_issues) live. Does not create a new drillable node — just increments a count. Fine.

New event type → COVERED_IF_REGISTERED

event_type_registry (52) feeds TRIG:event_type count. New event type increments the census. Not official/active until governance (process.* events 0/7 active).

New governance object → NOT_COVERED end-to-end

governance_object_ownership is empty (0 rows). The whole ownership→officialization chain is untriggered. A new governance object would need ownership rows + approval + axis canon; none of that auto-flows.

Auto-scale scorecard

New item	Verdict	Blocker to full coverage
Axis	REQUIRES_VIEW_EDIT	contract UNION hardcoded (H1)
Pivot (AX-BASE)	AUTO_COVERED	grouping/substrate map for count>1
Source adapter (known class)	COVERED_IF_REGISTERED	registry row
Source adapter (new class)	NOT_COVERED	bespoke adapter
DOT	COVERED_IF_REGISTERED	owner gate for official
Trigger (DB)	COVERED_IF_REGISTERED	AX-TRIGGER canon
Trigger (host)	NOT_COVERED	excluded from 525 universe
Workflow/process	COVERED_IF_REGISTERED	president vote; job:cut special-case
Topic	COVERED_IF_REGISTERED	AX-TOPIC ratification
Document/IU	AUTO_COVERED (count only)	—
Event type	COVERED_IF_REGISTERED	event activation
Governance object	NOT_COVERED	ownership table empty

Bottom line

The counting/census layer auto-scales reasonably (registry- and adapter-driven). The rendering/contract layer does not — it is a hand-maintained UNION. Until v_rp_universal_node_ui_contract is rebuilt to iterate over axis_registry (+ a per-axis source-binding registry), RP cannot honestly claim "auto-scales without hardcode." This is the #1 architecture fix and it is T1-fixable without authority.