01 — Full-Stack Governance SSOT Map (Branch A)

Governance is not "the law files". It is six distinct SSOT layers. Treating any one of them as the whole is how a local island forms. Below: each layer, its real SSOT, what is centralized, what is fragmented.

A1. Law SSOT

Official Law SSOT = normative_registry (47 rows; PG operational SSOT per Đ37 Principle 9 "PG = SSOT operational, KB = text context"). Constitution NRM-CON-HP-V4P6P3 enacted (doc_level 1); laws at doc_level 2.

Complete? No. Enacted & present: Đ0/0-B/0-G/0-H/0-SML, 1–19, 22(V1P1), 24, 26, 28, 29, 30, 31, 32(V1P1), 33(V2P1), 35(V5P2), 36, 37, 38, 39, 41, 43. Draft: Đ34 (Workflow). Retired stubs superseded by amended rows: 22/32/33/35.
In KB but NOT in normative_registry (coverage gap): Đ20 (dieu20-thiet-ke-truoc-trien-khai.md), Đ23 (dot-scanning-system.md), Đ45 (dieu45-pg-native-queue-and-task-orchestration-law.md). These are enacted-as-documents but unregistered as rows.
law_catalog (5 rows) = STALE legacy; superseded by normative_registry (Đ38 merged old law_registry → v_law_registry read-only view).
governance_docs (12 rows) = a drifted UI index, NOT the SSOT: row 1 says "Hiến pháp v3.5 (25 Điều)" while the SSOT is v4.6.3; it labels Đ26 "Counting Law" and Đ28 "Matrix Law" whereas the SSOT names Đ26 = Luật Pivot and Đ28 = Luật Kỹ thuật Hiển thị.
Rules that live only in architecture/design docs (should be law/design patches): the threshold "max-ungrouped 50 ceiling", PIVOT_MISSING, phantom = LAW_DEFINITION_GAP, CLASSIFICATION_REQUIRED, count_integrity_status=FAILED — none appear in enacted Đ24/Đ26/Đ28/Đ31 text.

Verdict: authoritative core, but incomplete (Đ20/23/45 unregistered) and shadowed by a stale UI index. Grouping concepts have no law text yet.

A2. Authority / ownership SSOT

= governance_registry (9 agencies) + governance_relations (8 edges) + law_jurisdiction (law→domain coverage) + governance_audit_log. Đ37 mandates all of these (TẦNG 1→5 model).

9 agencies: GOV-COUNCIL (council, domain=governance), GOV-SIV (system, monitoring.integrity, Đ31), GOV-DOT (system, monitoring.dot, Đ35), GOV-KG-SYS (system, kg, Đ39), GOV-NRM-SYS (system, normative, Đ38), GOV-MOW/MOT/MOIT/MOUT (factory "mothers", assembly.*, Đ7 — all draft).
Capability model: only the 4 mothers carry a capability JSON (can_create / must_not_own / can_reference / output_family). must_not_own = the no-double-ownership guard, but it exists only in the live table, not in the enacted Đ37 v3.3 text (the law expresses ownership relationally via output_target, governance_relations.relation_type, law_jurisdiction.coverage_type, law_dot_enforcement.enforcement_role).
Ownership edges: all 8 governance_relations rows are agency→law (relation_type owner/approver_tbox/executor_abox). There are NO agency→collection / agency→pivot / agency→domain object-ownership edges. Object-level ownership is therefore unrecorded except via governance_registry.domain (FK→dot_domains).
Domain ownership (law_jurisdiction): classification → Đ24 primary, Đ29 secondary; pivot → Đ26 primary; governance → Đ37 primary, Đ32 secondary. But no agency has domain='classification' or domain='pivot' ⇒ these domains are agency-orphans (Đ37 §1 "Khoảng trống").
governance_audit_log = 1 stale row (relation_id NULL, codex 2026-04-24) ⇒ the DOT-GOV-VERIFY/DISCOVERY audit loop Đ37 mandates is not running into this table.

Important objects orphaned? Yes — the classification, classification.label, classification.species, pivot domains (agency layer); and grouping/threshold/pin/phantom (no domain at all). Double-owned? Not at agency level (sparse); the only multi-claim is the legitimate classification law layer (Đ24 primary + Đ29 secondary, allowed).

Verdict: real and law-mandated, but sparse + drifted + agency-orphaned for exactly the domains Registries-Pivot needs.

A3. Execution / approval SSOT

= approval_requests + apr_approvals, typed by apr_request_types (14) + apr_action_types (6), under Đ32. nrm_approval_rules keys authority off normative_registry.doc_level.

Authority engine (nrm_approval_rules): doc_level 1–2 → council / council_review; 3–4 → leadership / apr_dieu32 (= the approval_requests spine); 5–6 → department / department_head.
Đ32 quorum (enacted §4.2): high = ≥1 president + ≥2 ai_council + 0 reject; medium = ≥1 president; low = ≥1 approve / valid auto-approve. No-self-approval (§4.3.1): "Cấm self-approve cho high-risk request của chính người/agent tạo request." A valid approval artifact = an apr_approvals row (approver_type ∈ {human, ai_council}, decision ∈ {approve,reject,abstain}, UNIQUE(apr_id, approver)).
Distinguishable approvers? Yes. Live: apr_approvals = 42 rows → ai_council (28; gpt/gemini/ai_council_1/2) + human (14; sole approver president). Machine auto-apply (orchestrator-s142b, auto-apply-function, system_auto_expire) appears in approval_requests.reviewed_by but NOT as apr_approvals rows ⇒ it is not a sovereign approval.
Invalid/self approvals? None observed; quorum + UNIQUE enforce it. But the label/taxonomy/pivot collections (entity_labels, taxonomy_facets, pivot_definitions, label_rules) entered only via birth_orphan auto-apply (machine birth registration, Đ0-G) — not governed approval of any grouping policy.
Missing Registries-Pivot approvals: ALL of them. No reclassify/rule_change/schema_add/new_dot approval exists for display_policy, registry_pin, phantom, PIV-500, or grouping DOTs. os_proposal_approvals = 0.

Verdict: the spine is centralized, enforced, and the ONLY valid one. NO_APPROVAL_FOUND for every Registries-Pivot grouping artifact ⇒ COMMIT_FORBIDDEN.

A4. Execution / DOT SSOT

= dot_tools (288) + law_dot_enforcement (252) + dot_operations (20) + dot_iu_command_catalog (47) + dot_domains (46) under Đ35.

Authorization model (Đ35): A-tier (audit/monitor) = read-only, auto-approve; B-tier (execute) = read+write, pending approval (Đ32), and must be paired (paired_dot FK, trigger trg_dot_enforce_paired) with an A-tier monitor of the same scope. law_dot_enforcement.enforcement_role ∈ {executor (225), auditor (47)}.
Operations already present: classify, audit, health, verify, report, refresh, register, create, update, delete, restore, snapshot — grouping needs no new operation type.
Command metadata: every dot_iu_command_catalog row is tagged mutating/reversible (read=mostly non-mutating; collection/lifecycle=mutating+reversible). This is the read-only-vs-mutating contract grouping DOTs would inherit.
fix flow: fix_repair_dot (request) → patch_ops_code (high-risk action) with backup + regress-test (Đ35 §6.2/§6.5).

Verdict: complete and directly reusable. Grouping scan=A-tier read-only · propose=dot-apr-propose · apply=B-tier (approval-gated, paired) · audit=A-tier. No DOT may bypass this.

A5. Issue / event SSOT

= system_issues (183k) + event_outbox (175k) + event_type_registry (40) under Đ45 / Đ31 / Đ23.

Where failures go (existing classes): orphan → data_fault (thiếu_quan_hệ/thiếu_mã_định_danh) + orphan_file; drift → sync_fault (sai_lệch_dữ_liệu); display/Đ28 → render_fault (lỗi_lớp_2); hardcode → hardcode_violation/hc_finding_*; phantom → only as apr_phantom_applied (no first-class type).
Events: system.issue_opened/resolved/archived (active); mother.proposal.created/approved/rejected + mother.governance.blocked/unblocked exist but active=false — the exact governed-proposal lifecycle lane, dormant because the mothers are draft.
Allowed without emit: detection/raising an issue is automatic, never approval-gated (Đ31 "phát hiện TRƯỚC, fix SAU"). Approval-gated: acting on a finding (cleanup/repair) and emitting NEW event types (register-before-emit, Đ45).
Missing for grouping: no issue type for count_integrity_failed / phantom_candidate|confirmed / label_grouping_required / CLASSIFICATION_REQUIRED / PIVOT_MISSING; no event type for registries_pivot.* / pin.created|removed. ⇒ additive INSERT gap (no new table).

Verdict: centralized and reusable; grouping/pivot-coverage findings should be new rows in these registries (approval-gated), never a new local issue store.

A6. UI / display boundary

Governed by Đ28 (Display Technique Law): design_templates + template_statuses; "Nuxt CHỈ render từ khuôn đã đăng ký trong PG."

Belongs in UI (Nuxt): read Directus API, render registered template, emit event/submit payload (NT-D1). MUST NOT: business logic, query DB directly, hardcode, count math, create components outside the template whitelist.
Belongs in PG/API: all counting (pivot_count(), Đ26 MT2), all grouping/labels, all config (NT-D3 "config in PG not text").
Current Đ28 violations (documented, grep-verified in prior sessions): legacy /knowledge/registries index.vue hardcodes phantom rows CAT-ORP/PHA/UNM/017; health.get.ts:123 computes totalGap = reduce(+Math.abs(gap)); raw-counts sums Σrecord. GOOD pattern: pivot-query.get.ts (Directus items API, no count math).
Registries-Pivot local-encoding risk: the shipped route uses Nitro endpoints querying views via a direct read-only pg Pool (rpGatewayDb.ts) — an explicit exception to PG→Directus→Nuxt (forced because Directus 403s PK-less views). This is a process-island risk needing explicit Đ41/API-exception approval. The render layer itself is otherwise Đ28-compliant (dedicated UTable, PG-backed).

Verdict: display is centrally governed by Đ28; Registries-Pivot's render is mostly compliant, but the direct-pg API bypass is the one place it currently encodes a convention exception locally.

Cross-layer summary

Layer	SSOT	Centralized?	Fragment/gap for grouping
A1 Law	normative_registry	✅ core	Đ20/23/45 unregistered; no grouping/threshold/pin/phantom law
A2 Authority	governance_registry + relations + law_jurisdiction	⚠️ mandated but sparse	classification/pivot domains agency-orphaned; no object edges; schema drift
A3 Approval	approval_requests + apr_approvals	✅ enforced	zero approvals for any RP artifact
A4 DOT	dot_tools + law_dot_enforcement	✅ complete	no grouping DOTs yet (not local-built — must be Đ35 paired)
A5 Issue/Event	system_issues + event_outbox + event_type_registry	✅	missing grouping/pivot issue+event types (additive)
A6 Display	Đ28 design_templates	✅	direct-pg API bypass needs exception approval