02 — Axis Substrate: Live Apply + Operator Packet (Workstream A)

(KB stores prose only; executable DDL/DML kept in operator files, not inlined here, to satisfy the KB content firewall.)

Decision

The two generic objects (axis_registry, axis_assignment) plus two read-only views and one resolver function were applied LIVE — pure additive, reversible, trigger-free infrastructure (the DDL event-guard ignores non-trigger objects; these tables carry no triggers). Rehearsed in a BEGIN/ROLLBACK transaction first, net-zero confirmed, then committed.

Rehearsal proof (net-zero)

The full create-and-populate body ran inside one transaction: two table creates, three index creates, one axis-registry insert, twenty-five assignment inserts, two view creates, one function create. Verification queries returned 1 axis row / 25 assignments / 7 distinct nodes / 7 surface rows / 14 pivot rows / full resolver substrate. After ROLLBACK, the information-schema reported zero axis tables and zero axis views — proving full reversibility.

Commit proof (live)

Same body committed. Independent read-only re-check: axis_registry = 1 (AX-TOPIC = CANDIDATE); axis_assignment = 25 rows / 7 distinct nodes; v_registries_pivot_axis_surface = 7 rows; v_axis_topic_pivots = 14 rows; source topic tags untouched = 25.

axis_registry — generic, supports any future axis

Fields: axis_code (unique), axis_name, domain, node_source, node_filter (jsonb), relation_source, root_rule, child_rule, lifecycle_field, owner_governance_ref, substrate_resolver, pivots_ref, status (check: CANDIDATE / PROVISIONAL / ACTIVE / DEPRECATED / RETIRED; default CANDIDATE), approval_ref, notes, _dot_origin, created_at, updated_at. Unique key = axis_code. A new axis is a new row — no code, no schema change. No topic identifier appears as a column.

axis_assignment — generic, supports multiple target types

Fields: axis_code (foreign key to axis_registry), node_code (text, deliberately NOT a foreign key to taxonomy), target_type (information_unit / knowledge_document / workflow / dot_tool / agent / event / …), target_code, relation_type (default classified_as), confidence, source, status (check: candidate / provisional / approved / rejected / retired; default candidate), evidence_ref, approved_by, approval_ref, _dot_origin, created_at, updated_at. Unique key = (axis_code, node_code, target_type, target_code, relation_type). Indexes on (axis_code, status), (target_type, target_code), (node_code).

Design proofs

• No topic hardcode: AX-TOPIC supplied entirely as a data row; FAC-08 referenced inside node_filter jsonb, never as a column.
• No-FK-to-taxonomy is the keystone: candidate topic tokens (TOPIC-CAND:*) exist as data with no governed node, so candidates need no taxonomy row and trigger no birth. Ratification later promotes a token to a real taxonomy code.
• Birth/governance implication: assignment rows are not births and never enter birth_registry; only ratified taxonomy roots get births (operator step 2).
• Multi-target mapping: target_type + target_code generalise to IU, document, workflow, DOT, agent, event — the foundation of the 4-Mothers bridge (doc 08).
• Rollback: drop the function, the two views, then axis_assignment and axis_registry (one transaction). Originals untouched. Script: axis_rollback file.

Forbidden-action compliance

No topic island table; no topic levels; AX-TOPIC not in schema; only two new tables (the views/function are reporting surfaces, not registries); no faked governance approval; no candidate auto-promoted.

Operator / owner packet (GATED — authored, NOT applied)

Six independently-reversible steps held in the operator SQL file:

1. Owner records law-ratification ownership rows for axis_registry, axis_assignment, AX-TOPIC (governance_object_ownership is currently empty; owner supplies the real GOV-COUNCIL code).
2. GOV-COUNCIL approves and creates FAC-08 root topic nodes in taxonomy — warned: taxonomy insert fires the birth trigger (unretirable birth) and the edge-sync trigger; create only ratified roots, with valid _dot_origin and description.
3. Owner re-points approved candidate assignments to the new taxonomy code and marks them approved.
4. Owner flips AX-TOPIC CANDIDATE → ACTIVE once at least one approved root exists.
5. Owner (optional) births canon topic pivots into pivot_definitions — unnecessary for reporting because v_axis_topic_pivots already exposes the same numbers live without a birth.
6. GOV-COUNCIL files the approval_requests audit row (observed status vocabulary: approved/applied/rejected/expired).