06 · Synthetic-Axis Governance Design

Area 6 verdict: GOVERNANCE_BLOCKED + DESIGN_DRIFT (P1). Three axes are RP-visible but absent from axis_registry → governed-by-nothing. The fix is labeling now + candidate-register, with one axis (AX-PXT) that must never become an independent official axis.

---

1. The three synthetic axes (live: not in axis_registry)

axis_registry = 2 rows (AX-TOPIC, AX-PROCESS). The contract emits 5 axes (AX-BASE 39, AX-PROCESS 22, AX-PXT 12, AX-TOPIC 7, AX-TRIGGER 7 = 87). So AX-BASE, AX-PXT, AX-TRIGGER are synthetic (v_rp_synthetic_axis_register_gap = 3; dashboard synthetic_axes_unregistered=3).

2. Per-axis governance nature & recommendation

AX-BASE — structural rendering lens

• Nature: the "base registries" lens (pivots / dot_tools / birth_registry / event_type_registry). It is not a governed taxonomy; it is a structural view over already-governed base objects. 39 nodes incl. MTX-TEST (test) + PIV-020 (deprecated).
• Recommendation: CANDIDATE-REGISTER NOW as governance_class=DERIVED_STRUCTURAL, status=SYSTEM_LENS (not requiring a president vote, because it governs nothing new — it reflects base objects that already have owners). Label in UI as "structural lens".
• Caveat: axis_registry row inserts are owner-gated (Điều 32/39). Engineering may propose the row as CANDIDATE; an owner ratifies status to active. Until then: label, don't claim official.

AX-PXT — derived cross-product (must stay DERIVED forever)

• Nature: AX-PROCESS × AX-TRIGGER. Pure derivation. It has no independent substrate — its "substrate" is the actionability ledger / grouping surface. It must never be an independent official axis or seek its own owner.
• Recommendation: REGISTER as governance_class=DERIVED_CROSS, derived_from=["AX-PROCESS","AX-TRIGGER"], and BLOCK independent officialization permanently. Its governance is inherited from its two parents: AX-PXT is "official" only to the degree both parents are. UI label: "derived from AX-PROCESS × AX-TRIGGER".
• Why this matters: treating AX-PXT as a candidate-for-official would create a phantom governance object. The design must encode "DERIVED axes are never independently officialized" as a rule (doc 03 governance_class=DERIVED ⇒ no axis_assignment, no ownership row, no president vote sought).

AX-TRIGGER — real candidate axis awaiting owner

• Nature: a genuine axis (universe 525 DB + 77 host [ckpt]), structurally like AX-PROCESS/AX-TOPIC, but absent from axis_registry and with no owner (Điều-39 owner pending).
• Recommendation: CANDIDATE-REGISTER NOW (governance_class=CANDIDATE, status=CANDIDATE), BLOCK official-active until owner. Mirror the AX-PROCESS pattern (which is already a CANDIDATE registry row awaiting GOV-MOW). UI label: CANDIDATE / not official.

3. Decision summary

Axis	governance_class	Register now?	Can become OFFICIAL?	UI label	Unblocks on
AX-BASE	DERIVED_STRUCTURAL	yes (candidate)	as a lens only (no new governance)	"structural lens"	operator/owner ack of the lens row
AX-PXT	DERIVED_CROSS	yes (as DERIVED)	never independently (inherits parents)	"derived: AX-PROCESS × AX-TRIGGER"	n/a (inherits)
AX-TRIGGER	CANDIDATE	yes (candidate)	yes, after owner (Điều-39) + president	"CANDIDATE / not official"	AX-TRIGGER owner + ratification

Net recommendation: register-as-candidate/derived now (engineering proposes rows, never auto-active), label everywhere, block official-active until owner. This removes the "RP-visible-but-not-governed" hole without faking governance.

4. How UI shows them (ties to doc 05 source_scope + doc 09 badges)

• source_scope becomes 4-value: AX-BASE→DERIVED(structural), AX-PXT→DERIVED(cross), AX-TRIGGER→CANDIDATE, AX-PROCESS/AX-TOPIC→CANDIDATE (today; OFFICIAL after ratification).
• Badge text from governance_class; tooltip from axis_registry.notes.
• AX-PXT nodes additionally render "derived from {derived_from}" and suppress any "officialize" affordance.

5. How governance/birth later officializes (the path)

1. Engineering proposes axis_registry rows for AX-BASE/AX-TRIGGER as CANDIDATE (AX-PXT as DERIVED, terminal).
2. Owner law (Điều-32/39) ratifies: owner assigned in governance_object_ownership, axis_registry.status: CANDIDATE→ACTIVE, governance_class: CANDIDATE→OFFICIAL.
3. President vote (where required) lands axis_assignment rows → official RP for that axis.
4. AX-PXT skips all of this — it is never independently officialized; its officiality is computed from parents.
5. Birth: axis_registry row inserts are subject to the birth registry / governance onboarding like any governed object; the proposal is birth-tracked but the activation is owner-gated. No fake birth, no auto-active.

6. Classification

Issue	Class	Severity
3 synthetic axes unregistered (RP-visible, not governed)	GOVERNANCE_BLOCKED + DESIGN_DRIFT	P1
No governance_class to distinguish DERIVED vs CANDIDATE vs OFFICIAL	ARCHITECTURE_GAP	P1
No rule "DERIVED axes never independently officialized"	DESIGN_DRIFT	P1
AX-BASE contains MTX-TEST (test) + PIV-020 (deprecated) in prod lens	DATA_DEBT	P2

7. Required technical spec for T1 (Area 6)

1. Add governance_class + derived_from columns (doc 03 §2).
2. Propose 3 rows: AX-BASE(DERIVED_STRUCTURAL), AX-PXT(DERIVED_CROSS,derived_from), AX-TRIGGER(CANDIDATE) — all status non-active; document that inserts are candidate proposals (owner ratifies).
3. Encode the DERIVED-never-official rule in the binding (no axis_assignment/ownership lookup for governance_class IN (DERIVED_*); officiality = MIN(parents)).
4. source_scope (doc 05) reads governance_class.
5. Label MTX-TEST / PIV-020 out of the headline AX-BASE counts (lane_split already separates them — surface that on the node).
6. Acceptance: v_rp_synthetic_axis_register_gap → 0 unlabeled synthetic axes (all 3 carry a governance_class); AX-PXT exposes no officialize path; AX-TRIGGER shows CANDIDATE awaiting owner.