Điều 44 — Implementation Folder

Status: controlled DRAFT support folder | Authority: Đ44 v0.1.2 (chưa enacted) Path: knowledge/dev/laws/dieu44-trien-khai/ Created: S190 (2026-05-01) Owner doc: P44-0 (Folder + README + 5-Doc Plan) — Opus 4.7 soạn, GPT-5.5 review PASS với 3 chỉnh nhẹ + 2 nuance bổ sung

1. Folder làm gì

Folder này chứa các tài liệu thiết kế dưới luật cho Điều 44 — Luật Schema Đối tượng Chuẩn (UOSL). Mục đích:

Soạn design docs cho các logical capability mà Đ44 yêu cầu (Family Registry, SCMR, Profile Registry, Relation Edge Conformance, Update Mechanism).
Audit + report production state (P11A) đối chiếu Đ44.
Lưu decision log cho các OPEN items (OP-A..G) và Technical Debt (TD-44-1/2/3) trong §11.5 của Đ44.
Làm móng để khi Đ44 ENACTED v1.0, các design docs đã sẵn để đưa vào APR (Đ32 cấp high) + có Đ44 Conformance Clause (§9.5) đầy đủ.

⚠️ Folder này KHÔNG sửa Đ44 và KHÔNG sinh luật mới. Folder chỉ chứa tài liệu thiết kế dưới luật để triển khai Đ44. Mọi đề xuất amend Đ44 phát hiện trong design phase phải đi qua amendment process chính thức (Đ44 §11.4) — không patch trực tiếp Đ44 trong folder.

2. Đ44 đang ở trạng thái nào — phân biệt phase

Đ44 v0.1.2 là controlled DRAFT — CHƯA CÓ HIỆU LỰC CƯỠNG CHẾ.

2.1 Trong giai đoạn controlled DRAFT (hiện tại)

Folder chỉ được dùng cho design / read-only planning / sandbox dry-run:

Được làm	Không được làm
Soạn design doc (markdown, logical)	DDL / migration production / code chạy trên data thật
Đề xuất tên bảng/cột (đánh dấu proposal)	Chốt tên bảng vật lý
Audit production state (read-only)	Mutate production PG / Directus
Pilot sandbox / dry-run (Đ44 §10.3 yêu cầu làm pre-condition enact)	Block production hoặc ép Agent sửa schema
Đối chiếu OPEN/TD và đề xuất resolve	Tự coi mình là luật cưỡng chế
Phát hiện gap → đề xuất amend Đ44 qua §11.4	Patch trực tiếp Đ44 trong folder

2.2 Sau ENACTED v1.0 (sau khi User ban hành)

Folder mới được chuyển sang implementation / migration / pilot có tác động production:

Design docs trong folder này đưa vào APR (Đ32 cấp high) để chốt physical implementation.
Tên bảng cứng được chốt qua APR, không phải qua design doc.
Cắt miếng Đ44 theo LSL-01 từ KB record (không từ artifact).
Pilot có tác động production (Family Registry seed live, SCMR seed live, DOT cặp Schema Conformance Audit live) chạy theo Appendix A roadmap.

3. Nguyên tắc thiết kế: PG First / Native / Driven

Mọi design doc trong folder phải tuân thủ ba nguyên tắc, hiểu đúng theo NS-4 của Đ44:

3.1 PG First — thử PG trước khi đẻ store mới

Trước khi đề xuất một metadata store mới (Mongo, key-value, file system, …), phải chứng minh PG không đáp ứng được. Mặc định: PG là nơi đầu tiên cân nhắc.

3.2 PG Native — dùng đúng tính năng PG

Constraint, FK, trigger, JSONB, materialized view, partial index, generated column, NOTIFY/LISTEN, pg_cron, RLS — đây là toolkit native. Không reinvent bằng application layer khi PG đã có.

3.3 PG Driven — PG là nguồn điều khiển event

Event/sync sang Qdrant, Directus, Agent Data, Nuxt phải được PG điều khiển (qua trigger + NOTIFY hoặc cron). PG là động cơ chính, không phải kho thụ động.

3.4 Hiểu đúng — KHÔNG hiểu sai

Hiểu đúng (NS-4)	Hiểu sai (cần tránh)
Schema metadata governance sống trong PG	Mọi data phải sống trong PG
Family Registry, SCMR, Profile Registry → PG	Vector chunk → PG (sai, ở Qdrant)
Edge metadata → PG (universal_edges)	File binary → PG (không, ở Lớp KHO)
Workflow definition metadata → PG	Workflow execution log → PG (tùy, có thể ở engine)
Vector projection metadata (sync status, chunk count) → PG	Vector embedding bytes → PG

Quy tắc nhận diện: nếu là cái dùng để quản trị schema/identity/governance/relation của object → PG. Nếu là payload thực (text body, vector, binary, log volume) → tùy kiến trúc HP v4.6.3 (Não/Kho/Cổng).

4. Thứ tự design docs

#	Design doc	Code	Phụ thuộc	Lý do thứ tự
1	Family Registry Design	P44-1	Không	Mọi object family phải đăng ký ở đây trước. Móng.
2	Schema Conformance Mapping Registry Design	P44-2	P44-1	Cần `family_code` + `owner_law` + `family status` ổn định mới map physical → logical chuẩn.
3	Profile Registry Design	P44-3	P44-1	Profile là extension theo family. Cần Family Registry trước.
4	Relation Edge Conformance Design	P44-4	P44-1, P44-3	Edge là quan hệ giữa object → cần biết family + profile của 2 đầu.
5	Update Mechanism / Living DB Design	P44-5	P44-1..4	Cập nhật cơ chế dựa trên schema đã có. Mechanism layer.

Quy tắc tuần tự nghiêm: P44-1 PASS → P44-2 mới bắt đầu. Không làm song song. Nếu P44-1 thay đổi schema khung Family Registry, P44-2 phải redo SCMR mapping → tốn công gấp đôi. Tuần tự = tiết kiệm.

P44-1 và P44-2 là 2 cái quan trọng nhất. Hai cái này xong là đủ để quay lại thiết kế information_unit với tư cách 1 family conform Đ44.

5. Cầu nối quay về Miếng thông tin

Sau khi P44-1, P44-2, P44-3 PASS:

information_unit là 1 family trong Family Registry (family_code = 'information_unit', owner_law = 'Đ38').
Schema của information_unit được mô tả trong SCMR entry, mapping tac_logical_unit + tac_unit_version + tac_publication + tac_publication_member → G1..G12.
Profile của information_unit (identity_profile, content_profile, publication_profile) được đăng ký qua Profile Registry, không phải doctrine riêng.

→ Lúc đó mới quay lại thiết kế chi tiết information_unit schema chuẩn. Đây là deliverable sau P44-3 (gọi là P38-X).

6. Tham chiếu

Tài liệu	Path	Vai trò
Đ44 controlled DRAFT v0.1.2	`knowledge/dev/laws/dieu44-universal-object-schema-law.md`	Luật nguồn
HP v4.6.3	`knowledge/dev/laws/hien-phap.md`	14 NT
LSL-01 v0.4	`knowledge/dev/laws/lsl-01-information-unit-first.md`	Doctrine text-as-code
L3 Metadata Governance	`knowledge/dev/laws/l3-metadata-governance.md`	Nguồn 4 family pattern
02C3 Metadata Governance	(TBD path)	4 nhóm core + 4 loại fill
P5 Schema Draft	(TBD path)	TAC schema thực tế
P11A Schema Inventory	`knowledge/dev/laws/dieu38-trien-khai/reports/p11a-information-unit-schema-inventory-2026-05-01.md`	Production state
NĐ-36-01 v1.2	`knowledge/dev/laws/nd-36-01-relation-law.md`	universal_edges
Đ39 v2.3	`knowledge/dev/laws/dieu39-knowledge-graph.md`	KG/vector
Đ37	`knowledge/dev/laws/dieu37-governance-organization.md`	owner_agency mapping
Đ32	`knowledge/dev/laws/dieu32-approval-process.md`	APR

7. Status board

ID	Tài liệu	Trạng thái	Phiên
P44-0	Folder + README + Plan	DONE (uploaded)	S190
P44-1	Family Registry Design	TODO (next)	—
P44-2	SCMR Design	TODO (sau P44-1 PASS)	—
P44-3	Profile Registry Design	TODO (sau P44-2 PASS)	—
P44-4	Relation Edge Conformance Design	TODO	—
P44-5	Update Mechanism / Living DB Design	TODO	—

8. Folder structure

knowledge/dev/laws/dieu44-trien-khai/
├── README.md                                       ← P44-0 (this file)
├── design/
│   ├── 01-family-registry-design.md                ← P44-1
│   ├── 02-schema-conformance-mapping-design.md     ← P44-2
│   ├── 03-profile-registry-design.md               ← P44-3
│   ├── 04-relation-edge-conformance-design.md      ← P44-4
│   └── 05-update-mechanism-living-db-design.md     ← P44-5
├── reports/
│   └── (audit reports: TAC SCMR audit, edge legacy audit, …)
├── reviews/
│   └── (review docs từ GPT/Opus/User)
├── decisions/
│   └── (decision logs cho OPEN items + TD)
└── pilots/
    └── (proof artifacts khi test capability — sandbox/dry-run trong DRAFT phase, có-tác-động-production sau ENACTED)