14 — Synthetic Axis / Generator Relation (Phase 15)

Object

v_rp_synthetic_axis_generator_relation — clarifies what the generator needs vs what authority gates.

Per-axis

• AX-BASE (synthetic_native_pivot): REMAIN_DERIVED. Generator binds the pivot node contract directly; no registration needed for backbone parity. Remains synthetic-native by design.
• AX-PROCESS (candidate_registered, registry-backed): CANDIDATE_IN_AXIS_REGISTRY. Generator binds candidate+jobcut+workflow. Official RP officialization = president PROC-OWN vote (authority), independent of backbone parity.
• AX-PXT (synthetic_ledger): CANDIDATE_REGISTER. Generator binds the live_v2 ledger directly; backbone parity needs no registration. Official registration (owner + live-ledger refactor) is authority-gated and unlocks registryization (kills 12 view-edits).
• AX-TOPIC (candidate_registered, registry-backed): CANDIDATE_IN_AXIS_REGISTRY. Generator binds the axis surface.
• AX-TRIGGER (synthetic_census): REGISTER_IN_AXIS_REGISTRY. Generator binds the trigger surface directly; backbone parity needs no registration. Official registration (owner + president) unlocks registryization (kills 7 view-edits).

Key clarification

Generator BACKBONE replacement does NOT depend on synthetic-axis registration — generator_backbone_ready_now is true for all 5 axes because the generator binds the synthetic source views directly. What DOES depend on authority is (a) the full registryization that reduces the 58 requires_view_edit to 0, and (b) official RP. Those proceed on the authority track and are not blockers for closing the backbone parity gap.

What can proceed before registration

• Backbone parity (done).
• Generated candidate + replacement readiness (done).
• Operator repoint via decorated-on-generated rebuild (operator, not authority).