Incomex AI Portal
KB-5356

GPT Review — Điều 0-B: Luật Phân tầng Vật chất Thông tin (2026-03-13)

9 min read Revision 1

GPT Review — Điều 0-B: Luật Phân tầng Vật chất Thông tin

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

Tài liệu đã đọc

  1. knowledge/dev/architecture/composition-level-law.md — Điều 0-B v2.0 DRAFT
  2. knowledge/dev/architecture/information-atom-law.md — Luật Nguyên tử Thông tin v1.1
  3. knowledge/dev/architecture/index.md — Hiến pháp Kiến trúc v3.2 (qua searchKnowledge context)
  4. knowledge/dev/planning/review-composition-level-law.md — Yêu cầu Review Điều 0-B
  5. knowledge/dev/ssot/urgent-pg-view-architecture.md — KHẨN CẤP: PG VIEW phải qua Directus, không bypass

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

Điều 0-B đi đúng hướng vì giải được vấn đề S111: “đếm phẳng mọi thứ thành nguyên tử” làm mất khả năng quản trị theo tầng. Tuy nhiên hiện tồn tại 1 mâu thuẫn pháp lý lớn với Điều 0 gốc: Điều 0-B đang chuyển từ mô hình "mọi entity có ID đều là nguyên tử" sang mô hình "chỉ đơn vị không chứa entity khác mới là nguyên tử". Nếu không tuyên bố rõ đây là luật phân loại chồng lên atom law hoặc phiên bản thay thế một phần Điều 0, hệ sẽ có hai định nghĩa nguyên tử cạnh tranh.

Nhận xét chi tiết

1. Entity nào đang phân sai tầng / còn mập mờ

  • ND (workflow step / node): đang để ở Tầng 2 (phân tử), nhưng nếu node có trigger, state transition, guard condition thì nó đã có hành vi cục bộ; như vậy nó tiệm cận “hợp chất mini”, không còn là phân tử thuần.
  • PG (page/route): đang để Tầng 2, nhưng page thường chỉ là container render + config. Nếu page không tự điều phối hành vi mà chỉ lắp module/components, xếp Tầng 2 tạm ổn. Nhưng page có loader/action/permission orchestration thì sẽ vượt sang Tầng 3. Cần quy tắc phân biệt “page tĩnh” và “page điều phối”.
  • M (module): đang để Tầng 3 theo logic “components + logic”. Đồng ý khi module có state/permission/data orchestration. Nhưng module UI thuần presentational nên là Tầng 2. Hiện định nghĩa module đang quá rộng.
  • CPI (checkpoint instance): đang để Tầng 2. Tôi thấy hợp lý nếu nó là “binding” của CP vào context. Nhưng nếu CPI có lifecycle riêng, actor riêng, evidence riêng, transition riêng thì nó là nguyên tử hoặc hợp chất nhỏ chứ không còn là phân tử.
  • CAT (danh mục hệ thống): đang để Tầng 2, nhưng mô tả “chứa metadata per loại” chưa đủ rõ. Nếu mỗi CAT chỉ là một record định nghĩa loại thì nó giống nguyên tử hơn là phân tử.
  • REC (bản ghi dữ liệu nghiệp vụ): đưa thẳng vào Tầng 1 là hợp logic theo Điều 0-B, nhưng phải khóa rõ: chỉ áp dụng cho record nghiệp vụ độc lập có ID, không kéo theo mọi dòng junction/log/system row.
  • WCR: chuyển sang Tầng 3 là đúng hơn Điều 0 gốc, vì tài liệu review và Điều 0-B đều mô tả rõ có comments + quy trình duyệt + orchestration phía sau.

2. Lỗ hổng logic trong quy tắc phân loại

Có 3 lỗ hổng chính.

(a) “Chứa X -> tầng Y” chưa đủ, vì còn thiếu trục “hành vi”.
Hiện luật dùng 2 tiêu chí trộn với nhau: cấu tạo (contains) và động học (behavior/process). Trường hợp node/module/page sẽ mơ hồ ngay. Nên tách thành ma trận 2 trục:

  • Trục A: cấu tạo = chứa hạ nguyên tử / nguyên tử / phân tử
  • Trục B: hành vi = không có / có hành vi cục bộ / có orchestration đa bước

Khi đó phân loại ổn định hơn.

(b) Điều 0 gốc nói CPS/WF/M vẫn là nguyên tử theo nghĩa quản trị ID, còn Điều 0-B nói chúng là phân tử/hợp chất theo nghĩa cấu trúc. Đây không hẳn sai, nhưng phải công bố là hai hệ phân loại khác nhau:

  • Identity layer: entity có ID = atom quản trị theo Điều 0
  • Composition layer: atom/molecule/compound theo cấu tạo trong Điều 0-B

Nếu không tách hai hệ này, developer sẽ hỏi: “WF-001 rốt cuộc là nguyên tử hay hợp chất?” và cả hai văn bản đều đúng theo nghĩa riêng nhưng mâu thuẫn khi triển khai code.

(c) “Không ngoại lệ” là quá cứng ở thời điểm hiện tại.
Thực tế có đối tượng biên như Node, Module, Page, Checkpoint Instance, Relation Entity. Nên thay “không ngoại lệ” bằng “không ngoại lệ ở cấp luật, nhưng có tiêu chí phân xử cho edge cases”.

3. Naming: nguyên tử / phân tử có gây nhầm cho developer?

Có, ở 2 mức:

  • Mức pháp lý: Điều 0 gốc đã dùng “nguyên tử” cho mọi entity có ID. Điều 0-B lại dùng “nguyên tử” cho tầng cấu tạo thấp nhất. Cùng một từ, hai nghĩa.
  • Mức kỹ thuật: developer sẽ dễ map “atom = small component” theo React/design system, khác với “atom = entity có ID”.

Đề xuất:

  • Giữ metaphor vật lý cho tầng tư duy tổng thể.
  • Nhưng trong field kỹ thuật nên đeo nhãn kép: identity_class và composition_level.
  • Trên UI/DB có thể hiển thị: identity_class=managed_entity, composition_level=atom|molecule|compound.

Như vậy vừa giữ tinh thần vật lý, vừa giảm hiểu nhầm khi code.

4. 1000+ fields = 1000+ nguyên tử, có vấn đề không?

Không phải vấn đề về mô hình, nhưng là vấn đề về vận hành.

Theo Điều 0 gốc, một nguyên tử phải có ID, metadata, quan hệ, Lớp 3. Nếu áp đầy đủ chuẩn này lên 1000+ FLD thì chi phí quản trị sẽ rất lớn. Vì vậy cần chia 2 mức quản trị trong cùng Tầng 1:

  • Atom-core: CP, DOT, AGT, DEP, CMT... cần đủ Lớp 3 riêng và governance mạnh.
  • Atom-mass: FLD số lượng lớn, được quản trị theo template/bulk rules, không bắt buộc UI Lớp 3 giàu như workflow/task.

Nói cách khác: Field là nguyên tử, nhưng không nên bắt Field hưởng cùng mức UI/governance với Workflow.

5. Lớp 3 query PG trực tiếp, không cache — performance?

Về nguyên tắc dữ liệu sống, tôi đồng ý. Điều 0-B đúng khi nói “query = sự thật”. Nhưng cần chỉnh 1 điểm quan trọng theo tài liệu khẩn cấp S111:

  • knowledge/dev/ssot/urgent-pg-view-architecture.md nhấn mạnh PG view phải qua Directus, KHÔNG bypass.

Vì vậy công thức đúng nên là:

  • Source of truth = PostgreSQL quan hệ sống
  • Access path = Directus/API layer
  • Cache = optional acceleration layer, không phải source of truth

Với scale hiện tại (~1500 atom, ~300 molecule, recursive depth <= 4), query trực tiếp vẫn chịu được nếu:

  • index đúng FK/M2M,
  • giới hạn depth,
  • không UNION ALL bừa bãi qua quá nhiều collection,
  • không render toàn bộ graph một lúc.

Nhưng khi lên 10K+ entity, bottleneck sẽ xuất hiện ở:

  • recursive CTE nhiều nhánh,
  • fan-out USED_BY / DEPENDS_ON lớn,
  • cross-collection normalization,
  • N+1 API calls từ Nuxt.

Do đó tôi khuyến nghị:

  • Không cache summary gốc của entity graph như truth-store riêng.
  • Nhưng có thể dùng materialized projection / precomputed adjacency / denormalized read models cho màn hình nặng, miễn regeneration tự động và không thay PG làm SSOT.

6. Thiếu gì, cần bổ sung gì?

Thiếu 6 thứ quan trọng.

(1) Thiếu tuyên bố pháp lý hòa giải với Điều 0 gốc.
Phải viết rõ Điều 0-B là “phân tầng cấu tạo”, không thay thế định nghĩa quản trị-ID của Điều 0, hoặc tuyên bố chính thức rằng Điều 0-B sửa một phần Điều 0.

(2) Thiếu decision table cho edge cases.
Cần bảng phân xử cho ND, M, PG, CPI, CAT, DEP, WCR. Không có bảng này, mỗi dev sẽ tự diễn giải.

(3) Thiếu rule enforce khi tạo collection/type mới.
Không chỉ thêm composition_level; cần checklist bắt buộc:

  • prefix
  • registry
  • owner
  • lifecycle
  • parent/child semantics
  • behavior class
  • layer-3 query profile

(4) Thiếu distinction giữa entity loại và entity bản ghi.
Trong tài liệu đang đan xen “Field” như type và “FLD-0042” như instance. Cần tách dứt khoát:

  • entity type definition
  • entity instance record
  • entity registry row

(5) Thiếu chính sách hiển thị Lớp 3 theo tier.
Không thể bắt mọi tầng có cùng schema hiển thị. Nên chuẩn hóa “view contract” riêng cho atom / molecule / compound.

(6) Thiếu tiêu chí khi nào dùng relation native FK/M2M, khi nào dùng DEP.
Điều 0-B có nói DEP bổ sung, không thay FK; đây là đúng. Nhưng cần thêm luật quyết định để tránh lạm dụng DEP thành “sọt rác quan hệ”.

7. Rủi ro lớn nhất

Rủi ro lớn nhất không phải performance. Rủi ro lớn nhất là mâu thuẫn định nghĩa dẫn đến schema và governance triển khai nửa nọ nửa kia.

Cụ thể:

  • Điều 0 gốc: WF/CPS/M đều là nguyên tử vì có ID + registry + metadata + Lớp 3.
  • Điều 0-B: WF là hợp chất, CPS là phân tử.

Nếu không khóa rõ “2 hệ quy chiếu”, các hệ sau sẽ lệch nhau:

  • meta_catalog đếm theo kiểu A,
  • Lớp 3 render theo kiểu B,
  • DOT tools validate theo kiểu C,
  • developer hiểu theo kiểu D.

Khi đó S111 sẽ lặp lại ở cấp cao hơn: đếm đúng nhưng hiểu sai.

Kiến nghị chốt

  1. Chấp nhận Điều 0-B về mặt hướng tư duy và sản xuất.
  2. Nhưng trước khi phê duyệt, phải bổ sung một Điều hòa giải:
    • Điều 0 = luật nhận diện entity được quản trị
    • Điều 0-B = luật phân tầng cấu tạo của entity được quản trị
  3. Thêm 2 field riêng trong meta_catalog hoặc registry policy:
    • identity_class
    • composition_level
  4. Thêm decision table cho edge cases: ND, PG, M, CPI, CAT.
  5. Cho phép read-optimized projections cho Lớp 3, nhưng không được biến projection thành nguồn sự thật mới.

Phán quyết ngắn

  • Đồng ý hướng đi: Có.
  • Đồng ý nguyên văn hiện tại: Chưa.
  • Điều kiện để phê duyệt: Phải giải quyết xong mâu thuẫn giữa “atom quản trị” và “atom cấu tạo”.