L3 Phụ lục 05 Đ38 — Metadata Governance
PHỤ LỤC ĐIỀU 38 — METADATA GOVERNANCE
Phụ lục 05 Điều 38 (Metadata)
Trạng thái: DỰ THẢO — chờ Council review + User duyệt Loại: Phụ lục mới gắn vào Đ38 Concept gốc: 02C3 (Metadata Governance) Đóng blocker: 02D0 blocker "Chưa có phụ lục metadata governance" Che phủ hở: 02DX QĐ3 — "Chưa luật hóa core schema + profile" Tiền đề: L1 (Text Unit) + L2 (Component/BOM) đã soạn GPT review: PASS có điều kiện, 11 chỉnh + 3 khuyến nghị đã áp dụng
§1. Mục đích
Luật hóa bộ quy tắc metadata xuyên suốt 4 loại object: document envelope, text unit, component, relation. Trả lời câu hỏi cốt lõi: "field nào bắt buộc, ai điền, khi nào điền, máy tự điền gì, kiểm tra chất lượng bằng gì?"
Phụ lục này đưa metadata từ "mỗi nơi mỗi kiểu" sang "1 bộ quy tắc thống nhất, máy enforce được".
Metadata không thay đổi hiệu lực pháp lý của nội dung. Hiệu lực pháp lý vẫn nằm ở lifecycle/approval của unit/document/change-set (Đ32, L5).
§2. Phạm vi
Áp dụng cho mọi object thuộc scope Đ38: document envelope, text unit (L1), component (L2), relation (universal_edges). 4 loại object, 1 bộ quy tắc.
Không làm: Không chốt tên bảng/cột, kiểu dữ liệu, constraint cụ thể, trigger, function, DOT list, migration. Không mở scope sang workflow engine hoặc KG implementation. Tất cả thuộc design phase.
§3. Kiến trúc 2 tầng: Core schema + Profile
§3.1 Core schema
Bộ metadata bắt buộc chung. Mọi object thuộc scope quản trị của phụ lục này phải có core metadata hoặc core-equivalent theo family. Core schema là khung cứng — thay đổi core = phải đi qua amend path hợp pháp theo hệ thống luật hiện hành. Không xử lý như config change.
§3.2 Profile
Bộ metadata bổ sung theo loại object hoặc doc family. Profile không phá core, chỉ thêm.
Quy tắc profile:
- Profile schema = config, không phải code. Thêm profile mới theo config/registration path PG-native; chi tiết lưu trữ xác định ở design phase (NT4).
- Profile phân biệt required vs optional: required → birth path phải block/warn/escalate theo rule, mặc định block với object mới nếu không có ngoại lệ hợp lệ. Optional → DOT daily nhắc, không block.
- Mỗi field trong profile phải justify "PG không tự biết" (NT11). Chống khai thừa.
- Agent không tự sáng tác profile field. Phải nằm trong config đã đăng ký. Free-form = cấm.
- Metadata profile cũng phải có owner/version/lifecycle ở mức governance — profile không phải "đống config vô chủ".
§3.3 Tại sao 2 tầng?
1 tầng → cứng, không mở rộng. Quá nhiều tầng → phức tạp. 2 tầng = vừa đủ: core giữ kỷ luật, profile cho linh hoạt.
§4. Core metadata framework
§4.1 Các nhóm core metadata (4 nhóm — áp cho mọi object)
Đây là các nhóm core metadata, không phải danh sách field/cột cụ thể.
| Nhóm | Mô tả |
|---|---|
| Identifier | Định danh duy nhất toàn hệ thống (code, address, edge_id tùy loại) |
| Status / Validity | Trạng thái hiện hành (lifecycle status, governance status, valid_time) |
| Timestamps | Khi nào tạo, khi nào sửa |
| Classification | Thuộc loại gì (doc_type, section_type, component_type, edge_type) |
§4.2 Core-equivalent theo từng object family
Ngoài 4 nhóm chung, mỗi loại object có core-equivalent đặc thù — bắt buộc cho loại đó nhưng không áp cứng cho loại khác. Các mục dưới đây là ví dụ core-equivalent ở mức concept hiện hành, không chốt tên cột hay kiểu dữ liệu cụ thể.
Document envelope: name, owner, version, description, doc_type, article_number, enacted_at, council_score, kb_path. Trong giai đoạn hiện hành có thể map với normative_registry; thiết kế chi tiết xác định ở design phase.
Text unit: title, owner, version, description, doc_code (FK document), parent (FK self), sort_order, body, body_hash (derived), section_code, section_type, tier (derived-first). Chi tiết định nghĩa xem L1.
Component: name, owner, version, description (spec_summary), component_type, interface (in/out ở mức governance), lifecycle_status, governance_status, base_component (nếu variant), reuse_decision_ref. Chi tiết xem L2.
Relation: source, target, edge_type, confidence, provenance, status. Relation không có title/owner/version theo nghĩa thông thường — provenance + valid_time thay vai trò tương đương.
§4.3 Về description
Description thuộc core governance expectation — mức bắt buộc theo object type:
- Document, text unit, component: bắt buộc. Description Governance (Fix 27-28) đã proven pattern.
- Relation: không bắt buộc. Provenance + edge_type đã đủ ngữ nghĩa.
- Object kỹ thuật nhỏ: theo config, tránh bắt tuyệt đối quá sớm (bài học Đ43).
§5. Profile — bổ sung theo loại
§5.1 Nguyên tắc chung
Profile mở rộng core theo ngữ cảnh (doc family, section_type, component_type, edge_type). Ví dụ: luật cần legal_effect, SOP cần actor/department, guard cần trigger_timing/severity. Danh sách profile fields cụ thể là config data — chốt tại design/seed phase, không chốt trong phụ lục pháp lý này.
§5.2 Phân loại profile field
| Loại | Birth path | DOT daily |
|---|---|---|
| Required profile | Block/warn/escalate theo rule; mặc định block nếu không có ngoại lệ | — |
| Optional profile | Không block | Nhắc nếu thiếu (INFO) |
Phân loại required/optional cho từng profile field = config data, xác định khi đăng ký profile.
§6. Field responsibility — ai điền, khi nào, bằng gì?
§6.1 Bốn loại fill
| Loại fill | Ai làm | Khi nào | Cơ chế |
|---|---|---|---|
| System auto | PG-native system mechanism | Mỗi INSERT/UPDATE, tự động | PG-native system mechanism (trigger, generated column là ví dụ; cơ chế cụ thể thuộc design phase) |
| DOT derive | DOT chạy theo schedule hoặc event | Sau INSERT, daily, hoặc khi event trigger | DOT paired (writer derive + checker verify). Các field dẫn xuất áp dụng theo từng object type, không phải mọi field derive áp cho mọi object. |
| Agent manual | Agent khi tạo/sửa object | Birth (INSERT) hoặc amend (UPDATE draft) | Birth path validate bắt buộc |
| Agent assisted | Agent fill, system gợi ý | Birth hoặc sửa, có suggest | Tương lai: search/recommend từ KG hoặc catalog |
§6.2 Nguyên tắc phân công
| Nguyên tắc | Giải thích |
|---|---|
| Máy trước, người sau | Nếu PG có thể tự tính (timestamps, hash, status transitions) → system auto. Không bắt agent khai cái máy biết. |
| Derived-first cho metadata cấu trúc | Tier, binding count, species count = tính từ PG data, không hardcode. Agent chỉ đề xuất ban đầu; DOT/system xác nhận cuối cùng. |
| Agent chỉ khai cái người biết | Owner, body, title, doc_type, component_type, section_type = chỉ agent biết. |
| DOT kiểm cái có thể sai | Business rule, cross-object consistency, drift = DOT daily. |
§6.3 Ma trận field × fill type
Ma trận chi tiết cho từng object type (document, text unit, component, relation) đã chốt ở mức concept trong 02C3 mục 4.2. Tên cột/kiểu dữ liệu cụ thể xác định ở design phase. Phụ lục này chốt nguyên tắc phân công, không chốt schema.
§7. Ba tầng kiểm tra chất lượng
Bài học Fix 27-28: Completeness ≠ correctness. Có field là chưa đủ — field phải đúng.
§7.1 Completeness — đủ metadata (birth path)
Kiểm lúc INSERT. Core metadata + required profile phải có giá trị hợp lệ. Thiếu required metadata → block/warn/escalate theo rule; mặc định block với object mới nếu không có ngoại lệ hợp lệ.
Áp cho cả 4 object family. Birth path = cơ chế máy (NT2), reuse nguyên lý từ Đ0-G/Fix 27-28 (02DY). Thiết kế cụ thể birth path cho multi-field + profile validate = mới, không copy 42 triggers Fix 27-28. Enforcement mode chi tiết thuộc L4/design.
§7.2 Correctness — đúng logic (DOT daily)
Kiểm sau INSERT, theo schedule. Giá trị metadata phải đúng ngữ nghĩa, đúng business rule. Ví dụ: parent trỏ unit khác document → sai; binding/reference target trỏ tới đối tượng không tồn tại → sai.
DOT paired (checker verify). Self-healing pattern (02DY): phát hiện sai → log issue → auto-fix metadata/derived fields nếu draft + rule cho phép → re-check → escalate nếu không fix được.
§7.3 Consistency — nhất quán chéo (DOT daily/weekly)
Kiểm cross-object. Metadata giữa các object liên quan phải nhất quán. Ví dụ: document enacted nhưng unit con draft → sai; BOM version ≠ component version thực → mismatch.
§7.4 Optional enrichment (DOT nhắc)
Object có đủ core + required profile nhưng thiếu optional profile fields → INFO. Nhắc fill, không block. Đây là enrichment, không phải enforcement.
§8. Nguyên tắc bắt buộc
| # | Nguyên tắc | Cơ sở |
|---|---|---|
| 1 | Metadata governance áp đồng đều 4 object family. Không có object family nào được miễn core governance; mức field cụ thể theo core-equivalent/profile. | 02C3, Phụ lục 01 |
| 2 | Core schema = amend path hợp pháp. Thay đổi core không phải config change. | HP, Đ32 |
| 3 | Profile schema = config. Thêm profile theo config/registration path PG-native (NT4). Agent không tự sáng tác field. | NT4, 02C3 |
| 4 | Birth path validate completeness. Core + required profile phải đủ tại INSERT. Enforcement mode thuộc L4/design. | Đ0-G, Fix 27-28, 02DY |
| 5 | DOT daily validate correctness + consistency. Business rule + cross-object. | Fix 26, 02DY |
| 6 | Self-healing cho metadata/derived fields của draft objects. Enacted → escalate, không auto-fix nội dung. | Fix 26, 02DY |
| 7 | Derived-first cho metadata cấu trúc. Tier, counts = tính từ data. Agent đề xuất, DOT xác nhận. | NT11, Đ26 |
| 8 | Máy trước, người sau. System auto > DOT derive > agent manual. | NT2, NT11 |
| 9 | Controlled vocabulary cho mọi classification metadata. doc_type, section_type, component_type, edge_type = FK config. | 02C2, 02C3 |
| 10 | Reuse pattern proven, không copy nguyên trạng. Birth gate, config-driven, checksum, self-healing = lấy nguyên lý. Schema/trigger mới theo scope mới. | 02DY |
§9. Ranh giới — không làm gì trong phụ lục này
| Không làm | Lý do |
|---|---|
| Không chốt tên bảng/cột, kiểu dữ liệu, constraint cụ thể | Schema thuộc design phase |
| Không chốt trigger/function cụ thể | Implementation thuộc design phase |
| Không chốt DOT list/DOT config cụ thể | Implementation thuộc design phase |
| Không liệt kê danh sách profile fields cụ thể | Profile fields = config data, chốt tại design/seed phase |
| Không chốt enforcement mode cụ thể (reject/warn/escalate) | Thuộc L4/design |
| Không chốt migration plan | Thuộc C7 |
| Không định nghĩa text unit / component | Thuộc L1, L2 |
| Không định nghĩa review/approval flow | Thuộc L5 (clarify Đ32) |
| Không mở scope sang workflow engine hoặc KG implementation | Ngoài scope phụ lục này |
§10. Liên kết với luật hiện hành
| Luật | Quan hệ |
|---|---|
| Đ38 v3.0 | Phụ lục này luật hóa metadata governance cho toàn bộ scope Đ38 |
| L1 (Text Unit) | L3 chốt core + profile cho text unit. L1 chốt model + nguyên tắc unit. |
| L2 (Component/BOM) | L3 chốt core + profile cho component. L2 chốt model + reuse/BOM. |
| Đ0-G (Birth) | Birth path validate completeness — L4 mở rộng Đ0-G thêm scope |
| Đ4 (Lifecycle) | Lifecycle status = core metadata. Tuân thủ Đ4. |
| Đ29 (Species) | Classification = core. Species registration xem L4. |
| Đ32 (Approval) | Review state, approval = metadata fields. Chi tiết xem L5. |
| Đ33 (PG) | PG First. Metadata sống trong PG. |
| Đ39 (KG) | Metadata cung cấp provenance/authority/context cho KG; vector/KG là projection, không phải source of truth. |
| HP NT2 | Cơ chế máy, không guideline |
| HP NT4 | Profile = config, không code |
| HP NT11 | Khai tối thiểu — chỉ khai cái PG không tự biết |
| Fix 26 | Self-healing loop pattern |
| Fix 27-28 | Birth gate + description governance pattern |
§11. Điều kiện PASS
| # | Điều kiện |
|---|---|
| 1 | Core metadata 4 nhóm + core-equivalent rõ ràng, nhất quán với 02C3 |
| 2 | Profile 2 tầng (required/optional) nhất quán với 02C3 mục 3.5 |
| 3 | Field responsibility (4 loại fill) nhất quán với 02C3 mục 4 |
| 4 | 3 tầng kiểm tra (completeness/correctness/consistency) nhất quán với 02C3 mục 5 |
| 5 | Không trượt sang schema/implementation/tên bảng/tên cột |
| 6 | Không mâu thuẫn với L1, L2, Đ38, Đ4, Đ0-G, Đ29, Đ32, Đ33, Đ39, HP |
| 7 | L3 đủ làm tiền đề cho L4 (Birth Gate mở rộng) và L5 (Unit-level Review) |
| 8 | L3 không tự mở scope sang workflow engine hoặc KG implementation |
| 9 | Council review + User duyệt |
DỰ THẢO | Phụ lục 05 Đ38 — Metadata Governance | L3 | GPT review: PASS có điều kiện, 11 chỉnh + 3 khuyến nghị đã áp dụng | Chờ Council + User