RP UI Axis — 04 Owner / GOV-COUNCIL Approval Packet
04 — Owner / GOV-COUNCIL Approval Packet (Workstream C)
Five decision packets. Each is written so the owner / GOV-COUNCIL can approve, reject, or defer without re-reading the technical reports. Điều-32 (governance approval) and Điều-39 (AI proposes only) apply throughout. Nothing here is executed by AI.
Packet 1 — AX-TOPIC activation (CANDIDATE → ACTIVE)
Decision: Should AX-TOPIC become an active governed axis?
Why now: the substrate is live and proven; the axis cannot route or govern topics while CANDIDATE.
What changes: UPDATE axis_registry SET status='ACTIVE', approval_ref='<APPROVAL-CODE>' WHERE axis_code='AX-TOPIC' (one row, reversible).
Risk: low — activation only declares the axis governed; it does not by itself create taxonomy nodes or promote candidates.
Rollback: set status back to CANDIDATE; clear approval_ref.
Verification: /api/axes shows AX-TOPIC ACTIVE; decision queue unchanged.
Pre-req: none. Can be approved independently of Packets 2–5.
Options: ☐ Approve ☐ Defer ☐ Reject.
Packet 2 — FAC-08 root topic approval (Điều-32)
Decision: Which of the 7 candidates become governed FAC-08 root topics? Evidence (live, from decision queue):
| Candidate | IU evidence | Recommendation |
|---|---|---|
| knowledge_graph | 10 | Promote to root (strong) |
| architecture | 5 | Promote to root (strong) |
| dot_trigger | 3 | Review → likely root |
| governance | 3 | Review → likely root |
| workflow | 2 | Defer (weak) or root |
| cut_pipeline | 1 | Group under a new pipeline parent, or defer |
| render_pipeline | 1 | Group under a new pipeline parent, or defer |
Uncertain / synonym: cut_pipeline + render_pipeline share token pipeline → consider one pipeline root with two children. |
||
| Options per candidate: ☐ Approve as root ☐ Approve as child of ___ ☐ Defer ☐ Reject. |
Packet 3 — Taxonomy node creation (the dangerous step)
Decision: Authorise the operator to create taxonomy nodes for the approved candidates. Why operator-gated: taxonomy carries 13 triggers. Creating ONE FAC-08 node (rehearsal-proven, doc 05) produces +1 taxonomy row, +2 auto-managed universal_edges (node↔FAC-08 BELONGS_TO/CONTAINS), and +3 to +5 birth_registry rows — and births are unretirable (no retire mechanism exists). Birth count is name-dependent (knowledge_graph → 5 births; a fresh name → 3). Rollback limit: fully reversible only inside an uncommitted transaction. Once committed, the births cannot be retired — this is a one-way door per node. Therefore each node must be dry-run individually before commit. What the operator runs: see doc 05 apply order (per-node BEGIN..verify..COMMIT). Options: ☐ Authorise creation for approved roots ☐ Authorise dry-run only ☐ Hold.
Packet 4 — axis_assignment promotion (candidate token → taxonomy code)
Decision: After taxonomy nodes exist, re-point the 25 assignments from TOPIC-CAND:<label> to the new LBL-NNN codes.
Note: generated taxonomy codes are generic LBL-NNN (e.g. LBL-509), not topic-prefixed — so promotion is an explicit remap, not a rename.
What changes: UPDATE axis_assignment SET node_code='LBL-NNN', status='active', approved_by='<owner>', approval_ref='<code>' WHERE node_code='TOPIC-CAND:<label>'. Evidence_ref preserved (provenance kept).
Rollback: reverse map LBL-NNN → TOPIC-CAND:<label>, status back to candidate. (Assignment rows are reversible; the taxonomy births behind them are not.)
Options: ☐ Approve remap ☐ Defer.
Packet 5 — Governance ownership rows
Decision: Assign a governance owner to AX-TOPIC (and to each promoted topic).
Live blocker: governance_object_ownership is empty system-wide (0 rows) — there is currently no owner for any object. The axis ownership row would be among the first ownership rows ever written.
What is needed: an owner_gov_code (e.g. GOV-COUNCIL) that exists in the governance role registry, plus an OSPA/authorization for ownership writes.
What changes: INSERT INTO governance_object_ownership (object_type, object_ref, scope, owner_kind, owner_gov_code, lifecycle_status, approval_ref, ...) for object_type='axis', object_ref='AX-TOPIC'.
Exact blocker if unmet: if no GOV owner code / OSPA exists, this packet STOPS — record the missing GOV code; do not invent one.
Options: ☐ Approve owner = ___ ☐ Blocked (no GOV owner code) → escalate.
Approval recording convention
On approval, the owner (or operator on the owner's behalf) should file the decision as an approval_requests row so the chain is auditable. There is no axis/topic request_type yet — propose request_type='axis_activation' / 'topic_promotion' / 'taxonomy_node_create'. AI may draft these rows as status='pending' proposals (Điều-39), but only the owner sets status='approved'.