Incomex AI Portal
KB-59DF

GPT Review Round 1 — Điều 24 Luật Nhãn v1.0 (2026-03-15)

8 min read Revision 1

GPT Review Round 1 — Điều 24: Luật Nhãn v1.0

Ngày: 2026-03-15 Nguồn: Incomex Hội đồng AI (GPT) Phạm vi: Phản biện kiến trúc, KHÔNG sửa luật gốc

Đã đọc

  1. knowledge/dev/architecture/label-law.md
  2. knowledge/dev/architecture/index.md (Điều 24 tóm tắt qua search)
  3. knowledge/dev/architecture/composition-level-law.md
  4. knowledge/dev/architecture/layer3-information-law.md
  5. knowledge/dev/ssot/operating-rules.md

Kết luận tổng quát

🟢 Đồng ý hướng đi tổng thể. Luật Nhãn đi đúng hướng hơn hẳn tình trạng hiện tại vì nó giải quyết đúng gốc: chuẩn hoá vocabulary, đưa nhãn về 1 SSOT, và biến “Cùng nhóm” thành quan hệ tính được từ dữ liệu thay vì text tự do.

Tuy nhiên để triển khai an toàn và đơn giản lâu dài, tôi thấy có 3 điểm cần sửa và 4 điểm nên cân nhắc.

1. Thiết kế 5 chiều có đủ không?

🟢 Đồng ý phần lớn

5 chiều hiện tại là đủ để khởi động:

  • Chuyên môn
  • Vai trò
  • Hành động
  • Phạm vi
  • Giai đoạn

Bộ này bao phủ được nhu cầu hiện tại của hệ thống kiến trúc + registry + DOT.

🟡 Nên cân nhắc

Thiếu duy nhất một chiều có thể business sẽ sớm cần là “Đối tượng phục vụ / audience” hoặc “đối tượng tác động chính”. Ví dụ:

  • công cụ phục vụ AI agent hay admin hay user cuối?
  • workflow phục vụ nội bộ hay khách hàng?

Tôi không đề nghị thêm ngay ở v1.0 vì sẽ làm hệ phình ra quá sớm. Nhưng nên ghi rõ trong luật: chiều thứ 6 có thể mở sau, không phá schema.

Kết luận câu 1

  • Hiện tại: đủ để bắt đầu
  • Dài hạn: có thể cần thêm 1 chiều “audience/target actor”

2. 3 tầng cha-con-cháu cho chiều Chuyên môn có quá phức tạp không?

🟢 Đồng ý

Không quá phức tạp. Với mục tiêu ~1200 nhãn business thì 3 tầng là mức hợp lý nhất.

Lý do

  • 1 tầng phẳng: chắc chắn rối.
  • 2 tầng: đủ cho kỹ thuật hiện tại, nhưng sẽ sớm vỡ khi business mở rộng.
  • 3 tầng: đủ sâu để scale, vẫn còn dễ hiểu với Tree View Directus.

🔴 Cần sửa

Không nên để depth là field người dùng/agent tự điền logic nghiệp vụ. depth nên là derived field hoặc ít nhất bị ràng buộc bằng CHECK/trigger theo parent_id.

Nếu không, rất dễ có dữ liệu:

  • parent_id trỏ đúng nhưng depth sai
  • hoặc depth=2 gắn thẳng dưới root

Đề xuất

  • Giữ self-ref 3 tầng như hiện tại
  • Thêm rule cứng:
    • root: parent_id IS NULL, depth=0
    • con: parent.depth=0, depth=1
    • cháu: parent.depth=1, depth=2
    • cấm depth>2 ở v1.0

3. Schema 5 collections — có thừa/thiếu gì?

taxonomy_facets

🟢 Đồng ý.

taxonomy

🟢 Đồng ý.

entity_labels

🟢 Đồng ý, nhưng nên thêm cột facet_id hoặc enforce gián tiếp để tối ưu conflict check. Hiện có thể join qua taxonomy, vẫn đúng. Không bắt buộc thêm cột nếu muốn tối giản.

label_rules

🟢 Đồng ý.

taxonomy_matrix

🟡 Nên cân nhắc mạnh

Tôi nghiêng về GIỮ riêng taxonomy_matrix, không merge vào taxonomy_facets.

Lý do

taxonomy_matrix là quan hệ giữa:

  • chiều (facet)
  • lớp cấu tạo (composition_level)
  • requirement

Đây là dữ liệu 2 chiều độc lập, không phải thuộc tính của facet. Merge vào taxonomy_facets sẽ làm facet phình thành JSON hoặc nhiều cột cứng, khó query và khó enforce.

Kết luận câu 3

  • Không thừa collection nào rõ ràng
  • taxonomy_matrix nên giữ riêng
  • Điểm thiếu duy nhất: ràng buộc mạnh hơn cho cây taxonomy và xung đột gán nhãn

4. Quy tắc gán tự động — có lỗ hổng nào?

🟢 Đồng ý hướng 3 tầng

collection → keyword → AI đề xuất là đúng.

🔴 Cần sửa 1: xung đột cùng chiều chưa được chốt luật đủ rõ

Hiện tài liệu nói cardinality theo chiều, nhưng chưa khóa rõ khi rule đụng nhau:

  • chiều single: match 2 rules cùng chiều thì sao?
  • collection rule + keyword rule cùng chiều thì merge hay override?

Đề xuất luật cứng

  • Nếu facet là single:
    • lấy rule priority thấp nhất (ưu tiên cao nhất)
    • nếu đồng priority mà khác result → ghi system_issues để user duyệt, KHÔNG auto chọn bừa
  • Nếu facet là multiple:
    • gộp tất cả labels hợp lệ
    • nhưng cấm gán label cha + label con cùng một nhánh trong cùng 1 lần auto nếu không có chủ ý

🔴 Cần sửa 2: pattern trên tên + mô tả chưa đủ tin cậy nếu không có boundary

Regex kiểu data, flow, check rất dễ match quá rộng.

Đề xuất

  • Ưu tiên rule theo collection trước
  • keyword rule phải có review coverage report trước khi bật active
  • thêm cột thống kê cho rule: match_count, last_matched_at hoặc ít nhất DOT report phải show rule nào match bao nhiêu entity

🟡 Nên cân nhắc

Nên coi rule theo relation là phase 2. V1 chỉ cần collection + keyword là đủ.

5. Label của Label — quản lý đã đủ chưa?

🟢 Đồng ý phần lớn

Ý tưởng dùng self-ref + recursive CTE là đúng.

🔴 Cần sửa

Hiện còn thiếu 3 ràng buộc chống dữ liệu bẩn:

  1. Cycle prohibition: label không được làm cha của chính nó qua vòng lặp
  2. Same-facet rule: parent và child phải cùng facet_id
  3. Depth boundary: cấm quá 3 tầng ở v1.0

Nếu thiếu 3 cái này, tree sẽ hỏng rất nhanh dù CTE vẫn chạy.

Kết luận câu 5

  • Hướng quản lý label của label: đúng
  • Ràng buộc dữ liệu cây: chưa đủ chặt

6. Migration từ 7 dropdown hiện có — risk gì?

🟡 Nên cân nhắc

Backward compatibility về tinh thần là ổn, nhưng migration có 3 rủi ro:

  1. Alias mapping risk

    • quản_lý_ai vs ai_management
    • nếu không có bảng map cũ→mới, sẽ mất lịch sử nghĩa

  2. Dual-write / dual-read risk

    • giai đoạn chuyển tiếp nếu vừa dropdown cũ vừa taxonomy mới mà không chốt nguồn sự thật tạm thời, dữ liệu sẽ lệch

  3. Over-migration risk

    • không phải mọi dropdown cũ đều cần migrate 1:1 thành facet label
    • có cái là metadata nội bộ, không nên ép thành taxonomy label

Đề xuất

  • migration theo từng nhóm field
  • mỗi field cũ phải có quyết định rõ:
    • bỏ hẳn
    • map sang label nào
    • hay giữ làm metadata riêng

7. So với SKOS / Kubernetes labels / Jira — thiếu gì?

🟢 Đồng ý

Giải pháp hiện tại đã học đúng tinh thần ngành:

  • SKOS: broader/narrower
  • Kubernetes: controlled vocabulary + policy
  • Jira: grouping thực dụng

🟡 Thiếu 3 thứ nhỏ nhưng quan trọng

  1. Preferred label / alias / deprecated label

    • SKOS rất mạnh ở chỗ này
    • hiện taxonomy mới có name, name_en, chưa có alias/deprecated replacement rõ ràng

  2. Conflict policy rõ ràng

    • K8s mạnh ở enforcement
    • luật hiện còn mềm ở chỗ collision giữa rules cùng chiều

  3. Canonical replacement path

    • khi nhãn bị deprecated, entity đang dùng nhãn đó sẽ chuyển sang nhãn nào?
    • nên liên thông với Luật Chống Trùng

Đề xuất tối giản

Không cần framework ngoài. Chỉ cần thêm vào taxonomy:

  • canonical_label_code nullable hoặc replaced_by
  • alias table thì chưa cần ngay; có thể phase 2

Phán quyết theo mức độ

🔴 Cần sửa

  1. Chốt luật conflict resolution cho facet single vs multiple
  2. Thêm ràng buộc cây taxonomy: same-facet, depth<=2, no-cycle
  3. Không để depth là dữ liệu tự do không kiểm soát

🟡 Nên cân nhắc

  1. Ghi rõ khả năng mở facet thứ 6 trong tương lai (audience/target actor)
  2. Rule relation để phase 2
  3. Có cơ chế alias/deprecate/replaced_by cho label
  4. Có thống kê hiệu quả rule để tránh regex match quá rộng

🟢 Đồng ý

  1. 5 chiều hiện tại đủ để khởi động
  2. 3 tầng chuyên môn là hợp lý
  3. Giữ taxonomy_matrix là collection riêng
  4. 5 collections tổng thể là tối giản hợp lý
  5. Nhãn là đầu vào, quan hệ là đầu ra — đúng hướng kiến trúc

Kết luận cuối

🟢 Đồng ý kiến trúc tổng thể. 🔴 Chưa nên triển khai ngay nếu chưa khóa chặt 3 điểm: conflict rules, tree constraints, depth governance.

Sau khi chốt 3 điểm này, tôi đánh giá Điều 24 đủ chắc để bước sang round phản biện kỹ thuật PG/Directus.