03 — Axis Decision Queue (Workstream B) — LIVE

Status: LIVE

v_axis_topic_decision_queue was rehearsed in BEGIN..ROLLBACK (output verified, net-zero) then applied live as an additive, read-only, DROP-reversible view. It turns the 7 candidate topic nodes / 25 assignments into a governable, evidence-ranked queue. It activates nothing — Điều-39 (AI proposes, never activates) is enforced by construction: the view writes nothing and every node stays candidate.

What it computes (per node, all in SQL)

• node_code, node_label, lifecycle_status, governance_status
• parent_codes[], has_multiple_parents
• assignment_count, iu_count, document_count (live derivable, 0 today), evidence_tag_count, source_tag_keys[]
• evidence_strength: STRONG (≥5) / MODERATE (3–4) / WEAK (≤2)
• proposed_classification: ROOT_CANDIDATE (no parent) / CHILD_CANDIDATE (has parent) — data-driven from parent_codes, not hardcoded
• sibling_suspicion_tokens + duplicate_synonym_suspicion: computed by tokenising labels and finding tokens shared by >1 node
• proposed_lifecycle_action: PROPOSE_PROMOTE_TO_ROOT / PROPOSE_GROUP_UNDER_SHARED_PARENT / PROPOSE_DEFER_WEAK_EVIDENCE
• review_bucket: LIKELY_ROOT / DUPLICATE_OR_SIBLING_SUSPECT / WEAK_EVIDENCE / NEEDS_MANUAL_REVIEW
• gov_council_decision_needed (true for all today), approval_ref (null today), governance_note (Điều-39 reminder string)

Live output (prod 2026-06-04)

node	IU	evidence	bucket	proposed action	dup/synonym
knowledge_graph	10	STRONG	LIKELY_ROOT	PROPOSE_PROMOTE_TO_ROOT	—
architecture	5	STRONG	LIKELY_ROOT	PROPOSE_PROMOTE_TO_ROOT	—
dot_trigger	3	MODERATE	NEEDS_MANUAL_REVIEW	PROPOSE_PROMOTE_TO_ROOT	—
governance	3	MODERATE	NEEDS_MANUAL_REVIEW	PROPOSE_PROMOTE_TO_ROOT	—
workflow	2	WEAK	NEEDS_MANUAL_REVIEW	PROPOSE_DEFER_WEAK_EVIDENCE	—
cut_pipeline	1	WEAK	DUPLICATE_OR_SIBLING_SUSPECT	PROPOSE_GROUP_UNDER_SHARED_PARENT	pipeline
render_pipeline	1	WEAK	DUPLICATE_OR_SIBLING_SUSPECT	PROPOSE_GROUP_UNDER_SHARED_PARENT	pipeline

Decision groupings (the queue's recommended buckets)

• Likely roots (promote): knowledge_graph, architecture — strong evidence, distinct names.
• Roots needing manual review: dot_trigger, governance — moderate evidence (3 IUs each); GOV-COUNCIL confirms whether they are top-level topics.
• Weak evidence (defer or strengthen): workflow (2 IUs) — keep candidate until more evidence accrues.
• Sibling / grouping suspects: cut_pipeline + render_pipeline — share token pipeline; recommend creating a pipeline parent topic and grouping both as children, OR keeping as two weak roots. GOV-COUNCIL decides.

Reversibility

DROP VIEW v_axis_topic_decision_queue; — depends only on read access to v_registries_pivot_axis_surface, axis_assignment, iu_metadata_tag. No business table touched.

What the queue deliberately does NOT do

• Does not change any status field.
• Does not write approval_requests rows (that is the operator/owner step — see doc 04; the UI only drafts the request).
• Does not create taxonomy nodes.
• Does not merge cut_pipeline/render_pipeline — it only suspects and proposes.

How the queue drains (future)

When GOV-COUNCIL approves a node and it is promoted to a real FAC-08 taxonomy node (doc 05 apply order), its governance_status flips to TAXONOMY_BACKED and gov_council_decision_needed becomes false — the same view will show it as drained with no view change.