Incomex AI Portal
KB-7D26

Ý kiến Hội đồng AI — Định hướng sửa luật Đ43 Phase C (Vòng 1)

13 min read Revision 1
councildieu43phase-claw-amendmentround1gpt2026-04-20

Ý kiến Hội đồng AI — Định hướng sửa luật Đ43 Phase C (Vòng 1)

  • Ngày: 2026-04-20
  • Agent: Incomex Hội đồng AI (GPT)
  • Phạm vi: cho ý kiến về hướng sửa, chưa đi vào dự thảo câu chữ.
  • Tài liệu gốc: knowledge/current-state/reports/dinh-huong-sua-luat-d43-phase-c.md
  • Căn cứ đã đọc:
    • knowledge/dev/laws/constitution.md
    • knowledge/dev/laws/law-03-metadata.md
    • knowledge/dev/laws/law-04-birth-process.md
    • knowledge/dev/laws/label-law.md
    • knowledge/dev/laws/dieu29-classification-law.md
    • knowledge/dev/laws/dieu35-dot-governance-law.md
    • knowledge/dev/laws/dieu37-governance-organization-law.md
    • knowledge/dev/laws/dieu39-knowledge-graph-law.md
    • knowledge/dev/laws/dieu43-system-context-law.md

1) Kết luận tổng

Hướng sửa đúng trọng tâm và đúng tinh thần Hiến pháp. 6 lỗ hổng được nhận diện là đúng và đủ cho phạm vi Đ43 MT2, đặc biệt ba lỗ blocking ở Đ3/Đ4/Đ35 là chuẩn. Tuy nhiên có 2 rủi ro bổ sung cần ghi rõ ngay từ vòng định hướng:

  1. Quy cách description phải machine-checkable, không chỉ prose guideline. Nếu chỉ viết "nên có mục đích, trigger, paired DOT" mà không biến thành checklist/regex/rule validate tối thiểu, Đ4 sẽ không thể enforce tự động một cách nhất quán.
  2. Backfill phải có provenance/audit riêng. Nếu AI viết description hàng loạt mà không lưu nguồn sinh (assigned_by, generated_by, generated_at, review_status hoặc tương đương) thì chính dữ liệu mới lại thành production truth mù, trái tinh thần NT9.

2) 6 lỗ hổng: đánh giá đúng/sai/thiếu

2.1. Sáu lỗ hổng nhận diện: ĐÚNG

  • Lỗ 1 (Đ3) đúng: Đ3 hiện bắt buộc description nhưng chưa có quy cách nội dung/độ dài/type-specific.
  • Lỗ 2 (Đ4) đúng: Đ4 yêu cầu "gán metadata tối thiểu" nhưng chưa chỉ ra field nào và chưa có birth guard cụ thể cho description.
  • Lỗ 3 (Đ35) đúng: DOT có description bắt buộc nhưng chưa ép mô tả trigger + paired DOT theo NT12.
  • Lỗ 4 (Đ37) đúng: domain hiện nghiêng về DOT, chưa thành universal domain assignment cho mọi entity governed.
  • Lỗ 5 (Đ24) đúng: auto-assign labels thiếu trạng thái chất lượng/duyệt trước khi coi là production truth.
  • Lỗ 6 (Đ39) đúng: alias/synonym là mảnh ghép cần thiết cho search/disambiguation khi scale.

2.2. Lỗ hổng còn thiếu nhẹ nhưng nên ghi chú

Lỗ 7 (gợi ý thêm, chưa cần tách track riêng): provenance của metadata/backfill.

  • Đ3/Đ24/Đ43 hiện thảo luận nhiều về nội dung mô tả và phân loại, nhưng chưa nhấn mạnh nguồn gốc của mô tả.
  • Với dữ liệu AI-generated, nên có cách phân biệt: human-authored / ai-generated / ai-reviewed / approved.
  • Đây không nhất thiết cần luật mới; có thể gài vào Đ3 metadata mở rộng hoặc Đ24 trạng thái phân loại, tùy cách thiết kế.

3) Phân công sửa vào luật chuyên môn: nhìn chung ĐÚNG CHỖ

Đúng chỗ

  • Đ3 sở hữu semantics của metadata → đặt quy cách description ở đây là đúng.
  • Đ4 sở hữu birth enforcement → đặt birth guard ở đây là đúng.
  • Đ35 sở hữu DOT-specific contract → quy định nội dung description cho DOT là đúng.
  • Đ37 sở hữu domain/jurisdiction → universal domain registry nên đặt tại đây.
  • Đ24 sở hữu phân loại đa chiều → confidence/status đặt ở đây là đúng.
  • Đ39 sở hữu semantic relation/disambiguation → alias/synonym relation đặt ở đây là đúng.
  • Đ43 chỉ nên tiêu thụ kết quả và render ra context pack, không nên trở thành nơi định nghĩa truth mới.

Một chỉnh nhỏ về ranh giới

  • Đ3 nên định nghĩa “minimum semantic contract” cho description theo entity type.
  • Đ4 chỉ enforce sự hiện diện + shape/checklist tối thiểu, không nên gánh logic semantic quá sâu.
  • Đ35 mở rộng specialized contract cho DOT vượt lên trên baseline của Đ3.

Tức là: Đ3 định nghĩa chuẩn, Đ4 chặn ở cửa sinh, Đ35 thêm điều khoản chuyên ngành. Cách chia này sạch và không chồng luật.

4) Trả lời 6 câu hỏi cụ thể

Câu 1 — Enforcement tại birth dùng governance_role (Đ29) đúng không?

Kết luận: Đồng ý, nhưng chỉ dùng như trục policy cấp collection; không dùng thay thế semantic rule của description.

Lý do:

  • Đ29 xác lập governance_role là nhãn thống nhất để phân mức quản trị collection: governed / observed / excluded.
  • Dùng lại governance_role để quyết định mức enforcement là hợp NT1 SSOT và tinh thần đơn giản hóa của Đ29.
  • Nếu tạo description_enforcement_map riêng thì rất dễ tái diễn 2 hệ hành chính song song — trái tinh thần Đ29.

Điều kiện kèm theo:

  • Chỉ nên dùng governance_role để quyết định mức cưỡng chế: BLOCK / WARN / EXEMPT.
  • Không nên suy rộng governance_role thành nơi quyết định description phải chứa gì; phần đó phải do Đ3/Đ35 định nghĩa.
  • Nên cho phép override rất hẹp ở dot_config cho rollout tạm thời, nhưng override phải có expiry/audit để không phá SSOT.

Khuyến nghị chốt:

  • governed = BLOCK
  • observed = WARN
  • excluded = EXEMPT
  • Có cờ rollout tạm thời trong config, nhưng config không được thay nghĩa của role, chỉ thay mode vận hành trong giai đoạn chuyển tiếp.

Câu 2 — Đ3 field classification có lỗi thời không?

Kết luận: Có dấu hiệu lỗi thời, nhưng chưa nên xử lý dứt điểm trong Track A.

Nhận định:

  • classification 5 giá trị trong Đ3 là di sản sớm, nay đã overlap với ít nhất 3 trục khác: Đ24 facets, Đ29 governance_role, Đ35 tier/domain.
  • Nếu sửa mạnh ngay trong Track A thì dễ làm trôi phạm vi từ “fix description” sang “cải tổ taxonomy”.

Khuyến nghị:

  • Track A: giữ nguyên field để tránh đụng dữ liệu rộng, nhưng ghi rõ là legacy / non-authoritative for new governance decisions.
  • Track B: thiết kế lộ trình deprecate chính thức.
    • classification trong Đ3 trở thành trường tương thích ngược hoặc trường hiển thị.
    • Truth phân loại mới tham chiếu Đ24 + Đ29 (+ Đ35 nếu là DOT).
  • Tuyệt đối tránh duy trì lâu dài 4 hệ phân loại ngang quyền.

Câu 3 — Backfill description bằng AI agent có vi phạm NT3 không?

Kết luận: Không xem là vi phạm nếu đóng khung đúng là ngoại lệ “công việc trí tuệ”, nhưng không được để AI ghi thẳng production truth không qua guard.

Căn cứ:

  • Hiến pháp v4.6.3 nêu NT3 là “DOT 100% (có ngoại lệ)” và chỉ rõ 5 ngoại lệ ghi trong Điều 33 §13.
  • Bản chất backfill description là công việc semantic/intellectual: đọc code, hiểu ngữ cảnh, tóm nghĩa. Đây không phải thao tác CRUD cơ học thuần túy mà bash DOT làm tốt.

Điều kiện để hợp hiến:

  1. AI chỉ đề xuất/generate description.
  2. Ghi vào hệ thống phải đi qua quy trình đã đăng ký (DOT wrapper hoặc batch write path có audit), không nhập tay lén.
  3. Có provenance + review status.
  4. Batch nhỏ + spot-check là đúng tinh thần NT9.

Khuyến nghị mạnh:

  • Không cần ép “AI phải biến thành bash DOT” ở khâu suy luận.
  • Nhưng khâu ghi nhận vào PG/registry phải đi qua DOT hoặc write path hợp pháp có audit.
  • Nên bổ sung vào dự thảo câu rõ: backfill semantic bằng AI là ngoại lệ NT3 ở pha suy luận, còn pha cập nhật dữ liệu vẫn phải đi qua hành lang vận hành hợp pháp.

Câu 4 — Keywords dùng Đ24 entity_labels hay tạo riêng?

Kết luận: Đồng ý dùng Đ24, không tạo keywords riêng.

Lý do:

  • NT1 SSOT: đã có entity_labels + label_rules thì không nên nhét keywords vào extra_metadata JSONB.
  • Keywords thực chất là một dạng classification facet cắt ngang. Đ24 là nơi tự nhiên nhất.
  • Làm riêng sẽ phá queryability, governance và audit.

Điều kiện:

  • Nên định nghĩa rõ “keyword labels” là facet/nhóm con nào để tránh lẫn với domain hoặc governance labels.
  • Nếu cần nhẹ, hãy tạo preset/rule nhẹ trong Đ24, không tạo storage mới.

Câu 5 — Thứ tự sửa Track A rồi backfill rồi Track B có đúng không?

Kết luận: Đúng, nhưng nên chèn thêm 1 bước giữa Đ4 và backfill.

Thứ tự khuyến nghị:

  1. Chốt định hướng.
  2. Sửa Đ3 (định nghĩa rule description).
  3. Sửa Đ35 (DOT-specific description contract).
  4. Sửa Đ4 (birth guard dựa trên rule đã có ở Đ3/Đ35).
  5. Tạo rule validator / checklist machine-checkable + rollout mode.
  6. Chạy pilot backfill mẫu nhỏ.
  7. Backfill diện rộng.
  8. Làm Track B.

Lý do đổi nhẹ:

  • Nếu sửa Đ4 trước khi chuẩn của Đ3/Đ35 rõ ràng, birth guard sẽ không biết enforce cái gì ngoài “không rỗng”.
  • Cần một bước pilot để tránh backfill 1277 row theo rule còn non.

Câu 6 — Sửa chui hay bump version?

Kết luận: Không đồng ý sửa chui. Nên bump version tối thiểu cho mỗi luật bị amend.

Lý do:

  • Hệ thống này đã ở mức governance cao, nhiều luật enacted, nhiều vòng Council; audit trail là tài sản chứ không phải overhead.
  • Giữ nguyên version mà thay nội dung substantive sẽ làm mờ lịch sử diễn giải, đặc biệt khi các DOT/trigger/enforcement thay hành vi runtime.
  • Điều 38 có thể chưa hoàn thiện PG-first, nhưng điều đó không phải lý do để bỏ version discipline.

Khuyến nghị thực dụng:

  • Không cần quy trình hành chính nặng ngay.
  • Nhưng mỗi amend substantive nên bump version/minor revision rõ ràng trong đầu tài liệu + changelog + effective date.
  • Có thể triển khai theo kiểu “lightweight version discipline” trước khi Đ38 hoàn thiện đủ.

5) Track A vs Track B

Đồng ý với Track A hiện tại

Ba mục Đ3 + Đ35 + Đ4 là blocking thật.

Nhưng nên kéo thêm 1 phần nhỏ từ Track B vào Track A

Kéo một phần hẹp của Đ24 vào Track A: ít nhất phải có review/provenance trạng thái cho output AI/backfill.

Không nhất thiết triển khai full classification_confidence cho toàn Đ24 ngay, nhưng với chiến dịch backfill description và/hoặc keyword auto-assign diện rộng, cần tối thiểu một trong hai:

  • review_status cho description/label AI-generated, hoặc
  • assigned_by + confidence/status đủ để không coi auto-output là truth tuyệt đối.

Nếu không kéo phần này vào trước backfill, rủi ro là:

  • sửa xong Đ3/Đ4/Đ35 nhưng dữ liệu backfill vẫn thiếu quality gate,
  • sau đó phải làm lại một vòng cleanup vì không biết cái nào AI sinh, cái nào người duyệt.

Đề xuất điều chỉnh tracks:

  • Track A: Đ3 + Đ35 + Đ4 + một lát cắt tối thiểu của Đ24 cho provenance/review gate.
  • Track B: Đ37 universal domain, Đ24 confidence đầy đủ, Đ39 alias, Đ43 section mới.

6) Rủi ro người đề xuất chưa nhìn hết

  1. Rule quá mềm, trigger không enforce được.

    • Nếu description standard chỉ là guideline văn xuôi, Đ4 không thể kiểm tra máy.
    • Cần định nghĩa tối thiểu kiểu checklist theo type, không cần NLP phức tạp.

  2. Enforce quá sớm gây nghẽn birth.

    • Với hệ thống đang có backlog 1277 row thiếu description, bật BLOCK ngay có thể làm nghẽn sinh mới.
    • Nên rollout: observed=WARN, governed có thể WARN→BLOCK theo phase.

  3. Description bị tối ưu để qua gate thay vì hữu ích cho Đ43.

    • Agent có thể sinh description “đúng form nhưng rỗng nghĩa”.
    • Cần spot-check chất lượng, không chỉ check kỹ thuật.

  4. Không có provenance cho AI-generated text.

    • Sau 2 tuần sẽ không biết cái nào con người xác nhận, cái nào AI tự sinh.

  5. Alias đặt ở Đ39 nhưng không nối về search/index pipeline.

    • Nếu chỉ thêm relation type mà không có consumer dùng alias trong retrieval/classification, hiệu quả thực tế thấp.

  6. Domain universal hóa ở Đ37 có thể đụng taxonomy hiện có.

    • Cần phân biệt rõ domain là “jurisdiction/business area” chứ không phải species hay label facet khác.

  7. Sửa chui tạo nợ audit và tranh cãi diễn giải.

    • Khi có bug post-enact, rất khó truy xem bug thuộc bản luật nào.

7) Kết luận hành động

Hội đồng đồng ý về nguyên tắc với hướng sửa

  • Thông qua định hướng tổng thể.
  • Thông qua assignment vào đúng luật chuyên môn.
  • Thông qua Track A là ưu tiên.

Điều kiện để sang vòng dự thảo

  1. Mô tả rõ description standard machine-checkable ở mức tối thiểu.
  2. Chốt stance: governance_role dùng cho mức enforce, không dùng thay semantic rule.
  3. Bổ sung provenance/review gate tối thiểu cho AI backfill trước khi chạy diện rộng.
  4. Bỏ phương án sửa chui; chuyển sang bump version nhẹ nhưng rõ ràng.

Phán quyết ngắn

  • Câu 1: Đồng ý, có điều kiện.
  • Câu 2: Có lỗi thời, nhưng defer xử lý lớn sang Track B.
  • Câu 3: Không vi phạm NT3 nếu coi là ngoại lệ trí tuệ và write path có audit.
  • Câu 4: Đồng ý dùng Đ24, không tạo keywords riêng.
  • Câu 5: Thứ tự cơ bản đúng, nhưng nên là Đ3 → Đ35 → Đ4 → pilot → backfill.
  • Câu 6: Không sửa chui; nên bump version.

8) Đề xuất 1 câu chốt cho vòng sau

“Track A chỉ được coi là hoàn chỉnh khi description standard đã đủ để máy kiểm tra tối thiểu, AI backfill có provenance/review gate, và mọi thay đổi luật substantive đều có version/changelog rõ ràng.”