ĐIỀU 38 — LUẬT SQL HOÁ VĂN BẢN v3.0

(Document Digitization Law — DRAFT chờ Huyên duyệt)

v3.0 | S168 (2026-04-06) | Viết lại toàn bộ từ v2.3 Lý do viết lại: v2.3 xa vời thực tế, không nói rõ mục tiêu cần giải quyết. Tuân thủ: OR v7.53 (Công thức soạn luật mục XII) Trạng thái: DRAFT — MT đã duyệt cơ bản, GP đang viết chi tiết

PHẦN 1 — MỤC TIÊU

MT1 — Dữ liệu hoá nội dung non-SQL, quản lý bằng PG ở mức tối đa có thể

Mọi văn bản pháp quy (hiến pháp, luật, chính sách, quy định quản trị công ty — nhân sự, kinh doanh...) được chia nhỏ thành đoạn có cấu trúc, lưu trong PG để:

PG quản lý non-SQL như SQL — mỗi đoạn văn bản là dữ liệu có metadata, có trạng thái, có quan hệ, query được, index được, trigger được.
DOT hiểu được phần cứng của văn bản — metadata, binding, con số, status, thời hạn → DOT tự so sánh chính xác, phát hiện chênh lệch, tự động 100%.
AI hiểu được phần mềm của văn bản — ngữ nghĩa, mâu thuẫn logic giữa các đoạn, ý đồ chính sách → AI rà soát và suggest, con người duyệt.

Ranh giới DOT / AI:

Phần cứng (DOT): tự động 100%, không cần người → so sánh con số, status, thời hạn, binding
Phần mềm (AI): tự động có giám sát → ngữ nghĩa, mâu thuẫn logic, diễn giải

Nhằm: rà soát, so sánh mức độ chênh lệch giữa văn bản với nhau, giữa văn bản với hệ thống chương trình — thực thi được tự động và chính xác.

Đối tượng hữu hạn: hiến pháp, luật, chính sách, quy định trong quản trị công ty.

Mở rộng cho Điều 39: Công nghệ Đ38 (chia thẻ + metadata + binding) không chỉ áp dụng cho văn bản pháp quy mà có thể dùng làm công cụ tiền xử lý cho đầu vào của Điều 39 (Knowledge Graph). Nếu thông tin đầu vào của KG được cấu trúc hoá bằng phương pháp Đ38 trước khi xây Graph → Graph chính xác hơn so với xây từ text thô. Thiết kế Đ38 cần tính đến khả năng này từ đầu để tránh đập đi làm lại.

MT2 — Sinh văn bản đầu ra tự động

Hợp đồng, biên bản, thông báo, giấy tờ — tất cả được sinh từ PG data + biểu mẫu đã đăng ký. Ban đầu dùng Directus làm giao diện quản lý, sau gắn thêm phần mềm nguồn mở (Carbone, docxtemplater) để render PDF/DOCX.

MT3 — Hạ tầng quản lý toàn bộ vòng đời

PG quản lý: văn bản gốc, phiên bản, mối quan hệ giữa các văn bản, trạng thái (bản nháp → duyệt → ban hành → hết hiệu lực). DOT tự động kiểm tra. AI đọc PG thay vì đọc text.

Tầm nhìn: Chính sách thay đổi → PG cập nhật → DOT phát hiện chênh lệch → Agent sửa hoặc cảnh báo → Văn bản đầu ra tự sinh đúng theo chính sách mới. Con người chỉ duyệt.

PHẦN 2 — GIẢI PHÁP (tóm tắt đã thảo luận)

Tóm tắt 5 việc + vòng đời + bảo vệ

A. NỀN TẢNG — Xây 1 lần

A1. Chia thẻ + Metadata — Mỗi văn bản được chia thành từng đoạn, mỗi đoạn có cấu trúc: loại nội dung, mã, tên, mục đích, keywords, phiên bản, thời hạn hiệu lực. Tổ chức theo chuẩn ngành. Tất cả lưu PG, query được.

A2. Kết nối (Binding) — Đoạn nào có giá trị số hoặc tham chiếu dữ liệu → gắn link whitelist đến đúng bảng, đúng cột PG. Hệ thống biết "đoạn này liên quan data nào."

A3. Bảo vệ tính toàn vẹn — PG tự chặn lỗi phổ biến:

Sửa VB đã ban hành → REJECT, bắt buộc tạo bản mới version++
Nạp bừa không nâng version → REJECT
2 VB trùng mã/tên → REJECT
2 VB cùng loại hiệu lực cùng lúc → REJECT (EXCLUDE constraint)
Nội dung sửa lén → SHA256 hash tự phát hiện
Ban hành không qua duyệt → REJECT (trigger kiểm APR)
VB con trỏ VB cha đã nghỉ hưu → REJECT
2 VB cùng article_number đều enacted → REJECT (★ S178-Fix19). Mặc định CẤM. Ngoại lệ song song (nếu cần) phải thiết kế bằng metadata có cấu trúc trong phiên riêng — KHÔNG dùng notes text làm căn cứ (NT10).

B. VÒNG ĐỜI — 3 sự kiện chính

B1. Văn bản mới ban hành — Đăng ký → chia thẻ → gán binding → nháp → duyệt → ban hành. Khi enacted: trigger kích hoạt → DOT tự quét binding → so sánh data PG → chênh lệch = cảnh báo ngay.

B2. Văn bản sửa đổi — Bản cũ bất biến → retire → tạo mới version++ (PG bắt buộc nâng version). DOT so sánh bản cũ ↔ mới, phát hiện chênh lệch data, phân tích ảnh hưởng cascade.

B2.1. Retire tự động bản superseded (★ S178-Fix19) — Khi bản mới enacted thành công:

PG trigger tự kiểm tra: có row nào superseded_by = NEW.code AND status = 'enacted'?
Nếu có: UPDATE status = 'retired' cho predecessor trực tiếp đó. Trigger nrm_enacted_immutable cho phép enacted → retired. Chỉ retire predecessor trực tiếp — không quét rộng hơn trong amend chain.
Nếu không có: bỏ qua (enact lần đầu, không phải amend).
DOT_NRM_ENACT verify sau trigger: xác nhận predecessor đã retired + không còn duplicate enacted cùng article_number. Ghi governance_audit_log với checked_by = 'DOT_NRM_ENACT', result = 'auto_retired'.
Idempotent: re-run trigger trên row đã enacted không gây side effect (predecessor đã retired thì WHERE clause trả 0 row).

B3. Văn bản nghỉ hưu — DOT phát hiện tự động (hết hạn) hoặc retire thủ công. Kiểm tra phụ thuộc + cảnh báo data đang chạy theo VB hết hiệu lực.

C. KHOANH VÙNG — Dán nhãn theo chuồng

Dữ liệu phân loại theo collection (Đ36): vào chuồng nào → tự động dán nhãn theo chuồng đó. Bảng phân loại nằm trong PG, được Đ38 quản trị. Thay đổi phân loại → DOT phát hiện → cập nhật.

D. KIỂM TRA LIÊN TỤC

DOT daily: so sánh toàn bộ binding (VB ↔ data PG), phát hiện chênh lệch, phát hiện hết hạn. AI: rà soát ngữ nghĩa, mâu thuẫn logic giữa các VB.

E. SINH VĂN BẢN ĐẦU RA

Biểu mẫu + data PG → sinh hợp đồng, thông báo, giấy tờ tự động → PDF/DOCX. Đã ký = bất biến.

PHẦN 3-5 — CHI TIẾT

(Chi tiết đã soạn trong artifact, sẽ cập nhật sau khi thảo luận xong với Huyên)

GHI CHÚ S169: Sản phẩm đầu ra chính của Đ38 = Semantic Annotation (bản chú thích ngữ nghĩa). Mỗi VB ban hành kèm 1 bản "dịch" cho DOT: đoạn nào → thực thể nào → binding PG chỗ nào → quan hệ gì → mức tin cậy. Con người đọc VB gốc, DOT đọc annotation. DOT tự so sánh VB ↔ data PG → phát hiện chênh lệch → cảnh báo. Không cần AI, không tốn token. Chuẩn ngành: Semantic Annotation (W3C). Hạ tầng: NĐ-36-01 (Entity Linking + Relation Extraction).

Điều 38 v3.0 DRAFT | 3 MT + Giải pháp tóm tắt 5 việc + vòng đời + bảo vệ | ★ S178-Fix19 +B2.1 auto-retire + A3 guard 2 enacted | Chờ Huyên duyệt