Incomex AI Portal
KB-6A90

GPT Review Round 2 — Luật Loài + Collection

14 min read Revision 1
reviewgptspeciescollectionround2architecturecritical

GPT Review Round 2 — Luật Loài + Collection

Ngày: 2026-03-20 Vai trò: Kiến trúc sư phản biện Trọng tâm Round 2: phản biện các quyết định của Orchestrator, chốt ma trận 2 trục collection, soft enforcement, cheat sheet 10 dòng, pilot plan Tài liệu đã đọc qua Agent Data:

  • knowledge/dev/architecture/species-collection-law-draft.md
  • knowledge/dev/reports/gpt-review-species-collection-round1-2026-03-20.md
  • knowledge/dev/architecture/information-atom-law.md
  • knowledge/dev/architecture/composition-level-law.md
  • knowledge/dev/architecture/label-law.md
  • knowledge/dev/architecture/entity-lifecycle.md
  • knowledge/dev/ssot/operating-rules.md

Kết luận ngắn

Round 2 đã tiến đúng hướng hơn Round 1. Tuy nhiên vẫn còn 3 chỗ có thể sai nặng nếu không khóa lại:

  1. Soft enforcement rất dễ trượt thành “cho sai sống lâu” nếu không có SLA, owner và hàng đợi xử lý rõ ràng.
  2. Ma trận 2 trục collection đúng hơn mô hình 5 nhóm, nhưng vẫn chưa đủ nếu thiếu trục phụ managed_entity_kind / native_resource_kind; nếu không vài collection sẽ “lọt nghĩa”.
  3. Bác ý naming/Assembly First quá mạnh có thể đúng ở mục tiêu, nhưng sai ở nhịp triển khai. Nền móng mới không có nghĩa được phép tạo chồng hệ song song bừa bãi.

I. Phản biện các quyết định mục B (chỗ Orchestrator có thể SAI)

1) 🔴 Bác GPT #12 quá mạnh: “1 tên chính theo collection + alias đơn giản” vẫn có rủi ro ontology lệ thuộc storage

Vấn đề: Quyết định giữ 1 tên chính theo tên collection giúp đơn giản giai đoạn đầu, nhưng nếu dùng nó làm quy tắc mặc định thì species bị neo vào storage.

Lý do: Collection là quyết định vật lý lưu trữ. Species là ontology gốc. Hai thứ này thường trùng ở giai đoạn đầu nhưng có thể tách khi refactor, merge, split, hoặc khi 1 collection chứa nhiều loài. Nếu tên chính luôn đi theo collection, lần đổi collection sẽ kéo rối tên species hoặc ngược lại.

Giải pháp: Không cần 3 lớp tên đầy đủ như tôi đề xuất Round 1, nhưng tối thiểu phải có:

  • species_name = tên ontology chính
  • collection_name = storage container hiện tại
  • alias = optional

Tức là không bắt species_name phải bằng collection_name. Cho phép mặc định giống nhau, nhưng không đồng nhất về luật.

2) 🟡 Bác GPT #17 chưa sai hoàn toàn, nhưng cần khóa lại câu chữ roadmap

Vấn đề: Orchestrator bác ý “chưa nên làm sớm” vì chiến lược dài hạn bắt buộc là đa chiều.

Lý do: Bác như vậy về chiến lược là đúng. Nhưng rủi ro nằm ở văn bản: agent đọc roadmap có thể hiểu “đa chiều là next step gần” và nhảy làm giao diện/ma trận trước khi ontology ổn định.

Giải pháp: Giữ đa chiều trong roadmap, nhưng phải ghi rõ:

  • Roadmap strategic yes
  • Execution gate no cho đến khi hoàn tất bucket 100%, pilot pass, resolution rate đạt ngưỡng

Nói cách khác: không gạt bỏ đa chiều, nhưng phải khóa điều kiện mở khóa.

3) 🔴 Bác GPT #15 có phần sai: “luật nền tảng” không miễn trừ Assembly First

Vấn đề: Lập luận “Luật Loài là nền móng nên PHẢI tạo mới; Assembly First chỉ áp cho feature” là quá rộng.

Lý do: Điều 0-B đã nói rất rõ: loại nào Directus/PG đã quản lý sẵn thì không dựng hệ song song. Luật nền tảng vẫn phải tôn trọng nguyên tắc dùng native resource khi đủ tốt. Nếu không, danh nghĩa “nền móng” sẽ trở thành giấy phép để tạo chồng registry mới lên directus_fields, activity logs, system tables.

Giải pháp: Sửa cách nói thành:

  • Được phép tạo registry mới cho ontology root
  • Không được phép tạo song song cho loại mà native system đã đủ làm SSOT vật lý

Tức là Luật Loài được tạo mới, nhưng phạm vi của nó phải là overlay ontology, không phải hệ quản trị thay thế toàn bộ native resources.

4) 🟡 Bác Gemini #3 là hợp lý ở hiện tại, nhưng draft nên cài sẵn ngưỡng chuyển pha

Vấn đề: Chưa cần materialized view ở ~1500 records là đúng.

Lý do: Sai không nằm ở quyết định hiện tại, mà ở chỗ nếu dự thảo không ghi threshold chuyển pha, tương lai đội triển khai lại tranh luận từ đầu.

Giải pháp: Ghi một câu rất ngắn trong TD/roadmap:

  • < 50k rows hoặc query p95 < 300ms: dùng view/query trực tiếp
  • >= 50k hoặc p95 vượt ngưỡng: xem xét materialized view / snapshot

Không cần sửa kiến trúc hiện tại, chỉ cần cài điểm kích hoạt.

II. Ma trận 2 trục collection — gán cụ thể các collection được hỏi

Quy ước 2 trục

  • storage_role: primary | junction | log | system
  • governance_role: governed | observed | excluded

1) entity_labels

Đề xuất: junction × governed

Lý do: Về lưu trữ nó là junction table. Nhưng về governance nó là hạ tầng phân loại cốt lõi của Điều 24, không thể coi chỉ là “COUNT(*) cho biết”. Nó cần audit, integrity check, duplicate rule, orphan label check.

2) universal_edges

Đề xuất: junction × observed hoặc junction × governed tùy phạm vi hiện tại

Lý do: Nếu universal_edges là graph hạ tầng để quan sát liên kết rộng và chưa là đối tượng vận hành cứng, đặt observed an toàn hơn. Nếu đã dùng nó để enforce logic điều hướng / kiểm toán bắt buộc, nâng lên governed.

Khuyến nghị: Mặc định Round 2 nên để junction × observed cho an toàn. Chỉ nâng khi có rule enforce thật.

3) lifecycle_log

Đề xuất: log × observed

Lý do: Đây là nhật ký vận hành. Không nên đưa vào governed vì sẽ tạo gánh nặng lifecycle cho chính log.

4) trigger_registry

Đề xuất: primary × governed

Lý do: Trigger là đối tượng kiến trúc được quản trị, có code, purpose, lifecycle, ảnh hưởng hệ thống. Không phải log, không phải system table thuần.

5) directus_fields

Đề xuất: system × observed

Lý do: Điều 0-B đã chốt field là native-managed resource, natural key, không dựng hệ song song. Vì vậy không nên xếp governed theo nghĩa full-registry mới. Quan sát, audit, mapping species được; nhưng SSOT vật lý vẫn là Directus.

III. Có collection nào không rơi vào ma trận 2 trục không?

5) 🔴 Có — nếu chỉ dùng 2 trục, một số collection vẫn thiếu nghĩa quản trị

Vấn đề: 2 trục giải được rất nhiều, nhưng chưa diễn đạt được sự khác nhau giữa:

  • managed entity registry
  • native-managed resource mirror
  • derived/virtual view
  • policy/config registry

Lý do: Ví dụ meta_catalog, collection_registry, taxonomy_matrix, v_registry_counts không chỉ khác chỗ lưu trữ mà còn khác bản chất nguồn sự thật.

Giải pháp: Giữ ma trận 2 trục làm lõi, nhưng thêm 1 field phụ bắt buộc:

  • source_kind: registry | native | derived | policy

Đây không phải trục phân loại ngang hàng, mà là metadata phụ để tránh collection “rơi nghĩa”. Không có field này, agent vẫn lẫn giữa bảng thật, bảng dẫn xuất và bảng luật.

IV. Soft enforcement — phản biện + thiết kế cụ thể

6) 🔴 Rủi ro lớn nhất: soft enforcement biến thành “kho chứa lỗi vĩnh viễn”

Vấn đề: Cho INSERT + gắn pending_audit là thực dụng, nhưng nếu không có SLA và assignee thì pending sẽ thành bãi rác.

Lý do: Mọi hệ thống soft gate đều chết vì backlog, không chết vì kỹ thuật trigger.

Giải pháp: pending_audit phải đi cùng 4 thứ bắt buộc:

  • audit_status (clean | pending | reviewed | waived | fixed)
  • audit_reason_code
  • audit_deadline
  • audit_owner

7) 🔴 Không nên đặt pending_audit trực tiếp vào mọi business record như một field rollout-wide

Vấn đề: Nếu thêm field vào mọi collection, chi phí schema change rất lớn, đụng Directus config, permissions, UI, imports, API contracts.

Lý do: Luật này là nền ontology; không nên mở hàng trăm migration chỉ để treo cờ audit.

Giải pháp: Dùng bảng audit riêng là chuẩn hơn:

  • entity_audit_queue
    • id
    • entity_ref (code hoặc natural key)
    • collection_name
    • species_guess
    • issue_type
    • audit_status
    • owner
    • deadline
    • created_by_trigger
    • resolved_at

Business record giữ sạch. Audit nằm ngoài.

8) 🟡 Khi nào mới cần field ngay trên record?

Vấn đề: Có một số collection trọng yếu có thể cần hiển thị cờ đỏ ngay trong UI.

Lý do: Trigger registry, collection registry, entity_species có thể đáng để hiện audit_status trực tiếp vì đây là registry lõi.

Giải pháp: Quy tắc:

  • Default: audit ở bảng riêng
  • Exception: chỉ 3 registry lõi (entity_species, collection_registry, có thể meta_catalog) mới có field inline audit_status

9) 🟡 PG trigger hay Directus flow?

Vấn đề: Nếu dùng Directus flow thì có nguy cơ bypass khi insert ngoài Directus.

Lý do: Luật này đang xử lý “đẻ bừa ngoài governance”, nên bắt lỗi phải nằm ở tầng thấp nhất có thể.

Giải pháp:

  • PG trigger: phát hiện và ghi queue
  • Directus flow: chỉ để thông báo/UI/task creation

Nguồn phát hiện phải là PG, không phải Flow.

10) 🔴 Ai xử lý pending_audit?

Vấn đề: Nếu câu trả lời là “manual” thì sẽ chết backlog. Nếu là “auto” hoàn toàn thì sẽ sửa sai âm thầm.

Lý do: Đây là loại việc nửa cấu trúc, nửa phán đoán.

Giải pháp: Phải chia 3 tầng xử lý:

  • Auto-resolve: case rõ (đủ discriminator, map chắc chắn)
  • Agent-propose: case mơ hồ vừa phải, AI đề xuất species/bucket/owner
  • Human-finalize: case ontology conflict / species mới / collection đa loài phức tạp

Không được chọn 1 trong 2 cực đoan.

V. Agent cheat sheet ≤10 dòng

11) 🟢 Có thể tóm trong 10 dòng — nghĩa là luật đã bắt đầu đủ sắc

1. Mỗi object trong phạm vi governance phải resolve được đúng 1 species hoặc bị đưa vào audit queue.
2. Species là ontology gốc, đứng TRƯỚC Điều 24; không phải facet thứ 7.
3. Khi tạo loài mới: kiểm tra loài cũ, quét trùng nghĩa, giải thích vì sao loài cũ không đủ.
4. Species định nghĩa collection được phép; runtime create chọn species trước, system chọn collection sau.
5. Collection phải có 2 nhãn: storage_role và governance_role.
6. Collection đa loài chỉ hợp lệ nếu có mapping + discriminator rule máy đọc được.
7. Không hard-fail insert; record mơ hồ được ghi vào audit queue để tự phát hiện và tự phục hồi.
8. Count không lưu trong registry nóng; đọc từ PG view/source truth.
9. meta_catalog tiếp tục chạy song song; entity_species là ontology gốc, chưa thay thế ngay.
10. Agent không chắc species/collection => không tự đoán kín; phải tạo issue/audit record.

Nhận xét: Tóm được trong 10 dòng. Chưa cần đơn giản hóa thêm ở mức luật; chỉ cần contract hóa implementation.

VI. Pilot plan cụ thể

12) 🔴 Chọn pilot sai sẽ cho kết quả giả đẹp

Vấn đề: Nếu chọn 3 collection quá “sạch”, pilot sẽ pass giả.

Lý do: Luật mới sinh ra để xử lý vùng mập mờ. Pilot phải đụng đúng vùng khó.

Giải pháp: Chọn 3 loại có tính đại diện khác nhau:

Pilot A — dot_tools

  • Loại: primary × governed
  • Lý do chọn: collection thuần, 1 loài khá rõ, có code/lifecycle, dễ kiểm baseline
  • Mục tiêu: chứng minh luồng species → collection → audit queue hoạt động trơn ở case sạch

Pilot B — entity_labels

  • Loại: junction × governed
  • Lý do chọn: junction chiến lược, dễ bị hạ thấp thành “chỉ bảng nối” nhưng thực ra là hạ tầng governance cốt lõi
  • Mục tiêu: chứng minh ma trận 2 trục không làm mất collection chiến lược

Pilot C — directus_fields

  • Loại: system × observed
  • Lý do chọn: đại diện native-managed resource; đây là chỗ kiểm tra Assembly First thật sự
  • Mục tiêu: chứng minh Luật Loài không biến native resource thành registry song song

13) 🟡 Có thể thêm pilot dự bị nếu muốn test multi-species thật

Vấn đề: 3 pilot trên chưa kiểm tra đủ collection đa loài nếu hiện tại chưa có case thật rõ.

Giải pháp: Có thể thêm pilot D không bắt buộc trên collection nghi ngờ đa loài như checkpoint_types nếu thực tế có nhiều species con, hoặc tạo sandbox test collection đa loài để kiểm tra discriminator rule.

14) 🔴 Tiêu chí “pilot thành công” phải là tiêu chí phủ rủi ro, không phải chỉ “không lỗi”

Vấn đề: Nếu chỉ đo insert thành công hoặc UI hiện đúng thì quá nông.

Giải pháp: Pilot pass khi đồng thời đạt:

  1. Classification pass

    • 100% records trong phạm vi pilot resolve được species hoặc vào audit queue, không có record “im lặng không nhãn”

  2. No silent failure

    • Mọi case không resolve được đều sinh entity_audit_queue record

  3. No double SSOT drift

    • Không xuất hiện count/hard-state mới mâu thuẫn với source truth cũ

  4. Nuxt verification pass

    • UI/Registries hiển thị đúng role, species, trạng thái audit so với PG

  5. Operational pass

    • Audit queue có owner, SLA, và ít nhất 1 vòng resolve end-to-end thành công

  6. Assembly pass

    • Với directus_fields, không sinh registry song song full-copy

  7. Rollback pass

    • Tắt luật/pilot không làm vỡ collection gốc

VII. Kết luận phản biện Round 2

Chốt cái Orchestrator đang đúng

  • Loài đứng trước Điều 24
  • Giữ meta_catalog song song
  • Bỏ record_count khỏi entity_species
  • Chuyển 5 nhóm phẳng sang 2 trục
  • Dùng mapping riêng cho collection đa loài
  • Chia audit fault thành 3 loại
  • Yêu cầu 3 hiện thân của luật

Chốt cái Orchestrator có thể đang sai hoặc chưa khóa đủ

  1. Soft enforcement chưa có cơ chế chống backlog
  2. 2 trục collection chưa đủ nếu thiếu source_kind phụ
  3. Bác Assembly First quá mạnh — nền móng mới vẫn phải tôn trọng native-managed resources
  4. Naming vẫn đang bị neo quá sát vào collection
  5. Roadmap đa chiều cần execution gate rõ ràng

Phán quyết

Round 2 đã đủ tốt để lên v0.4, nhưng chỉ nếu bổ sung 4 khóa an toàn:

  • entity_audit_queue + SLA + owner
  • source_kind phụ cho collection registry
  • câu ngoại lệ Assembly First được viết lại cho chuẩn
  • điều kiện mở khóa roadmap đa chiều

Nếu thiếu 4 khóa này, v0.4 vẫn có nguy cơ triển khai xong rồi backlog pending_audit phình ra, agent hiểu ma trận 2 trục chưa đủ sâu, và ontology mới tiếp tục phụ thuộc storage cũ.