ĐỀ BÀI — Text as Code

Nền tảng quản trị văn bản thông minh trên PG

Chuẩn hóa component, BOM, traceability và SSOT Catalog cho chuỗi Text → Code → Workflow → Knowledge

Phụ lục 01 Điều 38

Trạng thái: BAN HÀNH — Phụ lục 01 Điều 38 (Mục tiêu) Council: Claude Opus 4.6 + GPT 5.5 + Gemini — ~10 vòng, session 2026-04-24 Phạm vi: Nền tảng cho MỌI loại văn bản quản trị. Luật = pilot (< 1% tổng text). Phụ lục 02: Giải pháp chuẩn ngành (bước 2, file riêng).

TẦM NHÌN

Incomex cần nền tảng biến mọi văn bản quản trị (luật, chính sách, quy trình, hướng dẫn, knowledge) thành dữ liệu thông minh trong PG — đồng bộ, liên thông, lắp ráp được, tự động hóa cao nhất có thể.

Use case vận hành cốt lõi: AI/Agent thao tác trên đúng 1 đơn vị thông tin nhỏ trong PG qua write path hợp pháp — UPDATE trực tiếp draft/working copy, hoặc tạo version/change-set mới với unit đã ban hành (Đ4 lifecycle). Không đọc cả file, không patch string. PG trigger tự kiểm: ref còn hợp lệ? binding còn đúng? BOM bị ảnh hưởng? → block hoặc cảnh báo nếu sai. Khi 1 đơn vị được sửa, hệ thống tự tính lại, bổ sung hoặc cập nhật các thuộc tính cấu trúc/metadata/binding phát sinh theo rule sống trong PG — metadata không tụt hậu sau nội dung. Agent chỉ xử lý ngoại lệ. Đây là lý do tại sao phải xây nền tảng này.

Chuỗi giá trị:

Text → Code → Workflow → Knowledge

Text: Mọi văn bản quản trị được chia nhỏ, addressable (mỗi đơn vị có địa chỉ riêng để tham chiếu, review, bind), meta hóa, quản lý bằng PG.
Code: Phần mechanical/enforceable trong text (trigger, constraint, guard, config, function, validation rule, approval gate, assembly rule — mọi thứ kiểm được bằng máy) được bind sang PG code — đồng bộ 2 chiều, có kiểm soát. Text không sinh code tự do — text được cấu trúc hóa + bind hóa, rồi phần enforceable mới map sang code/config.
Workflow: Quy trình nghiệp vụ = lắp ráp từ component chuẩn hóa. Hợp chất trưởng thành → workflow chạy tự động, hạn chế viết code mới. Workflow trong đề bài này là lớp lắp ráp và thực thi nghiệp vụ; engine/orchestration cụ thể là bài toán triển khai ở bước sau, phải giữ ranh giới với KG.
Knowledge: Tri thức được tích lũy từ text, code, data và workflow traces; được graph hóa, gắn provenance, source authority và temporal context. Knowledge layer mặc định là lớp đề xuất và hỗ trợ suy luận; chỉ tri thức vượt qua rule auto/manual, provenance, authority và validation mới được nâng thành truth chuẩn trong Catalog/Registry.

4 tầng đồng bộ qua SSOT Catalog trên PG. Chuỗi Text → Code → Workflow → Knowledge là trục nghiệp vụ/tri thức; việc triển khai tuân thủ trục hạ tầng 5 tầng Hiến pháp: PG → Directus → Nuxt và các lớp não/kho/cổng tương ứng. Hai trục bổ sung, không thay thế nhau.

Thiết kế 1 lần, dùng cho mọi loại văn bản. Luật là pilot — không phải đích.

Quy mô tham chiếu:

Giai đoạn	Văn bản	Miếng thông tin	Liên kết chéo	Binding
Pilot (luật)	~20	~500	~1,500	~300
Mở rộng 20%	~200	~5,000	~15,000	~2,000
Đầy đủ 100%	~1,000+	~25,000+	~75,000+	hàng ngàn

PG16 xử lý thoải mái quy mô này. Tư duy thiết kế học từ 3 ngành đã proven ở quy mô lớn hơn nhiều: PLM/ngành xe hơi (30,000 linh kiện/xe), CMDB/ITSM (500,000+ CI), CCMS/DITA (Boeing 4 triệu trang).

Nguyên tắc hiệu năng — Hot path / Cold path:

Nguyên tắc	Nội dung
Direct write to PG (hot path)	Sửa unit, binding, reference, metadata, review state → ghi thẳng PG. Kiểm integrity ngay trong transaction.
Async enrichment (cold path)	Embedding, vector sync, semantic indexing, graph enrichment → chạy sau vài phút, không chặn thao tác nóng.
Immediate integrity, delayed searchability	Tính toàn vẹn đúng ngay khi ghi. Khả năng search ngữ nghĩa đến sau.
Vector băm theo miếng	Vector granularity = PG unit granularity. Sửa 1 miếng → re-vector đúng miếng đó. Tìm theo miếng. Metadata theo miếng. Cấu trúc nền thống nhất.
Vector hóa tất cả	Mọi text unit thuộc phạm vi quản trị của nền tảng đều vector hóa phục vụ search dài hạn. Không skip. Chỉ hoãn. (Không áp cho log kỹ thuật, chat tạm, data ngoài scope governance.)

4 ranh giới quan trọng:

Text as Code ≠ text sinh code tự do. Text được cấu trúc hóa + chú thích hóa + bind hóa → phần enforceable mới đi vào guard/trigger/config/workflow, có kiểm soát.
Workflow ≠ nguồn tri thức chuẩn trực tiếp. Workflow tạo event/trace/outcome/evidence → lớp KG trích xuất, classify, validate, govern trước khi thành tri thức dùng cho suy luận.
Knowledge ≠ thư viện linh kiện. Component registry là nền cho reuse/assembly. KG là lớp tri thức phía trên — có provenance, authority, trust, temporal, context projection (Đ39).
Knowledge layer và Workflow layer liên thông nhưng không nhập làm một. KG không thay workflow engine; workflow engine không tự ban hành tri thức chuẩn.

Nguyên tắc chung: Incomex có quy mô 1/triệu so với MNC. Không sáng tạo — học tối đa cách MNC đã giải bài toán này, kết hợp tư duy quản lý chuỗi linh kiện ngành xe hơi, áp dụng trên PG.

PHẦN A — VẤN ĐỀ ĐANG GẶP

Minh họa qua luật (pilot). Mọi vấn đề sẽ lặp lại gấp nhiều lần khi mở rộng sang chính sách, quy trình, workflow.

Nhóm 1 — Văn bản quá lớn, AI/Agent không xử lý nổi (triệu chứng)

V1. File quá lớn cho context window. Đ43 = 45KB, Đ35 = 36KB. AI nhồi cả file → chật, đọc sót, tự suy diễn. Fix 31: 7 vòng council không hội tụ. Mới ~1% dữ liệu đã tắc. Chính sách + quy trình sẽ gấp 100 lần.

V2. Sửa 1 đoạn = mở cả file, rủi ro hỏng. patch_document match exact string → sai 1 ký tự = fail hoặc nhầm. Với 1000+ file quy trình, bất khả thi.

V3. Tham chiếu chéo = text thủ công, không ai kiểm. Ref gãy khi khoản bị xóa/đổi. Chuỗi ref 3+ tầng (quy trình A → chính sách B → luật C) hoàn toàn thủ công.

V4. Số cứng lạc hậu so với production. "33 species", "14 DOT" — thực tế thay đổi, text không tự cập nhật. Mở rộng sang KPI, SLA → nhân bản.

Nhóm 2 — Quy trình soạn/duyệt không scale (triệu chứng)

V5. Review cả file, không target đoạn cụ thể. Council review 45KB → hời hợt. Mở rộng sang nhân viên review SOP → tệ hơn.

V6. Viết văn bản mất thời gian hơn triển khai. Chi phí soạn > chi phí code. Hàng trăm SOP → bottleneck chết người.

Nhóm 3 — Không có SSOT triệt để (★ NGUYÊN NHÂN GỐC)

Nhóm 1 và 2 là triệu chứng. Nhóm 3 là nguyên nhân gốc. Giải nhóm 1-2 mà không giải nhóm 3 = vá đau, bệnh vẫn còn.

V7. Cùng 1 khái niệm, nhiều nơi mô tả khác nhau, code triển khai lại khác nữa. "Birth gate": Đ4 nói 1 kiểu, Đ35 khác, Đ43 khác, Codex khác nữa. Mở rộng sang "approval flow", "SLA check" → lặp pattern này ở quy mô lớn hơn.

V8. SSOT là khẩu hiệu, chưa triệt để. PG chỉ SSOT cho data. Patterns, quy chuẩn, định nghĩa khái niệm — rải rác trong text. Không có danh mục master.

V9. Văn bản là "xe độc bản" — viết riêng từ đầu. Không lắp ráp từ component chuẩn. 100 SOP + 50 chính sách → trùng lặp, mâu thuẫn, vỡ trận.

V10. Text, code, data, workflow — các thế giới rời rạc. Chưa có truy vết xuôi/ngược giữa 4 tầng. Sửa 1 chỗ → không biết chỗ khác bị ảnh hưởng.

V11. Không rõ quyền sở hữu và thẩm quyền ở cấp component/pattern. Nhiều văn bản dùng chung 1 pattern nhưng chưa có authority model: ai chốt spec, ai dùng, ai override, ai review tác động liên văn bản.

Nhóm 4 — Hệ quả chiến lược

V12. Đ38 và Đ39 bị chặn. Đ38 mới deploy schema vỏ. Đ39 cần output Đ38. Cả hai đứng im.

V13. Mâu thuẫn nội tại. NT10 + NT13 nói PG First — nhưng văn bản quản trị sống bằng text.

V14. Không có nền tảng cho chuỗi Text → Code → Workflow → Knowledge. Chỉ có 2 tầng đầu (text + code) và cả 2 chưa đồng bộ. Workflow (lắp ráp) và Knowledge (graph) chưa có nền.

Kết luận Phần A: Hệ thống đang vận hành theo mô hình "văn bản nào làm văn bản đó" — sản xuất xe độc bản. Chạy được ở 19 luật nhưng sẽ sụp khi mở rộng. Phải chuyển sang mô hình công nghiệp ngay từ đầu: chuẩn hóa linh kiện, quản lý SSOT catalog, quản lý BOM và chuỗi phụ thuộc, lắp ráp từ component chuẩn — cho MỌI loại văn bản. Thiết kế 1 lần, không đập đi làm lại.

PHẦN B — MỤC TIÊU CẦN ĐẠT

Chưa nói HOW — chỉ nói WHAT. Thiết kế cho toàn bộ chuỗi Text → Code → Workflow → Knowledge. Luật = pilot. Nền tảng serve mọi loại văn bản.

★ TRỤ CỘT — SSOT Catalog, Component Registry & Reuse Governance

Đây là nền. Không có nền này, mọi thứ khác chỉ vá đau.

MT0A — SSOT Catalog (giải V8)

Danh mục master quản lý bằng PG — cho MỌI loại thực thể quản trị:

Khái niệm/pattern (birth-gate, approval-flow, SLA-check, escalation...) — 1 định nghĩa duy nhất, spec, version, owner.
Thực thể (luật, chính sách, quy trình, SOP, DOT, trigger, function, table, config, workflow...) — mỗi thực thể biết loài (Đ29), tầng (Atom → Building, Đ0-B), authority, ai reference.
Binding giữa khái niệm ↔ văn bản ↔ code ↔ data ↔ workflow.

SSOT không chỉ áp cho data runtime mà áp cho cả pattern, component, binding, authority, BOM và traceability. Tổ chức hierarchical theo Atom → Building. Quản lý bằng PG. Generic — serve luật hôm nay, chính sách và quy trình ngày mai.

Catalog không chỉ để tra cứu mà là lớp truth vận hành: mọi tầng khác phải đọc từ đây hoặc từ nguồn PG-native mà catalog trỏ tới (NT1). Catalog phải queryable, enforceable, traceable và auditable bằng PG.

MT0B — Component Registry với Ownership & Authority (giải V7, V9, V11)

Quản lý "linh kiện" chuẩn hóa — mỗi component có:

Spec: giải quyết bài toán gì.
Interface: input cần gì, output ra gì.
Compatibility: dùng được với loài/tầng nào, không tương thích với gì.
Variant: biến thể kiểm soát, giữ trace với base component.
Lifecycle: draft → active → deprecated → retired → superseded.
Governance status: approved-for-reuse / experimental / restricted / deprecated-but-allowed / forbidden-for-new-assembly.
Ownership & Authority: ai chốt spec, ai dùng, ai override, ai review khi version bump.
Composition: lắp với component nào, thay thế cái nào.
Anti-pattern / negative knowledge: tổ hợp cấm, pattern thất bại, kinh nghiệm tiêu cực.

Registry không khai lại cái PG đã biết. PG catalog (pg_proc, pg_trigger, pg_class) đã lưu metadata kỹ thuật — registry chỉ khai thêm phần PG không tự biết: semantic, authority, composition, business meaning, compatibility và BOM (NT11).

Component registry phục vụ trực tiếp cho Text, Code, Workflow; đồng thời cung cấp cấu trúc đầu vào, điểm neo và quy tắc quản trị cho lớp Knowledge.

MT0C — Reuse Decision Support (giải V9, phòng ngừa đẻ mới vô tội vạ)

Trước khi tạo component/pattern/workflow mới, hệ thống hỗ trợ quyết định theo thứ tự bắt buộc:

① Reuse nguyên trạng    → dùng đúng component đã có
② Reuse + cấu hình      → dùng component đã có + config khác
③ Extend bằng variant   → tạo biến thể, giữ trace với base
④ Tạo mới (justified)   → chỉ khi 1-3 bất khả thi, phải chứng minh lý do

Đây là cơ chế máy — không phải guideline hành vi. Mọi quyết định reuse / extend / new phải được hệ thống hỗ trợ, lưu vết và kiểm tra được bằng máy; không phụ thuộc trí nhớ người dùng hay agent (NT2).

Nhóm I — Atomize & Meta hóa mọi văn bản (giải V1, V2, V5, V6)

MT1. Chia nhỏ văn bản thành đơn vị thông tin độc lập, addressable, versionable, quản lý bằng PG. Mỗi khoản/mục/bước = 1 đơn vị (atom/molecule theo Đ0-B). Mỗi đơn vị có địa chỉ riêng (section_code) để tham chiếu, review, bind riêng lẻ; và có version riêng để biết bản nào hiện hành, draft, superseded. Generic cho mọi loại văn bản. Đọc < 2KB thay vì load cả file. Sửa 1 đơn vị không đụng đơn vị khác.

Agent/AI sửa văn bản = thao tác trên 1 unit trong PG bằng write path hợp pháp: UPDATE trực tiếp với draft/working copy, hoặc tạo version mới với unit đã ban hành (Đ4 lifecycle). Không đọc cả file, không patch string. PG trigger tự kiểm đồng bộ: ref hợp lệ? binding đúng? BOM ảnh hưởng? → block/cảnh báo nếu sai. Cập nhật chia 2 lớp:

Lớp	Thời điểm	Nội dung
Immediate (trong transaction)	Ngay khi ghi	version, updated_at, structural refs, binding integrity, lifecycle, authority, review state, basic derived fields
Deferred (cold path)	Sau vài phút	Re-embedding miếng vừa sửa, vector sync Qdrant, semantic tags nặng, KG enrichment

Nhanh hơn, ít lỗi hơn, đảm bảo đồng bộ tự động giữa miếng vừa sửa với các miếng khác.

MT2. Meta hóa tối đa — 3 lớp metadata.

Lớp	Nội dung	Tác dụng
Governance	Owner, status, version, authority, review state	Biết ai sở hữu, trạng thái gì, ai duyệt
Structural	Thuộc document nào, parent/child, pattern nào, loài, tầng	Biết nằm ở đâu, thuộc cái gì, liên kết cái gì
Machine semantics	rule_type, applies_to, trigger_condition, binding_type, literal/bound/dynamic	PG tự xử lý, không cần AI đọc text suy luận

Machine semantics là lớp trung gian: text trở thành dữ liệu máy đọc được → phần enforceable mới bind sang code/config/workflow một cách có kiểm soát. Không phải LLM đọc text rồi sinh code tự do.

Metadata gồm phần do người/agent cung cấp (manual) và phần do hệ thống tự suy ra, tự đồng bộ hoặc tự duy trì theo rule (derived/machine-maintained). Bước 2 phải phân rõ đâu là manual, đâu là derived — tránh biến metadata thành gánh nặng nhập tay.

Metadata schema chuẩn bắt buộc — 2 tầng:

Tầng	Nội dung	Ví dụ
Core schema (chung mọi text unit)	Fields bắt buộc cho mọi loại unit	owner, status, version, parent, section_code, authority, review_state, timestamps
Metadata profile (theo loại unit/document family)	Fields đặc thù, bổ sung trên nền core, không phá schema lõi	Luật: legal_effect, amendment_relation, normative_type. Workflow step: input, output, precondition. SOP: actor, tool, expected_duration

Field nào bắt buộc, field nào system auto fill (trigger/GENERATED), field nào DOT derive (tính từ data khác), field nào Agent phải cung cấp. Birth gate kiểm metadata completeness tối thiểu lúc INSERT (mở rộng Đ0-G). DOT/checker kiểm tiếp metadata correctness và consistency theo rule trong PG (mở rộng Đ22) — completeness ≠ correctness: có field là chưa đủ, field phải đúng logic/ngữ nghĩa.

Loại fill	Ai làm	Khi nào	Ví dụ	Cơ chế
System auto	PG trigger	on INSERT/UPDATE	version, timestamps, body_hash, status transitions	Trigger, GENERATED column
DOT derive	DOT	on event / daily	species, tier, drift, stale, binding validation	DOT + health check
Agent manual	Agent	birth / amend	owner, doc_code, parent, section_type, title, body	Birth gate validate
Agent assisted	Agent + system	birth / amend / review	pattern_refs gợi ý, binding_type đoán từ body	Suggestion, tương lai KG

MT3. Review target vào đơn vị cụ thể. Comment + vote gắn vào đơn vị. Áp dụng mọi loại review.

Nhóm II — Traceability toàn chuỗi (giải V3, V4, V10)

MT4. Tham chiếu chéo = PG enforce, phát hiện ref gãy tự động. Xóa/đổi đơn vị → PG biết ai reference → cảnh báo hoặc chặn. Xuyên loại: luật ↔ chính sách ↔ SOP ↔ workflow.

MT5. Thiết lập Traceability toàn chuỗi: Text ↔ Code ↔ Workflow ↔ Knowledge.

Mục tiêu không chỉ là mô tả được liên kết, mà là hệ thống tự phát hiện khi liên kết gãy, khi component mồ côi, khi BOM sai, khi version bump gây bất tương thích — và tự tạo cảnh báo / issue / review task (NT5).

Khả năng	Ý nghĩa
Truy vết xuôi	Sửa component → biết ngay toàn bộ scope ảnh hưởng
Truy vết ngược	Code/workflow đang chạy → biết văn bản nào claim
Phát hiện mồ côi	Code/workflow không văn bản nào claim → cảnh báo tự động
Phát hiện ref gãy	Văn bản ref đến thứ không còn tồn tại → cảnh báo tự động
Impact analysis	Đổi version component → scope ảnh hưởng xuyên chuỗi

Tận dụng PG catalog (pg_proc, pg_trigger, pg_class) — tài nguyên miễn phí, PG Native (NT13), khai tối thiểu (NT11).

MT6. Số động liên thông production. DOT cập nhật tối đa, Agent tối thiểu. Binding: {{species_count}} → query PG. DOT daily → drift = tự phát hiện. Áp dụng cho KPI, SLA, target, threshold, count. Pattern Đ43. Phát hiện drift là bắt buộc; auto-fix hay chỉ cảnh báo phải do rule sống trong PG quyết định (NT9, NT13).

MT7. Liên thông giữa các văn bản qua SSOT Catalog. Nhiều văn bản cùng dùng 1 component → reference cùng 1 entry → đồng nhất. Sửa 1 chỗ = nhất quán mọi nơi. Xuyên loại: luật ↔ chính sách ↔ SOP ↔ workflow.

Nhóm III — Module hóa & Assembly (giải V7, V8, V9)

MT8. Đóng gói cái đã làm thành module chuẩn. Rà soát 19+ luật + code → nhận diện pattern lặp → đóng gói thành component. Không làm lại — gói lại. Tầng (Atom → Building) + loài (Đ29). Mở rộng: cùng phương pháp cho chính sách, SOP.

MT9. Văn bản = bản lắp ráp (BOM) từ component chuẩn. Văn bản nói "dùng component Z cấu hình W" thay vì mô tả kỹ thuật 3 trang. Mỗi văn bản có BOM — biết lắp từ component nào. BOM phải machine-readable và machine-checkable: máy kiểm được composition hợp lệ, phát hiện component thiếu/thừa/sai version và chạy impact analysis (NT5, NT12).

Hướng tới: Atom → Molecule → Compound → Workflow = chuỗi lắp ráp, mỗi tầng dùng lại tầng dưới. Hợp chất trưởng thành = workflow tự động, hạn chế code mới.

Nhóm IV — Quản lý chuỗi linh kiện / BOM (giải V11, scale dài hạn)

Học từ ngành xe hơi: quản linh kiện + chuỗi cung ứng + tổ hợp cho phép.

MT10. Quản lý dependency chain & impact propagation. Component đổi version → biết: văn bản, code, workflow, config nào bị ảnh hưởng, review nào chạy lại. Xuyên chuỗi Text → Code → Workflow → Knowledge.

MT11. Quản lý lifecycle của component. draft → active → deprecated → retired → superseded. Đúng Đ4, Đ27, Đ32.

MT12. Quản lý compatibility, variant, golden path, reference architecture & anti-pattern.

Khía cạnh	Nội dung
Compatibility	Tổ hợp cho phép, cấm, cần approval đặc biệt
Variant	Biến thể kiểm soát — giữ trace với base, không đứt gốc
Golden path / Reference assembly / Reference architecture	Mẫu lắp ráp chuẩn đã phê duyệt — bài toán loại X dùng sơ đồ Y
Anti-pattern	Tổ hợp cấm, pattern thất bại, negative knowledge (Đ39)

Golden path, compatibility matrix, assembly rules, reference architecture phải là data trong PG (PG-driven) — không phải markdown hướng dẫn. Máy đọc, máy enforce, máy kiểm tra.

Nhóm V — Runtime & Rendering (giải V6, V13)

MT13. Hot path đi thẳng PG; cold path enrichment chạy bất đồng bộ. Thao tác nóng (sửa unit, binding, metadata, review, lifecycle, reference) = commit nhanh qua PG, kiểm integrity ngay trong transaction. Embedding, vector sync Qdrant, semantic indexing, graph enrichment = chạy sau theo queue/event/listener. Vector/Qdrant là eventual consistency (~1-2 phút), phục vụ search dài hạn, không chặn hot path. Vector hóa tất cả text (không skip) nhưng hoãn — sửa miếng nào thì re-vector đúng miếng đó. Read path nóng (trigger kiểm rule/config) ưu tiên local/cheap lookup, tránh query nặng (proven ở Đ43).

Nguyên tắc vector:

Vector là projection bất đồng bộ của PG unit để phục vụ retrieval dài hạn; PG unit mới là gốc quản trị và chân lý vận hành. Vector search là lớp retrieval/recall để tìm candidate; đối chiếu chuẩn vẫn phải quay về PG unit + metadata + authority hiện hành (NT9, NT10).
1 PG unit = 1 vector document mặc định. Nếu tương lai cần chia nhỏ hơn cho retrieval, sub-chunk phải là con của đúng unit_id + version_id, không được cắt tự do mất trace.
Vector gắn unit_id + version_id + status. Search dài hạn không trộn draft/current/superseded mù mờ.
Re-vector policy: Text đổi → bắt buộc re-embed. Chỉ đổi status/authority/lifecycle → cập nhật metadata/search index, không cần re-embed (embedding phụ thuộc text content, không phụ thuộc metadata).

Mọi thao tác có tác động cấu trúc, binding, lifecycle, assembly, traceability phải có write path hợp pháp bằng PG trigger / DOT / flow đăng ký. Không phụ thuộc thao tác tay ad-hoc (NT3).

MT14. PG là SSOT, mọi output = render view.

View	Phục vụ	Áp dụng cho
Reading view	Người đọc, council, manager	Luật, chính sách, SOP
Machine view	Agent/DOT	Mọi loại văn bản
Diff view	Review sửa đổi	Mọi loại văn bản
BOM view	Kiến trúc sư	Luật, workflow — component + dependency
Graph view	Đ39 KG	Toàn bộ hệ thống
Workflow view	Vận hành	Quy trình, SOP
Portfolio/Dashboard view	Chủ tịch, kiến trúc sư	Toàn cảnh: 3 nhóm chỉ số cốt lõi — coverage (% atomize/bind/catalog + % vector coverage), integrity (broken refs, orphan, invalid BOM, stale vectors, pending sync), reuse efficiency (reuse vs new vs variant)

Sửa = sửa PG. View tự sinh lại.

Nhóm VI — Nền cho Đ38, Đ39 và toàn chuỗi

MT15. Hoàn chỉnh Đ38 và triển khai Đ39. Atomized content + rich metadata + traceability toàn chuỗi + component registry = Đ38 output thật → Đ39 scaffold graph xây từ structured data. Knowledge layer mặc định là lớp đề xuất; chỉ tri thức vượt qua rule auto/manual, provenance, authority và validation mới được nâng thành truth chuẩn (NT9, Đ39).

MT16. Thiết kế nền tảng 1 lần, serve toàn bộ chuỗi. Cùng schema, cùng catalog, cùng registry:

Hôm nay: luật (pilot)
Ngày mai: chính sách, SOP, hướng dẫn
Dài hạn: workflow assembly, knowledge graph, tự động hóa

Mở rộng = thêm loài/tầng, không thay schema. Không đập đi làm lại.

PHẦN C — NGUYÊN TẮC THIẾT KẾ & TIÊU CHÍ CHỌN GIẢI PHÁP (TC1–TC13)

#	Nguyên tắc	Giải thích	Nguồn HP
TC1	Chuẩn ngành, không sáng tạo	Mỗi MT match giải pháp proven. Học MNC. Adaptation ≠ sáng tạo; phát minh lại cái ngành đã có = sáng tạo.	—
TC2	Tận dụng cái đã làm, gói lại	normative_registry, binding_registry, dot_tools, 19 luật = tài sản	—
TC3	Không làm lại từ đầu	Xây cấu trúc → rà soát → đóng gói → catalog	—
TC4	DOT tối đa, Agent tối thiểu	Writer/build path thực hiện tối đa bằng trigger/DOT/flow; checker/auditor độc lập phát hiện lệch; agent xử lý ngoại lệ và vùng chưa tự động hóa được.	NT2, NT3, NT12
TC5	Kết hợp chặt Đ38 & Đ39	Mở rộng đã enacted, không viết mới riêng lẻ	—
TC6	PG-driven — PG điều khiển hành vi, không chỉ lưu trữ	Reuse policy, compatibility matrix, golden path, authority model, assembly rules, routing metadata — tất cả phải là data trong PG. PG enforce, PG route, PG validate.	NT13
TC7	Tư duy chuỗi linh kiện ngành xe hơi	BOM, dependency, compatibility, variant, lifecycle, golden path, reference architecture	—
TC8	Generic — serve mọi loại văn bản	Schema mở rộng = thêm loài/tầng, không thay cấu trúc	—
TC9	Thiết kế 1 lần, không đập đi làm lại	Mở rộng ≠ redesign	—
TC10	Reuse trước, tạo mới sau	Mọi tạo mới phải chứng minh không thể reuse/extend/compose	—
TC11	Paired architecture mặc định	Mọi module cốt lõi thiết kế theo cặp: writer/builder phía chính, validator/checker phía phụ độc lập. Không có checker = thiết kế chưa đạt.	NT12
TC12	Write path hợp pháp cho mọi thao tác cấu trúc	Binding, lifecycle, assembly, traceability update = qua trigger/DOT/flow đăng ký. Không thao tác tay ad-hoc.	NT3
TC13	Metadata governance ghép vào luật đã có	Birth gate validate metadata (Đ0-G), lifecycle transitions (Đ4), DOT kiểm quality (Đ22/Đ35), approval flow (Đ32). Không viết quy trình mới từ đầu.	Đ0-G, Đ4, Đ22, Đ32, Đ35

PHẦN D — RÀNG BUỘC CỨNG (R1–R9)

#	Ràng buộc	Nguồn
R1	PG First, PG Native, PG Driven	NT13, Đ33
R2	Hierarchical theo Atom → Building (Đ0-B)	Đ0-B
R3	Loài theo Đ29	Đ29
R4	Hạn chế sinh khái niệm mới	Anh Huyên
R5	Single VPS $8/month, PG16, Directus, Nuxt, Qdrant	Hạ tầng
R6	NT14: đủ cụ thể để triển khai	HP v4.6.3
R7	Không vi phạm luật enacted (trừ amend chính thức theo Đ32)	Đ32
R8	Không tạo kiến trúc song song hoặc vocabulary cạnh tranh với Hiến pháp; mọi mở rộng gắn vào trục kiến trúc và thuật ngữ hiện hành hoặc amend chính thức theo Đ32	HP
R9	Zero-Downtime Migration: chuyển đổi từ text sang atom không được gián đoạn tra cứu hiện hành; hệ thống phải hoạt động song song trong quá trình chuyển đổi	Thực tế vận hành

PHẦN E — CHECKLIST & CẦU NỐI SANG BƯỚC 2

Checklist duyệt đề bài

#	Câu hỏi	Trả lời
1	Tầm nhìn + chuỗi giá trị + 4 ranh giới + nối trục 5 tầng HP — đúng?	✅ Đã duyệt
2	14 vấn đề (V1–V14) — đủ?	✅ Đã duyệt
3	MT0A + MT0B + MT0C (Catalog + Registry + Reuse) = trụ cột?	✅ Đã duyệt
4	16 mục tiêu (MT1–MT16) + trụ cột — đủ, thừa, thiếu?	✅ Đã duyệt
5	13 tiêu chí (TC1–TC13) — đủ?	✅ Đã duyệt
6	9 ràng buộc cứng (R1–R9) — đủ?	✅ Đã duyệt

Cầu nối NT14 — yêu cầu cho bước 2

Bước 2 chỉ khảo sát giải pháp đáp ứng trực tiếp các mục tiêu và ràng buộc trong đề bài; không mở rộng scope sang thiết kế engine, UI hay migration plan chi tiết nếu chưa cần.

Mỗi mục tiêu khi sang bước 2 bắt buộc phải cụ thể hóa thành:

Tiêu chí	Ý nghĩa
Data location	Dữ liệu nằm ở đâu trong PG (table, column, JSONB key)
Writer path	Ai/gì ghi vào (trigger, DOT, agent, user)
Checker path	Ai/gì kiểm tra độc lập (paired validator)
Trigger/timing	Khi nào chạy (on INSERT, daily DOT, on version bump...)
Validation method	Kiểm tra đúng/sai bằng gì
Failure handling	Khi sai thì xử lý thế nào (block, warn, issue, escalate)
Hot path latency budget	Thao tác sửa 1 unit được phép tốn bao nhiêu ms
Cold path sync SLA	Vector/KG/search enrichment được phép trễ bao lâu
Backlog observability	Còn bao nhiêu unit pending re-vector / sync failed / stale — hệ thống phải biết và hiển thị

5 Guardrails cho bước 2

#	Guardrail	Mô tả
GR1	Text as Code ≠ Text to Code Generator	Không trượt sang LLM đọc text sinh code tự do
GR2	Knowledge không nuốt Workflow	KG = suy luận/projection. Workflow = thực thi. Không nhập làm một
GR3	Registry ≠ metadata duplication layer	Không khai lại cái PG catalog đã biết (NT11)
GR4	Không vượt scope	Bước 2 = khảo sát giải pháp. Chưa chọn engine, chưa thiết kế UI, chưa migration plan
GR5	Metadata governance phải là gói khảo sát riêng	Bước 2 phải khảo sát chuẩn ngành cho: core schema, profile strategy, field responsibility, birth validation, derived metadata model, quality/completeness/correctness checking. Đặc biệt Machine Semantics cần khảo sát kỹ chuẩn như W3C Semantic Annotation, Entity Linking patterns — tránh trượt sang dùng LLM "đoán" binding (GR1). Metadata không được là "1 dòng" trong bước 2.

BAN HÀNH 2026-04-24 | Phụ lục 01 Điều 38 (Mục tiêu) | Council: Opus 4.6 + GPT 5.5 + Gemini | Phụ lục 02 = Giải pháp (bước 2, file riêng)