FX — GOVERNANCE ONE ROOF / OWNER / AUTHORITY GATES + ĐIỀU 39 KNOWLEDGE GRAPH COMPATIBILITY — REUSE SURVEY PACKET

Date: 2026-06-16 · Revision: rev1 · Layer: FX (framework rev56 §6c — D2, cross-cutting, NOT F6) · Prepares: FX read-only documentary execution report.

STATUS: PREPARATION PACKET — NON-AUTHORIZING. This is a read-only program package that prepares the FX (Governance One Roof) survey and its mandatory Điều 39 (Knowledge Graph Law v2.3) compatibility audit. It is not an FX execution authorization on its own (the FX read-only execution runs only if the internal safety gate in §11 passes), not a Phase-1 survey, not an implementation authorization, not an amendment to Điều 39. It performs no live DB / runtime / production query; touches no iu_staging_* / dot_tools / birth_registry / system_issues / event_outbox / universal_edges / entity_relations / kg_* live; calls no birth/checker/promote/scanner/heartbeat/governance/KG function; creates no schema/table/registry/index, no relationship DB, no governance graph engine, no governance registry, no Knowledge Graph registry, no Governance One Roof system, no scanner auto-fix, no second birth system; registers no 36 DOT-KG; runs no DOT/formula/assembly/checker/scanner/heartbeat/KG-extraction/self-learning/conversational-acquisition/scaffold-build/priority-decomposition/compliance-gate/promote; writes no canonical birth / BIRTH_STAMP / PROMOTE_STAMP / PROMOTE_BLOCKED state; creates no dashboard; resolves no CONS-002/003 / CELL-003/004/007; rewrites no Điều 39. It is structured around the same 3 reuse-first Owner questions as F0/F1/F2/F3/F4/F5 and is intended for GPT → Codex → Owner review. Documentary ≠ live proof · Engineering PASS ≠ Authority PASS · Codex/GPT/Claude PASS ≠ Owner authorization.

FX is the framework's D2 — Governance One Roof / Owner / Authority Gates · [CROSS-CUTTING FOUNDATION]: "Governance = thông tin/state/quan hệ trên sổ hiện có dưới một mái khái niệm (One Roof), không monster system riêng; Owner / authority gates; Mức 3 / canonical / production locks; Codex/GPT/Claude PASS ≠ Owner authorization." FX is cross-cutting, áp xuyên suốt F0–F5 — KHÔNG tầng build riêng, KHÔNG system mới.

§2 — Owner View — 3 câu hỏi reuse-first

Q1 — Cái gì đang có và dùng lại được? (likely reusable, on paper)

F0→F5 accepted evidence lineage — the full documentary spine + decision records + execution reports + Cross-F Matrix.
CONS-004 authority order (working precedence: KB practical-authority for laws-new docs · constitution-or-higher for enacted · VPS=SSOT code/runtime · PG/Directus=truth · cross-class=Owner gate).
Owner / GPT phase-gate pattern and the Codex control-verdict pattern.
Documentary-vs-live proof rule and Engineering PASS vs Authority PASS rule.
F0→F5 non-authorization pattern (read-only, default-NO, Owner-gated).
Governance as relationship / state / classification information (de-bai §IV: "Governance = bản đồ quan hệ và trạng thái quản lý của object trong hệ"), carried by DOT / stamp / checker / scanner roles.
Điều 39 enacted goals (KG reliable enough for AI decisions; EKGF/Zaveri/HTN/PKG/RLKGF; PG16+Qdrant).
Điều 39 provenance / trust / source_authority model (trust_score = confidence × freshness_decay × provenance_weight × source_authority; "Source_authority: quy định (Đ38) > báo cáo > chat").
Điều 39 TBox / ABox boundary (TBox = human approves; ABox = AI does).
Điều 39 "AI proposes, human approves canonical knowledge" rule ("AI ĐƯỢC ĐỀ XUẤT, KHÔNG ĐƯỢC TỰ BAN HÀNH TRI THỨC CHUẨN").
Điều 39 Data→Graph→KG→Priority→AI chain as long-term direction (the 5-tier value chain).
Old automatic-Governance work, if evidence is found (see §6/§8 — the DOT Repair Governance / Điều 35 lineage + One-Roof design corpus).
Existing coverage / scanner / report / warning-table assets, if evidence is found.
Governance One Roof as a cross-cutting review, not F6.

Q2 — Cái gì đang có nhưng cần sửa/kiểm chứng mới dùng lại được? (repair/verify before reuse)

Old Governance automation evidence must be source-pinned (path + revision + status) before any reuse.
Old automation must be classified by role: scanner/report/coverage vs authority/Owner-gate vs runtime substrate vs registry/schema vs implementation artifact vs documentary-only.
Old automation must not be assumed live unless proven; where a live-claim exists, the production-readiness and authority-bypass caveats attached to it must travel with it.
Điều 39 is enacted but essentially NOT implemented live on the current system (runtime empty; 0 DOT executions / 0 KG events; KG owner unregistered).
Điều 39 implementation assumptions must be reconciled with F0→F5 (Lego/DOT/stamp/checker/scanner model; staged, not big-bang).
36 DOT / 18 KG pairs are too heavy for immediate rollout unless staged.
universal_edges / entity_relations / kg_* tables must not be assumed ready/live unless proven.
KG self-learning / conversational / discovery must not be treated as current implementation.
Risk of central governance registry / monster system; risk of monster Knowledge Graph rollout; risk of scanner auto-fix; risk of second birth / governance birth layer; risk of stuffing governance into birth P0; risk of graph / relationship DB overbuild.
Runtime / checkout sync not proven; Owner / authority conflicts (CONS-004 order) still working-precedence, not enacted.
Relation enrichment must be bounded by DOT / stamp / provenance (not a free-running graph mutator).

Q3 — Cái gì thật sự phải làm thêm? (add later only if needed — future, Owner-gated, default-NO)

Điều 39 compatibility / amendment note after FX, if evidence supports it (preserve goals, change rollout) — recommendation only, never a rewrite.
Decision notes for CONS-002 / CONS-003 / CELL-003/004/007 — Owner decisions, not done by FX.
Phase-1 read-only substrate / runtime survey (the one place old-automation live-status and kg_*/universal_edges liveness can actually be verified).
Technical-design preparation only after FX.
Staged Điều 39 rollout only after Owner gate (one KG fact-type at a time via Lego/DOT/stamp).
DOT for a new relation type, only when need is proven (DOT_RELATION_<name>, Owner-gated, future only).
Governance coverage scanner / report — list-only, no auto-fix (a warning table, never a whole-system fixer).
Any registry / table / schema only after reuse-insufficiency proof + Owner gate.
Implementation later, never from FX survey.

§3 — FX scope and non-scope

In scope (read-only, documentary):

Classify the F0→F5 accepted evidence lineage and the governance/authority/Owner/Mức-3/production-lock concepts as a single conceptual roof over existing ledgers.
Search, source-pin, and classify the old automatic-Governance work (built + repaired-3rd-revision claim) for reuse / repair / add-later.
Classify dot_governance / governance-coverage / scanner candidates if evidence is found.
Classify governance reports / warning tables / coverage scans if found.
Map how governance information rides on existing substrate (governance_role, governance_audit_log, universal_edges, system_issues, owner/scope, required-stamp evidence) under one roof — without building anything.
Assess data self-enrichment over time in a bounded form (event → DOT/re-run → relation/stamp/provenance; scanner → missing/stale/orphan report; Owner/Agent → authorize DOT/rule expansion).

Out of scope (forbidden — see §10):

Building any Governance One Roof system, registry, relationship DB, graph engine, scanner, scanner auto-fix, checker, second birth layer.
Putting governance into birth P0.
Any live DB / runtime / Phase-1 / production query.
Resolving CONS-002/003 / CELL-*; writing technical design / decision note / implementation prompt.

§4 — Điều 39 compatibility scope and non-scope

In scope (read-only, documentary):

Read enacted Điều 39 (Knowledge Graph Law v2.3) directly and classify: goals (Q1), implementation assumptions (Q2/Q3), live status (Q2 — essentially not implemented).
Map the Data→Graph→KG→Priority→AI chain, TBox/ABox boundary, AI-proposes-human-approves rule, provenance/trust/source_authority model, 36 DOT / 18 pairs, self-learning / conversational acquisition / bottom-up discovery, and runtime/config tables as concepts.
Determine how Điều 39 combines with the F0→F5 model (where its goals map onto Lego/DOT/stamp/checker/scanner; where its rollout assumptions conflict).
Recommend whether a future "Điều 39 Compatibility / Amendment Note" is needed — preserve goals, change rollout sequencing — as a recommendation only.

Out of scope (forbidden):

Rewriting / amending / re-enacting Điều 39.
Implementing any KG mechanism: extraction / classification / linking / validation / self-learning / conversational acquisition / scaffold build / priority decomposition / compliance gate.
Creating universal_edges / entity_relations / kg_* tables; registering the 36 DOT-KG; treating the enacted law as live implementation.

§5 — Reuse-now inventory template (Q1 detail)

For each candidate, the FX execution report fills: Asset · KB source pin (path/rev) · Currency · Classification · Why reusable now · What it is NOT.

Asset (Q1)	KB source pin	Reuse-now claim	NOT
F0→F5 evidence lineage	`reports/f0..f5/*` + Cross-F Matrix	reusable paper contract	not a running system
CONS-004 authority order	F0 decision record	working precedence for laws-new	not enacted; cross-class = Owner gate
Governance-as-relationship model	de-bai §IV	the FX mental model	not a new machine
DOT/stamp/checker/scanner roles	de-bai §IV/§VI, F3/F4/F5	governance carriers	not approval workflows
Điều 39 goals	`dieu39-knowledge-graph-law.md` §0	long-term direction (required)	not live implementation
Điều 39 provenance/trust model	Điều 39 §0 "Evidence/Trust"	reusable provenance discipline	thresholds/tables not live
Điều 39 TBox/ABox + golden rule	Điều 39 §0/§7B	human-over-AI canonical rule	not an authorization to auto-enact
Old DOT-governance / repair loop	(to be source-pinned in §8)	reusable enacted loop if proven	live-status + bypass caveats apply
Old One-Roof design corpus	(to be source-pinned in §8)	reusable design blueprint	design-only; not built
existing scanner/coverage assets	(to be source-pinned)	reusable if proven	absent/design-only unless proven

§6 — Repair / verify-before-reuse inventory template (Q2 detail)

For each, the report fills: Asset · what is documentary vs claimed-live · what must be verified · Phase-1/Owner gate.

Asset (Q2)	Documentary vs live	Must verify before reuse
Old Governance automation	source-pin status	Phase-1 live check of `dot_tools` / `governance_*` rows; production-readiness + authority-bypass caveats
Điều 39 live status	enacted law, runtime empty	confirm 0-execution / unregistered-owner via Phase-1 (not FX)
36 DOT / 18 KG pairs	designed as one block	stage; do not register all 36 at once
`universal_edges` / `entity_relations` / `kg_*`	named in law, liveness unproven	Phase-1 liveness; no assumption
KG self-learning / conversational / discovery	designed (C9/C10/Process G)	not current; bound by guardrails before any reuse
runtime / checkout sync	unproven	source-currency gate (Nhóm S)
relation enrichment	concept	bound by DOT/stamp/provenance; no free graph mutation

§7 — Add-later-only-if-needed template (Q3 detail)

For each, the report fills: Candidate · trigger (need-proven) · Owner gate · default.

Candidate (Q3)	Trigger (need-proven)	Default
Điều 39 Compatibility / Amendment Note	FX shows rollout conflict but goals stay	recommend only; default-NO rewrite
CONS-002/003 + CELL-* decision notes	Owner chooses to resolve	Owner-only; default-HOLD
Phase-1 read-only substrate/runtime survey	Owner authorizes	default-NO
Technical-design preparation	after FX + Owner	default-NO
Staged Điều 39 rollout	Owner gate; one fact-type at a time	default-NO
`DOT_RELATION_<name>` for new relation	existing metadata cannot hold the fact	Owner-gated; default-NO
Governance coverage scanner/report	list-only need proven	no auto-fix; default-NO
New registry/table/schema	reuse-insufficiency proof + Owner gate	default-NO
Implementation	never from FX	default-NO

§8 — FX + Điều 39 evidence obligations

The FX execution report must, for each claim:

Source-pin every old-Governance-automation artifact (path + revision + content_length where available) and quote the exact wording that establishes LIVE vs design-only vs documentary status. If absent, classify as Q2 — source recovery / evidence search needed and do not infer it.
Classify old automation by role (scanner/report/coverage · authority/Owner-gate · runtime substrate · registry/schema · implementation artifact · documentary-only) and by the "sửa lần 3 / third-revision" lineage if found.
Carry caveats with claims — any "production-readiness FAIL" or "confirmed authority bypass" finding attached to a live asset must travel with that asset and never be dropped.
Read Điều 39 directly and classify goals (Q1) vs implementation assumptions (Q2/Q3) vs live status (Q2), with verbatim quotes for the chain / TBox-ABox / golden rule / provenance / 36-DOT / self-learning / runtime tables. Separate DOT-KG registration evidence from execution evidence: registration/spec (e.g. S161-P2 current-state/reports/s161-p2-kg-dot-registration-report 36/36 registered; S161-P2-Fix …/s161-p2-fix-report trigger-config) is documentary registry evidence only and does not prove execution / live rollout / production-readiness (2026-06-04 KG evidence: last_executed NULL / 0 runs / 0 KG events) — registered ≠ executed ≠ live ≠ production-ready.
Record conflicts, not resolve them — wherever Điều 39 assumes a big-bang / monster rollout that conflicts with the Lego/DOT/stamp model, record the conflict and prefer a reinterpretation / staged-rollout recommendation.
Keep Engineering PASS ≠ Authority PASS and PASS ≠ Owner authorization explicit.

§9 — Known risks / stop conditions

Risks FX must name (Q2):

Monster governance registry / central governance system.
Monster Knowledge Graph rollout (36 DOT + 14 config tables + 24/7 self-learning as one block).
Scanner auto-fix (must stay list-only).
Second birth system / governance birth layer.
Governance stuffed into birth P0.
Central relationship DB / graph engine overbuild.
Treating enacted Điều 39 as live implementation.
Treating old automatic-Governance as live/authoritative without proof.
Self-learning altering TBox / canonical knowledge.
Scanner becoming the canonical source of truth.

Stop conditions (report BLOCKED) if FX execution would require: live DB/runtime/Phase-1; building scanner/governance-automation/KG; central registry/relationship DB/schema; technical design or decision note; resolving CONS-002/003/CELL-*; or rewriting Điều 39. If the F5 patched Cross-F Matrix, Điều 39 enacted law, framework rev56, de-bai (Governance One Roof boundary), or catalog (governance/authority/risk rows) cannot be read, report BLOCKED.

§10 — Bad-input / adversarial checks (the FX execution must reject all)

"Cross-F Matrix already covers FX, so FX is done." → Reject — the matrix only flags FX readiness; FX is a separate, dedicated survey.
"PASS / ANSWERED / Codex-PASS = authorization." → Reject — PASS ≠ Owner authorization.
"Old Governance automation is live and authoritative, reuse it directly." → Reject — source-pin + classify + carry caveats; live only if proven.
"Điều 39 is enacted, therefore implemented — wire it in." → Reject — enacted ≠ implemented; runtime empty.
"Register all 36 DOT-KG now." → Reject — too heavy; stage; Owner-gated.
"Build a governance registry / relationship DB / graph engine to hold governance." → Reject — reuse existing edges/role/owner; no new machine.
"Make the scanner fix what it finds." → Reject — list-only, no auto-fix.
"Add a second/birth governance layer / put governance in birth P0." → Reject — birth stays minimal; governance evidence at promote (D9/D10).
"Let KG self-learning update canonical/TBox automatically." → Reject — TBox = human-approved; AI proposes only.
"Scanner is the source of truth for governance state." → Reject — scanner reports gaps; it is not canonical.
"Rewrite / amend Điều 39 to fit F0→F5." → Reject — recommend a compatibility note only; do not rewrite.
"Resolve CONS-002/003 / CELL-* to unblock FX." → Reject — carried, not resolved.
"Create the kg_* / universal_edges / entity_relations tables to be ready." → Reject — no schema; Phase-1/Owner only.
"FX can prepare the technical design." → Reject — technical design is post-FX, Owner-gated.

§11 — Internal gate: when to proceed from packet to FX execution

The FX read-only execution (Document 3) is created only if all gate items are GREEN. Any RED → STOP at PARTIAL/BLOCKED and Document 3 is not created.

Gate item	Pass condition
G1 Sources readable	F5 decision record (this macro) + F5 bundle + Cross-F Matrix + F0→F4 records/reports + framework rev56 (§6c D2) + de-bai rev33 (§IV/§VI) + catalog rev82 (Nhóm B GOV-, Nhóm R, GOV-REUSE-) + constitution rev44 + operating-rules + required-stamps rev6 + checker rev11 + addendum rev14 + Điều 39 enacted law + KG supporting evidence all readable.
G2 F5 gate closed first	`reports/f5/f5-owner-decision-record-2026-06-16.md` (rev1) exists and closes F5, unlocking FX-macro-only.
G3 Every asset classifiable honestly	Each FX/Điều 39 asset maps to a KB pin without inventing live proof; old automation classified by role + live-status; Điều 39 goals=Q1, implementation=Q2/Q3, live-status=Q2; absent evidence = Q2 source-recovery, not inferred.
G4 No live DB/runtime/Phase-1 needed	No `iu_staging_` / `dot_tools` / `birth_registry` / `system_issues` / `event_outbox` / `universal_edges` / `entity_relations` / `kg_` live touch; no `fn_*` call.
G5 No conflict resolution needed	CONS-002/003, CELL-*, HOLD-1/2, Nhóm R carried; Điều 39 conflicts recorded, not resolved.
G6 No schema/design/implementation needed	No registry/table/relationship-DB/graph-engine/scanner/second-birth; no technical design / decision note / implementation prompt; no Điều 39 rewrite.
G7 Boundary held	Governance = info/state/relationship under one conceptual roof; scanner list-only; no auto-fix; no monster KG; no governance-in-birth-P0; Điều 39 read as compatibility source, not live.
G8 3 Owner questions preserved	Q1/Q2/Q3 present in the FX execution report.

Gate rule: All GREEN → run the read-only FX survey (Document 3). Any RED → STOP.

§12 — Expected FX execution report format

Document 3 (reports/fx/fx-governance-one-roof-dieu39-compatibility-execution-report-2026-06-16.md) must contain:

Status / boundary confirmation (+ internal gate G1–G8 result).
Owner 3-question answer (Q1/Q2/Q3).
FX asset classification table.
Old Governance automation reuse analysis (source-pinned, role-classified, caveats carried).
Điều 39 compatibility analysis (goals vs implementation vs live status; chain / TBox-ABox / golden rule / provenance / 36-DOT / self-learning / runtime tables).
New DOT/stamp governance model analysis.
Data self-enrichment / living-data balance analysis (allowed vs forbidden roles).
Monster-governance / monster-KG / second-birth risk analysis.
Authority / Owner gate / Mức-3 analysis.
Evidence-currency table.
Conflict / HOLD log.
Adversarial check result (all 14 rejected).
Non-authorization confirmation.
Post-FX next-gate recommendation.

It must directly answer: (1) What old Governance automation can be reused? (2) What must be verified/reclassified before reuse? (3) What truly needs to be added? (4) How does Điều 39 combine with F0→F5? (5) Does Điều 39 need an amendment / reinterpretation note (preserve goals, change rollout)? (6) How do we preserve data self-enrichment without returning to old monster governance / monster KG?

§13 — How FX feeds the post-survey decision / Phase-1 / blocker notes / technical design

FX → GPT → Codex → Owner. FX does not decide; it surveys.
After acceptance, Owner chooses among: 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 (the only place old-automation live-status, kg_*/universal_edges liveness, and the production-readiness/authority-bypass caveats can be verified); D. technical-design preparation; E. implementation planning later.
Technical design is not authorized before FX is accepted by Owner. Every downstream candidate stays future, Owner-gated, default-NO.

Self-check (packet discipline)

3 Owner questions present? — Yes (§2).
FX kept cross-cutting (D2), not F6? — Yes (§1, §3).
Điều 39 set as mandatory compatibility source, read-only, not live? — Yes (§4).
Old Governance automation set to be source-pinned + role-classified + caveats-carried, not assumed live? — Yes (§6, §8).
Scanner kept list-only, no auto-fix? — Yes (§9, §10).
No monster governance registry / monster KG / second birth / relationship-DB overbuild? — Yes (§9, §10).
Data self-enrichment framed as bounded (event→DOT→stamp/provenance; scanner→report; Owner→authorize)? — Yes (§2 Q3, §12 item 7).
No technical design / decision note / implementation / Điều 39 rewrite? — Yes (§9, §10).
Owner/GPT kept as the only phase authority? — Yes (§13).
Internal gate defined with a clear STOP rule? — Yes (§11).

FX — Governance One Roof + Điều 39 Knowledge Graph Compatibility Reuse Survey Packet (2026-06-16)