Review Hội đồng AI — Dự thảo sửa luật Track A REV 2 (Vòng 2)

Ngày: 2026-04-20
Agent: Incomex Hội đồng AI (GPT)
Phạm vi: review REV 2 sau khi áp 7 patch từ vòng 1
Tài liệu chính: knowledge/current-state/reports/du-thao-sua-luat-track-a-d43-phase-c.md (revision 2)
Căn cứ đã đọc:
- knowledge/current-state/reports/dinh-huong-sua-luat-d43-phase-c.md
- knowledge/dev/laws/law-03-metadata.md
- knowledge/dev/laws/law-04-birth-process.md
- knowledge/dev/laws/dieu35-dot-governance-law.md
- knowledge/dev/laws/label-law.md
- knowledge/dev/laws/constitution.md

1) Phán quyết tổng

Verdict: APPROVE FINAL

Điểm: 9.4/10

Độ chặt chẽ pháp lý: 9.4
Khả thi kỹ thuật: 9.2
Tuân HP/NT: 9.5
Mức sẵn sàng ban hành: 9.4

Nhận định chính

REV 2 đã xử lý đúng các điểm khó của vòng 1:

đóng lỗ gov_role IS NULL (P1), phù hợp NT9;
tách trigger gate khỏi audit issue logging (P2), sạch hơn nhiều về vai trò và recursion risk;
thêm btrim() + anti-gaming cơ bản (P3/P4);
áp dụng threshold override per table (P5) để Đ35 thật sự được thực thi;
làm rõ FAC-PROV scope (P6);
viết đúng hơn về NT3 ngoại lệ trí tuệ và write path hợp pháp có audit (P7).

Kết quả: bản REV 2 đã đạt đúng tinh thần Track A — đơn giản, machine-checkable, config-driven, PG-first — mà không kéo quá nhiều phức tạp của Track B vào sớm.

2) Trả lời 4 câu hỏi vòng 2

Câu 1 — Function logic có sạch không?

Kết luận: Sạch và đủ để ban hành.

Luồng logic hiện tại là đúng:

đọc mode;
đọc baseline min length;
đọc override per table;
lookup governance_role;
NULL thì WARN/BLOCK;
excluded thì bỏ qua;
chuẩn hóa _desc = btrim(COALESCE(to_jsonb(NEW)->>'description', ''));
kiểm tra rỗng / ngắn / gaming;
governed+block thì reject, còn lại cho qua để H11 audit.

Edge case to_jsonb(NEW)->>'description' = NULL:

Nếu trigger chỉ được gắn đúng cho “bảng có cột description”, thì case này gần như không xảy ra về mặt nghiệp vụ.
Nếu do lỗi triển khai mà gắn trigger vào bảng không có cột description, biểu thức sẽ trả NULL, sau đó COALESCE(...,'') → fail check. Điều này là an toàn thất bại hơn là bypass.
Vì vậy hành vi hiện tại là chấp nhận được.

Một ghi chú minor:

Comment “không phải bảng nào cũng expose column trực tiếp trong trigger context” không thật sự là lý do chính xác nhất về kỹ thuật; bản chất đúng hơn là dùng to_jsonb(NEW) để đọc generic, tránh phụ thuộc compile-time vào field cụ thể. Nhưng đây chỉ là wording minor, không ảnh hưởng thiết kế.

Câu 2 — Anti-gaming regex đủ chưa?

Kết luận: Đủ cho Track A.

Regex hiện tại chặn được nhóm gaming rẻ và phổ biến nhất:

1 ký tự lặp 10+ (aaaaaaaaaa, ..........)
chuỗi ký tự vô nghĩa kiểu punctuation/space lặp

Đúng là chưa chặn được:

abcabcabcabc
test test test test
các câu dài nhưng semantically rỗng

Nhưng đó là trade-off đúng cho Track A. Nếu cố chặn thêm ở PG bằng regex/heuristic sẽ:

tăng false positive,
làm trigger khó hiểu,
đẩy Track A sang vùng semantic validation nửa vời.

Khuyến nghị: giữ nguyên hiện tại. Semantic gaming còn lại để H11 + spot-check xử lý. Track B mới là nơi phù hợp nếu muốn nâng thành scoring/rules phức tạp hơn.

Câu 3 — H11 audit role trong WARN mode, độ trễ 3h có chấp nhận được không?

Kết luận: Chấp nhận được cho rollout phase.

Lý do:

WARN mode là giai đoạn chuyển tiếp có chủ đích, không phải steady-state cuối cùng;
mục tiêu là tránh làm nghẽn birth trong lúc còn backfill + ổn định hệ thống;
dual-trigger vẫn tồn tại: birth guard chặn điều kiện tệ nhất khi chuyển block, H11 làm audit/coverage cho rollout.

Độ trễ tối đa 3h là chấp nhận được vì:

entity thiếu description không làm hỏng dữ liệu cấu trúc ngay tức thì;
đây là governance debt có thể chịu trễ ngắn trong phase rollout;
dự thảo đã quy định sau backfill + 7 ngày stable sẽ chuyển sang block.

Điều kiện để kết luận này giữ đúng:

H11 phải thực sự scan đủ scope “mọi bảng governed có cột description”;
rollout checklist phải có xác nhận H11 coverage trước khi dựa vào nó như trigger phụ.

Câu 4 — REV 2 đã đủ ban hành chưa?

Kết luận: Đủ ban hành.

Phán quyết của tôi là APPROVE FINAL.

Không còn lỗi HIGH. Các điểm còn lại chỉ là tinh chỉnh nhỏ, không đủ để giữ lại thêm một vòng revision bắt buộc.

3) Ghi chú minor còn lại (không chặn ban hành)

Minor-1 — Tên config key ở changelog và implementation nên thống nhất tuyệt đối

Trong phần tóm tắt đầu yêu cầu có nhắc pattern dot_tools_description_min_length = 50, còn changelog trong draft nói “dot_description_min_length”. Phần implementation luật đã dùng pattern đúng là '<table_name>_description_min_length'.

Khuyến nghị: rà lại toàn văn để chỉ giữ một chuẩn duy nhất: dot_tools_description_min_length.

Minor-2 — `PROV-HUMAN` nên mô tả rõ hơn một chút

Hiện mô tả là “Description đã được con người xác nhận”. Ổn. Nhưng để tránh tranh cãi về sau, có thể viết rõ hơn:

“con người viết trực tiếp hoặc đã review và approve output AI”.

Không bắt buộc sửa trước ban hành.

Minor-3 — Câu về `notes`

“Lưu trong extra_metadata JSONB nơi có, hoặc cuối description nơi chưa có JSONB” là workaround chấp nhận được ở Track A, nhưng về mặt purity thì hơi pha semantics.

Không phải blocker. Chỉ nên ghi nhớ rằng Track B hoặc phase sau cần chuẩn hóa chỗ lưu notes nếu field này được dùng rộng.

4) Kiểm tra Hiến pháp — 13 NT

PASS rõ ràng

NT1 SSOT: dùng lại governance_role, entity_labels, dot_config → PASS
NT2 Tự động: enforcement bằng trigger/function → PASS
NT4 Config-driven: mode + threshold đều nằm trong config → PASS
NT7 / NT12: birth guard là động cơ chính, H11 là động cơ phụ → PASS
NT9: NULL governance_role không còn bypass → PASS
NT10: rule thực thi/queryable trong PG, không chỉ prose → PASS
NT11: không đẻ subsystem mới không cần thiết → PASS
NT13: PG-native trigger/function/config → PASS

PASS có giải thích

NT3: backfill semantic bằng AI được đóng khung đúng là ngoại lệ trí tuệ ở pha suy luận; pha ghi dữ liệu phải qua write path hợp pháp có audit → PASS

Không thấy dấu hiệu vi phạm trực tiếp

NT5, NT6, NT8 không bị chạm theo hướng xấu trong phạm vi amendment này.

5) Kết luận ngắn cho Chủ tịch

REV 2 đã đạt trạng thái có thể ban hành. Đây là một amendment gọn, đúng bệnh, không over-engineer, và quan trọng nhất là đã biến “description bắt buộc” từ khẩu hiệu thành cơ chế enforce được bằng máy.

Phán quyết cuối:

APPROVE FINAL
Điểm: 9.4/10

Nếu muốn cực kỳ chỉnh chu trước khi đóng, chỉ cần rà lại 2 wording minor:

thống nhất tên config key override per table;
mô tả PROV-HUMAN rõ hơn một nấc.

Nhưng hai điểm này không cần mở thêm vòng revision bắt buộc.