Council Review — GPT — Điều 38: Luật Văn bản Quy phạm v1.0

Tài liệu đã đọc

knowledge/dev/architecture/dieu38-normative-document-law-draft.md
knowledge/dev/laws/constitution.md
knowledge/dev/architecture/dieu37-governance-organization-law-draft.md
Context đối chiếu: Điều 35, 36, 0-G, handoff S150+

Điểm tổng thể

7.8/10 — THÔNG QUA CÓ ĐIỀU KIỆN.

Hạt nhân của Điều 38 là đúng và cần ban hành: đưa văn bản quy phạm từ Markdown rời rạc vào PG, có vòng đời, có render, có quan hệ, có DOT. Điều này sửa đúng vi phạm NT1, NT2, NT3, NT10. Tuy nhiên v1.0 còn một số chỗ “đúng hướng nhưng chưa khóa gốc”, nhất là ở temporal validity, content schema, conflict detection, migration từ Điều 37, và scale của document_instances.

1. Đánh giá theo 3 mục tiêu

Mục tiêu 1 — Áp dụng tư duy tốt nhất của ngành IT

Đánh giá: Đạt nền tảng tốt, nhưng chưa đủ chặt để gọi là bản chuẩn ngành hoàn chỉnh.

Điểm đúng:

Có đủ các pattern lõi của Policy Lifecycle Management: draft/review/enacted/retired, parent hierarchy, supersede, impact analysis, conflict detection, temporal validity.
Có hướng đúng của Business Rules Management: section types, formula/table/doc/DOT references, shared data binding.
Có hướng đúng của Document Assembly: template + data merge + document instances + render engine tách riêng.
Có ý thức đúng về cascade propagation: không auto-retire dây chuyền, chỉ flag review required.

Thiếu hoặc chưa đủ chuẩn ngành:

Hiệu lực thời gian đang dùng 2 cột valid_from/valid_until là dùng được, nhưng chưa phải pattern tốt nhất của PG. Với bài toán temporal validity, tstzrange + exclusion constraint thường mạnh hơn cho kiểm tra overlap, period query, index GiST, và semantics rõ hơn. Hai cột riêng vẫn ổn ở v1, nhưng nếu đã nhấn mạnh PG16 thì nên cân nhắc range type là thiết kế “đúng nghề” hơn.
Versioning chưa đủ chặt. version TEXT + trigger tăng version là quá nhẹ. Văn bản quy phạm cần phân biệt rõ major/minor hoặc ít nhất revision_no số nguyên + superseded_by/supersedes nhất quán. Nếu không, impact analysis và instance rendering sau này sẽ mơ hồ.
Sections JSONB chưa có schema version / section_id ổn định. Ngành IT thường tránh JSON array thuần cho nội dung chuẩn vì reorder hoặc sửa nhỏ sẽ làm hash/diff khó dùng. Nên có section_id, section_order, section_type, payload, schema_version.
5 cơ chế nhất quán đúng nhưng chưa đủ. Thiếu ít nhất 2 cơ chế chuẩn:
- Effective view / rules resolution order: khi nhiều văn bản cùng áp lên 1 đối tượng, ai thắng? Hiến pháp > luật > regulation > policy > procedure > template cần được máy tính hóa, không chỉ viết bằng text.
- Snapshot policy cho instances: cái gì bind sống, cái gì snapshot tại thời điểm render/sign? Đây là trọng yếu của document assembly, nhất là hợp đồng/thông báo đã gửi.
Conflict detection tầng AI nên chỉ là bổ sung, không được nằm trong khung chính.** Khung chính phải là cấu trúc + precedence + overlap + relation graph. AI semantic check chỉ là lớp 3, không phải trụ cột.

7 cấp văn bản: hợp lý cho Incomex, không có gì sai. Ngành IT không có “số cấp chuẩn duy nhất”; thường chỉ cần 4-7 cấp tùy tổ chức. 7 cấp ở đây là chấp nhận được vì cấp 7 đã tách hẳn sang document_instances. Điểm cần sửa là đừng gọi cấp 7 là “cấp văn bản” trong cùng logic với normative documents; bản chất nó là artifact instance, không phải normative source.

7 section types: đúng hướng nhưng còn thiếu 2 loại có ích cho business rules:

enum_ref / taxonomy_ref: trỏ chuẩn hóa tới danh mục/taxonomy thay vì text tự do
approval_ref / workflow_ref: trỏ tới luồng phê duyệt hoặc state machine khi văn bản có thủ tục thi hành

Shared Data Binding qua JSONB formula_ref: đúng hướng, nhưng không nên để formula tùy ý tự do trong JSONB. Nên có catalog các binding types chuẩn hoặc formula DSL hạn chế; nếu không agent sẽ sáng tác công thức lung tung, khó verify, khó impact analysis.

Kết luận mục tiêu 1: đúng ADN ngành, nhưng chưa tới mức “best practice hoàn chỉnh”.

Mục tiêu 2 — Khai thác tối đa tài nguyên và hệ thống hiện có

Đánh giá: Nhìn chung tốt, Assembly First chuẩn, nhưng có vài chỗ nên dùng PG mạnh hơn và vài chỗ đang hơi tham trigger.

JSONB cho nội dung sections: là lựa chọn đúng cho PG hybrid. Với 2500 văn bản quy phạm, JSONB hoàn toàn chịu được. Nhưng phải kèm:

GIN index cho sections
generated columns hoặc materialized views cho các field hay lọc
JSON schema validation hoặc trigger validation sớm

PG range types: tôi nghiêng về nên dùng tstzrange hoặc ít nhất chuẩn bị đường nâng cấp. Nó hợp PG hơn 2 cột riêng cho bài toán hiệu lực và overlap. Nếu muốn đơn giản v1.0, có thể giữ 2 cột nhưng nên ghi TD rất rõ: chuyển sang range/exclusion khi temporal rules phức tạp lên.

2 render engine: docxtemplater + Carbone CE là cặp hợp lý cho stack hiện tại. Không thấy cần thêm engine khác ở v1.0. Carbone CE đủ cho DOCX/PDF/XLSX. Điểm cần cẩn thận là PDF quality và font/LibreOffice pipeline khi self-host trên Docker; đây là chuyện vận hành, không phải sai kiến trúc.

normative_registry thay law_registry bằng ALTER + VIEW: hướng đúng. Đây là cách sạch nhất để không tạo 2 registry song song. Nhưng phải khóa semantic thật rõ:

law_registry cũ thành VIEW read-only hoặc compatibility view
mọi DOT mới chỉ ghi normative_registry
Điều 37 phải được cập nhật viện dẫn để tránh 2 SSOT sống song song

11 PG triggers: không quá nhiều nếu mỗi trigger rất nhỏ và một trách nhiệm. Nhưng ở dạng liệt kê hiện tại, có nguy cơ thành “trigger spaghetti”. Tôi khuyên:

giữ trigger bảo toàn dữ liệu cứng ở PG
đẩy logic nhiều bước sang DOT
gom một số trigger kiểm tra nội dung thành 2-3 trigger function dùng chung

Scale 1000+ VB + vô hạn instances: PG JSONB đủ sức. Điểm nghẽn không nằm ở normative_registry, mà nằm ở document_instances và render pipeline.

Indexing strategy nên có ngay trong luật hoặc TD gần:

normative_registry(status, doc_type, doc_level)
normative_registry(parent_code)
normative_registry(superseded_by)
normative_registry(valid_from, valid_until) hoặc GiST trên range
GIN on sections
normative_relations(source_code, relation_type, status) và (target_code, relation_type, status)
document_instances(template_code, status, rendered_at)
partition/time-based strategy cho document_instances

Kết luận mục tiêu 2: tận dụng stack hiện có đúng hướng, nhưng nên dùng PG temporal mạnh hơn và nói rõ indexing/partition strategy.

Mục tiêu 3 — Đáp ứng nhu cầu cụ thể của Incomex

Đánh giá: Khớp nhu cầu thực tế rất tốt.

Điểm mạnh:

Quản lý luật hiện có + chính sách tương lai trong cùng khung là hợp lý.
Agent flow “đọc PG → tìm template → generate → render → email” là đúng hướng.
PG = SSOT, KB = generated, Directus = UI là nhất quán với NT10.

Rủi ro khi gộp tất cả VB vào 1 collection:

Về nguyên tắc: gộp được.
Về vận hành: phải cực rõ ranh giới giữa normative source documents và rendered instances. Ở bản hiện tại đã tách document_instances, đây là đúng. Tôi ủng hộ giữ 1 registry cho nguồn quy phạm, miễn là doc_type, doc_level, category, department, status được enforce tốt.
Rủi ro lớn nhất không phải hiệu năng mà là nghĩa dữ liệu: hiến pháp, policy, procedure, template cùng ở một chỗ nhưng quy trình phê duyệt và hiệu lực khác nhau. Vì vậy cần rule engine/phê duyệt theo doc_level, không thể chỉ để text mô tả.

document_instances scale vô hạn: nên có partition strategy. Với single VPS, ít nhất nên partition theo tháng/quý trên rendered_at hoặc created_at, vì đây là bảng tăng mãi và chứa snapshot/file metadata. Không cần làm ngay ngày đầu, nhưng phải ghi rõ là thiết kế đích.

Agent automation §9: logic đúng nhưng còn thiếu 3 chốt:

Idempotency key cho generate/render/email để tránh gửi trùng
Human approval gate theo loại văn bản, không phải mọi thứ đều auto-send
Snapshot/binding policy: signed contract phải freeze nội dung nào, còn report live thì được re-render

Migration path từ 22 luật Markdown: có rủi ro thật.

Nếu migrate thẳng text MD → sections JSONB mà không có mapping rules, rất dễ tạo “PG chứa text thô”, nhìn như đã chuẩn hóa nhưng thực ra chưa.
Nên chia 2 bước:
- bước 1: import metadata + relation + lifecycle + path + level
- bước 2: chuẩn hóa sections dần theo loại văn bản
Không nên ép chuẩn hóa hết 22 luật ngay một lần nếu chưa có grammar ổn định.

Kết luận mục tiêu 3: phù hợp Incomex, nhưng migration cần đi 2 pha và automation cần thêm idempotency + approval gates.

2. Góp ý cụ thể — cần sửa, thêm, hoặc bỏ

Nên sửa ngay trước ban hành

Làm rõ precedence / conflict resolution order bằng máy đọc được. Không chỉ có parent_code và relation, mà phải có rule rõ: cấp cao hơn thắng cấp thấp hơn; cùng cấp thì version/enacted date/department authority xử lý thế nào.
Bổ sung snapshot policy cho document_instances. Phải ghi rõ trường nào live-bound, trường nào snapshot tại render, trường nào bất biến sau sign.
Đổi hoặc chuẩn bị đổi temporal model sang tstzrange. Nếu chưa đổi ngay, ít nhất ghi rõ đây là hướng chuẩn ngành cần tiến tới.
Chuẩn hóa sections JSONB. Mỗi section nên có section_id, section_type, payload, order, schema_version.
Thêm validation/DSL cho formula_ref. Không cho SQL tự do trong JSONB. Phải là binding DSL có whitelist.
Tách rõ normative source vs template vs instance ở semantics. Template là normative design asset; instance là artifact vận hành. Không để level 6/7 gây lẫn.
Cập nhật Điều 37/compatibility view thật chặt khi thay law_registry. Tránh 2 SSOT cùng sống.
Bổ sung indexing/partition strategy ngay trong luật hoặc appendix kỹ thuật. Đặc biệt cho document_instances và JSONB search.

Nên thêm

Approval matrix theo doc_level. Hiện mới mô tả Council/lãnh đạo/phòng ban ở text. Nên có rule máy đọc được.
Idempotency + retry semantics cho DOT-DOC-GENERATE / RENDER / email send.
Audit trail rõ cho nội dung enacted. content_hash là tốt nhưng chưa đủ. Cần revision trail hoặc ít nhất immutable revision records.
Text search strategy. Nếu văn bản tăng lên 2500+, phải có full-text search hoặc search index plan. Hiện đang để TD, nên chấp nhận được nhưng cần ưu tiên sớm.

Nên bỏ hoặc làm yếu đi

Đừng dựa quá nhiều vào “AI conflict detection” như một phần lõi. Giữ nó ở mức TD hoặc supplementary check. Trục chính phải là cấu trúc, precedence, relation graph, temporal overlap.

3. Rủi ro nếu ban hành v1.0 ngay

Temporal validity chưa tối ưu → query/overlap logic có thể phình phức tạp dần.
formula_ref tự do quá → shared binding biến thành nguồn lỗi và injection logic.
Migration từ Markdown sang JSONB sections có thể sinh “PG-text giả cấu trúc”.
Điều 37 ↔ Điều 38 có thể bị double-SSOT tạm thời nếu compatibility không khóa chặt.
document_instances sẽ lớn nhanh hơn tưởng tượng nếu auto-generate theo batch mà chưa có partition/idempotency.

Cần sửa gì trước?

precedence engine
snapshot policy
formula DSL/validation
migration 2 pha
compatibility với Điều 37

4. So sánh với pattern/giải pháp ngành IT

Pattern đúng nên giữ

Registry + lifecycle + relations + supersede
Structured sections thay vì blob text thuần
Rendered instances tách khỏi normative source
Temporal validity
Impact analysis trước retire/amend

Pattern tốt hơn nên cân nhắc

Effective dating bằng range type
Rules precedence encoded in data
Normalized bindings catalog thay vì formula tự do
Immutable revision records cho enacted docs
Read model / effective view cho “document currently effective” tương tự topology view ở Điều 37

5. Kết luận cuối

Điều 38 v1.0 là một bước rất đúng và nên làm ngay. Nó sửa đúng một lỗ hổng hiến pháp đang có: luật sống trong Markdown mà PG không biết. Kiến trúc lõi hợp với NT1, NT2, NT3, NT10, NT11 và hợp stack hiện tại.

Nhưng nếu hỏi “đã sẵn sàng ban hành nguyên trạng chưa”, câu trả lời của tôi là:

GO có điều kiện — 7.8/10

Muốn lên mức 8.5+ để ban hành chắc tay, tôi muốn thấy 5 sửa khóa gốc sau:

precedence/conflict resolution machine-readable
snapshot policy cho instances
formula/binding DSL có validation
temporal model rõ hơn (ưu tiên range type hoặc roadmap chặt)
migration + compatibility Điều 37 không tạo 2 SSOT song song