Luật Nguyên tử Thông tin — Nền tảng Cơ bản Nhất (Điều 0 Hiến pháp)
Luật Nguyên tử Thông tin — Nền tảng Cơ bản Nhất
LUẬT v1.1 | S107→S109 (2026-03-10) | Trực thuộc Hiến pháp Kiến trúc Điều 0 v1.1: +Phân nhóm nguyên tử 5 nhóm (S109 Huyen). +Dòng "Tổng nguyên tử" trong Registries. Đây là LUẬT NỀN TẢNG — mọi Luật khác, mọi Điều khác ĐỀU xây trên Luật này. Đọc:
search_knowledge("luật nguyên tử thông tin")Học theo tổ chức thế giới vật lý — kiến thức phổ quát, ai cũng hiểu.
I. TẠI SAO CẦN LUẬT NÀY
Thế giới vật lý phức tạp nhất mà con người từng biết — hàng tỷ tỷ vật thể, từ hạt cát đến ngôi sao. Nhưng TẤT CẢ đều được xây từ ~118 loại nguyên tử. Hiểu nguyên tử → hiểu bảng tuần hoàn → hiểu phản ứng hoá học → LÀM CHỦ vật chất.
Hệ thống Incomex sẽ có hàng ngàn quy trình, hàng vạn entity, hàng triệu quan hệ. Nếu không có định nghĩa RÕ RÀNG về đơn vị nhỏ nhất → mỗi AI/Agent hiểu khác nhau → xây khác nhau → RỐI LOẠN.
Luật này định nghĩa "nguyên tử" của hệ thống — từ đó TẤT CẢ mọi thứ phía trên đều nhất quán.
II. BẢNG SO SÁNH: THẾ GIỚI VẬT LÝ ↔ HỆ THỐNG INCOMEX
| Thế giới Vật lý | Hệ thống Incomex | Giải thích |
|---|---|---|
| Quark | Field value | Thành phần bên trong nguyên tử. KHÔNG có ID riêng. Ví dụ: name = "CI phải GREEN", status = "active". Quản lý bởi Directus field system. |
| Nguyên tử ★ | Entity có ID (PREFIX-NNN) | ĐƠN VỊ NHỎ NHẤT ĐƯỢC QUẢN LÝ. Có ID, metadata, 8 quan hệ, Lớp 3. Ví dụ: CP-005, ND-0007, DOT-042. |
| Nguyên tố | Entity Type (loại nguyên tử) | Loại nguyên tử: Checkpoint, Workflow, DOT tool... Mỗi loại có tính chất chung. |
| Bảng tuần hoàn | meta_catalog |
Danh sách TẤT CẢ loại nguyên tử. 14 loại hiện tại. Thêm loại mới = thêm record. |
| Phân tử | Tổ hợp (Set / Template) | Ghép nhiều nguyên tử: CPS-001 = phân tử gồm CP-003 + CP-005 + CP-008. Bản thân tổ hợp CŨNG LÀ nguyên tử (có ID). |
| Hợp chất | Module / Workflow | Cấu trúc phức tạp: WF-001 gồm 10 nodes, mỗi node gắn 1 set. Bản thân CŨNG LÀ nguyên tử. |
| Vật thể | Ứng dụng Tầng 4 | Customer Journey, quy trình đại lý. ĐÍCH ĐẾN cuối cùng — xây từ nguyên tử + phân tử + hợp chất. |
| Liên kết hoá học | Quan hệ (8 quy tắc) | Nguyên tử kết nối với nhau: cộng hoá trị, ion, kim loại... ↔ BELONGS_TO, CONTAINS, DEPENDS_ON... |
| Phản ứng hoá học | Thao tác nghiệp vụ | Tạo/sửa/xoá/gộp entities = "phản ứng" thay đổi cấu trúc. Phải tuân thủ quy tắc (giống bảo toàn năng lượng). |
| Nhiệt động lực học | Lifecycle (draft→active→retired) | Vật chất có trạng thái (rắn/lỏng/khí). Entity có trạng thái (draft/active/deprecated/retired). |
| Nhà vật lý | AI Agent / Con người | Người thao tác trên nguyên tử. Phải hiểu nguyên tử trước khi thao tác. |
Bài học từ vật lý: Thế giới vật lý tạo nên VÔ VÀN vật thể phức tạp — nhưng tất cả từ việc sắp xếp những thứ NHỎ, ĐƠN GIẢN lại theo quy tắc. Incomex cũng vậy: xây dựng workflow phức tạp nhất (Tầng 4) = sắp xếp nguyên tử thông tin theo quy tắc.
III. ĐỊNH NGHĨA: NGUYÊN TỬ THÔNG TIN
3.1 Định nghĩa formal
Nguyên tử Thông tin (Information Atom) = đơn vị nhỏ nhất trong hệ thống Incomex được:
- Gán ID duy nhất — PREFIX-NNN, không trùng, không thay đổi
- Đăng ký trong registry — nằm trong 1 Directus collection, query được
- Mang metadata đầy đủ — name, description, classification, status, owner (Đúng, đủ, sạch, sống)
- Tuân thủ 8 quy tắc quan hệ — IDENTITY, BELONGS_TO, CONTAINS, DEPENDS_ON, USED_BY, TRANSITIVE, PEERS, SIMILAR
- Có Lớp 3 — trang Wikipedia riêng, hiển thị tất cả thông tin + quan hệ
Bất kỳ thứ gì trong hệ thống thoả mãn 5 điều kiện trên = Nguyên tử Thông tin. Bất kỳ thứ gì KHÔNG thoả mãn = Hạ nguyên tử (sub-atomic) — tồn tại nhưng KHÔNG được quản lý bằng registry.
3.2 Ranh giới quản lý
HẠ NGUYÊN TỬ (Sub-atomic — KHÔNG có ID riêng):
├─ Field values: "active", "CI phải GREEN", "2026-03-08"
├─ Config JSON: {"key": "code", "label": "Mã"}
├─ File content: nội dung bên trong script/document
└─ UI state: filter, sort order, pagination
→ Quản lý bởi: Directus field system, file system, browser
→ KHÔNG áp dụng registry, 8 quy tắc, Lớp 3
═══════════════ RANH GIỚI NGUYÊN TỬ ═══════════════
NGUYÊN TỬ (Atomic — CÓ ID PREFIX-NNN): ★
├─ CP-005 "Code Review Passed" (checkpoint type)
├─ ND-0007 "Task Submitted" (workflow node)
├─ DOT-042 "dot-health-check" (DOT tool)
├─ WF-001 "Quy trình duyệt công việc" (workflow)
├─ CPS-001 "Bộ CI/CD" (checkpoint set — TỔ HỢP, nhưng CŨNG LÀ nguyên tử)
└─ M-001 "Comment Module" (module — HỢP CHẤT, nhưng CŨNG LÀ nguyên tử)
→ Quản lý bởi: Registry + 8 quy tắc + Lớp 3
→ MỌI thao tác phải qua DOT/script chuẩn
Insight quan trọng: Phân tử (CPS-001) và hợp chất (WF-001) CẤU THÀNH từ nhiều nguyên tử, nhưng bản thân chúng CŨNG LÀ nguyên tử (có ID, có metadata, có 8 quy tắc). Giống hoá học: phân tử nước H₂O vừa là tổ hợp (2H + 1O) vừa là đơn vị thao tác (1 phân tử nước).
3.3 Bảng tuần hoàn = meta_catalog
meta_catalog = Bảng tuần hoàn của hệ thống. Mỗi record = 1 LOẠI nguyên tử (nguyên tố).
TRẠNG THÁI THỰC TẾ (S107):
| Code | Nguyên tố | Prefix | Ví dụ | Số lượng | Trạng thái |
|---|---|---|---|---|---|
| CAT-000 | catalog (tự tham chiếu) | CAT | CAT-001 | 14 | ✅ Active |
| CAT-001 | table (Bảng UI) | TBL | TBL-001 | 16 | ✅ Active |
| CAT-002 | module | M | M-001 | 4 | ✅ Active |
| CAT-003 | workflow | WF | WF-001 | 2 | ✅ Active |
| CAT-004 | workflow_step (Node) | ND | ND-0001 | 70 | ✅ Active |
| CAT-005 | wcr (Đề xuất) | WCR | WCR-001 | 3 | ✅ Active |
| CAT-006 | dot_tool | DOT | DOT-001 | 97 | ✅ Active |
| CAT-007 | page | PG | PG-001 | 39 | ✅ Active |
| CAT-008 | collection | COL | COL-001 | 113 | ✅ Active |
| CAT-009 | task | TSK | TSK-001 | 6 | ✅ Active |
| CAT-010 | agent | AGT | AGT-001 | 6 | ✅ Active |
| CAT-011 | checkpoint_type | CP | CP-001 | 31 | ✅ Active |
| CAT-012 | checkpoint_set | CPS | CPS-001 | 2 | ✅ Active |
| CAT-013 | entity_dependency | DEP | DEP-0001 | 173 | ✅ Active |
| — | table_proposal | TP | TP-001 | ? | ❌ CẦN THÊM |
| — | checkpoint_instance | CPI | CPI-0001 | ? | ❌ CẦN THÊM |
Nguyên tố KẾ HOẠCH (chưa tạo collection):
| Prefix | Nguyên tố | Khi nào | TD |
|---|---|---|---|
| SCR | schema_change_request | Khi enforce Schema Governance | Điều 9 |
| API | api_endpoint | Khi scale API routes | — |
| CMP | ui_component | Khi scale shared components | — |
| JT | journey_template | Tầng 4 (Business) | TD-082 |
| EVT | event | Khi cần event registry | — |
| DOM | domain | Tầng 4 (Multi-domain) | TD-086 |
Quy tắc: Thêm nguyên tố mới = thêm record meta_catalog + tạo collection + auto-ID flow. Bảng tuần hoàn CHỈ TĂNG, KHÔNG GIẢM.
3.5 Nguyên tắc Kiểm toán Bảng tuần hoàn — 3 phương pháp đếm ĐỘC LẬP
Mỗi dòng trong Bảng tuần hoàn có 3 con số PHẢI đếm từ 3 NGUỒN KHÁC NHAU:
| Cột | Đếm từ đâu | Ý nghĩa | Ví dụ (DOT tools) |
|---|---|---|---|
| record_count | Directus COUNT trên REGISTRY collection | "Hệ thống BIẾT bao nhiêu" | COUNT(dot_tools) = 97 |
| actual_count | Nguồn gốc THỰC TẾ, KHÔNG qua registry | "Thực tế TỒN TẠI bao nhiêu" | ls dot/bin/dot-* | wc -l = 100 |
| orphan_count | = actual − record (TÍNH, không đếm) | "Bao nhiêu mồ côi" | 100 − 97 = 3 orphan |
Nguyên tắc kiểm toán: Nếu 3 cột đếm từ CÙNG NGUỒN → orphan LUÔN = 0 → KHÔNG BAO GIỜ phát hiện sai → vô nghĩa. 3 nguồn ĐỘC LẬP = cross-check thực sự.
Model A (Directus = source): record_count VÀ actual_count đều query Directus — nhưng phải là 2 QUERY ĐỘC LẬP. Nếu khác nhau = BUG registry desync. Model B (File scan = source): record_count = Directus, actual_count = file system. Khác nhau = orphan thực sự.
3.4 Phân biệt: Nguyên tử / Liên kết / Hạ nguyên tử
HẠ NGUYÊN TỬ (Sub-atomic): KHÔNG có ID PREFIX-NNN
├─ Field values: "active", "CI phải GREEN"
├─ Config JSON: {"key": "code", "label": "Mã"}
└─ File content: nội dung script
LIÊN KẾT HOÁ HỌC (Bond): Junction table M2M — KHÔNG có ID riêng
├─ checkpoint_set_items: NỐI CP ↔ CPS (record có set_id + type_id)
├─ journey_template_steps: NỐI ND ↔ JT (tương lai)
└─ Tồn tại ĐỂ KẾT NỐI 2 nguyên tử, KHÔNG phải entity độc lập
→ KHÔNG trong meta_catalog, KHÔNG có PREFIX-NNN
→ Quản lý bởi: Directus M2M relation system
NGUYÊN TỬ (Atom): CÓ ID PREFIX-NNN ★
├─ Mọi thứ trong meta_catalog: CP-005, ND-0007, DOT-042...
├─ Bao gồm TỔ HỢP (CPS-001 = phân tử, nhưng CŨNG LÀ nguyên tử)
└─ Bao gồm HỢP CHẤT (WF-001 = hợp chất, nhưng CŨNG LÀ nguyên tử)
→ TRONG meta_catalog, CÓ PREFIX-NNN, CÓ Lớp 3
Ranh giới rõ ràng: Nếu entity KHÔNG có PREFIX-NNN → KHÔNG phải nguyên tử → KHÔNG áp dụng 8 quy tắc → KHÔNG có Lớp 3. Junction tables (liên kết) quản lý ở mức Directus schema, KHÔNG ở mức registry.
IV. LUẬT LẮP RÁP — TỪ NGUYÊN TỬ ĐẾN VẬT THỂ
4.1 Nguyên tắc lắp ráp (giống hoá học)
Trong hoá học: nguyên tử → liên kết → phân tử → hợp chất → vật liệu. Có QUY TẮC rõ ràng: nguyên tử nào liên kết được với nhau, bao nhiêu liên kết, cấu trúc gì.
Trong Incomex: nguyên tử → quan hệ → tổ hợp → module → workflow. Cũng phải có QUY TẮC:
QUY TẮC LẮP RÁP:
1. NGUYÊN TỬ + NGUYÊN TỬ → TỔ HỢP (M2M)
CP-003 + CP-005 + CP-008 → CPS-001 (checkpoint_set)
ND-0001 + ND-0002 + ND-0003 → JT-001 (journey_template)
→ Cơ chế: M2M junction table (checkpoint_set_items, journey_template_steps)
→ Bản thân tổ hợp CŨNG LÀ nguyên tử (có ID CPS-001, JT-001)
2. NGUYÊN TỬ THUỘC VỀ NGUYÊN TỬ LỚN HƠN (M2O)
ND-0001 → WF-001 (node thuộc workflow)
Task → M-002 (task thuộc module)
→ Cơ chế: FK field (workflow_id, module)
→ Quan hệ: BELONGS_TO ↑ / CONTAINS ↓
3. NGUYÊN TỬ PHỤ THUỘC NGUYÊN TỬ KHÁC (Functional)
PG-015 depends_on collection `workflows` (đọc data)
DOT-042 depends_on Admin token (cần để chạy)
→ Cơ chế: entity_dependencies (relation_type = "depends_on")
→ Quan hệ: DEPENDS_ON → / USED_BY ←
4. NGUYÊN TỬ GẮN VÀO NGUYÊN TỬ (Decorator)
ND-0007.checkpoint_set_id = CPS-001 (gắn bộ checkpoint vào node)
→ Node + Checkpoint Set = node CÓ KIỂM SOÁT CHẤT LƯỢNG
→ Cơ chế: FK field (nullable — có thể gắn hoặc không)
5. TỔ HỢP LỒNG GHÉP (Compound)
WF-001 chứa 10 ND-nodes
Mỗi ND-node gắn 1 CPS-set
Mỗi CPS-set chứa nhiều CP-types
→ 3 tầng lồng ghép: WF → ND → CPS → CP
→ Giống hoá học: Protein (hợp chất) = amino acids (phân tử) = atoms (nguyên tử)
4.2 Nguyên tắc di chuyển (lifecycle)
Trong vật lý: vật chất có trạng thái (rắn → lỏng → khí → plasma). Chuyển trạng thái theo ĐIỀU KIỆN (nhiệt độ, áp suất).
Trong Incomex: nguyên tử có lifecycle (draft → active → deprecated → retired). Chuyển trạng thái theo QUY TẮC:
NGUYÊN TẮC DI CHUYỂN:
draft → active:
ĐK: Metadata đủ + review pass + verify production
Ai quyết: Agent tạo (draft) → Supervisor approve (active)
active → deprecated:
ĐK: Có entity thay thế + thông báo mọi USED_BY
Ai quyết: Owner đề xuất → Supervisor approve
Hệ quả: UI hiện cảnh báo, không cho tạo mới reference tới entity này
deprecated → retired:
ĐK: USED_BY = 0 (không ai còn dùng) + đã qua 30 ngày deprecated
Ai quyết: Tự động (scheduled check) hoặc Owner xác nhận
Hệ quả: Ẩn khỏi UI, giữ trong registry cho audit
retired → (xoá vĩnh viễn):
KHÔNG BAO GIỜ xoá vĩnh viễn. Retired = archive. Data giữ mãi.
(bất kỳ) → draft (phục hồi):
ĐK: Có nhu cầu tái sử dụng + Owner đề xuất
Ai quyết: Supervisor approve
4.3 Nguyên tắc bảo toàn (giống bảo toàn năng lượng)
Trong vật lý: năng lượng không mất đi, chỉ chuyển đổi dạng. Trong Incomex:
NGUYÊN TẮC BẢO TOÀN:
1. ID KHÔNG BAO GIỜ TÁI SỬ DỤNG
CP-005 retired → CP-005 KHÔNG BAO GIỜ gán cho entity khác
Giống số serial: 1 lần cấp, vĩnh viễn thuộc về entity đó
2. QUAN HỆ KHÔNG TỰ MẤT
Nếu A DEPENDS_ON B → xoá B mà không xử lý A = VI PHẠM
Phải: deprecate B → migrate A → retire B
Giống hoá học: phá vỡ liên kết cần năng lượng + tạo liên kết mới
3. METADATA KHÔNG GIẢM, CHỈ TĂNG
Entity đã có description → KHÔNG ĐƯỢC xoá description
Chỉ được: sửa (tốt hơn), thêm (đầy đủ hơn)
Nguyên tắc "Đúng, đủ, sạch, sống" = chỉ đi LÊN
4. REGISTRY KHÔNG CO LẠI
meta_catalog có 14 loại → KHÔNG BAO GIỜ giảm xuống 13
Loại mới thêm = vĩnh viễn (có thể deprecated nhưng không xoá)
Bảng tuần hoàn chỉ thêm nguyên tố, không bớt
V. DOT TOOLS — QUẢN LÝ NGUYÊN TỬ
5.1 Phân loại DOT theo thao tác nguyên tử
| Thao tác | DOT tool | Vật lý tương đương |
|---|---|---|
| Sinh nguyên tử | dot-entity-create, dot-schema-*-ensure |
Phản ứng tổng hợp |
| Đọc nguyên tử | dot-layer3-audit, dot-orphan-scan |
Quan sát, đo lường |
| Sửa nguyên tử | dot-metadata-fill, dot-dependency-scan |
Phản ứng biến đổi |
| Gắn nguyên tử | dot-relation-discover, dot-cross-ref-populate |
Tạo liên kết hoá học |
| Kiểm tra nguyên tử | dot-selftest-registries, dot-registries-verify |
Kiểm nghiệm, QC |
| Phân loại nguyên tử | dot-catalog-sync, dot-registry-diff |
Phân loại nguyên tố |
| Deprecate nguyên tử | dot-entity-deprecate (CẦN TẠO) |
Phân rã phóng xạ |
| Chống trùng | dot-duplicate-engine (CẦN TẠO) |
Nguyên lý loại trừ Pauli |
5.2 DOT cốt lõi theo lifecycle
SINH: dot-entity-create → gán ID → đăng ký registry → metadata → permissions
ĐỌC: dot-layer3-audit → kiểm tra 8 quy tắc → coverage report
GẮN: dot-relation-discover → phát hiện quan hệ → entity_dependencies
KIỂM: dot-selftest-registries → verify toàn hệ thống → PASS/FAIL
SỬA: dot-metadata-fill → bổ sung metadata trống
BỎ: dot-entity-deprecate → cảnh báo USED_BY → chờ migrate → retire
CHỐNG: dot-duplicate-engine → quét trùng → cảnh báo/block
VI. QUY TẮC CHO AI/AGENT
6.1 Trước khi thao tác, Agent PHẢI hiểu:
┌────────────────────────────────────────────────────────────────────┐
│ AGENT PHẢI TRẢ LỜI TRƯỚC KHI THAO TÁC: │
│ │
│ 1. Tôi đang thao tác trên NGUYÊN TỬ nào? (PREFIX-NNN) │
│ 2. Nguyên tử này thuộc NGUYÊN TỐ nào? (entity type trong catalog) │
│ 3. Nguyên tử này có QUAN HỆ gì? (8 quy tắc) │
│ 4. Thao tác này ẢNH HƯỞNG nguyên tử nào khác? (USED_BY query) │
│ 5. Tôi dùng DOT tool nào cho thao tác này? │
│ │
│ Không trả lời được = KHÔNG ĐƯỢC THAO TÁC. │
└────────────────────────────────────────────────────────────────────┘
6.2 Khi tạo nguyên tử mới, Agent PHẢI:
- Gọi DOT script chuẩn (KHÔNG code trực tiếp)
- Verify ID được gán (PREFIX-NNN)
- Verify registry record tồn tại
- Verify metadata đủ (name, description, classification, status, owner)
- Verify Lớp 3 trang hiện (discovery mode)
- Verify quan hệ phát hiện (dot-relation-discover)
6.3 Khi xoá/sửa nguyên tử, Agent PHẢI:
- Query USED_BY → liệt kê ảnh hưởng
- Nếu USED_BY > 0 → KHÔNG xoá, phải deprecate + migrate trước
- Sửa metadata → cập nhật TOÀN BỘ nơi tham chiếu
VII. TẦM NHÌN DÀI HẠN
7.1 Tầng 4 = "Hoá học ứng dụng"
Khi hiểu nguyên tử (Tầng 2) → xây phân tử/hợp chất (Tầng 3) → ỨNG DỤNG vào thực tế (Tầng 4):
Tầng 4: Customer Journey = "sản phẩm hoá học"
Nguyên liệu: nodes (ND), checkpoints (CP), sets (CPS), templates (JT)
Phản ứng: khách hàng đi qua từng state → verify checkpoints → chuyển state
Sản phẩm: khách hàng hoàn thành journey → đạt mục tiêu
MỌI THỨ = thao tác trên nguyên tử + quy tắc lắp ráp.
KHÔNG CÓ "phép màu" — chỉ có nguyên tử + quy tắc.
7.2 Scale = "Bảng tuần hoàn mở rộng"
Vật lý phát hiện nguyên tố mới → thêm vào bảng tuần hoàn → mọi quy tắc vẫn áp dụng. Incomex tạo entity type mới → thêm vào meta_catalog → mọi quy tắc (8 quan hệ, Lớp 3, DOT tools) vẫn áp dụng.
Không cần thiết kế lại. Không cần code mới. Chỉ cần thêm "nguyên tố" vào bảng.
Luật Nguyên tử Thông tin v1.0 | S107 (2026-03-08) "Hiểu nguyên tử → hiểu mọi thứ. Không hiểu nguyên tử → mọi thứ phía trên là đoán mò." Tác giả: Huyen (tầm nhìn vật lý) + Claude (formal definition + IT mapping)