Incomex AI Portal
KB-1E71

Kế hoạch PG-native hoá Hiến pháp + Kho luật + KB làm việc chung người/AI

12 min read Revision 1
planpg-nativeconstitutionlawsknowledge-basesuper-sessiondieu38dieu392026-04-23

Kế hoạch PG-native hoá Hiến pháp + Kho luật + KB làm việc chung người/AI

  • Ngày: 2026-04-23
  • Agent: Incomex Hội đồng AI / GPT
  • Mục tiêu: chuyển cách quản lý tri thức pháp quy từ file text/document-centric sang PG-first, PG-native, PG-driven; đồng thời tách runtime nóng của hội đồng/agent khỏi lớp archive/vector.

1. Kết luận chiến lược

Hướng đúng KHÔNG phải là “đưa nguyên file markdown vào PG”.

Hướng đúng là tách thành 3 lớp:

  1. Lớp runtime chuẩn hoá trên PG: văn bản/điều/khoản/đoạn/binding/quan hệ/revision/comment/session.
  2. Lớp trình bày: Directus + Nuxt để duyệt, sửa, review, pivot, treeview.
  3. Lớp tìm kiếm dài hạn: Agent Data/Qdrant cập nhật bất đồng bộ chậm 1-2 phút, không nằm trên hot path ghi/sửa.

2. Căn cứ luật

  • Hiến pháp v4.6.3: NT1, NT2, NT4, NT9, NT10, NT11, NT12, NT13, NT14.
  • Điều 33 §0, §13, §15: PG là nền tảng; có ngoại lệ hợp pháp cho Agent Data; CI/deploy phải qua DOT hợp pháp.
  • Điều 32: mọi thay đổi có ảnh hưởng hệ thống phải đi qua approval/quorum rõ ràng.
  • Điều 35: DOT phải có domain, cặp kiểm tra, audit, không hardcode.
  • Điều 37: phải có cơ quan chủ quản, thẩm quyền TBox/ABox rõ ràng.
  • Điều 38 MT1-MT3: SQL hoá văn bản bằng đoạn có cấu trúc, binding PG, version, lifecycle.
  • Điều 39 §0, §5, §6, §7C, §8: Data → Graph → KG; output Đ38 là scaffold cho KG; config-driven; temporal/provenance/authority.

3. Phán đoán chính

3.1. Gốc của vấn đề hiện tại

  • KB hiện tại đang phù hợp cho archive/report/handoff, nhưng không phù hợp cho chỉnh sửa nóng, viện dẫn dày, và đồng biên tập nhiều agent.
  • Chậm không phải vì PG kém, mà vì đang dùng document/blob path cho bài toán cần record graph path.
  • File lớn khiến MCP/agent vừa chậm vừa tăng xác suất sửa nhầm.

3.2. Mâu thuẫn pháp lý cần xử lý trước

Hiện có lệch trạng thái của Điều 38:

  • Hiến pháp đang coi Đ38 là enacted.
  • File dieu38-normative-document-law.md hiện là v3.0 DRAFT, viết lại từ v2.3.

Không được triển khai lớn khi chưa chốt lại:

  • bản enacted hiện hành của Đ38 là gì,
  • v3.0 là draft thay thế hay chỉ là đề xuất cải biên.

4. Mục tiêu hệ thống mới

  1. Mỗi luật/hiến pháp/quy định được quản lý như thực thể có cấu trúc, không phải blob text.
  2. Mỗi đơn vị nhỏ (điều/khoản/điểm/đoạn/annotation/binding) sửa độc lập, version độc lập, audit độc lập.
  3. Liên kết viện dẫn, phụ thuộc, supersede, mâu thuẫn, binding, provenance đều nằm trong PG.
  4. Treeview/pivot/trace/explain/query là khả năng mặc định từ PG.
  5. Session nóng của hội đồng/agent ghi cực nhanh trên PG; vector sync chậm phía sau.
  6. Nuxt chỉ là lớp hiển thị/duyệt/sửa; không giữ logic cứng.
  7. Đ38 và Đ39 không còn là ý tưởng trên giấy mà trở thành runtime thật.

5. Kiến trúc đích

5.1. Lớp A — Normative Core (PG SSOT)

Các bảng lõi đề xuất:

  • nrm_documents: 1 văn bản gốc (hiến pháp, luật, phụ lục, quy định, chính sách)
  • nrm_revisions: mỗi lần ban hành/sửa đổi là 1 revision bất biến
  • nrm_sections: cây văn bản (phần/chương/mục/điều/khoản/điểm/đoạn)
  • nrm_section_atoms: đơn vị nhỏ nhất để AI/agent sửa nhanh
  • nrm_bindings: liên kết đoạn ↔ PG/table/field/query/template/config
  • nrm_references: viện dẫn/hyperlink giữa section ↔ section
  • nrm_effectivity: hiệu lực, supersede, retire, as_of_date
  • nrm_annotations: semantic annotation cho DOT/KG đọc
  • nrm_change_sets: nhóm thay đổi đang soạn
  • nrm_render_views: dữ liệu render lại thành văn bản hoàn chỉnh

5.2. Lớp B — Knowledge Graph Overlay

  • entity_relations / universal_edges / KG config tables theo Đ39
  • mỗi section/atom/binding là node hoặc nguồn cho node/edge
  • Đ38 output sinh scaffold graph theo Đ39 C1
  • reference/binding/provenance/authority/temporal trở thành edge có trọng số

5.3. Lớp C — Super Session Runtime

  • super_sessions
  • super_session_participants
  • super_session_messages
  • super_session_checkpoints
  • super_session_links
  • super_session_summaries

Session nóng chỉ lưu log/decision/checkpoint. Kết luận chưng cất mới đẩy sang KB archive.

5.4. Lớp D — Archive + Vector

  • KB document tiếp tục dùng cho report/handoff/biên bản/final snapshot
  • vector/Qdrant cập nhật bất đồng bộ sau 1-2 phút
  • không vectorize every hot write

6. Nguyên tắc thiết kế bắt buộc

  1. Không nhập cả file thành 1 row text lớn.
  2. 1 thay đổi nhỏ = 1 atom/1 revision nhỏ, không rewrite toàn file.
  3. Render là đầu ra, không phải SSOT.
  4. Reference và binding là first-class data, không viết tay trong text rồi để agent tự đoán.
  5. Số sống trong luật phải tách loại:
    • số pháp lý cố định → lưu literal có audit,
    • số thực tế phụ thuộc hệ thống → lưu binding/query/config để PG đọc runtime.
  6. Hot path và cold path tách riêng.
  7. Không để Qdrant/MCP document path chặn thao tác ghi nóng.
  8. Mọi hành vi runtime phải config-driven trong PG.

7. Cách mô hình hoá luật để sửa nhanh và thông minh

7.1. Một văn bản không còn là 1 file

Một văn bản sẽ gồm:

  • metadata văn bản,
  • revision,
  • cây section,
  • atom nội dung,
  • reference,
  • binding,
  • annotation,
  • render template.

7.2. Mỗi atom có 3 lớp nội dung

  • human_text: phần user đọc
  • machine_semantics: loại quy tắc, đối tượng áp dụng, hành động, điều kiện, ngưỡng
  • binding/provenance: lấy dữ liệu ở đâu, authority nào, hiệu lực khi nào

7.3. Phân biệt 3 kiểu con số

  • Literal norm: ví dụ “quorum = 2 AI council”
  • Bound runtime value: ví dụ “số nhóm hiện hành lấy từ bảng X/query Y”
  • Derived display value: số chỉ để render dashboard, không có hiệu lực quy phạm

Điểm này giúp tránh bệnh “10 nhóm hôm nay, mai thành 11 nhóm là luật lạc hậu”.

Không dùng text regex là chính. Phải có bảng quan hệ rõ:

  • source_section_id
  • target_section_id
  • reference_type (cites, amends, supersedes, depends_on, contradicts, implements, explains)
  • strength
  • is_hard_requirement
  • as_of_revision

Từ đây AI/agent đọc nhanh hơn, đúng hơn, và Nuxt render hyperlink/native treeview tự nhiên.

9. Cơ chế session nóng cho hội đồng/agent

9.1. Mục tiêu

  • append message nhanh
  • đọc delta nhanh
  • comment theo tab/phạm vi
  • checkpoint/decision không lẫn vào text dài

9.2. Quy tắc

  • message log append-only
  • summary async
  • KB chỉ nhận output chưng cất
  • vector sync chậm 1-2 phút

9.3. Liên kết với luật

Mỗi session có thể link tới:

  • document/revision/section/atom,
  • APR,
  • issue,
  • patch,
  • report.

Như vậy session trở thành công cụ làm luật và review luật chuẩn PG-native.

10. Nuxt/Directus nên làm gì

Directus

  • quản lý CRUD collections lõi
  • filter/sort/search/pivot
  • flow phê duyệt / publish / retire / re-render
  • permission theo vai trò Đ37

Nuxt

  • treeview văn bản nhiều tầng
  • panel chi tiết atom/binding/reference/history
  • diff revision
  • graph/trace view
  • session room / comment room
  • view “rendered document” cho user đọc như văn bản hoàn chỉnh

Nuxt không giữ logic luật. Mọi logic nằm ở PG/DOT/config.

11. Kế hoạch thực hiện

Giai đoạn 0 — Chốt pháp lý và SSOT (bắt buộc trước)

  1. Chốt tình trạng Đ38: enacted nào là hiệu lực hiện tại, v3.0 draft đứng ở đâu.
  2. Chốt vocabulary chuẩn cho văn bản: document / revision / section / atom / binding / annotation / reference.
  3. Chốt cơ quan chủ quản theo Đ37: ai duyệt TBox, ai duyệt ABox, ai duyệt publish.
  4. Chốt ranh giới KB archive vs PG runtime.

Đầu ra: 1 quyết nghị kiến trúc ngắn + 1 law amendment/clarification nếu cần.

Giai đoạn 1 — Xây Normative Core tối thiểu

  1. Tạo schema/collections lõi cho nrm_documents, nrm_revisions, nrm_sections, nrm_references, nrm_bindings.
  2. Tạo trigger/version guard theo tinh thần Đ38 + Đ32.
  3. Tạo render pipeline: từ sections → văn bản hoàn chỉnh.
  4. Tạo query treeview/pivot cơ bản.

Đầu ra: nhập được 1 văn bản lớn vào cấu trúc mới và render lại gần đúng 100%.

Giai đoạn 2 — Di trú thí điểm 9 hệ thống luật hiện tại

  1. Chọn 3 mẫu đầu tiên:
    • Hiến pháp
    • 1 luật nền ngắn (Đ32 hoặc Đ33)
    • 1 luật nặng liên kết (Đ39 hoặc Đ43)
  2. Tách mỗi luật thành section/atom/reference/binding.
  3. So khớp render với file gốc.
  4. Kiểm tra edit 1 atom và render lại.

Đầu ra: chứng minh “sửa atom nhỏ nhanh hơn và ít sai hơn rewrite file”.

  1. Bổ sung nrm_annotations.
  2. Biến viện dẫn và binding thành edge/query thật.
  3. Tách số chết thành literal/bound/derived.
  4. Tạo audit phát hiện atom nào còn số chết đáng lẽ phải bound.

Đầu ra: luật bắt đầu “sống”, query được, giải thích được, trace được.

Giai đoạn 4 — Super Session PG-native

  1. Tạo session runtime tables.
  2. Tạo MCP actions riêng cho session runtime.
  3. Dùng session room để review/chỉnh luật mới.
  4. Async summary → archive KB.

Đầu ra: hội đồng làm việc nóng trên PG, không còn dùng blob document cho chat.

Giai đoạn 5 — Đồng bộ Đ39 và Qdrant bất đồng bộ

  1. Đ38 output phát scaffold/annotation cho KG.
  2. Job async 1-2 phút đẩy summary/semantic chunks sang vector.
  3. KG đọc từ PG trước, vector hỗ trợ recall sau.

Đầu ra: đúng tinh thần PG First, vector không chặn tương tác.

Giai đoạn 6 — Nuxt law workbench

  1. Treeview nhiều tầng
  2. atom editor
  3. diff view
  4. binding inspector
  5. reference graph
  6. session side panel

Đầu ra: chỗ làm việc chung người/AI hoàn chỉnh.

12. Thứ tự ưu tiên đúng

Ưu tiên 1: Normative Core tối thiểu + nhập thử Hiến pháp.

Ưu tiên 2: session runtime nóng.

Ưu tiên 3: semantic annotation + KG overlay.

Không nên làm ngược. Nếu chưa có lõi dữ liệu chuẩn mà đã làm graph/view phức tạp thì sẽ lặp lại bệnh cũ ở quy mô lớn hơn.

13. Rủi ro và cách chặn

R1. Làm quá lớn ngay từ đầu

Chặn bằng pilot 3 văn bản trước, không migrate hết một lần.

R2. Biến luật thành mô hình quá trừu tượng, khó dùng

Chặn bằng nguyên tắc “render lại được văn bản hoàn chỉnh” ở mọi revision.

R3. Trộn runtime nóng với archive/vector

Chặn bằng tách bảng + queue async.

R4. Agent lại hardcode vì luật chưa đủ operational

Chặn bằng NT14: mọi trường hợp cần binding/query/config phải ghi rõ trong schema, không để agent tự suy.

R5. Đ38 mâu thuẫn trạng thái

Chặn bằng quyết nghị pháp lý ở Giai đoạn 0.

14. Chốt đề xuất

Tôi đề xuất chốt theo 5 ý:

  1. Không nâng cấp KB file hiện tại thêm nữa cho hot path chỉnh luật.
  2. Dựng một Normative Core PG-native làm SSOT mới cho hiến pháp + luật + quy định.
  3. Dùng mô hình section/atom/reference/binding/revision, không dùng blob file làm SSOT.
  4. Dựng Super Session PG-native riêng cho hội đồng/agent, summary async sang KB/vector.
  5. Xem 9 hệ thống luật hiện tại là “nguồn di trú” vào Đ38+Đ39 runtime, không phải là trạng thái đích cuối.

15. Việc nên làm ngay sau kế hoạch này

  1. Ra quyết nghị xử lý mâu thuẫn trạng thái Đ38.
  2. Chốt schema tối thiểu của Normative Core.
  3. Chọn 3 văn bản pilot để di trú.
  4. Viết DOT migration + DOT render + DOT verify đầu tiên.
  5. Sau đó mới làm session runtime và Nuxt workbench.

Kết luận cuối

Hướng Chủ tịch nêu ra là đúng và phù hợp với Hiến pháp, Đ33, Đ37, Đ38, Đ39. Điểm cần sửa không phải là “làm KB tốt hơn”, mà là chuyển hẳn từ document-centric sang PG-native normative runtime.

Nếu làm đúng theo lộ trình trên, kết quả sẽ là:

  • sửa nhanh hơn,
  • ít sai hơn,
  • AI/agent đọc đúng hơn,
  • viện dẫn và kết nối tốt hơn,
  • luật bớt lạc hậu vì số sống được bind runtime,
  • hội đồng làm việc nóng trên PG,
  • vector chỉ còn là lớp hỗ trợ dài hạn thay vì nút thắt tương tác.