01 — Live Substrate & SSOT Recovery

All facts below were verified live this session against query_pg (database directus, read-only). Old reports are evidence; these live reads are authority.

1. Registries-Pivot surface — LIVE (confirmed)

Object	Type	Status
v_registries_pivot_surface	view, 34 cols	LIVE
v_registries_pivot_node_contract	view	LIVE
v_registries_pivot_tree	view	LIVE
v_rp_aggregate_candidate_register	view	LIVE
registry_pin	table	LIVE (empty)
rp_grouping_policy	table	LIVE (default threshold 50)
pivot_definitions	table, 39 rows / 37 active	LIVE
pivot_results	table	LIVE
fn_registries_pivot_node_substrate(code)	function	LIVE (function; to_regclass returns null for functions — not a defect)

Surface shape (critical for UI): v_registries_pivot_surface is tree-shaped — node_code, parent_code, is_root assume exactly one parent. It has no axis_code, no breadcrumb/path, no has_multiple_parents, no relation_type, no lifecycle_status, no governance_status. A topic axis is graph-shaped (many-to-many parents). This is the central UI/API gap (doc 07).

Pivot engine: pivot_definitions rows carry source_object (= any table/view name), filter_spec, group_spec, metric_spec, parent_code (graph live: PIV-101→001, 201..206→101, 104→007, etc.), display_order, is_active, superseded_by. The engine already reads FROM an arbitrary relation — so new axis pivots need no engine change, only new rows + ratified definitions. PIV-311 (information_unit) and PIV-313 (system_issues) are live.

2. Information-piece substrate — LIVE

Fact	Value (verified)
information_unit total (not deleted)	219 (= PIV-311)
— by unit_kind	law_unit 187, design_doc_section 32
iu_metadata_tag total assignments	536
iu_metadata_tag topic assignments (topic:%)	25, covering 16 of 219 IUs (7%)
iu_relation rows	60
knowledge_documents	5,710 (separate, larger corpus)

information_unit columns include the three source/structure axes (doc_code, section_type, section_code, sort_order), parent_or_container_ref (containment), unit_kind, lifecycle_status, identity_profile jsonb. iu_three_axis_envelope is the denormalized projection: axis_a_* (source/order), axis_b_tags jsonb + axis_b_tags_by_source, axis_c_parent_id/depth/ancestors. knowledge_documents has parent_document_id (tree), tags jsonb, category, status, version_group_id — i.e. documents already have structure and tags.

3. Topic / axis / taxonomy substrate — PARTLY LIVE, SPLIT

taxonomy_facets (10 facets, all status=active):

facet_id	code	name	nodes	hierarchical?
1	FAC-01	Chuyên môn gì? (expertise)	29	yes (depth 1, 21 with parent)
3	FAC-03	Hành động gì?	7	flat
6	FAC-06	Phục vụ ai?	6	flat (has deprecated nodes)
2	FAC-02	Vai trò hệ thống?	5	flat
4	FAC-04	Phạm vi tác động?	4	flat
5	FAC-05	Giai đoạn?	4	flat
7	FAC-PROV	Description Provenance	3	flat
8	FAC-07	Thuộc tài liệu nào? (which document)	0	—
9	FAC-08	Chủ đề nội dung? (CONTENT TOPIC)	0	—
10	FAC-09	Tầng kiến trúc? (architecture layer)	0	—

taxonomy node store supports dynamic-depth hierarchy and lifecycle: id, code, name, name_en, facet_id, parent_id, parent_facet, depth, scope[], status, replaced_by, sort. FAC-01 already proves multi-level hierarchy works in this store.

The split (classification island, flagged): there are two topic vocabularies:

1. Governed but empty: facet FAC-08 in taxonomy — the canonical, lifecycle-bearing home for content topics. 0 nodes.
2. Live but ungoverned: iu_metadata_tag_registry tag_kind='topic' — 7 flat keys (topic:architecture, topic:cut_pipeline, topic:dot_trigger, topic:governance, topic:knowledge_graph, topic:render_pipeline, topic:workflow), assigned via iu_metadata_tag with confidence (25 assignments). No hierarchy, no replaced_by, no facet anchor.

Decision (doc 03/04): FAC-08 is the governed home; the 7 live tags become candidate FAC-08 nodes via reconciliation — never auto-promoted to approved roots.

4. Governance & relation substrate — LIVE, RICHER than the 2026-06-01 design assumed

The one-roof docs (2026-06-01) described several governance tables as "decreed, unbuilt." Live evidence overrides:

Object	2026-06-01 doc said	Live this session
governance_object_ownership	unbuilt (SB-2)	EXISTS
governance_responsibility_scope	unbuilt (SB-2)	EXISTS
universal_edges (any↔any edges)	live	EXISTS ✓
system_issues	live	EXISTS ✓
event_type_registry	live	EXISTS ✓
approval_requests (Điều 32)	live	EXISTS ✓
birth_registry	live	EXISTS ✓
entity_relations (ND-36-01 alias/soft)	unbuilt	still ABSENT
axis_registry (M-DEF-9)	absent (critical gap)	still ABSENT
axis_assignment / axis_node / axis_relation	absent	still ABSENT
topic / topic_registry island table	(none)	ABSENT (correct — none needed)

Consequence: ownership and approval wiring for topics can use live tables (governance_object_ownership, approval_requests) — no new ownership substrate needed. The only genuine new substrate is axis_registry + axis_assignment (doc 06). The absence of axis_registry is itself the critical inventory_gap named in the open-axis model.

5. SSOT recovered (read this session)

RP final-acceptance checkpoint + doc 08 information handoff; layer-definition dynamic-drilldown canon; open-axis model (M-DEF-8/9) docs 02/03; unified governance model proposal; label-grouping governance; IU governance coverage; mục-tiêu-mở operating law v1.3. Key inherited rules applied throughout: count>1 ⇒ a layer exists (depth not hardcoded); no hardcoded axis array; provenance-or-quarantine for uncertain axes; KG proposes, never auto-mutates (Điều 39 Golden Rule); grouping ceilings are governed rows, never literals; Registries-Pivot owns nothing — it is a read/verification surface and computes no truth in Nuxt.