Council Review — GPT — Điều 37 v2.1 + NT11 + Glossary v2.1

Tài liệu đã đọc

knowledge/dev/architecture/dieu37-governance-organization-law-draft.md
knowledge/dev/laws/terminology-glossary.md
knowledge/dev/laws/law-01-foundation-principles.md
Context: Điều 28, 29, 31, 35, 36, Operating Rules

A. Điều 37 — Kiến trúc

1. §0 Mục tiêu + 4 nhiệm vụ

Đánh giá: Rõ, cô đọng, đúng lỗ hổng. Mục tiêu “khớp top-down với bottom-up” là chuẩn vì bù đúng phần Điều 0-G/29/26 chưa cover. 4 nhiệm vụ đủ lõi, không thấy thừa.
Thiếu nhẹ: nên thêm 1 dòng nhấn mạnh nhiệm vụ thứ 5 ở mức vận hành: “phân xử nguồn sự thật” — cái gì lấy từ PG catalog, cái gì khai báo logic, cái gì chỉ là text. Điểm này hiện nằm rải ở NT11 + §8 nhưng chưa đứng thành nhiệm vụ rõ.
Kết luận: GO có điều kiện nhỏ. Tuân thủ Điều 1 NT1, NT8, NT11.

2. 4 tầng quản lý (Luật→Cơ quan→Liên kết→Thực thi)

Đánh giá: Gần đủ, nhưng hiện văn bản mô tả mục tiêu là “Luật → Cơ quan → Thực thể”, còn schema thực tế lại là “Luật → Cơ quan → Liên kết → DOT thực thi / phạm vi”. Vậy tầng 4 đang bị gọi chưa nhất quán.
Thiếu 1 tầng logic cần gọi tên rõ: Phạm vi (jurisdiction) là tầng riêng, không chỉ là thuộc tính phụ. Vì câu hỏi “domain nào vô chủ/chồng chéo” sống ở tầng này, không sống ở tầng thực thi.
Đề xuất: Chuẩn hóa thành 5 tầng quản lý: Luật → Phạm vi → Cơ quan → Liên kết/Hợp đồng → Thực thi. Như vậy khớp đúng §5 và §6 hơn.
Kết luận: Ý đúng, tên tầng chưa chốt.

3. 5 ma trận

Đánh giá: 5 ma trận giải được phần lớn 10 câu hỏi §0. MTX-LAW-DOMAIN, MTX-LAW-DOT, MTX-GOV-HEALTH là 3 ma trận load-bearing.
Thiếu 1 ma trận quan trọng: MTX-AGENCY-COLLECTION hoặc MTX-GOV-SCOPE để trả lời dứt điểm câu 7: “Collection Z thuộc phạm vi luật/cơ quan nào? Collection nào vô chủ?” Hiện đang suy từ jurisdiction + primary_collection, nhưng chưa có ma trận nhìn 1 phát ra ngay.
Kết luận: 5 ma trận tốt nhưng chưa đủ trọn bộ cho câu hỏi collection vô chủ.

4. Assembly First

Đánh giá: Đúng hướng. Việc tận dụng dot_domains, system_issues, pivot_definitions, PG catalog là phù hợp Điều 1 NT8, Điều 26, Điều 35, Điều 36. Không có dấu hiệu tạo mới vô cớ ở các phần đó.
Điểm cần siết: law_registry là hợp lý vì luật chưa có SSOT có cấu trúc; nhưng scope_summary TEXT dễ trượt về NT10/NT11 nếu người ta nhét operational truth vào text. Trường này chỉ nên là narrative, không được làm nguồn máy đọc.
Kết luận: Assembly First đạt.

5. `governance_relations` 1 bảng

Đánh giá: Ở giai đoạn đầu, 1 bảng là đúng. Nó giữ hệ thống đơn giản, dễ scan, dễ pivot, đúng tinh thần Điều 29 v2.0 “1 hệ thống thay vì 2 hệ thống hành chính song song”.
Rủi ro: trộn chung 3 loại quan hệ rất khác nhau trong 1 bảng: law↔agency logic, agency↔agency contract, PG physical dependency. Khi scale, một bảng sẽ bị mơ hồ semantics và khó enforce FK.
Kết luận: Giữ 1 bảng ở v1 là đúng, nhưng phải khóa chặt bằng enum mạnh cho relation_type, source_type, target_type, và thêm rule: physical relations = read-only, chỉ DOT scan ghi; logical relations = DOT/onboarding ghi. Nếu không, sau này dữ liệu bẩn.

B. Điều 37 — Phạm vi và xung đột

6. Ranh giới với Điều 29, 31, 35, 36

Đánh giá: Khá rõ nhưng còn 2 chỗ vênh:

Với Điều 35: Điều 35 quản trị DOT như thực thể/DOT system domain; Điều 37 quản trị DOT System như cơ quan. Ý này đúng trong Glossary 8.2, nhưng luật nên nhắc lại ngay §3 hoặc §9 để agent khỏi lẫn.
Với Điều 31: Điều 37 nói “Điều 31 thêm CHECK governance”. Câu này đúng hướng nhưng dễ trượt phạm vi. Điều 37 nên phát hiện cấu trúc quản trị sai, còn Điều 31 chỉ nên verify contract/health của hệ thống, không ôm nội dung tổ chức.
Không thấy xung đột trực tiếp với Điều 29 và Điều 36. Điều 29 phân loại collection; Điều 37 tổ chức cơ quan/luật ở lớp cao hơn. Điều 36 quản trị protocol tạo collection; Điều 37 dùng output đó để trả lời “ai chịu trách nhiệm”.

7. Phạm vi TRONG vs NGOÀI

Đánh giá: Bản kê hiện khá tốt.
Thiếu: chưa ghi rõ ngoài phạm vi: không chuẩn hóa nội dung text luật và không làm knowledge graph phổ quát cho mọi entity. Nếu không ghi, agent dễ nhét luôn mọi quan hệ entity vào Điều 37, đụng universal_edges hoặc Điều 0/21.
Thừa nhẹ: “Onboarding mới” nằm trong TRONG là đúng, nhưng nên viết “onboarding luật/cơ quan mới”, không phải onboarding mọi entity mới.

8. `law_jurisdiction` dùng `dot_domains`

Đánh giá: Dùng dot_domains là đúng theo NT8 và NT11. Không nên tạo domain taxonomy riêng chỉ cho luật lúc này.
Nhưng: chỉ domain thôi là chưa đủ granularity. Luật nhiều khi bao domain rộng, còn trách nhiệm thực tế nằm ở tập collection con.
Đề xuất: giữ domain làm trục chính, nhưng thêm khả năng scope override bằng collection/prefix/species ở phase sau, hoặc ít nhất có bảng phụ/matrix phụ. Không cần tạo ngay luật mới, nhưng nên ghi nợ kiến trúc rõ.

9. Quy trình ban hành luật mới

Đánh giá: INSERT law_registry + jurisdiction + enforcement là thực tế và không quá nặng. Với số lượng luật ít, đây là chi phí chấp nhận được để tránh “luật tủ kính”.
Điểm cần chốt: luật draft có thể chưa có enforcement hoàn chỉnh; luật enacted thì bắt buộc phải có ít nhất 1 enforcement role hoặc exemption có expiry, đúng tinh thần Điều 1 NT2, NT5.
Kết luận: quy trình hợp lý, nhưng nên tách rõ chuẩn draft vs enacted.

C. NT11 — Trọng tâm

10. NT11 đã đủ rõ chưa?

Đánh giá: Ý đúng, mạnh, chạm đúng vết thương cũ. Nhưng để agent tuân thủ ổn định, cần thêm 3 quy tắc thao tác cụ thể:

Catalog-first check: trước khi tạo field/collection quan hệ mới, DOT phải hỏi “PG/Directus/system collection đã có thông tin này chưa?”.
Source-of-truth tagging: mọi field/quan hệ phải có nhãn nguồn pg_catalog / directus_system / manual_logic.
Read precedence: khi có cả catalog và khai báo tay, catalog thắng với quan hệ vật lý; manual chỉ được bổ sung lớp logic, không được ghi đè.
Nếu không thêm 3 rule này, NT11 vẫn dễ bị hiểu thành khẩu hiệu hơn là luật vận hành.

11. Kiến trúc lâu dài để toàn hệ thống tận dụng PG catalog

Đề xuất kiến trúc:

Lớp 1: Raw truth = PG catalog (pg_trigger, pg_constraint, pg_depend, information_schema) + Directus system collections.
Lớp 2: Normalized relations view = 1 lớp chuẩn hóa đọc-only, ví dụ v_governance_discovered_relations, hợp nhất catalog thô thành schema chung: source, target, relation_type, confidence, discovered_at.
Lớp 3: Overlay logic = governance_relations cho phần PG không tự biết: law scope, DOT serves law, contract nghĩa vụ.
Lớp 4: Unified read API/view = v_governance_relations_effective hợp nhất discovered + manual, có precedence rõ. MỌI DOT đọc từ view này, không tự đọc mỗi nơi mỗi kiểu.
Kết luận: Không nên để mọi DOT tự đọc thẳng PG catalog theo cách riêng. Phải có 1 abstraction layer chuẩn. Đó mới là SSOT thực dụng theo NT1 + NT11.

12. PG catalog scan → INSERT governance_relations

Đánh giá: Khả thi. Quan hệ FK/trigger/dependency scan hàng ngày trên 138 collections là nhẹ với PG16 single VPS.
Rủi ro:

pg_depend khó diễn giải, dễ false positive/false meaning.
INSERT trực tiếp vào governance_relations làm lẫn discovered facts với human logic.
Manual override có thể mâu thuẫn với scan.
Đề xuất: scan daily + on-demand, chưa cần realtime. Ghi vào staging/view hoặc record có discovery_source='pg_catalog' + read-only lock. Không cho người sửa tay record loại này. Xung đột manual/cataloɡ → DOT tạo system_issues, không tự merge im lặng.

D. Rà soát xung đột giữa các luật

13. Có xung đột nào không?

Đánh giá: Không thấy xung đột trực diện kiểu “A nói X, B nói ngược X”. Nhưng có 3 vùng dễ chồng ranh giới:

Điều 31 vs 37: cùng chạm health/check/violation. Phải tách: Điều 37 = tổ chức/phạm vi/liên kết; Điều 31 = verification engine.
Điều 35 vs 37: cùng chạm DOT. Phải tách: Điều 35 quản trị DOT entities/domain/tool lifecycle; Điều 37 quản trị DOT System như cơ quan thực thi trong bộ máy.
Điều 29 vs 37: cùng chạm “phạm vi”. Phải tách: Điều 29 nói collection là gì; Điều 37 nói luật/cơ quan nào chịu trách nhiệm với collection/domain đó.
Đây là vênh ranh giới, chưa phải xung đột logic.

14. `governance_relations` như kênh rà soát xung đột

Đánh giá: Khả thi, và là hướng đúng. Khi quan hệ được data hóa, có thể tự động phát hiện:

2 DOT cùng ghi 1 collection nhưng khác enforcement role
2 luật cùng primary trên 1 domain
1 collection có physical dependency nhưng 0 agency owner
1 law enacted nhưng 0 enforcement

Cần thêm:

taxonomy chuẩn cho relation_type và enforcement_role
ownership/write-intent metadata (ai đọc, ai ghi, ai verify)
severity rules trong system_issues
1 view/phép kiểm tra chuyên cho “conflicting writers”, không chỉ generic relations.

E. Tổng thể

15. Điều 37 có vi phạm 11 nguyên tắc không?

Đánh giá: Không vi phạm rõ ràng.

Hợp NT1 vì tạo SSOT mới cho luật/cơ quan.
Hợp NT8 vì tận dụng dot_domains, pivot, PG catalog.
Hợp NT10 vì data máy dùng nằm trong PG.
Hợp NT11 vì ưu tiên scan catalog.
Điểm cần sửa để tránh trượt: không để scope_summary hoặc text glossary trở thành nguồn máy đọc; và không để quan hệ physical bị khai tay.

16. Tính khả thi 2-3 sprint

Đánh giá: Khả thi trong 2-3 sprint trên PG16 + Directus + Nuxt + single VPS nếu chia pha:

Sprint 1: schema + seed law_registry, governance_registry, law_dot_enforcement
Sprint 2: pivot + dashboard + onboarding/orphan checks
Sprint 3: PG catalog scan + conflict rules + backfill jurisdiction

Rủi ro chính: không phải hiệu năng, mà là semantic drift — agent điền tay sai meaning của relation; và boundary drift — Điều 37 nuốt sang phạm vi Điều 31/35. Đây là rủi ro thiết kế, không phải hạ tầng.

Chấm điểm

Tiêu chí	Điểm /10
Mục tiêu + Nhiệm vụ	8.5
Kiến trúc	7.8
Phạm vi	7.6
NT11	8.0
Xung đột giữa các luật	7.7
Tổng thể	8.0
TRUNG BÌNH	7.9/10

Kết luận

THÔNG QUA CÓ ĐIỀU KIỆN.

Trước khi ban hành, nên sửa 5 điểm ngắn:

Chuẩn hóa lại mô hình thành 5 tầng quản lý: Luật → Phạm vi → Cơ quan → Liên kết/Hợp đồng → Thực thi.
Bổ sung 1 ma trận cho Cơ quan × Collection hoặc Scope coverage.
Ghi rõ draft law có thể 0 enforcement; enacted law thì không.
Thiết kế abstraction layer chuẩn cho catalog scan: raw catalog → normalized view → overlay logic → effective view.
Khóa cứng rule: physical relations read-only từ scan, không khai tay, không override im lặng.