Incomex AI Portal
KB-6186 rev 6

FX — Governance One Roof + Điều 39 KG Compatibility — Read-Only Documentary Execution Report (2026-06-16)

44 min read Revision 6
laws-newFXgovernance-one-roofdieu39knowledge-graphexecution-reportread-onlynon-authorizingPARTIAL

FX — GOVERNANCE ONE ROOF + ĐIỀU 39 KNOWLEDGE GRAPH COMPATIBILITY — READ-ONLY DOCUMENTARY EXECUTION REPORT

Date: 2026-06-16 · Revision: rev1 · Layer: FX (framework rev56 §6c — D2, cross-cutting, NOT F6) · STATUS: PARTIAL (honest, non-blocking).

§1 — Status / boundary confirmation

STATUS: PARTIAL — READ-ONLY, NON-AUTHORIZING FX SURVEY. This report executes the FX (Governance One Roof) read-only documentary survey + the mandatory Điều 39 compatibility audit, after the FX packet passed its internal gate. It made no live DB / runtime / production / Phase-1 query; touched no iu_staging_* / dot_tools / birth_registry / system_issues / event_outbox / universal_edges / entity_relations / kg_* live; called no birth/checker/promote/scanner/heartbeat/governance/KG function; created no schema/table/registry/index, no relationship DB, no governance graph engine, no governance/KG/One-Roof registry, no scanner auto-fix, no second birth system; registered no 36 DOT-KG; ran no DOT/formula/assembly/checker/scanner/heartbeat/KG-extraction/self-learning/conversational-acquisition/scaffold/priority/compliance/promote; wrote no canonical birth / BIRTH_STAMP / PROMOTE_STAMP / PROMOTE_BLOCKED; created no dashboard; resolved no CONS-002/003 / CELL-*; rewrote no Điều 39. Documentary ≠ live proof · Engineering PASS ≠ Authority PASS · Codex/GPT/Claude PASS ≠ Owner authorization.

STATUS = PARTIAL because: (a) the old automatic-Governance work is partly enacted but not production-certified and partly design-only / not built; (b) Điều 39 is enacted but essentially not implemented live and its compatibility requires a future amendment/compatibility note; (c) every implementation candidate remains Owner-gated; (d) live status of old automation and kg_*/universal_edges can only be confirmed by a future Phase-1, not by FX. This is honest and non-blocking.

Internal gate (G1–G8) result — all GREEN → executed:

Gate Result Evidence
G1 Sources readable GREEN F5 decision (this macro) + F5 bundle + Cross-F Matrix + F0→F4 records/reports + framework rev56 §6c (D2) + de-bai rev33 §IV/§VI + catalog rev82 (GOV-, Nhóm R, GOV-REUSE-) + constitution rev44 + operating-rules rev51 + required-stamps rev6 + checker rev11 + addendum rev14 + Điều 39 rev15 + KG supporting docs (D1 cluster, agent-api-registry, roadmap, handoff-s159, council-review-round3) all read.
G2 F5 gate closed first GREEN reports/f5/f5-owner-decision-record-2026-06-16.md rev1 exists, closes F5, unlocks FX-macro-only.
G3 Assets classifiable honestly GREEN Every FX/Điều 39 asset pinned to a KB source; old automation role-classified + live-status-quoted; absent evidence handled as Q2 source-recovery, not inferred.
G4 No live DB/runtime/Phase-1 GREEN No live touch / no fn_* call performed.
G5 No conflict resolution GREEN CONS-002/003, CELL-*, HOLD-1/2, Nhóm R carried; Điều 39 conflicts recorded, not resolved.
G6 No schema/design/impl GREEN No registry/table/relationship-DB/graph-engine/scanner/second-birth; no technical design/decision note/implementation; no Điều 39 rewrite.
G7 Boundary held GREEN Governance = info/state/relationship under one conceptual roof; scanner list-only; no monster KG; no governance-in-birth-P0; Điều 39 read as compatibility source only.
G8 3 Owner questions preserved GREEN Q1/Q2/Q3 in §2.

§6c mapping confirmed: FX = framework §6c D2 — Governance One Roof / Owner / Authority Gates · [CROSS-CUTTING FOUNDATION], áp xuyên suốt F0–F5, KHÔNG tầng build riêng, KHÔNG system mới. (F0=D1, F1=D3+D10-root, F2=D4+D5, F3=D6+D7, F4=D8+D9+D10-canonical, F5=D11+D12.)

§2 — Owner View — 3-question answer

Q1 — Cái gì đang có và dùng lại được? A complete documentary governance spine is reusable on paper. Reusable now: (a) the F0→F5 accepted evidence lineage + decision-gate / control-verdict / non-authorization patterns; (b) CONS-004 authority order as working precedence; (c) the governance-as-relationship model (de-bai §IV: "Governance = bản đồ quan hệ và trạng thái quản lý của object trong hệ") carried by DOT (narrow info-completion) / stamp (completion marker) / checker (verdict-only gate) / scanner (list-only gap-detector); (d) Điều 39 goals + provenance/trust/source_authority model + TBox/ABox boundary + "AI proposes, human approves" golden rule + Data→Graph→KG→Priority→AI chain as the long-term direction; (e) an enacted old governance loop — the DOT Repair Governance / Điều 35 v5.2 lineage (the literal "sửa lần 3 / Council Round 3 SIGN-OFF") with its scan→propose→approve→apply→verify pattern; (f) a large One-Roof Governance design corpus reusable as a blueprint. None of (a)–(f) is, by itself, a built+production-certified running governance system; (e) has live substrate but a "production-readiness FAIL" + "confirmed authority bypass" caveat, and (f) is design-only.

Q2 — Cái gì đang có nhưng cần sửa/kiểm chứng mới dùng lại được? Almost everything operational. The old DOT-governance substrate exists in dot_tools/governance_* (per a documentary 2026-06-05 Codex audit) but carries "CORE AUDIT PASS / PRODUCTION READINESS FAIL" and a "confirmed authority bypass" (fn_auto_approve_add, 160 scanner requests applied without vote) — it must be Phase-1 verified and the bypass closed before reuse. The One-Roof coverage-scanner family (dot_governance_coverage_scan etc.) is ABSENT from live (design-only, BUILD NO-GO). Điều 39 is enacted but essentially not implemented live (runtime empty — 0 DOT executions / 0 KG events; KG owner unregistered in governance_registry; registry IUs still lifecycle_status=draft). Its 36 DOT / 18 pairs, 14 config tables, 24/7 self-learning loop, and universal_edges/entity_relations/kg_* tables must not be assumed ready/live and must be staged, not registered as one block. Important distinction — registration ≠ execution: DOT-KG registration/spec evidence is not execution evidence. Even though S161-P2 (current-state/reports/s161-p2-kg-dot-registration-report, rev1, "ALL PASS") and S161-P2-Fix (current-state/reports/s161-p2-fix-report, rev1, trigger-config fix) show 36/36 DOT-KG registered (18/18 pairs, 0 NULL), the 2026-06-04 KG evidence still shows execution/live rollout not proven: last_executed NULL / 0 runs across all 36 (…/kg-dot-process-discovery-and-document-building-pilot-2026-06-04/04-dot-kg-process-evidence-graph.md, rev1, "No DOT executed"), 0 DOT executions / 0 KG events (D1 cluster), and DOT "đăng ký nhưng chưa dispatch" (agent-api-registry.md, Phase 2+), with no runtime-correlation proof. Therefore registered ≠ executed ≠ live ≠ production-ready. GOV-016 (no risk/blast-radius calculator) and GOV-017 (no fail-closed-on-uncomputable-risk code) are open BLOCKERs; GOV-REUSE-001 (can existing edges/role/owner hold the minimal governance graph) is a BLOCKER. Authority order (CONS-004) is working-precedence, not enacted; runtime/checkout sync unproven.

Q3 — Cái gì thật sự phải làm thêm? Genuinely new work, all future, Owner-gated, default-NO: a Điều 39 Compatibility / Amendment Note (preserve goals, change rollout — recommendation only, no rewrite); decision notes for CONS-002/003 + CELL-*; a Phase-1 read-only substrate/runtime survey (the only place old-automation live-status, the authority-bypass, and kg_*/universal_edges liveness can be verified); technical-design preparation after FX; a staged Điều 39 rollout (one KG fact-type at a time via Lego/DOT/stamp); DOT_RELATION_<name> only when a relation need is proven; a list-only governance coverage scanner/report (never auto-fix); and any registry/table/schema only after reuse-insufficiency proof + Owner gate. FX builds none of these.

§3 — FX asset classification table

Asset KB source pin Currency Classification Reuse verdict
F0→F5 evidence lineage reports/f0..f5/*, Cross-F Matrix (2026-06-16) current documentary spine Q1 reuse as paper contract
CONS-004 authority order F0 decision record (2026-06-16) current authority/Owner-gate Q1 working precedence
Governance-as-relationship model de-bai rev33 §IV current concept Q1 the FX model
DOT/stamp/checker/scanner roles de-bai §IV/§VI; F3/F4/F5 reports current concept Q1 governance carriers
GOV_STAMP / OWNER_STAMP required-stamps rev6; addendum rev14 §4 DRAFT not-enacted authority stamps (high-risk) Q1/Q2 vocab reusable; runtime delivery UNKNOWN
governance_role framework §6c D2 substrate; addendum §4 (✅) reported-live (documentary) runtime substrate Q2 verify live (Phase-1)
governance_audit_log framework §6c D2 (~1 row); catalog GOV-007 reported ~1 row, "dormant" runtime substrate Q2 not the Đ32 ledger; verify
governance_candidate_state catalog GOV-008 (0 row / 0 writer) design-only registry/schema Q2 design-only; not live
universal_edges catalog GOV-REUSE-001 (~2,199 rows) reported-live (documentary) runtime substrate Q2 reuse for relation graph; verify
Điều 35 DOT-governance law (v5.2) dieu35-dot-governance-law.md rev13 ENACTED; metrics unchecked authority/registry (enacted law) Q1/Q2 reuse enacted loop; not production-certified
DOT Repair Governance v4 FINAL (sửa lần 3) patch-dot-repair-governance-s178-fix15.md rev12 + 2 council reviews enacted package implementation artifact (spec) Q1 reuse repair loop design
Live DOT/governance substrate (audit) checkpoint-codex-…-2026-06-05.md rev1 documentary live audit scanner/report (audit) Q2 PRODUCTION-READINESS FAIL + authority bypass — verify+fix
One-Roof Governance decision pack …/one-roof-governance-decision-pack-2026-06-01/ (14 docs rev1) design-only authority/Owner-gate + registry DESIGN Q1 blueprint; NOT built
One-Roof technical addendum / impl index …/one-roof-governance-technical-addendum-and-implementation-index-2026-06-01/ (~120 docs) design-only, BUILD NO-GO scanner/coverage + registry DESIGN Q1 blueprint; NOT built
dot_governance_coverage_* scanner family decision-pack doc 00 (ABSENT in live) design-only, ABSENT scanner/coverage candidate Q3 add-later, list-only, Owner-gated
Điều 39 goals dieu39-knowledge-graph-law.md rev15 §0 ENACTED (BAN HÀNH) concept/direction Q1 required direction
Điều 39 implementation (36 DOT, 14 tables, self-learning) Điều 39 §7/§7C/§10; D1 cluster designed; runtime EMPTY implementation assumption Q2/Q3 stage; not live

§4 — Old Governance automation reuse analysis (source-pinned, role-classified, caveats carried)

The search FOUND old automatic-Governance evidence. It is two distinct bodies that must not be conflated.

4.1 — Cluster 1: ENACTED "DOT Repair Governance" → Điều 35 v5.2 (the "sửa lần 3")

  • The "third revision repair" is FOUND and real. The DOT Repair Governance package went through three Council review rounds (Round 3 SIGN-OFF: Gemini 10/10 APPROVE FINAL, GPT 9.6/10 APPROVE WITH MINOR) and was enacted as Điều 35 — Luật Quản trị DOT, v5.2 FINAL (BAN HÀNH 2026-04-18, S178 Fix 15), "BAN HÀNH sau enact gói DOT Repair Governance v4 FINAL".
    • Source pins: knowledge/dev/laws/dieu35-dot-governance-law.md (rev13, content_length 36,904); knowledge/dev/laws/patch-dot-repair-governance-s178-fix15.md (rev12, 21,273); knowledge/current-state/reports/council-review-dot-repair-governance-gpt-round1.md; …-gemini-round3.md.
    • What was repaired (4 holes), verbatim: "(1) Đ41 path vô chủ; (2) Đ32 proposed_action whitelist hardcode; (3) Đ35 §5.2 nhắc fix_repair_dot không định nghĩa; (4) Đ22 silent-fail pattern lan rộng." The repair built an end-to-end fix_repair_dot flow (detect→propose→approve→apply→verify→close), a DB-enforced quorum gate (apr_approvals + fn_apr_quorum_check), an admin_fallback_log audit table, and a trigger blocking handler_ref='unimplemented'.
    • Nuance: "lần 3" = Council Round 3 of one package, not three separate repairs — though the law's version lineage (v5.0 → v5.1 → v5.2) does show a genuine multi-revision repair history.
  • Role classification: authority/Owner-gate + registry/schema (enacted law governing DOT) + implementation artifact (the patch spec). Reusable as an enacted scan→propose→approve→apply→verify loop pattern (paired A/B DOTs, APR/quorum, fallback audit) — this is the closest existing analog to the laws-new "scanner→checker→promote, list-only, fail-closed" model.
  • Live status + CAVEATS (must travel with the asset): the live substrate exists per a documentary audit — dot_tools total=309 active=291, governance_registry 9 rows (5 active), governance_relations 8, governance_audit_log 1 (dormant), approval_requests 211, apr_approvals 42. BUT the same audit (checkpoint-codex-design-code-live-alignment-audit-…-2026-06-05.md, rev1) reads "CORE AUDIT PASS / PRODUCTION READINESS FAIL" and records a "confirmed authority bypass" (fn_auto_approve_add(), "applied scanner requests without vote=160"); the Điều 35 success metrics are still unchecked ("[ ] 14/14 health checks LIVE"). Verdict: governance automation is built and live in substrate, but not certified production-complete, and has a live authority-bypass that must be closed. This caveat must NOT be dropped when reusing.

4.2 — Cluster 2: "One-Roof Governance" / GCOS coverage-scanner DESIGN body

  • FOUND, design-only, BUILD NO-GO. A ~120-document corpus (2026-06) under knowledge/dev/reports/architecture/one-roof-governance-decision-pack-2026-06-01/ (14 docs, rev1), …/one-roof-governance-technical-addendum-and-implementation-index-2026-06-01/ (~120 docs), and knowledge/dev/design/one-roof-governance-concepts/ (4 docs, concept-only/not-ratified). Pervasive status markers: "design-only", "apply NO-GO", "BUILD NO-GO", "NOT_RUN — blocked at M-1", "NO BUILD; substrate untouched".
  • The prior "Governance One Roof" principle (source-pinned, verbatim, decision-pack doc 01): "Nguyên tắc Một Mái Nhà Quản trị (One-Roof Governance): Mọi đối tượng và hành động liên quan đến quản trị đều sống dưới một mái nhà quản trị trung tâm duy nhất. Một sổ đăng ký cơ quan (governance_registry), một trục phê duyệt (Điều 32), một hệ thống phát hiện/sự cố/sự kiện (Điều 31 + Điều 45), một mô hình thực thi DOT (Điều 35)." Headline verdict (doc 00 §0.4): "The central governance roof already exists and is sufficient as a spine; the defect is incomplete coverage, not absence of governance. … The missing piece is a Governance Coverage Invariant and an automatic anarchy/governance-orphan detector."
  • Role classification: scanner/report/coverage + authority/Owner-gate + registry/schema — DESIGN only. The dot_governance_coverage_scan / dot_governance_orphan_detect / dot_governance_gap_propose / dot_governance_assignment_apply / dot_governance_coverage_audit / dot_governance_exception_review / dot_governance_issue_route family is verbatim ABSENT from live ("all ABSENT → they are NEW (design only)"); there is no dot_governance_coverage table; governance-domain event_type_registry rows are all active=false.
  • Reusable as a design blueprint only — there is no running One-Roof scanner to inherit. Whole build is gated NO-GO pending sovereign authorization M-1 + council gates.

4.3 — Reuse mapping (old → laws-new)

Old asset laws-new analog Reuse verdict
Điều 35 DOT-governance enacted loop (scan→propose→approve→apply→verify, paired A/B, APR/quorum, fail-closed) de-bai §IV/§V scanner(list-only)→checker(verdict)→promote(atomic) + Mức-3/Đ32 Q1 reuse the pattern; do not re-derive. Carry the production-readiness + authority-bypass caveats.
One-Roof principle ("một mái nhà quản trị", coverage invariant, orphan detector) framework D2 "Governance One Roof = MỘT mái khái niệm" + de-bai §V.6 scanner-list-only Q1 reuse as blueprint; but laws-new One Roof is a conceptual roof over existing ledgers, explicitly NOT the "central governance registry/system" the old pack centered on — see §8.
dot_governance_coverage_* scanner family list-only governance coverage scanner/report (Q3) Q3 add-later, Owner-gated, no auto-fix.
fn_auto_approve_add auto-approve path RISK-BYPASS-001/002/004 (catalog Nhóm R) Q2 must close the bypass before any canonical-write reuse.

If the Owner means "an automatic governance subsystem built + repaired through a 3rd revision," that is the DOT Repair Governance / Điều 35 lineage (enacted, live substrate, but not production-certified). If the Owner means "an automatic governance-coverage One-Roof scanner," that was designed, council-reviewed, rehearsed — never built.

§5 — Điều 39 compatibility analysis

Source: knowledge/dev/laws/dieu39-knowledge-graph-law.md (rev15, content_length 25,015) — "ĐIỀU 39 — LUẬT KNOWLEDGE GRAPH v2.3 — BAN HÀNH" (S159, Council 3 vòng: Gemini 9.5 + GPT 8.8). Enacted.

5.1 — Goals (Q1 — required, reusable as direction)

  • §0 Vision (verbatim): "Tạo ra Knowledge Graph đủ tin cậy để AI ra quyết định và điều hành hoạt động kinh doanh của Incomex."
  • 3 goals: best practices (EKGF, Zaveri, HTN, PKG, RLKGF); PG16+Qdrant maximized (NT8); business = consequence when (1)+(2) are correct.

5.2 — The Data→Graph→KG→Priority→AI decision chain (Q1 — direction)

Verbatim "Chuỗi giá trị 5 tầng": "① Data (PG) → ② Data Graph (edges, FK) → ③ Knowledge Graph (tri thức ngữ nghĩa) → ④ Priority Graph (ưu tiên theo context) → ⑤ AI quyết định → Con người giám sát." This is long-term direction, fully compatible with F0→F5 as a destination, not a current build.

5.3 — TBox / ABox boundary (Q1 — directly compatible)

Golden rule (§0): "TBox (schema/scaffold/ontology) = CON NGƯỜI duyệt. ABox (data/link/weight) = AI tự thực hiện." §7B authority: TBox → Council/Data Stewards (Đ37); ABox-large-exception → dept management; ABox-normal → AI (guardrail). This is the same human-over-canonical discipline as laws-new Mức 3 / Đ32 / "no new core mandatory stamp without Mức-3 change."

5.4 — "AI proposes, human approves canonical knowledge" (Q1 — load-bearing, compatible)

Verbatim NGUYÊN TẮC VÀNG: "AI ĐƯỢC ĐỀ XUẤT, KHÔNG ĐƯỢC TỰ BAN HÀNH TRI THỨC CHUẨN." Auto/manual gate via kg_auto_approve_rules: "KHÔNG CÓ rule = CẤM auto = mặc định human." This is identical in spirit to the laws-new fail-closed / "uncertain → escalate to Mức 3, no self-downgrade" rule.

5.5 — universal_edges / entity_relations / Đ38 bindings (Q2 — verify, do not assume live)

Two graph sources: entity_relations (soft/static semantic relations, living beside Birth Registry Đ0-G) + Đ38 output (live/dynamic bindings). Nodes = born entities; static edges = entity_relations + universal_edges (FK); dynamic edges = Đ38 bindings. The law specifies columns to ADD (provenance JSONB, valid_time, knowledge_type='negative') — i.e. to-be-built, not claimed live. Q2: must Phase-1-verify liveness; reuse universal_edges (~2,199 rows, per catalog GOV-REUSE-001) rather than build a new relation DB.

5.6 — Trust / provenance / confidence / freshness / source_authority (Q1 — reusable discipline)

Verbatim: "Mọi edge + decision PHẢI có confidence + freshness + provenance + source_authority. … trust_score = confidence × freshness_decay × provenance_weight × source_authority. Edge trust < threshold → chỉ suggestion. Source_authority: quy định (Đ38) > báo cáo > chat. … Không provenance = quarantine." This provenance/quarantine discipline maps cleanly onto laws-new stamp/provenance + "missing stamp → quarantine-from-promote (not from existence)".

5.7 — 36 DOT / 18 pairs (Q2/Q3 — too heavy as one block; stage)

§7: "36 DOT-KG (18 CẶP)" — 18 producer (Cấp B) / verifier (Cấp A) pairs ("Cấp A IDLE = Cấp B đúng = thiết kế tốt"). Per agent-api-registry.md, 22 of 36 need Agent API, 14 are PG-only. The law fixes the whole 36 as one contract ("không tách hoặc renumber matrix"). Q2/Q3: incompatible with immediate rollout under Lego/DOT/stamp; must be staged — register PG-only DOTs first, one fact-type at a time, never all 36 at once. D1 cluster confirms only 18 verifiers are even visible in inventory (18 producers orphaned), 0 executions. DOT-KG registration status must be separated from DOT-KG execution status. The 36/36 DOT-KG registration is real and source-pinned (S161-P2 current-state/reports/s161-p2-kg-dot-registration-report rev1, "ALL PASS", 18/18 pairs 0 NULL, execution-engine present 36/36; S161-P2-Fix current-state/reports/s161-p2-fix-report rev1, trigger-config), but FX treats this only as documentary/registry/spec evidence. It does not prove execution, live rollout, runtime correlation, or production readiness — the same inventory records last_executed NULL / 0 runs for all 36 (…/04-dot-kg-process-evidence-graph.md rev1, "No DOT executed"). Registered ≠ executed ≠ live ≠ production-ready.

5.8 — Self-learning / RLKGF / conversational acquisition / bottom-up discovery (Q2 — not current; guardrail-bound)

C9 RLKGF self-learning loop (decide→result→self-score→learn) bounded by max_delta + kg_weight_snapshots rollback + champion/challenger + PG trigger REJECT when ai_self_learn touches species/relation_type (TBox). C10 Conversational Acquisition (chat internal/customer/interview → extract→classify→auto-small/APR-large). Process G bottom-up: "Data→DISCOVER→PROPOSE→APR→Human duyệt→Update scaffold." Q2: must NOT be treated as current implementation; self-learning may touch ABox weights only, never TBox/canonical — fully consistent with "AI proposes, human approves".

5.9 — Runtime / config tables (Q2/Q3 — planned, not live; create only when phase needs)

§7C names ~14 tables — dot_tools, universal_edges, entity_embeddings (Qdrant), kg_signal_config, kg_thresholds, kg_constraint_config, kg_acl_config, kg_auto_approve_rules, kg_source_authority, kg_priority_templates, scaffold_dependency_map, kg_weight_snapshots (khi C9), kg_model_versions (khi C9), kg_quality_log + kg_evolution_snapshots. NT11: "Tables chỉ tạo khi Phase cần." Q2/Q3: none assumed live; this "create only when phase needs" rule is the SAME minimal-creation discipline as laws-new "no new registry/table without reuse-insufficiency proof + Owner gate."

5.10 — Live status (Q2 — enacted ≠ implemented)

d1-knowledge-graph-curated-cluster-2026-06-04.md (rev1): runtime EMPTY — 0 DOT executions, 0 KG events ("the design has never run"); KG owner unregistered in governance_registry ("Chưa đăng ký = chưa triển khai", §7B); registry IUs lifecycle_status=draft despite the BAN HÀNH header. roadmap.md (rev2): currently EKGF Cấp 1, Phase 0. agent-api-registry.md: "Phase 1: KHÔNG có Agent API … DOT đăng ký nhưng chưa dispatch." Even where S161-P2 / S161-P2-Fix show 36/36 DOT-KG registered, the live-execution side remains unproven by this 2026-06-04 KG evidence: last_executed NULL / 0 runs (…/04-dot-kg-process-evidence-graph.md rev1, "No DOT executed") / 0 KG events / no runtime correlation. Therefore Điều 39 remains enacted + partly registered/spec'd, but not executed / not live / not production-ready — registered ≠ executed ≠ live ≠ production-ready. Điều 39 is enacted law with an essentially un-started implementation.

5.11 — Scaffold / Priority / HTN + the Đ34 boundary (Q1 — compatible discipline)

Scaffold Graph = TBox-shaped from regulation (Đ38 → DOT-KG-SCAFFOLD-BUILD → Graph khung). Priority Graph = HTN decomposition (Compound/Method/Primitive). C5 hard boundary: "Điều 39 CHỈ sinh Ordered Task List + Goal State TĨNH. KHÔNG sinh if/else, goto, retry, timeout, routing, state transition … = Điều 34 HOÀN TOÀN. Vi phạm ranh giới = vi phạm NT1." This narrow-output discipline mirrors laws-new "DOT = một việc hẹp" and "scanner = list-only".

5.12 — Combination verdict (how Điều 39 combines with F0→F5)

Điều 39 goals + governance discipline are COMPATIBLE with F0→F5; Điều 39 rollout assumptions are NOT. The law's direction (Data→KG→Priority→AI, TBox/ABox, AI-proposes-human-approves, provenance/trust/quarantine, narrow-output DOTs) maps onto the laws-new Lego/DOT/stamp/checker/scanner model almost one-to-one. The law's rollout (36 DOT as one block, 14 config tables defined together, 24/7 continuous self-learning loop, scaffold auto-build on every Đ38 enactment, per-person HTN trees) is big-bang and conflicts with the staged, gated, reuse-first model. Council Round 3 itself flagged 8 scale-risk points around exactly these. The resolution is reinterpretation / staged rollout: preserve Điều 39 goals; deliver them incrementally through F0→F5 + FX + Phase-1 + technical design — one KG fact-type, one PG-only DOT, one stamp/provenance at a time.

§6 — New DOT / stamp governance model analysis

The laws-new model carries governance as information completed piece-by-piece, not as a management machine:

  • Governance = relationship/state/classification map (de-bai §IV.2): where an object sits (tầng/loài/collection/domain), who owns it, what it relates to, which formula/IO/validation/rollback/promote it passed, whether high-risk. "Approval/quorum chỉ là một mảnh của governance, và chỉ bắt buộc ở vùng high-risk/canonical (Mức 3)."
  • DOT = narrow info-completion machine (§IV.3): "DOT là máy/agent làm một việc hẹp: bổ sung hoặc kiểm chứng một mảnh thông tin governance. Đó không phải một hệ governance mới."
  • Stamp = completion marker, not approval workflow (§IV.4): "Một stamp = một mảnh thông tin đã đủ, không phải một quy trình phê duyệt nhiều bước." BIRTH_STAMP/PROMOTE_STAMP are post-promote OUTPUTS.
  • GOV_STAMP / OWNER_STAMP (required-stamps rev6 high-risk extras; addendum §4): "GOV_STAMP → governance_role (governed/observed/excluded) — route vào One-Roof"; "OWNER_STAMP → governance_audit_log (Đ37 ownership minute) + axis_assignment." Both required only in canonical/kernel/high-risk; "Thêm một dấu bắt buộc mới = thay đổi Mức 3." This is the only literal "route vào One-Roof" tie — and §11 of the addendum states "GOV_STAMP route vào One-Roof, KHÔNG dựng governance song song."
  • Checker = verdict-only Mức-2 gate (checker rev11): local checks only, fail-closed, escalates kernel/canonical/production/governance-scope to ESCALATE_L3 → lane Canonical/Đ32; never self-stamps, never mutates. "No checker, no lane."
  • Scanner = list-only gap-detector (de-bai §V.17): "chỉ liệt kê thiếu dấu, orphan, promote-blocked; không tự sửa toàn hệ; không thay promote checker; không trở thành macro governance mới."

This DOT/stamp/checker/scanner balance must be preserved when wiring Điều 39 and the old governance loop in: Điều 39's 18 producer/verifier pairs map onto "DOT-narrow + verifier-idle-when-correct"; its provenance/quarantine maps onto stamp/scanner; its TBox-human-approval maps onto Mức-3/GOV/OWNER stamps + Đ32.

§7 — Data self-enrichment / living-data balance analysis

Bounded enrichment is allowed; an autonomous canonical-mutating engine is forbidden. de-bai §IV.5 gives the strict order to add a new governance/relation info-type: "1. Xác định mảnh thông tin cần bổ sung → 2. Xem registry/metadata hiện có đã chứa được chưa → 3. Nếu cần, thêm một DOT nhẹ → 4. Thêm stamp tương ứng → 5. Chỉ sửa birth core nếu thông tin mới là căn cước nền tảng bất biến." Điều 39's bottom-up "Data→DISCOVER→PROPOSE→APR→Human duyệt" + ABox-only self-learning is the same shape.

Mechanism Allowed role Forbidden role
Event → DOT / re-run emit a re-run that completes one relation/stamp/provenance fact trigger a whole-system rebuild / 24-7 autonomous mutation
Scanner list missing-stamp / stale / orphan / promote-blocked into a warning table auto-fix; become the canonical source of truth
Owner / Agent authorize a new DOT / rule / relation expansion (Owner-gated) self-authorize from a PASS verdict
KG self-learning (C9/RLKGF) adjust ABox weights within max_delta + snapshot rollback alter TBox / canonical knowledge / species / relation_type
universal_edges / relation graph enrich in place via DOT+stamp+provenance become a second/hidden graph source-of-truth or new relation DB
Provenance / trust quarantine edges lacking provenance / below survival threshold promote low-trust edges to canonical

Net rule: data may self-enrich only through event→DOT→stamp/provenance→(Owner-gated rule/relation expansion), with scanner reporting gaps and humans approving canonical changes. Self-enrichment must never silently grow into the old monster governance registry or a monster KG.

§8 — Monster-governance / monster-KG / second-birth risk analysis

Risk Status in FX survey Guardrail (source-pinned)
Monster governance registry / central system Named, avoided framework D2: "One Roof KHÔNG ủy quyền tạo governance registry/system mới"; de-bai §IV header; catalog GOV-REUSE-001 "không dựng governance machine mới." The OLD One-Roof pack centered on a central governance_registry — laws-new One Roof is deliberately a conceptual roof over existing ledgers, not that central system.
Monster Knowledge Graph rollout Named, deferred 36 DOT + 14 tables + 24/7 self-learning must be staged; Điều 39 NT11 "tables chỉ tạo khi Phase cần"; Council Round 3 flagged 8 scale risks.
Scanner auto-fix Named, forbidden de-bai §VI.7 "Làm được bằng scanner/report → KHÔNG tạo auto-fix"; §V.17; framework D11 forbidden "Auto-fix scanner".
Second birth system / governance birth layer Named, forbidden addendum §7b blocks "canonical write pass nhưng staging chưa consumed (rủi ro double-promote)"; framework D10 forbidden "birth-registry mới".
Governance stuffed into birth P0 Named, forbidden framework §6c rationale: "lỗi trung tâm cần tránh là 'nhồi governance vào birth P0'"; D2 note repeats it. Governance evidence + canonical birth live at the promote boundary (D9/D10).
Central relationship DB / graph engine overbuild Named, avoided reuse universal_edges (~2,199) + governance_role + owner (catalog GOV-REUSE-001/002); "không tạo store mới."
Treating enacted law as live implementation Named, enforced Điều 39 runtime empty (D1); enacted ≠ implemented.
Old automation assumed live/authoritative Named, caveated Cluster 1 live substrate carries "PRODUCTION READINESS FAIL" + "confirmed authority bypass"; Cluster 2 design-only/ABSENT.
Self-learning altering canonical/TBox Named, forbidden Điều 39 PG trigger REJECT on ai_self_learn touching species/relation_type.

All major bloat/anti-patterns are named and held; none is introduced by FX.

§9 — Authority / Owner gate / Mức-3 analysis

  • Authority order (CONS-004, working precedence): supreme constitution (HP v4.6.3, "Văn bản tối cao") > enacted laws (Đ32/Đ35/Đ38/Đ39) > laws-new KB practical-authority for drafts; VPS = SSOT code/runtime (operating-rules §0.3), PG/Directus = truth (constitution NT10 "PG = truth"); cross-class = Owner gate (operating-rules §8 "Chờ User/GPT/Opus quyết"). CONS-004 is decided as working precedence, not enacted — still Owner-gated.
  • Mức 3 / Canonical-Kernel Governance (de-bai §II.5 / §V.16; addendum §1.9): production / kernel / enacted-law / approval / rollback-rule / birth-gate changes "vẫn dùng governance nặng như hiện tại (Mức 3 / lane Canonical / Đ32)." "KHÔNG dùng Matrix/Stamp để né production/kernel gate." The 3 levels = 3 required-stamp sets (Mức 1 = TEMP_ID only; Mức 2 = promote preconditions+outputs; Mức 3 = full + rollback PROVEN_IN_STAGING + Đ32).
  • Owner / human authority is final: constitution "S178 CHỦ TỊCH CHỐT THẲNG"; Đ39 golden rule "AI đề xuất, không tự ban hành"; checker ESCALATE_L3 → lane Canonical/Đ32; addendum §12 enact precondition "(a) Owner chốt … addendum này không mở cổng nào."
  • GOV-016 / GOV-017 are open BLOCKERs (catalog Nhóm B): no risk/blast-radius calculator exists ("chưa có máy tính A–E"); no fail-closed-on-uncomputable-risk code ("nguyên tắc có, code chưa"). GOV-REUSE-001 BLOCKER: whether existing universal_edges/governance_role/owner can hold the minimal governance graph. RISK-BYPASS-001/002/004 BLOCKERs: any canonical-write path bypassing checker/atomic-promote → pilot BLOCKED (directly relevant to the live fn_auto_approve_add bypass found in Cluster 1).
  • PASS ≠ Owner authorization holds throughout: framework D2 "Codex/GPT/Claude PASS ≠ Owner authorization"; this FX report authorizes nothing.

§10 — Evidence currency table

Source Path Rev Currency Used for
F5 decision record reports/f5/f5-owner-decision-record-2026-06-16.md rev1 current (this macro) F5 closure / FX unlock
Cross-F Matrix reports/f5/f0-f5-cross-f-evidence-readiness-matrix-2026-06-16.md FX-patch applied current readiness/evidence summary
F5 execution report reports/f5/f5-…-execution-report-2026-06-16.md rev1 current F5 boundary facts
F4 decision + execution reports/f4/*-2026-06-16.md rev1 current stamp/checker/promote boundary
framework technical-slice-framework.md rev56 current §6c D2 / FX = cross-cutting
de-bai de-bai-cai-tien.md rev33 current governance-as-relationship / Lego
catalog cau-hoi-khi-tai-cau-truc.md rev82 current GOV-, Nhóm R, GOV-REUSE-
constitution laws/constitution.md rev44 enacted authority order / Mức-3 / Đ38/Đ39 refs
operating-rules ssot/operating-rules.md rev51 enacted VPS=SSOT / PG=truth / Owner gate
required-stamps required-stamps.v0.1.json rev6 DRAFT GOV/OWNER stamps
checker spec promote-checker-v0.1-spec.md rev11 DRAFT verdict-only gate / ESCALATE_L3
addendum matrix-stamp-governance-addendum.md rev14 DRAFT §7b atomic promote / One-Roof routing
Điều 39 laws/dieu39-knowledge-graph-law.md rev15 enacted (BAN HÀNH) KG goals / chain / TBox-ABox / 36 DOT / self-learning
Điều 39 D1 cluster design/knowledge-graph/d1-…-2026-06-04.md rev1 documentary runtime-empty / unregistered-owner
agent-api-registry architecture/agent-api-registry.md rev1 documentary 22/36 need Agent API; Phase 2+
DOT-KG registration evidence current-state/reports/s161-p2-kg-dot-registration-report + …/s161-p2-fix-report rev1 documentary registry/spec registration/spec only — 36/36 DOT-KG registered (18/18 pairs, 0 NULL); proves registration, not execution
DOT-KG execution / live status …/04-dot-kg-process-evidence-graph.md + D1 cluster + architecture/agent-api-registry.md rev1 documentary runtime-status execution / live / prod-readiness NOT proven — last_executed NULL / 0 runs / 0 KG events / no runtime correlation
KG roadmap laws/roadmap.md rev2 documentary EKGF Cấp 1 / 5-phase
council review v2.2 current-state/reports/council-review-round3-dieu39-v2.2-gpt.md rev1 documentary 8 scale-risk points
Điều 35 DOT-gov law laws/dieu35-dot-governance-law.md rev13 enacted old gov loop (sửa lần 3)
DOT Repair patch laws/patch-dot-repair-governance-s178-fix15.md rev12 enacted package repair lineage / 4 holes
live audit reports/architecture/checkpoint-codex-…-2026-06-05.md rev1 documentary live audit PROD-READINESS FAIL + authority bypass
One-Roof decision pack reports/architecture/one-roof-governance-decision-pack-2026-06-01/ rev1 design-only One-Roof principle / coverage scanner ABSENT

§11 — Conflict / HOLD log

Item Status Blocks what Carried to
CONS-002 (IO examples GAP) Unresolved concrete IO contracts Owner decision note
CONS-003 (6-vs-7 tầng) Unresolved cell_id tầng dimension Owner decision note
CONS-004 (authority order) Working precedence, not enacted cross-class authority Owner enactment
CELL-003/004/007 BLOCKER cell_id materialization Owner decision note
HOLD-1 (iu_staging_*) Phase-1-gated staging store proof Phase-1
HOLD-2 (atomic promote) Not lifted real promote / canonical birth F4 implementation
GOV-016 / GOV-017 BLOCKER risk calculator / fail-closed code Phase-1 + technical design
GOV-REUSE-001 BLOCKER minimal governance graph on existing edges Phase-1
RISK-BYPASS-001/002/004 BLOCKER any canonical-write bypass (cf. fn_auto_approve_add) Phase-1 + fix
Điều 39 live implementation Enacted, ~unimplemented KG rollout staged rollout (Owner-gated)
Điều 39 36-DOT / 14-table / self-learning rollout Designed, big-bang conflicts with staged model Điều 39 compatibility note
DOT-KG registration-vs-execution ambiguity PATCHED / CARRIED prevents treating registered DOT-KG as live/executed KG Phase-1 / Law Merge / Điều 39 compatibility note
Old gov automation production-readiness "PRODUCTION READINESS FAIL" + authority bypass reuse of live loop Phase-1 verify + fix
One-Roof coverage-scanner family Design-only, ABSENT governance coverage scanning Q3 add-later, list-only
Nhóm R (AP/IDX/STL/GC/CELL/RUN/CRASH/CAP/TIME) Open survey-gates operational safety Phase-1
runtime / checkout sync Unproven source currency Nhóm S / Phase-1

§12 — Adversarial check result

All 14 adversarial bad-assumptions from packet §10 were REJECTED → FX execution is not fail-open:

  1. "Cross-F Matrix already covers FX" → Rejected (FX is a separate dedicated survey; matrix only flags readiness). 2. "PASS = authorization" → Rejected. 3. "Old gov automation is live+authoritative, reuse directly" → Rejected (source-pinned, role-classified, caveats carried; live only where proven, with PROD-FAIL + bypass attached). 4. "Điều 39 enacted ⇒ implemented" → Rejected (runtime empty). 5. "Register all 36 DOT-KG now" → Rejected (stage). 6. "Build governance registry / relationship DB / graph engine" → Rejected (reuse edges/role/owner). 7. "Scanner should auto-fix" → Rejected (list-only). 8. "Add second birth / governance in birth P0" → Rejected (promote-boundary, minimal birth). 9. "Self-learning updates canonical/TBox" → Rejected (TBox human-only; AI proposes). 10. "Scanner is source of truth" → Rejected (reports gaps only). 11. "Rewrite/amend Điều 39" → Rejected (compatibility note only). 12. "Resolve CONS/CELL to unblock FX" → Rejected (carried). 13. "Create kg_*/universal_edges/entity_relations tables" → Rejected (no schema). 14. "FX prepares the technical design" → Rejected (post-FX, Owner-gated).

§13 — Non-authorization confirmation

  • No Phase-1: none run.
  • No DB / runtime / production: no live query; no fn_* call.
  • No KG implementation: no extraction/classification/linking/validation/self-learning/conversational-acquisition/scaffold/priority/compliance run.
  • No universal_edges / entity_relations / kg_* table creation.
  • No 36 DOT-KG registration.
  • No governance registry / relationship DB / graph engine / One-Roof system.
  • No scanner auto-fix; no scanner/checker/heartbeat run.
  • No second birth system; no governance in birth P0.
  • No canonical birth / BIRTH_STAMP / PROMOTE_STAMP / PROMOTE_BLOCKED write.
  • No CONS-002/003 / CELL- resolution.*
  • No Điều 39 rewrite / amendment / re-enactment.
  • No technical design; no decision note; no implementation prompt; no dashboard.
  • Only KB documents were read and three KB report/packet documents (this report, the F5 decision record, the FX packet) were created. Owner / GPT remain the only phase authority. Codex PASS ≠ Owner authorization.

§14 — Post-FX next-gate recommendation

Direct answers to the 6 FX questions:

  1. What old Governance automation can be reused? The enacted DOT Repair Governance / Điều 35 v5.2 loop (scan→propose→approve→apply→verify, paired A/B DOTs, APR/quorum, fail-closed) as a proven pattern, and the One-Roof Governance design corpus as a blueprint. Reuse the patterns and design, not a turnkey running system.
  2. What must be verified/reclassified before reuse? The Cluster-1 live substrate's "PRODUCTION READINESS FAIL" + "confirmed authority bypass" (fn_auto_approve_add, 160 unvoted applies) must be Phase-1-verified and the bypass closed (RISK-BYPASS-001/002/004); the Cluster-2 coverage-scanner family is ABSENT/design-only; Điều 39's kg_* / universal_edges / entity_relations liveness and the 36-DOT / self-learning status must be Phase-1-verified, not assumed.
  3. What truly needs to be added? Only, and only when need is proven + Owner-gated: a list-only governance coverage scanner/report, a DOT_RELATION_<name> per genuinely-missing relation type, and a staged Điều 39 delivery — never a monster registry / monster KG / second birth.
  4. How does Điều 39 combine with F0→F5? Its goals and governance discipline are directly compatible (TBox/ABox = Mức-3/Đ32; AI-proposes-human-approves = fail-closed/escalate; provenance/quarantine = stamp/scanner; narrow DOTs = "một việc hẹp"). Its big-bang rollout assumptions are not — they must be staged through F0→F5 + FX + Phase-1 + technical design.
  5. Does Điều 39 need an amendment / reinterpretation note? Yes — a future "Điều 39 Compatibility / Reinterpretation Note" is recommended (preserve goals, change rollout sequencing to F0→F5 + staged Lego/DOT/stamp). FX does not write or rewrite it; it recommends Owner authorize one. Điều 39 text stays enacted and unchanged.
  6. How do we preserve data self-enrichment without returning to monster governance / monster KG? Via bounded enrichment (§7): event → DOT/re-run → relation/stamp/provenance; scanner → gap report (never auto-fix, never canonical); Owner/Agent → authorize a light DOT/rule/relation expansion only when existing metadata cannot hold the fact; KG self-learning may touch ABox weights only, never TBox/canonical.

Next gate:

  • GPT reviews the F5 decision record + FX packet + this FX report.
  • Codex reviews them together (control verdict only).
  • If accepted, Owner decides the post-survey route: A. Điều 39 compatibility / amendment note (preserve goals, change rollout); B. blocker decision notes (CONS-002/003, CELL-*); C. Phase-1 read-only substrate/runtime survey (verify old-automation live-status + close the authority bypass + check kg_*/universal_edges liveness); D. technical-design preparation; E. implementation planning later.
  • Default HOLD. Every candidate future, Owner-gated, default-NO. Codex PASS ≠ Owner phase-authorization.
Back to Knowledge Hub knowledge/dev/laws-new/reports/fx/fx-governance-one-roof-dieu39-compatibility-execution-report-2026-06-16.md