04 — Axis Operating Model (hardened, common & open-ended)

Package: one-roof-axis-auth-proposal-operational-hardening-build-ready-design-2026-06-02 Mode: DESIGN ONLY · READ-ONLY · NO COMMIT · NO MUTATION Hardens: prior …-2026-06-01/03-axis-operating-model-common.md. Closes GPT review gap #2 (model half): one common axis model, open-ended, not hardcoded to current axes; storage half is doc 05.

4.0 Principle

An axis is a way of classifying / relating Information Units (and other born entities). The project already runs several axes via different live tables; the gap is that they are not one model and the uncertain ones (topic/semantic) lack a candidate/confidence layer. The hardened model gives one operating model for every axis — present and future — so a new axis is a row, not new infrastructure (Điều 37 no-hardcode; Điều 39 KG; Điều 38 scaffold).

Seven components, one lifecycle, two behavioural classes (deterministic vs uncertain).

4.1 The seven components and their live homes (reuse-first)

Component	What it is	Live home(s) — reuse	New (this package)
Axis Registry	the set of axes + how each behaves	`taxonomy_facets` (10 facets, partial)	`axis_registry` generalizes it (doc 05)
Axis Node	a value within an axis	`taxonomy` (58 nodes, intra-axis hierarchy); IUs; born entities	none (polymorphic by `node_kind`)
Axis Relation	edges between nodes/entities	`iu_relation` (60), `universal_edges` (2,199)+`v_kg_edges_all`, `taxonomy.parent_id`, `entity_relations` (decreed, unbuilt)	none — reuse; `entity_relations` deferred
Axis Assignment	entity ↔ node membership	`entity_labels` (787,723, deterministic/approved), `iu_metadata_tag` (confidence-bearing), `iu.parent_or_container_ref` (intrinsic)	`axis_assignment` for uncertain axes (doc 05)
Axis Projection	read model for humans/UI	`iu_three_axis_envelope` (216), `iu_tree_path` (199), `pivot_definitions`, `v_ui_*` views	per-axis `projection_view` declared in registry
Axis Quality / Issue	detected problems	`system_issues` (196,402), `kg_quality_log`/`kg_quality_issues`	new issue types (data, doc 09)
Axis Lifecycle	birth→active→deprecate→retire	`taxonomy.status`+`replaced_by`, `iu_lifecycle_vocab`, `doc_reviews`	`lifecycle_status` column

Consequence: six of seven components already exist. The model's job is (a) a registry that names every axis and its stores, (b) a confidence/zone-bearing assignment table for uncertain axes, (c) the lifecycle + coverage wiring.

4.2 The two behavioural classes (the load-bearing distinction)

Every axis is deterministic or uncertain (system axes are a deterministic sub-kind). This single column (axis_kind) decides the entire operating behaviour — assignment store, whether confidence/zone apply, whether the workflow is validation or proposal, and the governance issue family.

	Deterministic axis	Uncertain axis
Examples	AX-RECON (reconstruction), AX-CONTAINMENT, AX-LIFECYCLE, AX-VERSION, AX-PIVOT	AX-TOPIC (FAC-08), AX-EXPERTISE (FAC-01), AX-AUDIENCE (FAC-06), most label facets
Source of assignment	intrinsic — computed from structure (`doc_code`/`section_code`/`sort_order`, `parent_or_container_ref`)	inferred/asserted — by rule, AI, KG, or human
Confidence / zone?	No (a position either is or isn't correct)	Yes (`match_score`, `confidence`, `zone ∈ approved/candidate/quarantine`)
Workflow	validation (detect-and-fix; doc 08)	proposal (candidate → review → promote; docs 06/07)
Failure mode	integrity violation (gap/cycle/dangling) → `*_integrity_fail`, severity critical	mis-assignment / low-confidence / overlap → `wrong_topic`/`topic_overlap`, severity computed
Assignment store	`iu.parent_ref` / `iu_relation` (intrinsic) — no `axis_assignment` row	`axis_assignment` (SoT) → reconciled to `entity_labels` on approval
Owner (typical)	GOV-SIV (integrity)	GOV-KG-SYS (substrate) + GOV-COUNCIL (policy)

This is exhaustive for the live axes and the "at least nine IU axes" in the concept canon: a new axis is classified deterministic or uncertain at registration; nothing else in the model changes.

4.3 Concrete axis map (rows, not code)

Each row below is one future axis_registry row. No fixed array of axes lives in code — this table is data.

axis_code	family	kind	node_kind	relation_store	assignment_store	live anchor
`AX-RECON`	structural	deterministic	information_unit	(intrinsic order)	intrinsic (`doc_code`+`sort_order`)	FAC-07; `fn_iu_reconstruct_source`
`AX-CONTAINMENT`	structural	deterministic	information_unit	`iu_relation`(contains)	`iu.parent_or_container_ref`	`iu_tree_path` closure
`AX-TOPIC`	label/semantic	uncertain	taxonomy_node	`taxonomy.parent_id`+`universal_edges`	`axis_assignment` (→`entity_labels`)	FAC-08 (max=0 → operationalize)
`AX-EXPERTISE`	label	uncertain	taxonomy_node	`taxonomy.parent_id`	`entity_labels`/`axis_assignment`	FAC-01
`AX-AUDIENCE`	label	uncertain	taxonomy_node	`taxonomy.parent_id`	`entity_labels`	FAC-06
`AX-PIVOT-*`	pivot	system	(varies)	`pivot_definitions`	(computed)	Điều 26
`AX-LIFECYCLE`/`AX-VERSION`	system	system	born_entity	—	intrinsic	`*.status`/`unit_version`
`AX-<future>`	(declared)	(declared)	(declared)	(declared)	(declared)	—

4.4 What goes through Birth vs what stays a fact

(Reconfirmed against the live Birth spine, doc 01 §1.5.)

Born (identity-bearing classifiers, referenced by others): axis_registry rows; approved/active taxonomy topic nodes; IUs. These get a birth_registry row + owner + coverage.
Not born (facts/edges/memberships/projections): topic candidates; relations/edges; assignments; projection rows. They live as data, governed as input-quality until promoted.
Rule: "identity-bearing, referenced classifiers are born; facts, edges, memberships, and projections are not."

4.5 Candidate → born/governed promotion (the operating transition)

For an uncertain axis, a node/assignment starts as a candidate and is promoted only through the ladder:

candidate (taxonomy.status='candidate'/'provisional'; axis_assignment.zone='candidate')
   → review (doc_reviews 2-gate + approval_requests, L1/L2; agent proposes, never self-enacts)
   → L3 grant (governance_build_authorization for register_topic_node / register_axis)
   → promote txn (doc 16): taxonomy.status='active' + birth_registry + owner + coverage;
                           flip axis_assignment.zone candidate→approved; reconcile entity_labels
   → governed truth (now covered by the scanner, doc 09; visible in official UI, doc 10)

For a deterministic axis there is no candidate zone: assignment is recomputed from structure; the workflow is validate → if integrity fails, open issue → fix under the ladder (doc 08).

Minimum promotion evidence (hardened, GPT gap #3 — full criteria in doc 07): a topic candidate may be promoted only if it has (1) a non-null provenance, (2) confidence ≥ axis threshold (from coverage_rule_ref, a row not a literal), (3) no unresolved topic_overlap/wrong_topic issue, (4) an L2 approval for register_topic_node, and (5) a named owner scope. Missing provenance ⇒ zone='quarantine', never promoted.

4.6 Axis lifecycle states

birth → register → active → deprecate → retire (column lifecycle_status). Deprecate-not-delete (mirrors taxonomy.replaced_by). A deprecated node stays queryable, is excluded from the official UI lane, and its assignments are migrated to replaced_by under the ladder. Retirement requires no live axis_assignment(zone='approved') referencing it (a coverage check, doc 09).

4.7 Owner-per-scope and inheritance (SB-2 dependency)

Each axis declares owner_scope_ref → governance_responsibility_scope (SB-2, unbuilt). One accountable owner per axis per scope (SB-2 partial-unique).
Owner-link inheritance (M-DEF-7): a policy owner inherits down the containment tree via owner-link only; risk authorities (cut/split/merge approval, DOT authority, audit, rollback, reconstruction integrity) are computed per node and never inherited. This prevents a parent's policy owner silently acquiring destructive authority over children.
Until SB-2 lands, axis owners are recorded in the worked owner map (doc 09 §owner-map) "to ratify" — they are proposals, not live ownership.

4.8 Open-endedness guarantees (no hardcode, no island)

New axis = new axis_registry row. No code change, no new table, no enum edit. axis_family/axis_kind/node_kind/relation_store/assignment_store are text vocabularies (rows/CHECK-listed), so a new axis declares its stores declaratively.
iu_three_axis_envelope becomes a projection of axis_registry (SB-3 generalization): the hardcoded "three axes" (A/B/C) become three registry rows + a view, removing the fixed-arity assumption. This is non-breaking — the existing envelope view is rebuilt on top of the registry (doc 10).
No island: every axis routes the central spine — relations to iu_relation/universal_edges, issues to system_issues + the governance event domain, ownership to SB-2, approvals to Điều 32. An axis that stored its own relations/issues/owners privately would be flagged axis_grouping_island (doc 09).

4.9 Open decisions

O-AXIS-1: FAC-08 cardinality (single→multiple?) and max_labels_per_entity (0→N) — council L2 data decision (doc 07).
O-AXIS-2: entity_relations (decreed, unbuilt) — when to build vs keep reusing universal_edges/iu_relation (doc 05 §5.6).
O-AXIS-3: exact per-axis confidence thresholds (rows in coverage_rule_ref).
O-AXIS-4: whether AX-EXPERTISE/AX-AUDIENCE keep entity_labels as SoT or migrate to axis_assignment (doc 05 §5.5).

Forbidden-compliance: design-only; no schema/row/owner/issue created; read-only.