03 — Axis Operating Model: Common Layer (Branch C)

Branch C. Design-only. One common model for all axes — reconstruction, containment, topic/semantic, pivot, and future axes — so the system never grows per-axis infrastructure or a fixed axis array. Verdict: RECOMMENDED — generalize taxonomy_facets into the Axis Registry (M-DEF-9); make iu_three_axis_envelope a projection of it; reuse iu_relation/universal_edges, entity_labels/iu_metadata_tag, iu_tree_path for relation/assignment/projection. Minimal new substrate: axis_registry + a confidence/evidence axis_assignment (doc 04).

03.0 Governing principle (M-DEF-8, verbatim)

"An axis is any dimension along which system objects are classified, counted, grouped, pivoted, ordered, related, or displayed — i.e. any dimension that can change shared truth, classification, counting, display, or interpretation. An axis is a governed object (coverage profile AXIS)."

Membership is a predicate, not an enumeration: a thing is an axis if changing its definition / vocabulary / grouping policy changes what is classified, counted, grouped, or displayed as truth. Consequences, binding on this design:

There is no fixed axis array anywhere. A 4th/5th axis "is not a special case requiring code; it is the same governed-object contract applied to a new dimension" (concept doc 02). The live iu_three_axis_envelope is a denormalized projection of three example axes, not the model.
A future axis is a row, never a schema change (M-DEF-9).
The absence of an Axis Registry is itself a critical governance gap (inventory_gap).

03.1 The seven components, mapped to live reuse + gap

Component	What it is	Reuse (live)	Gap / minimal-new
Axis Registry	the ground-truth inventory of axes (nine attributes each)	`taxonomy_facets` (partial: cardinality, max, status — label axes only)	new `axis_registry` generalizing facets (G2) — §03.2
Axis Object / Node	the points on an axis	semantic: `taxonomy` rows (facet-scoped, hierarchical, status, `replaced_by`); structural: the IUs themselves; KG: any born entity (by code)	none — polymorphic by `node_kind`
Axis Relation	edges within an axis	IU↔IU: `iu_relation` (confidence/evidence/provenance/`assertion_mode`/bitemporal); any↔any: `universal_edges`; vocab hierarchy: `taxonomy.parent_id`/`parent_facet`; soft semantic: `entity_relations` (decreed, unbuilt — doc 01)	use `entity_relations` when built; until then `universal_edges`
Axis Assignment	entity ↔ axis-node membership	`entity_labels` (scale, no confidence); `iu_metadata_tag` (confidence, IU-only); `iu.parent_or_container_ref` (primary containment)	`axis_assignment` with confidence/evidence/zone/lifecycle for semantic axes (G3) — doc 04
Axis Projection	read/UI materialization (NOT truth)	`iu_three_axis_envelope` + `v_ui_*`; `iu_tree_path`; `pivot_definitions` (Điều 26)	make envelope a refresh over the registry
Axis Quality Issue	anarchy/integrity findings on an axis	`system_issues`; `kg_quality_log`/`kg_quality_issues`(v); governance event domain (SB-11)	register axis issue types (doc 09)
Axis Lifecycle	state of an axis & its nodes	`taxonomy.status`+`replaced_by`; `iu_lifecycle_vocab`; `doc_reviews`/`tac_review_state_vocab`	unify on candidate→provisional→active→merged/split→deprecated→retired/rejected

Key insight: six of the seven components are already in PG. Only the Registry (G2) and the semantic Assignment (G3) are genuinely missing. Everything else is reuse + activation.

03.2 Axis Registry (M-DEF-9) — generalize `taxonomy_facets`

taxonomy_facets is a proto-axis-registry for label axes (it already has cardinality, max_labels_per_entity, status). It is not enough: it has no owner-per-scope, no scope, no vocabulary-source pointer, no grouping policy, no coverage rule, no issue path, no lifecycle beyond status, and it only knows label/taxonomy axes — not containment, reconstruction, pivot, or KG.

Design: axis_registry (paper) with the nine M-DEF-9 attributes as columns/refs, with taxonomy_facets rows projected in (each facet becomes an axis of axis_family='label'):

axis_registry  (governed registry object; coverage profile POLICY/REGISTRY)
  axis_code            text PRIMARY KEY     -- stable code, e.g. AX-CONTAINMENT, AX-RECON, AX-TOPIC, AX-PIVOT-*
  axis_family          text NOT NULL        -- structural | label | semantic | pivot | system
  axis_kind            text NOT NULL        -- deterministic | uncertain | system   (the GPT split)
  owner_scope_ref      text NOT NULL        -- → governance_responsibility_scope (owner-per-scope, SB-2)
  scope                text NOT NULL        -- global | domain-local | object-local
  vocabulary_source    text NULL            -- → registry holding the vocab (taxonomy facet, species, none-for-structural)
  grouping_policy_ref  text NULL            -- → COUNCIL-owned grouping/threshold rows (max_ungrouped, pins)
  coverage_rule_ref    text NOT NULL        -- → coverage rule (when nodes/assignments become governed)
  issue_path_ref       text NOT NULL        -- → event_type_registry domain (register-before-emit)
  lifecycle_status     text NOT NULL        -- birth|register|active|deprecate|retire  (Đ0-G + Đ30)
  node_kind            text NOT NULL        -- taxonomy_node | information_unit | born_entity   (what its nodes are)
  relation_store       text NOT NULL        -- iu_relation | universal_edges | taxonomy_parent | entity_relations
  assignment_store     text NOT NULL        -- entity_labels | iu_metadata_tag | axis_assignment | iu.parent_ref
  projection_view      text NULL            -- the read view (e.g. v_ui_iu_three_axis_envelope)
  created_by, created_at, ...

This makes a future axis a row that declares which existing stores hold its nodes/relations/assignments and which view projects it — no schema change, no fixed array. iu_three_axis_envelope becomes the projection of three pre-registered axes (AX-RECON, AX-TOPIC, AX-CONTAINMENT).

03.3 The axis-kind taxonomy (the deterministic/uncertain split, made structural)

GPT's core direction — separate deterministic structural axes from uncertain semantic axes — is encoded in axis_registry.axis_kind:

axis_code	family	kind	nodes	relation store	assignment store	governing law
AX-RECON (reconstruction / source order)	structural	deterministic	IUs	derived from `doc_code`/`section_code`/`sort_order`	n/a (intrinsic)	Điều 38/44; invariant `fn_iu_reconstruct_source` (GOV-SIV)
AX-CONTAINMENT (parent→child)	structural	deterministic	IUs	`iu_relation` (`contains`) / `iu.parent_or_container_ref`	`iu_tree_path` (closure)	Điều 44; GOV-SIV integrity
AX-TOPIC (FAC-08 content topic)	label/semantic	uncertain	`taxonomy` nodes (facet FAC-08)	`taxonomy.parent_id` + `universal_edges` (broader/narrower/related)	`axis_assignment`/`entity_labels`/`iu_metadata_tag` (confidence)	Điều 24 vocab + Điều 39 KG; GOV-KG-SYS
AX-EXPERTISE (FAC-01 …)	label	uncertain	`taxonomy` (FAC-01)	`taxonomy.parent_id`	`entity_labels`	Điều 24
AX-PIVOT-*	pivot	system	group-by columns	n/a	n/a	Điều 26 (`pivot_definitions`)
AX-LIFECYCLE / AX-VERSION	system	system	`iu_lifecycle_vocab` / versions	n/a	`information_unit.lifecycle_status` / `unit_version`	Điều 38/44
AX-<future>	any	declared	declared	declared	declared	declared at registration

deterministic axes are validated by reconstruction (fingerprintable, non-exemptable, owner-link-inheritable). uncertain axes carry confidence/evidence, run the 3-zone (Approved/Candidate/Quarantine, NĐ-36-01 §MT4) discipline, and are APR-gated for vocab/grouping edits and KG-proposed-never-auto (Điều 39 Golden Rule). system axes are intrinsic/derived.

03.4 Owner-link inheritance (M-DEF-7) for axes

"owner-link inherits down the containment tree; risk-required links (cut/split/merge approval, DOT authority, audit, rollback, reconstruction integrity) are computed per node and never inherited."

For axes: an axis's policy owner (one accountable, per scope) inherits to its sub-axes/sub-vocabulary via owner-link only; risk links (who may edit the vocab, who approves a node merge, the issue path) are computed per axis/node and never inherited. This prevents a parent axis from silently "covering" a child axis's risky edits (anti-hiding). Owner-per-scope comes from SB-2 (governance_responsibility_scope / governance_object_ownership, both currently unbuilt — doc 01).

03.5 Điều 37 boundary — who owns which contract (no absorption)

Following the concept doc's OWN / REFERENCE / SPECIALIZE / EXCLUDE / DEFER hub model:

Concern	Home (referenced, not absorbed)
open-axis model + Axis Registry contract; coverage invariant; accountable-owner model; count>1 rule; gap types	Điều 37 (owns the contract)
knowledge graph (trust, decision, ACL, edges)	Điều 39 (`universal_edges`, `kg_*`)
label vocabulary	Điều 24 (`taxonomy`, `taxonomy_facets`, `label_rules`)
pivot mechanics	Điều 26 (`pivot_definitions`)
IU schema / IU axes / metadata	Điều 44 / Điều 38 (`information_unit`, envelope, `iu_metadata_tag`)
alias / soft relation / canonicalization / disambiguation	NĐ-36-01 (`entity_relations` — unbuilt)
approval spine	Điều 32 (`approval_requests`, `apr_*`)
event / queue	Điều 45 (`event_type_registry`, `event_outbox`)
birth registry	Điều 0-G / Điều 19 (`birth_registry`)

Worked axis owner map (for council to ratify under SB-2 / OP-B): policy → GOV-COUNCIL; substrate/vocabulary (KG, taxonomy, vector) → GOV-KG-SYS; detection/health/integrity → GOV-SIV; execution → GOV-DOT; render → GOV-MOUT (interim COUNCIL delegation, TTL-bounded); family law → GOV-NRM-SYS.

03.6 Anti-patterns this model avoids (mission §6)

Fixed axis arrays: none — axes are axis_registry rows; the 3-axis envelope is explicitly a projection of pre-registered axes.
One-off topic island: topic = FAC-08 + taxonomy + axis_assignment; no topic table.
UI as source of truth: UI reads projection_view only; a hardcoded axis list in Nuxt = hardcode_violation (#37).
Per-axis custom infrastructure: one Registry → Node → Relation → Assignment → Projection → Issue → Lifecycle contract for every axis; new axes declare which existing stores they use.

03.7 Verdict

RECOMMENDED. The common axis model is ~85% reuse. The two new pieces — axis_registry (generalizing taxonomy_facets) and axis_assignment (doc 04) — are additive, governed (L2/L3 per doc 02), and turn "add an axis" into "insert a registry row + declare its stores." Detailed storage decisions follow in doc 04; topic specifics in doc 06; reconstruction/containment in doc 07.