Bước A — Khảo sát cái đang có
Inventory & Direction Memo cho Phụ lục 02 Điều 38
Trạng thái: CHỐT — GPT + Opus review 2 vòng, User duyệt 2026-04-24.
Mục đích: Trả lời 4 câu trước khi chốt cách tiếp cận.
Không làm: Chưa chọn giải pháp, chưa thiết kế, chưa đặt tên bảng.
Câu 1 — Ta đang có gì dùng được ngay?
1.1 Registry & Catalog (đã live, đã proven)
| Tài sản |
Vai trò hiện tại |
Dùng được cho bài toán nào |
| normative_registry (27 cols, 9 triggers, EXCLUDE constraint) |
Quản lý VB quy phạm, lifecycle, version, council score |
Nền cho document management — đã hoạt động ổn |
| binding_registry (9 cols, whitelist DSL) |
Liên kết VB ↔ PG data |
Nền cho traceability text↔code |
| normative_relations |
Quan hệ giữa các VB |
Nền cho ref chéo giữa VB |
| nrm_doc_type_config (6 loại VB) |
Config-driven phân loại VB |
Mở rộng thêm loại = INSERT row |
| nrm_approval_rules (3 rules) |
Quy tắc phê duyệt theo loại VB |
Nền cho review/approval flow |
1.2 Phân loại & Khai sinh (đã live, đã proven)
| Tài sản |
Vai trò hiện tại |
Dùng được cho bài toán nào |
| entity_species (33 species, 15,307 births) |
Phân loại mọi thực thể |
Mở rộng thêm species mới = INSERT row |
| Birth gate (Đ0-G, 16 triggers BEFORE INSERT) |
Validate khi tạo thực thể |
Pattern mở rộng cho loại thực thể mới |
| Description Governance (Fix 27-28: 42 triggers, 3 helpers, 10 templates) |
Metadata auto-gen + validate description |
Pattern proven cho metadata governance |
1.3 Quan hệ & Truy vết (đã live)
| Tài sản |
Vai trò hiện tại |
Dùng được cho bài toán nào |
| universal_edges (450+ rows) |
Mọi quan hệ giữa thực thể |
Nền cho traceability toàn chuỗi |
| dot_tools (252+ DOTs) |
Registry DOT/script |
Inventory code components |
| pg_catalog (pg_proc, pg_trigger, pg_class) |
Metadata kỹ thuật PG native |
Truy vết code — miễn phí, NT11 |
1.4 Giám sát & Tự chữa (đã live)
| Tài sản |
Vai trò hiện tại |
Dùng được cho bài toán nào |
| system_health_checks (28+ checks) |
Giám sát sức khỏe hệ thống |
Mở rộng thêm check = INSERT row |
| system_issues |
Ghi nhận vấn đề tự phát hiện |
Nền cho failure handling |
| governance_audit_log |
Audit trail |
Nền cho traceability audit |
| Self-healing loop (Fix 26: fn_log_issue → auto-fix → re-check) |
Tự phát hiện, tự sửa |
Pattern mở rộng cho loại check mới |
1.5 Vector & Search (đã live)
| Tài sản |
Vai trò hiện tại |
Dùng được cho bài toán nào |
| Qdrant (Docker container) |
Vector store cho embedding |
Cold path retrieval |
| Agent Data FastAPI |
Orchestrator AI, đọc/ghi KB |
Cold path enrichment pipeline |
1.6 Pattern đã proven (tư duy, không phải code)
| Pattern |
Đã dùng ở đâu |
Áp dụng lại cho |
| Config-driven (INSERT row thay vì sửa code) |
nrm_doc_type_config, nrm_approval_rules, dot_config |
Mọi config mới |
| Birth gate + validate |
Đ0-G, Description Governance |
Mọi loại thực thể mới |
| Paired DOT (writer + checker) |
Đ35, 252 DOTs |
Mọi DOT mới |
| Binding pattern (text ↔ PG data) |
Đ38 binding_registry, Đ43 context pack |
Số động, drift detection |
| GENERATED column (body_hash, valid_period) |
normative_registry |
Auto-derive metadata |
| Trigger cascade + system_issues |
Self-healing loop |
Impact propagation |
Kết luận Câu 1: Tài sản dùng lại ngay không chỉ là bảng/hạ tầng, mà còn là 6 pattern đã proven ở trên. Đây mới là tài sản có giá trị nhất cho Bước B — vì pattern áp dụng được cho mọi khối mới, còn bảng chỉ phục vụ đúng bài toán ban đầu của nó.
Câu 2 — Ta thiếu những khối nào?
2.1 Thiếu cốt lõi (không có thì không triển khai được hoặc triển khai sẽ méo)
| # |
Thiếu gì |
Tại sao cần |
MT liên quan |
| T1 |
Bảng miếng thông tin nhỏ (text unit) |
Hiện VB = 1 file/1 row. Không chia nhỏ = không sửa riêng, không review riêng, không vector riêng. Đây là thiếu hụt lớn nhất. |
MT1, MT2, MT3 |
| T2 |
Registry cho pattern/component quản trị |
Hiện pattern (birth-gate, dual-trigger, health-check) tồn tại trong đầu/text, không có catalog. Không có catalog = không reuse, không quản version, không trace. |
MT0B, MT8 |
| T3 |
BOM — biết VB lắp từ component nào |
Hiện VB "tham chiếu" nhau bằng text. Không có BOM = không impact analysis, không biết sửa component ảnh hưởng ai. |
MT9, MT10 |
| T4 |
Metadata governance package chuẩn |
Không chỉ thiếu chỗ lưu text unit — còn thiếu: core schema, metadata profile theo loại VB, field responsibility (ai fill, khi nào), birth validation cho metadata, derived metadata rules, completeness/correctness checking. Nếu không tách riêng sẽ đánh giá thấp mức phức tạp. |
MT2, GR5 |
T1–T3 là thiếu cấu trúc dữ liệu lõi (chỗ để lưu + quản lý). T4 là thiếu gói governance để cấu trúc đó chạy đúng. Hai lớp khác bản chất — có T1 mà không có T4 thì data vào nhưng không ai kiểm.
2.2 Thiếu hỗ trợ (có thể hoãn nhưng nên thiết kế sẵn chỗ)
| # |
Thiếu gì |
Tại sao cần |
MT liên quan |
| T5 |
Impact analysis function |
Hiện không có recursive traversal trên universal_edges. Sửa 1 chỗ → không biết ảnh hưởng đâu. |
MT4, MT5, MT10 |
| T6 |
Reuse decision log |
Hiện tạo mới thoải mái, không ai hỏi "đã có cái tương tự chưa?" |
MT0C |
| T7 |
Compatibility / golden path data |
Hiện không có: tổ hợp nào cấm, mẫu lắp ráp nào chuẩn. |
MT12 |
| T8 |
Cơ chế vector sync / backlog observability rõ ràng |
Hiện vector sync ad-hoc. Không biết unit nào pending re-vector, bao lâu rồi. Cần cơ chế rõ ràng (hình thức triển khai chưa chốt ở bước này). |
MT13 |
| T9 |
Multi-view render |
Hiện đọc VB = đọc cả file hoặc sections JSONB. Không có reading view, BOM view, machine view riêng. |
MT14 |
Câu 3 — Chuẩn ngành nào giải từng loại bài toán?
| Bài toán |
Chuẩn ngành proven |
Ai dùng |
Tư duy cốt lõi |
| Chia nhỏ VB + metadata + content reuse |
DITA / CCMS (topic-based authoring) |
Boeing (4M trang), IBM, SAP, Siemens |
Mỗi "topic" = 1 unit độc lập, có metadata, lắp ráp thành publication qua "map". Sửa topic → mọi publication dùng nó tự cập nhật. |
| Addressing scheme cho VB pháp luật |
Akoma Ntoso (OASIS) |
Liên Hợp Quốc, EU, nhiều quốc gia |
Mỗi khoản luật có eId duy nhất, addressable, versionable. |
| Component catalog + lifecycle + variant + compatibility |
PLM / BOM (Product Lifecycle Management) |
Ô tô (30K parts/xe), hàng không, điện tử |
Component có spec, version, lifecycle, owner, approved/restricted. BOM = danh sách component lắp thành sản phẩm. ECO = quy trình thay đổi có kiểm soát. |
| Traceability + dependency + impact analysis |
CMDB / ITSM (Configuration Management Database) |
ServiceNow (500K+ CI), BMC, Atlassian |
Mỗi CI có relationships. Sửa CI → impact analysis tự động: upstream + downstream. Bidirectional traversal. |
| Traceability 4 tầng (req→design→code→test) |
DO-178C (hàng không) |
Boeing, Airbus, mọi hãng bay |
Traceability matrix record mọi liên kết giữa 4 tầng. Thay đổi requirement → biết test nào chạy lại. |
| Metadata governance / annotation |
W3C Semantic Annotation + Entity Linking |
Web standards, academic, enterprise search |
Annotation gắn vào nội dung, không phá nội dung. Entity Linking map text → entity đã đăng ký. |
Tổng hợp mapping
| Chuẩn ngành |
Giải cho nhóm MT nào |
| DITA/CCMS |
MT1 (atomize), MT2 (metadata), MT3 (review), MT9 (assembly) |
| Akoma Ntoso |
MT1 (addressing scheme) |
| PLM/BOM |
MT0B (registry), MT8-9 (module/BOM), MT10-12 (dependency, lifecycle, compat) |
| CMDB/ITSM |
MT0A (catalog), MT4-5 (traceability), MT7 (liên thông), MT14 (multi-view) |
| DO-178C |
MT5 (traceability 4 tầng Text→Code→Workflow→Knowledge) |
| W3C Semantic Annotation |
MT2 lớp 3 (machine semantics) |
Lưu ý: Các chuẩn ngành trên được dùng như mô hình tư duy và pattern proven; không đồng nghĩa Incomex sẽ bê nguyên toolchain hoặc runtime của họ vào hệ thống. Runtime của Incomex vẫn lấy PG làm nền (R1, NT13). Không có một chuẩn ngành đơn lẻ nào giải trọn bài toán này — Incomex phải kết hợp tư duy từ nhiều ngành, nhưng runtime thống nhất trên PG.
Câu 4 — Có giải pháp nào rõ ràng không nên dùng?
| Giải pháp |
Tại sao KHÔNG dùng |
Guardrail |
| LLM đọc text sinh code tự do |
Text as Code ≠ Code Generator. Machine semantics + binding controlled, không phải LLM đoán. |
GR1 |
| Vector/Qdrant làm hot path |
Vector = projection async cho retrieval. PG unit = SSOT cho mọi thao tác write/validate. Vector search = recall candidate, đối chiếu chuẩn quay về PG. |
Phụ lục 01 nguyên tắc hiệu năng |
| 1 "super table" cho catalog tổng |
Catalog = logic layer join registries đã có. Không gom vào 1 bảng khổng lồ → phá NT11, tạo duplication. |
GR3, NT11 |
| XML/DITA engine (Oxygen, AEM) |
Tư duy DITA dùng được, nhưng engine XML không phù hợp. PG là runtime, không phải XML parser. |
R1 (PG First), R5 ($8/month VPS) |
| Enterprise CMDB tool (ServiceNow, BMC) |
Tư duy CMDB dùng được, nhưng tool enterprise quá nặng + quá đắt. Triển khai tư duy trên PG. |
R5 |
| Graph database riêng (Neo4j, ArangoDB) |
PG + universal_edges + recursive CTE đủ cho quy mô 75K edges. Thêm DB = thêm complexity, vi phạm NT13. Đ39 đã chốt: AGE Phase 2-3 nếu cần. |
NT13, Đ39 §8.1 |
| Document-centric editing (patch file, sửa cả VB) |
Đây là mô hình hiện tại gây ra V1, V2, V5, V6. Phải chuyển sang unit-centric editing. |
MT1, use case vận hành cốt lõi |
| Metadata free-form / agent tự sáng tác field |
Agent tự đặt field, tự điền metadata theo cảm hứng → phá chuẩn, phá NT14, system không enforce được. Metadata phải có schema chuẩn, field responsibility rõ, birth validate bắt buộc. |
GR5, NT14 |
| Schema trước approach (đi thẳng vào tên bảng/function/DOT khi chưa chốt cách tiếp cận) |
Tăng xác suất thiếu/sai, trộn survey với design. Bài học từ vòng trước: phải chốt khung trước, bung chi tiết sau. |
Quy trình 3 bước |
Kết luận Bước A: Hệ thống đã có phần lớn hạ tầng nền ở mức pattern/registry (ước tính 60–70%, nhưng "live" chưa đồng nghĩa "áp dụng trực tiếp được" — cần đánh giá kỹ hơn ở Bước B). Thiếu 4 khối cốt lõi: (1) text unit table, (2) component registry, (3) BOM, (4) metadata governance package. Chuẩn ngành rõ ràng: DITA cho atomize, PLM cho component/BOM, CMDB cho traceability — dùng tư duy, không bê toolchain. Không dùng: LLM sinh code tự do, vector hot path, enterprise tool, document-centric editing, metadata free-form.
Bước A CHỐT | GPT + Opus review 2 vòng | User duyệt 2026-04-24