Incomex AI Portal
KB-4A43

Điều 44 — Luật Schema Đối tượng Chuẩn (UOSL) v0.1.2 controlled DRAFT

32 min read Revision 1
lawdieu-44uoslschema-logiccross-cutting-lawssotobject-schemacontrolled-draftv0.1.2s189council-not-requiredopus-gpt-user-reviewnot-enforced-yet

ĐIỀU 44 — LUẬT SCHEMA ĐỐI TƯỢNG CHUẨN

(Universal Object Schema Law — UOSL) v0.1.2 controlled DRAFT

Tên đầy đủ: Luật Schema Đối tượng Chuẩn — SSOT cho mọi đối tượng Incomex Mã: NRM-LAW-44 | Alias: UOS-LAW / UOSL Phiên bản: v0.1.2 controlled DRAFT — review bởi Opus 4.7 + GPT-5.5 + User; chưa ban hành. Authority: Hiến pháp Kiến trúc Hệ thống Incomex v4.6.3 (14 NT) KB path: knowledge/dev/laws/dieu44-universal-object-schema-law.md Loại luật: Luật nền schema logic toàn hệ thống (cross-cutting law) — KHÔNG phải luật chuyên môn Soạn: S189 (2026-05-01) — Opus soạn + tự phản biện 4 vòng + GPT review 3 vòng + User direction Trạng thái: controlled DRAFT — CHƯA CÓ HIỆU LỰC CƯỠNG CHẾ

⚠️ CẢNH BÁO HIỆU LỰC: Đây là controlled DRAFT dùng làm nguồn review và thiết kế tài liệu dưới luật. Chỉ ENACTED v1.0 (sau khi User ban hành) mới có hiệu lực cưỡng chế. Agent KHÔNG được áp dụng controlled DRAFT như luật ban hành.

ⓘ PATCH LOG

v0.1.1 → v0.1.2 (P4+P5 polish)

ID Patch Vị trí Lý do Nguồn
P-12 §10 Roadmap (G1-G7) chuyển sang Appendix A non-normative; thân luật chỉ giữ nguyên tắc + Pre-conditions §10 + Appendix A Roadmap không phải nghĩa vụ pháp lý GPT v3
P-13 Sequence: upload KB controlled DRAFT v0.1.2 ngay → User ban hành → patch ENACTED v1.0 → cắt miếng PG từ KB record §10.3, §11.4, footer Artifact chat ≠ controlled record GPT v3
P-14 LSL-01 reword: 2 luật đồng tồn tại theo phạm vi, không override ngoài phạm vi §7.2, §11.2 Tránh hierarchy wording GPT v3
P-15 SCMR + Family Registry chốt rõ: logical capability BẮT BUỘC; physical implementation thuộc design phase §3.4, §4.1 "Luật có răng" về capability GPT v3
P-16 Thêm §0.4 Non-goals (5 dòng tinh giản) §0.4 Tóm tắt phạm vi nhanh GPT v3
P-17 Thêm §9.5 Đ44 Conformance Clause với 5 yêu cầu C1–C5 §9.5 Enforcement clause GPT v3
P-18 Polish wording, KHÔNG mở rộng khái niệm mới nhiều chỗ Kỷ luật phạm vi GPT v3
P-19 ★PB NS-4 mềm wording: schema metadata governance ở PG; data layer tuỳ kiến trúc HP §1 NS-4 Tự rà NT 3 tầng — vector_projection ở Qdrant Opus self
P-20 Bỏ wording "Council vòng 1/2" → "User/GPT/Opus review" / "User ban hành sau GPT+Opus thống nhất" header, §10.3, §11.4, footer Không có hội đồng ngoài GPT v4
P-21 Sequence enactment cập nhật theo ý GPT v4: upload KB controlled DRAFT NGAY (sau P5) thay vì chờ header, §10.3, §11.4, footer Dùng làm nền design docs dưới luật GPT v4
P-22 Thêm cảnh báo "controlled DRAFT chưa có hiệu lực cưỡng chế" vào header + footer header, footer Tránh Agent áp dụng sai GPT v4
P-23 ★PB Authority Map (§7.1) thêm dòng Lifecycle rules → Đ4 §7.1 G3 lifecycle thiếu tham chiếu Đ4 Opus self
P-24 ★PB §4.2 thêm note "(gap codes B/C/D/E xem §8.1)" để forward reference rõ §4.2 Người đọc §4.2 trước §8.1 sẽ không hiểu Opus self
P-25 ★PB Appendix A G6 thêm note "(bao gồm edge legacy retrofit theo TD-44-3)" Appendix A TD-44-3 reference Appendix A nhưng Appendix A không có item retrofit Opus self
P-26 ★PB Patch Log lịch sử v0.1 → v0.1.1 (P-1..P-11) consolidate trong header (tóm tắt 1 bảng nén) thay vì reference "revision trước" này Khi upload KB không còn revision history artifact Opus self

→ 15 patches từ v0.1.1 → v0.1.2 (8 P4 + 7 P5). Doctrine giữ 100%. Không khái niệm mới.

v0.1 → v0.1.1 (P3 self-review) — lịch sử rút gọn (P-26)

Phạm vi Patches Tóm tắt
GPT v2 review P-1..P-8 Bỏ tên bảng PG cứng / Maturity provisional / relation_edge intended / chia edge core-candidate / conflict rule mềm / Config-Value mềm / Family seed illustrative / TD-44-1 Đ38 version
Opus tự phát hiện mâu thuẫn nội bộ P-9..P-11 SCMR clean / M4 universal-not-KG / Edge legacy grace period

§0. TẦM NHÌN, PHẠM VI, NGUỒN GỐC, NON-GOALS

§0.1 Tầm nhìn

Mọi đối tượng (object) trong Incomex — từ một miếng thông tin trong văn bản pháp quy, đến một component trong BOM, đến một workflow BPMN, đến một DOT-checker, đến một vector projection — đều phải có một bộ schema logic chuẩn duy nhất. Schema đó là căn cước của object: nó là ai, thuộc về đâu, nói về gì, liên quan ai, ai dùng nó.

Khi object có căn cước chuẩn, hệ thống có thể tự cập nhật, tự làm giàu, tự kiểm tra, tự phát hiện lệch — điều kiện tiên quyết để Smart Data trở thành Knowledge Graph có thể ra quyết định kinh doanh (Đ39).

Trước Đ44, schema và metadata bị rải rác ở Đ38, Đ39, NĐ-36-01, Đ24, L3 → mỗi luật ngấm ngầm sinh schema con. Đ44 hợp nhất phần schema logic chung thành SSOT, để mọi luật chuyên môn quy chiếu thay vì tự định nghĩa lại.

§0.2 Phạm vi

Đ44 LÀM Đ44 KHÔNG LÀM
Định nghĩa logical schema chuẩn cho mọi object family Chốt physical schema (tên bảng, cột, kiểu dữ liệu)
Định nghĩa Object Qualifying Criteria (OQC) Quản nội dung/nghiệp vụ family (thuộc luật chuyên môn)
Định nghĩa Object Family Registry + Owner Law mapping Chốt danh sách family (registry/APR mới là nguồn hợp pháp cuối)
Chuẩn hoá Relation Layer vocab + minimum fields trên hạ tầng NĐ-36-01 Đẻ hạ tầng relation mới
Yêu cầu 5 mục tiêu sống + 3 tầng kiểm tra cho mọi family Hứa "tự cập nhật hoàn toàn" — chỉ yêu cầu khai báo cơ chế
Đặt Authority Map với các luật khác Thay thế chuyên môn của Đ4/22/24/29/32/34/35/36/37/38/39/NĐ-36-01

§0.3 Nguồn gốc

Tài liệu Đóng góp Trạng thái
HP v4.6.3 14 NT, kiến trúc 4 DB + 3 lớp Não-Kho-Cổng BAN HÀNH
LSL-01 v0.4 Doctrine "Information Unit First" → mở rộng "Universal Object First" Council PASS
L3 — Metadata Governance (Đ38) Pattern "Core schema + Profile" cho 4 family DRAFT
02C3 — Metadata Governance 4 nhóm core + 4 loại fill + 3 tầng kiểm PASS
02C2/L2, 02C1/L1 Family component + text unit DRAFT/PASS
P5 — Schema Draft v0.2 TAC schema thực tế đã chốt OFFICIAL
P11A — Schema Inventory (2026-05-01) Production state map READ-ONLY
Addendum metadata sống miếng thông tin 5 tiêu chí "object sống" + 8 edge types core BRIDGE
NĐ-36-01 v1.2 Hạ tầng quan hệ (universal_edges) BAN HÀNH P1
Đ39 v2.3 KG/vector projection rules BAN HÀNH

§0.4 Non-goals

Đ44 v0.1.2 không chốt:

  • DDL / table / column names / constraint / index
  • Vector payload schema (Qdrant config, embedding model, chunk size)
  • DOT / checker names cụ thể
  • Profile field list per-family
  • Migration scripts / SQL data seed

Mọi mục trên thuộc design phase sau Đ44 enacted, qua APR (Đ32).

§1. NGUYÊN TẮC SSOT SCHEMA

# Nguyên tắc Diễn giải Cơ sở
NS-1 SSOT Schema Logic duy nhất Một bộ schema logic chuẩn cho mọi object. Mọi family map vào schema chung. NT1
NS-2 Logical ≠ Physical Đ44 quy định logical contract, KHÔNG quy định physical layout. Nhiều physical table được phép, miễn có Schema Conformance Mapping (§3.4). NT4
NS-3 Family có Profile, không có Doctrine riêng Family có profile (field bổ sung), không sinh metadata doctrine riêng. L3 §3, Addendum §1
NS-4 PG-anchored Schema Governance Schema metadata governance (Family Registry, Profile Registry, SCMR) phải sống trong PG. Data layer của family có thể ở Lớp NÃO / KHO / CỔNG tuỳ kiến trúc HP v4.6.3 (vd: vector_projection data ở Qdrant/Lớp NÃO; metadata về projection vẫn ở PG). NT13 + HP v4.6.3 Lớp 3
NS-5 Khai tối thiểu, thông tin tối đa Field PG tự suy ra (timestamp/hash/derived) → KHÔNG bắt agent khai. NT11

Hệ quả: Family tạo physical metadata table ngoài PG = vi phạm NS-1+NS-4. Family tự đẻ field metadata không qua Profile Registry = vi phạm NS-3.

§2. ĐỊNH NGHĨA OBJECT + OBJECT QUALIFYING CRITERIA (OQC)

§2.1 Định nghĩa Object

Object trong Đ44 là thực thể có danh tính bền trong hệ thống, được quản trị bởi luật/DOT, có lifecycle, có thể có metadata và quan hệ.

§2.2 OQC — 4 tiêu chí

Một thực thể là Object (thuộc scope Đ44) khi thoả ≥ 3/4 tiêu chí:

# OQC Diễn giải Ví dụ thoả Ví dụ KHÔNG thoả
OQC-1 Persistent Identity UUID/PK ổn định, không tái sử dụng logical_unit, document, component row vocab table, config flag
OQC-2 Lifecycle ≥ 2 trạng thái Có ≥ 2 state document, workflow, change-set timestamp value, hash value
OQC-3 Governance Subject Là chủ thể được luật/DOT quản, có owner, approval path DOT, collection, label rule dòng log audit, event
OQC-4 Has Relations Có ≥ 1 quan hệ với object khác publication ↔ unit, component ↔ BOM raw text body chưa parse

§2.3 Phân biệt Object / Config / Value

Loại Thuộc Đ44? Governance ngoài Đ44 Ví dụ
Object (thoả ≥ 3 OQC) ✅ thuộc — document, logical_unit, component, workflow, DOT, collection, vector_projection, label_rule, …
Config (thoả ≤ 2 OQC, có owner) ❌ không thuộc Đ44 Có thể chịu governance của luật chuyên môn hoặc registry dot_config, threshold, render_config
Value (không identity bền, không governance) ❌ không thuộc Đ44 — timestamp, hash, count derived

OPEN OP-A: Borderline cases (vocab row, label rule, registry entry) cần soi từng cái — §11 cho phép amend OQC sau pilot.

§3. UNIVERSAL OBJECT SCHEMA — 12 NHÓM FIELD LOGIC

§3.1 Nguyên tắc

  • Đây là logical schema — tên field là logical name, KHÔNG phải tên cột PG.
  • Cardinality = ràng buộc logical.
  • Mỗi family triển khai bằng physical column tự chọn, miễn có Schema Conformance Mapping (§3.4).

§3.2 12 nhóm field

# Nhóm Cardinality Logical fields tối thiểu SOURCE REALITY (TAC family)
G1 Identity 1..1 object_id, canonical_address (nếu có), object_code L3 §4.1, P5 tac_logical_unit.id + canonical_address
G2 Type & Family 1..1 family_code (FK §4), object_type L3 §4.1 tac_logical_unit.section_type
G3 Lifecycle & Version 1..1 lifecycle_status, version_label, version_seq, review_state L3 §4.1, L5, Đ4 tac_unit_version.*
G4 Owner & Authority 1..1 owner_agency (FK Đ37), governance_status, governing_law_code Đ37 §3 OPEN OP-B
G5 Source & Provenance 0..1 source_type, source_uri, captured_at, captured_by NĐ-36-01 §3 universal_edges.provenance JSONB
G6 Content / Profile 0..1 content_body, content_hash, profile_jsonb L3 §3.2, P5 tac_unit_version.body + content_profile JSONB
G7 Relation / Dependency 0..n edge ra (qua universal_edges, §5) Addendum §4 universal_edges (B — TAC chưa populate)
G8 Usage / Used-by 0..n reverse edges (suy ra từ §5) Addendum §2.5 reverse query universal_edges
G9 Compatibility / BOM 0..n base_object_ref, variant_of, compatible_with L2, 02C2 OPEN OP-C
G10 Vector / KG Projection 0..1 vector_sync_status, projection_chunks Đ39, Addendum §5 tac_unit_version.vector_sync_* (B)
G11 Checker / DOT Status 0..n last_check_at, last_check_result, drift_flag Đ35, Đ22 OPEN OP-D
G12 Timestamps & Audit 1..1 created_at, created_by, updated_at, updated_by L3 §4.1 TAC: timestamps có, audit OPEN

§3.3 SOURCE / REALITY / OPEN

Bảng §3.2 đã tag. Open: OP-B owner_agency cho TAC, OP-C BOM TAC, OP-D drift checker TAC.

§3.4 Schema Conformance Mapping (SCMR) — logical capability bắt buộc

★ SCMR là logical capability BẮT BUỘC. Physical implementation (table name, column, constraint, index, trigger, …) thuộc design phase qua APR (Đ32).

Mọi physical table thực hiện một family PHẢI có 1 entry trong SCMR. Đ44 chỉ định minimum logical requirements:

Yêu cầu logical Mục đích
Tham chiếu được tới family_code (FK Family Registry) Liên kết physical table → family
Mapping field logic (G1..G12) → physical column thực tế Cho phép verify conformance
Đánh dấu nhóm field không áp dụng (vd: G9 BOM với text unit) Tránh false-negative khi audit
Trạng thái conformance (compliant / partial / non-compliant) Audit có cơ sở
Audit timestamp Đo độ tươi của mapping

NON-NORMATIVE EXAMPLE: tên bảng có thể là tac_object_mapping hoặc universal_object_mapping — chốt tại design phase qua APR.

Không có SCMR entry = physical table không hợp pháp (NS-1 + NS-4).

§4. OBJECT FAMILY REGISTRY + OWNER LAW MAPPING

§4.1 Family Registry — logical capability bắt buộc

★ Family Registry là logical capability BẮT BUỘC. Physical implementation thuộc design phase qua APR (Đ32).

Family Registry là logical entity lưu danh sách family được Đ44 quản trị.

Minimum logical fields:

  • family_code (PK, unique)
  • family_name
  • owner_law_code (FK normative_registry)
  • owner_agency_code (FK Đ37)
  • schema_profile_jsonb (profile field schema — config, không code)
  • maturity_level (xem §6.C)
  • timestamps + status

NON-NORMATIVE EXAMPLE: bảng có thể đặt là tac_object_family — chốt qua APR.

Family mới đăng ký phải qua APR (Đ32) cấp high + có SCMR entry (§3.4).

§4.2 Family seed — initial proposal (illustrative)

★ Đây là illustrative initial registry proposal, KHÔNG phải danh sách hợp pháp cuối. Registry/APR là nguồn hợp pháp cuối. Maturity là provisional — chưa phải legal fact, cần audit per-family riêng. (Gap codes B/C/D/E ở cột Open: xem §8.1)

Family code Family name Owner law Maturity provisional Evidence / Reality Open
information_unit Miếng thông tin Đ38 M2 (provisional) TAC core 14 tables enacted, 86 units (P11A) profile populate (B)
document / publication Văn bản quy phạm + publication Đ38 M2 (provisional) 3 publications in tac_publication (P11A) publication_profile populate (B)
component Component (BOM) Đ38 (L2) M0 (provisional) L2 design only, no physical E
relation_edge ★ intended object family NĐ-36-01 needs audit universal_edges (2199 rows) có status + valid_time, OQC-2 lifecycle ≥ 2 state cần verify audit pending
knowledge_node KG TBox/ABox node Đ39 M1 (provisional) Đ39 design enacted, no physical proof D/E
vector_projection Vector chunk (Qdrant) Đ39 M0–M1 (provisional) tracking columns có (P11A), Qdrant config chưa trong PG D
workflow BPMN workflow Đ34 M0 (provisional) engine chưa active, DB workflow rỗng E
dot_checker DOT/checker Đ35 M2–M3 (provisional) Đ35 v5.2 enacted, 28 checks 17s end-to-end (Fix 25-26) drift checker per-family OPEN
collection Collection Đ36 M2 (provisional) Đ36 v4.0 enacted, 17 health checks self-healing pattern dùng được
label_rule Label/facet rule Đ24 M2 (provisional) Đ24 v1.0 enacted, 6 facets × 6 layers populate gap
species Species classification Đ29 M2 (provisional) Đ29 enacted, 33 species, 7 dimensions M3 self-healing chưa proven

§4.3 Family Profile rule

  • Required profile field → birth path block (NT2) khi missing.
  • Optional profile field → DOT daily nhắc (INFO), không block.
  • Profile field list không chốt trong Đ44 — chốt khi family đăng ký qua APR.
  • Agent KHÔNG tự sáng tác profile field. Free-form = cấm. (L3 §3.2)

§5. RELATION LAYER

§5.1 Nguyên lý

Relation edge là object metadata chính thức, KHÔNG phải ghi chú trong body. Mọi quan hệ giữa Object thuộc Đ44 phải đi qua universal_edges (NĐ-36-01).

Tham chiếu: NĐ-36-01 v1.2 quản hạ tầng. Đ44 KHÔNG đẻ bảng mới — chỉ chuẩn hoá edge_type vocab và minimum edge fields.

§5.2 Minimum edge fields (logical, theo Addendum §4)

source (collection+id+code), target (collection+id+code), edge_type (FK §5.3), confidence, provenance, status/lifecycle, valid_time, timestamps.

§5.3 Edge types — chia Core vs Candidate

§5.3.A — 8 Core edge types (Addendum §4 — Council PASS)

edge_type Reverse Family thường dùng
contains belongs_to publication ↔ unit, doc ↔ component
references referenced_by unit → unit
depends_on depended_on_by component → component
uses used_by publication → component
implements implemented_by component → spec
supersedes (1 chiều) version mới → version cũ
contradicts (đối xứng) unit ↔ unit
compatible_with incompatible_with component ↔ component

§5.3.B — 3 Candidate edge types (Đ44 v0.1 đề xuất, chờ User ban hành)

edge_type Reverse Family thường dùng Lý do đề xuất
derived_from (1 chiều) vector_projection → unit Phải biết projection từ object nào → audit/recompute
governed_by governs object → law/agency (Đ37) Authority Map cần lưu ai/luật nào quản object
published_in publishes unit → publication Liên kết unit ↔ publication ngoài containment

→ Ngoài 8+3 = 11, edge_type mở qua APR (Đ32) + bổ sung vocab.

§5.4 Edge governance — có grace period

  • Edge mới (post-Đ44 enactment): bắt buộc có provenance.
  • Edge legacy (pre-Đ44, ~2199 rows): audit + retrofit dần theo Appendix A roadmap.
  • Edge mới không có provenance = không hợp pháp; có thể bị DOT cặp (NT12) reject hoặc quarantine.
  • edge_type ngoài Core+Candidate mở qua APR + bổ sung vocab.

§6. CƠ CHẾ TỰ CẬP NHẬT — TÁCH 2 TẦNG

§6.A — Mục tiêu bắt buộc (REQUIREMENTS)

5 tiêu chí "object sống" (Addendum §2) — mọi family PHẢI thoả:

# Tiêu chí Diễn giải Cardinality
LV-1 Là ai identity + version metadata bắt buộc
LV-2 Thuộc về đâu membership / parent–child / containment bắt buộc nếu áp dụng
LV-3 Nói về gì profile metadata (topic, entity, claim, ref) bắt buộc cho family content-bearing
LV-4 Liên quan ai relation edges bắt buộc cho family có quan hệ
LV-5 Ai dùng nó reverse edges + projection bắt buộc cho family có downstream

§6.B — Cơ chế triển khai (MECHANISMS) + Decision Tree

Cơ chế Khi dùng Cơ sở luật Trạng thái
Trigger (PG) Event sync, cùng giao tác Đ25 + L4 có sẵn
DOT cặp Kiểm ngược lệch (NT12) Đ35 có sẵn 250+ DOT
Job / cron Async, batch Đ41 cron có sẵn
Workflow BPMN Multi-step có người duyệt Đ34 M0 — engine chưa active
Agent extraction Profile populate (topic/entity/claim) Đ39 + NĐ-36-01 §6 M0 — chưa proof

Decision Tree:

Sự kiện cần phản ứng?
├── Sync, cùng giao tác?              → Trigger (Đ25)
├── Kiểm ngược, phát hiện lệch?      → DOT cặp (Đ35 + NT12)
├── Async, batch, định kỳ?            → Job/cron (Đ41)
├── Multi-step, có người duyệt?      → Workflow (Đ34)
└── Cần AI suy luận?                  → Agent extraction (Đ39)

§6.C — Maturity Levels M0–M4

Level Tên Tiêu chí phổ quát
M0 Manual / doctrine Chỉ doctrine, chưa có physical schema
M1 Trigger-only Có physical + birth trigger
M2 DOT-paired Có cặp writer + checker (NT12)
M3 Self-healing Đ22 self-healing loop active per-family
M4 Cross-cutting integrated Đã tích hợp với các luật ngang khác (KG/BPMN/Self-healing đầy đủ tuỳ family)

Mỗi family khai báo maturity provisional. Audit per-family riêng để xác nhận maturity legal.

§6.D — OPEN

ID Item Lý do
OP-E "Agent extraction" cơ chế Chưa có proof — chờ Đ39 vector + KG impl
OP-F "Auto-self-healing" per-family Đ22 đã có cho system_issues, per-family rule chưa có
OP-G Threshold M3/M4 Chưa định lượng — sau pilot mới chốt

§7. AUTHORITY MAP

§7.1 Ma trận chuyên môn

Nguyên tắc tổng: Đ44 governs only schema logic. Trong phạm vi schema logic chung, Đ44 là SSOT. Ngoài phạm vi đó, luật chuyên môn giữ thẩm quyền.

Lĩnh vực Đ44 quản Luật chuyên môn quản
Schema logic chung (G1..G12, OQC, NS-1..NS-5) ✅ SSOT —
Object Family Registry ✅ Đ44 —
Lifecycle rules G3 lifecycle khai báo logical Đ4
Relation infrastructure Vocab + minimum fields NĐ-36-01 (universal_edges)
Text-as-code rules — Đ38
KG TBox/ABox + vector Khai báo vector_projection family Đ39
Label/facet taxonomy Khai báo label_rule family Đ24
Species classification Khai báo species family Đ29
Approval (APR) Family đăng ký qua APR Đ32
PG architecture NS-4 tham chiếu Đ33
DOT mechanics Yêu cầu DOT cặp (NT12) Đ35
Workflow BPMN Khai báo workflow family Đ34
Collection lifecycle Khai báo collection family Đ36
Self-healing Yêu cầu §6.A LV-5 Đ22
Birth gate Yêu cầu birth path validate L4 (Đ38), Đ0-G
Tổ chức cơ quan / role Tham chiếu owner_agency_code Đ37
Context pack Đ44 là 1 phần của context Đ43

§7.2 Quan hệ với LSL-01 v0.4 — đồng tồn tại theo phạm vi

★ Hai luật ĐỒNG TỒN TẠI THEO PHẠM VI CHUYÊN MÔN; không luật nào override ngoài phạm vi của mình.

Luật Phạm vi
LSL-01 v0.4 Quy trình text-as-code — segmentation, render, change-set, publication procedure cho miếng thông tin
Đ44 Schema logic object — căn cước, OQC, Family Registry, Relation Layer cho mọi object

Đ44 là mở rộng đồng nhất doctrine từ "Information Unit First" (LSL-01) → "Universal Object First". Information Unit = 1 family trong Đ44 family seed (§4.2). Đ44 KHÔNG override quy trình của LSL-01 trong phạm vi text-as-code.

§7.3 Đ38 version reference

Đ44 dùng wording "Đ38 (version hiện hành tại thời điểm áp dụng)" vì có conflict v2.3 (HP) vs v3.0 (file). Xem TD-44-1 (§11.5).

§8. MAPPING THỰC TẾ — PRODUCTION STATE (P11A 2026-05-01)

§8.1 Gap Classification

A = đang dùng | B = có schema chưa proof | C = lắp được không cần migration | D = cần migration | E = defer

§8.2 Mapping Đ44 → production (TAC family)

Đ44 group Family information_unit Gap
G1 Identity tac_logical_unit (id, canonical_address) A
G2 Type & Family section_type + vocab A
G3 Lifecycle & Version lifecycle_status + review_state + vocab A
G4 Owner & Authority (chưa có owner_agency riêng) OP-B
G5 Source & Provenance universal_edges.provenance JSONB C
G6 Content / Profile body + content_hash + content_profile JSONB A core / B profile
G7 Relation universal_edges (chưa có TAC edges) C
G8 Usage reverse query universal_edges C
G9 Compatibility / BOM (chưa có) E
G10 Vector Projection vector_sync_* tracking có, Qdrant chưa B / D
G11 Checker / DOT fn_tac_log_checker_issue có, drift checker chưa D
G12 Timestamps & Audit có timestamps; audit OPEN B

§8.3 Tỷ lệ tổng hợp

21/30 items (A+B+C) lắp được không cần migration. 5 items D. 4 items E.

→ Đ44 v0.1.2 không yêu cầu migration mới. Items D/E xử lý sau pilot (xem Appendix A).

§9. ENFORCEMENT + DOT CẶP + CONFORMANCE

§9.1 Ba tầng kiểm tra (kế thừa L3 §7)

Tầng Khi kiểm Cơ chế Hành động khi sai
Completeness INSERT (birth path) Trigger / birth gate Block / warn / escalate
Correctness Sau INSERT, theo schedule DOT daily Log issue → auto-fix nếu draft + rule cho phép → escalate
Consistency Cross-object, daily/weekly DOT weekly Log issue → escalate
Optional Enrichment Có core, thiếu optional DOT nhắc INFO (không block)

§9.2 DOT cặp (NT12)

Mọi family thoả §6.A LV-1 (identity) PHẢI đăng ký DOT cặp:

  • Động cơ chính (writer): tạo/cập nhật object
  • Động cơ phụ (checker): phát hiện lệch + xử lý + báo cáo

Family chỉ có 1 chiều = vi phạm NT12.

OPEN OP-D: tên DOT cụ thể không chốt trong v0.1.2 — thuộc Đ35 paired design.

§9.3 Schema Conformance Audit

DOT định kỳ audit SCMR (§3.4): physical table không có entry → log issue; SCMR entry nhưng physical thiếu cột logical → log issue.

§9.4 Birth gate cho Object mới

  1. Identity field hợp lệ (G1)
  2. Family code đăng ký trong Family Registry (G2)
  3. Lifecycle khởi tạo (G3 — mặc định draft)
  4. Owner xác định (G4)
  5. Required profile fields đầy đủ

Birth gate cụ thể tham chiếu L4 (Đ38) và Đ0-G.

§9.5 Đ44 Conformance Clause ⚡

★ Mọi thiết kế object-family mới sau khi Đ44 enacted PHẢI có một mục "Đ44 Conformance" trong design doc, chứng minh rõ family thoả 5 yêu cầu sau:

# Yêu cầu Conformance Reference
C1 OQC compliance — chứng minh family thoả ≥ 3/4 OQC §2.2
C2 G1–G12 mapping — list từng group field logic, ghi rõ nhóm nào áp dụng / không áp dụng / OPEN §3.2
C3 Family Registry entry — đăng ký qua APR (Đ32 cấp high), có owner_law + owner_agency §4.1
C4 Relation Layer integration — chỉ ra edge_type nào family sẽ dùng (Core / Candidate / new vocab) + cơ chế tạo provenance §5
C5 Cơ chế cập nhật — khai báo ≥ 1 cơ chế triển khai cho mỗi LV-1..LV-5 áp dụng (Trigger/DOT cặp/Job/Workflow/Extraction) §6.A + §6.B

Design doc thiếu mục "Đ44 Conformance" hoặc thiếu bất kỳ C1–C5 = không hợp pháp để vào APR. APR Council (Đ32) sẽ reject.

§10. NGUYÊN TẮC IMPLEMENTATION

§10.1 Nguyên tắc bắt buộc

  • Mọi physical implementation Đ44 phải có SCMR entry (§3.4) trước khi đưa vào production.
  • Mọi family mới phải qua APR cấp high (Đ32) + Đ44 Conformance Clause (§9.5).
  • Birth gate cho object mới phải tham chiếu L4 (Đ38) và Đ0-G.
  • DOT cặp NT12 phải có cho mọi family thoả LV-1.
  • Edge mới post-Đ44 bắt buộc có provenance; legacy retrofit dần.

§10.2 KHÔNG làm trong v0.1.2

(xem §0.4 Non-goals)

§10.3 Pre-conditions promote v0.1.2 → v1.0 ENACTED

  1. GPT + Opus đồng thuận v0.1.2 (đã đạt sau P5)
  2. Upload KB controlled DRAFT v0.1.2 ngay (sau P5) — KHÔNG chờ
  3. Pilot Family Registry seed + SCMR seed PASS (Appendix A)
  4. User chốt Đ38 version reference (xử OP-5 + TD-44-1)
  5. User chốt OQC borderline (xử OP-A)
  6. Audit relation_edge lifecycle (xử TD-44-2)
  7. User ban hành → patch status thành ENACTED v1.0

§11. AMENDMENT & COMPATIBILITY

§11.1 Conflict Resolution Rule

Đ44 governs only schema logic chung. Trong phạm vi đó là SSOT. Ngoài phạm vi đó, luật chuyên môn giữ thẩm quyền.

Tình huống Ai có thẩm quyền
Schema logic chung (G1..G12, OQC, NS-1..NS-5) Đ44 trong phạm vi schema logic
Nghiệp vụ family (text-as-code, KG, relation infrastructure) Luật chuyên môn (Đ38, Đ39, NĐ-36-01, …)
Hiến pháp v4.6.3 (14 NT) vs Đ44 HP thắng
Không rõ thẩm quyền APR (Đ32) phân xử

§11.2 Compatibility với LSL-01 v0.4

LSL-01 và Đ44 đồng tồn tại theo phạm vi chuyên môn:

  • LSL-01: quy trình text-as-code
  • Đ44: schema logic object

Không luật nào override ngoài phạm vi của mình.

§11.3 Cách Đ44 "thay thế" các luật khác

Đ44 thay thế Đ44 KHÔNG thay thế
Phần schema logic chung rải rác ở L3, 02C3, addendum (đã thành SSOT của Đ44) Chuyên môn của Đ4, Đ22, Đ24, Đ29, Đ32, Đ34, Đ35, Đ36, Đ37, Đ38, Đ39, NĐ-36-01
Khái niệm "object" / "metadata core" mơ hồ LSL-01 procedure (đồng tồn tại theo phạm vi)
Khái niệm "4 object family" trong L3 (mở rộng thành Family Registry) L3 vẫn còn hiệu lực như "L3 đặc thù text-as-code"

Sau khi Đ44 ban hành, các luật chuyên môn liên quan có patch nhẹ chỉ chứa tham chiếu Đ44 §X thay vì tự định nghĩa schema chung.

§11.4 Lộ trình amend Đ44

Mốc Hành động Thời điểm
P5 PASS (Opus + GPT đồng thuận v0.1.2) Upload KB controlled DRAFT v0.1.2 ngay bây giờ
User ban hành Patch KB record status → ENACTED v1.0 sau khi User duyệt
Sau ENACTED v1.0 Cắt miếng theo LSL-01 từ KB record (không từ artifact chat) sau enact
v1.0 → v1.1 Patch sau pilot Appendix A PASS sau pilot

§11.5 OPEN list + Technical Debt

OPEN items:

ID Item Phụ thuộc
OP-A OQC borderline User decision
OP-B Owner Agency cho TAC family Đ37 mapping
OP-C BOM cho TAC L2 design
OP-D TAC drift checker Đ35 paired design
OP-E Agent extraction cơ chế Đ39 + KG impl
OP-F Auto-self-healing per-family Đ22 extension
OP-G Threshold M3/M4 Pilot dữ liệu

Technical Debt:

ID Item Phụ thuộc
TD-44-1 Đ38 version conflict (HP v4.6.3 ghi v2.3 BAN HÀNH; file ghi v3.0 DRAFT; LSL-01/L3 tham chiếu v3.0) User chốt version Đ38 enacted
TD-44-2 relation_edge lifecycle audit (universal_edges có status nhưng chưa rõ ≥ 2 state thực) Schema audit universal_edges
TD-44-3 Edge legacy provenance retrofit (~2199 rows pre-Đ44) Appendix A G6 pilot

✅ KẾT THÚC v0.1.2 controlled DRAFT

Khẳng định cuối:

  • Đây là doctrine-level law, CHƯA CÓ HIỆU LỰC CƯỠNG CHẾ.
  • Không chốt physical names (P-1, P-9, P-15 đã clean).
  • Mọi OPEN + TD ghi minh bạch trong §11.5.
  • 14 NT HP v4.6.3 conform (NS-1..NS-5).
  • 5 phản biện độc lập PB-1..PB-5 + 7 phản biện tự rà ★PB giữ.
  • 4 vòng review: P3 self (8 GPT v2 + 3 self) + P4 (7 GPT v3 + 1 self) + P5 (3 GPT v4 + 4 self).
  • Tổng 26 patches từ v0.1 → v0.1.2.
  • Đ44 Conformance Clause (§9.5) là enforcement clear — luật có răng.

Sequence enactment & cắt miếng:

  1. P5 PASS → upload KB controlled DRAFT v0.1.2 ngay (chưa cưỡng chế)
  2. User ban hành → patch KB record → ENACTED v1.0 (có cưỡng chế)
  3. Sau ENACTED v1.0 → cắt miếng theo LSL-01 từ KB record
  4. Pilot Appendix A (Family Registry seed + SCMR seed)

⚠️ Nhắc lại: Controlled DRAFT dùng làm nguồn review và thiết kế tài liệu dưới luật. Agent KHÔNG áp dụng controlled DRAFT như luật ban hành.

📎 APPENDIX A — IMPLEMENTATION ROADMAP (NON-NORMATIVE)

★ Đây là kế hoạch triển khai, KHÔNG phải nghĩa vụ pháp lý trong thân luật. Roadmap có thể điều chỉnh sau pilot mà không cần amend Đ44.

Giai đoạn Mục tiêu Output Trạng thái
G1 P5 PASS + Upload KB Đạt v0.1.2 + upload KB controlled DRAFT KB record controlled DRAFT đang thực hiện
G2 User ban hành Patch KB record → ENACTED v1.0 KB record ENACTED + audit sau User duyệt
G3 Segmentation Cắt Đ44 thành miếng theo LSL-01 v0.4 từ KB record logical units trong tac_logical_unit sau G2
G4 Family Registry seed Tạo Family Registry + family seed PG entity + APR pass sau G3
G5 SCMR seed Mapping Đ44 → 14 TAC tables hiện có SCMR entries cho TAC family sau G4
G6 DOT enforcement DOT cặp Schema Conformance Audit (bao gồm edge legacy retrofit theo TD-44-3) active checker sau G5
G7 Pilot M2 → M3 Promote 1–2 family lên M3 proof of self-healing sau G6

Đ44 v0.1.2 controlled DRAFT | S189 (2026-05-01) | Soạn: Opus 4.7 + 5 phản biện độc lập + tự phản biện 4 vòng (P3/P4/P5/tự rà NT 3 tầng) | Review: GPT-5.5 (3 vòng) + User direction | Tổng 26 patches v0.1 → v0.1.2 | Authority: HP v4.6.3 (14 NT) | KB path: knowledge/dev/laws/dieu44-universal-object-schema-law.md | CHƯA CÓ HIỆU LỰC CƯỠNG CHẾ — chờ User ban hành để patch ENACTED v1.0