P38-XC — Information Unit Profile/Schema Design (Universal Substrate + UMC + DOT Contract)

Trạng thái: P38-XC final — uploaded | Phiên: S190 (2026-05-01) Authority: Đ38 (text-as-code chuyên môn — base contract) + extension qua Đ34 BPMN, Đ29 species, Đ24 label, Đ39 KG, ... — phải conform Đ44 v0.1.2 controlled DRAFT Path: knowledge/dev/laws/dieu44-trien-khai/design/04-information-unit-profile-schema.md Phụ thuộc: P44-0 README rev 1, P44-1 Family Registry rev 1, P44-2 SCMR rev 1, P44-3 Profile Registry rev 1 Nguồn nền: L3 Metadata Governance, 02C3 ma trận field × fill type, P11A Schema Inventory, LSL-01 v0.4 (10 patches), Đ44 §6.A 5 LV (Living DB), Đ0-B 7 lớp cấu tạo, Đ29 species, Smart Data 5 cấp Polish history:

• P38-XA → P38-XB: 5 GPT review điểm — universal substrate, UMC độc lập TAC, Base/Extension boundary, DOT Contract Matrix, progressive enforcement
• P38-XB → P38-XC: 3 GPT polish + 5 self-rà soát risk fix (vocab anchor, canonical_address format per unit_kind, recursive audit terminal, UMC contract invariant, baseline wording clarify)
• P38-XC → P38-XC final (upload): self-rà soát lần cuối — (a) path align dieu44-trien-khai/design/ để khớp folder triển khai Đ44; (b) clarify §5.7 + §10.5 — section_type ≠ unit_kind, mọi tac_logical_unit row đồng nhất unit_kind = law_unit, không nhầm khái niệm; (c) bổ sung OR principle "DOT phụ IDLE = thiết kế tốt" ở §8.4

---

§0. Tóm tắt 5 dòng cốt lõi

1. Information Unit là universal information substrate — đơn vị thông tin phổ quát của Incomex. Owner law base = Đ38; extension qua Đ34/Đ29/Đ24/Đ39. KHÔNG sinh object mới.
2. Universal Minimum Core (UMC) — 10 elements bắt buộc cho mọi information_unit instance, độc lập TAC physical. UMC là contract; TAC là một implementation cho unit_kind = law_unit. UMC contract invariant qua mọi implementation pattern.
3. Living DB Contract 9 câu hỏi sống + Capability set 10 chia 6 tier (Tier 0-5). 4 nhóm scope: Universal Core / Relation Core / Domain Extension / System Intelligence.
4. DOT Contract Matrix per capability — 5 responsibility (writer/checker/enrichment/drift/reverse-index). P38-XC chốt contract logical; P44-5 handoff chốt tên DOT, schedule, auto-fix policy, recursive audit terminal.
5. Wide design, progressive enforcement: 44 baseline contract elements (29 unit-facing + 9 conformance contract + 6 DOT state managed). Birth gate hẹp lúc đầu (15 strict elements), DOT enrich dần Tier 1-5.

---

§1. Reframing — Universal Information Substrate

1.1 Tầm nhìn chiến lược

User: Incomex không finetune model thông minh lên, mà làm dữ liệu thông minh lên (Smart Data 5 cấp: Đúng → Đủ → Sạch → Sống → Thông minh).

information_unit không chỉ "miếng văn bản luật" — phải là đơn vị thông tin phổ quát đại diện cho:

Use case	Diễn giải
Luật / điều khoản	Văn bản pháp lý (TAC pipeline)
Quy trình / SOP	Đoạn quy trình, bước SOP
Business workflow step	Bước workflow doanh nghiệp
Knowledge atom	Sự kiện, định nghĩa, claim trong KB
Decision	Quyết định kèm rationale
Task instruction	Mô tả công việc
Rule / constraint	Validation rule, business rule
Composite member	Phần tử trong composite

1.2 KHÔNG sinh object mới

Theo P44-1 §3.1 + Đ44 §0.2: mở rộng không phải đẻ family mới. Vẫn dùng family information_unit duy nhất, mở rộng qua:

• Capability set thêm capability cho cùng family
• Profile entries multi-role (P44-3 §2.1)
• Edge relation qua universal_edges (NĐ-36-01)
• Cross-law extension (Đ34/Đ29/Đ24/Đ39 mở rộng cho cùng family)

Hình tượng:

• Atom = information_unit granularity = atomic
• Molecule = unit mẹ chứa nhiều unit con qua edge contains
• Building = collection/publication/workflow chứa nhiều units (family khác)
• Species = facet/classification qua Đ29 + Đ24, không object mới

1.3 Owner law architecture

Aspect	Owner law base	Extension laws
Identity / address / canonical	Đ38	—
Content / body / hash	Đ38	—
Lifecycle / version / status	Đ38	—
Publication / authority	Đ38	—
Relation edges	Đ44 + NĐ-36-01	(P44-4)
Label / facet / topic	Đ24	—
Species / classification	Đ29	—
Vector / KG projection	Đ39	—
Workflow binding	Đ34 BPMN	(future)
DOT checker / drift	Đ35	—
Birth gate enforcement	Đ44 + Đ38	—

→ Đ38 là base law quản identity/content/publication. Các luật khác mở rộng capability cho cùng family.

1.4 Match Đ44 NS-1 / NS-3

• NS-1: 1 family information_unit duy nhất, không duplicate.
• NS-3: extension capability không phá core.

---

§2. Living DB Contract — 9 câu hỏi sống

Mỗi instance phải tự trả lời 9 câu. Match Đ44 §6.A 5 LV mở rộng.

2.1 9 câu hỏi sống

#	Câu hỏi	Cơ chế	Cấu trúc	Tier
Q1	Tôi là ai?	identity capability + canonical address	Profile JSONB + core column	Tier 0
Q2	Tôi thuộc ai?	parent/child + containment edge	Edge contains/belongs_to + parent_id	Tier 1
Q3	Ai thuộc tôi?	reverse contains	Computed reverse query	Tier 1
Q4	Tôi dùng ai?	uses/references/depends_on edges	Edges (universal_edges)	Tier 1
Q5	Ai dùng tôi?	reverse uses index	Computed reverse query	Tier 1
Q6	Tôi sinh từ đâu?	derived_from edge	Edge derived_from	Tier 1
Q7	Tôi đang ở workflow nào?	workflow binding	Edge step_in / Profile workflow_v1	Tier 3
Q8	Tôi có lệch không?	DOT checker + drift status	DOT state	Tier 4
Q9	Tôi cần tự enrich gì?	enrichment contract	DOT enrichment plan	Tier 4-5

2.2 Smart Data 5 cấp ánh xạ

Smart Data cấp	Câu hỏi cover	Tier
Đúng	Q1	Tier 0
Đủ	Q1+Q2	Tier 0+1
Sạch	Q1+Q2+Q3	Tier 0-1
Sống	Q1-Q6 + checker	Tier 0-1 + Tier 4
Thông minh	Q1-Q9 đầy đủ	Tier 0-5

2.3 Match Đ44 §6.A 5 LV

Đ44 LV	Living DB Q
LV-1 Là ai	Q1
LV-2 Thuộc về	Q2
LV-3 Nói về	Q9 (Tier 2)
LV-4 Liên quan	Q4, Q5, Q6
LV-5 Ai dùng nó	Q3, Q5

→ Living DB Contract = Đ44 5 LV + 4 mở rộng (Q3 reverse, Q7 workflow, Q8 drift, Q9 enrichment).

---

§3. Family registration + Capability set

3.1 Family Registry entry (P44-1 §2)

P44-1 Field	Giá trị đề xuất
F1 family_code	information_unit
F2 family_name	{vi: "Miếng thông tin", en: "Information Unit"}
F3 owner_law_code	NRM-LAW-38 (base; extension qua Đ34/Đ29/Đ24/Đ39 + Đ44)
F4 owner_agency_code	TBD/unassigned (OP-B)
F5 schema_profile_binding	references to N profile entries (cardinality 0..n per P44-3 §2.3)
F6 maturity_level	M2 provisional
F7 status	proposed
F8 timestamps	(PG tự suy ra)

3.2 Capability set — 10 capabilities

#	Capability	Trả lời câu hỏi sống	Owner law	Tier
Cap-1	identity	Q1	Đ38	Tier 0
Cap-2	content	(cơ sở Q9)	Đ38	Tier 0
Cap-3	publication	(cơ sở Q1, Q2)	Đ38	Tier 0
Cap-4	relation	Q4, Q5, Q6	NĐ-36-01 + Đ44	Tier 1
Cap-5	composition	Q2, Q3	Đ44 + Đ0-B	Tier 1
Cap-6	semantic	Q9 (Tier 2)	Đ24 + Đ29 + Đ39	Tier 2
Cap-7	workflow	Q7	Đ34 BPMN	Tier 3
Cap-8	governance	(Q1 base)	Đ44 + Đ37	Tier 0
Cap-9	checker	Q8	Đ35	Tier 4
Cap-10	execution_readiness	Q9 deep	Đ44 + Đ22	Tier 5

3.3 4 cấu trúc thực hiện

Cấu trúc	Mô tả	Ví dụ
Profile JSONB	Data stored in record	title, key_entities
Edge	Relation in universal_edges	contains, uses
DOT state	System-managed audit/health field	last_check_at, drift_flag
Derived check	System auto-verify, KHÔNG lưu	body_hash_verify_ok

→ Mỗi capability combine nhiều cấu trúc.

---

§4. Base Core vs Extension Capability Boundary

Phải có ranh giới rõ: base core (mọi unit phải có) vs extension capability (chỉ bật khi use case cần).

4.1 4 nhóm capability scope

Nhóm	Bắt buộc mọi unit?	Capabilities	Tier	Khi nào bật
Universal Core	✅ Có (mọi unit)	identity, content (anchor), publication (anchor), governance	Tier 0	Birth gate — block nếu thiếu
Relation Core	🔶 Nên có sớm	relation, composition (Q2, Q3, Q4)	Tier 1	Khi unit cần biết container/dependency
Domain Extension	❌ Tùy use case	semantic, workflow	Tier 2-3	Khi use case bật
System Intelligence	🔶 Tăng dần theo tier	checker, execution_readiness	Tier 4-5	Khi DOT mature + KG mature

4.2 Quy tắc enforce ranh giới

Quy tắc	Diễn giải
Universal Core thiếu → block birth	Không thể tạo unit thiếu identity / content anchor / governance
Relation Core thiếu → DOT warn, không block	Unit có thể tồn tại không edge, DOT log issue + nhắc populate
Domain Extension không bật → không log gì	Use case không cần
System Intelligence chưa active → DOT degrade gracefully	Tier 4-5 chưa active → conformance audit chỉ ở Tier 0-1 level

4.3 Hệ quả thiết kế

• Schema rộng (10 capability + baseline elements + roadmap Tier 1-5).
• Birth gate hẹp — chỉ block Universal Core.
• DOT enrich dần Relation Core + Domain Extension.
• Self-healing tăng dần System Intelligence.

---

§5. Universal Minimum Core (UMC) — Independent of TAC

UMC định nghĩa độc lập TAC physical. TAC là một implementation của UMC, không phải UMC sinh ra từ TAC. UMC contract invariant qua mọi implementation pattern (single inheritance table, per-kind tables, hybrid — chốt qua APR).

5.1 UMC định nghĩa

UMC là contract bắt buộc cho mọi information_unit instance — bất kể use case là luật/workflow/claim/decision/rule. UMC = nội dung của Universal Core scope (§4.1).

5.2 10 UMC elements

#	UMC element	Mục đích	Cardinality	Fill	Bắt buộc tại
U1	unit_id	Identity duy nhất toàn hệ thống	1..1	System auto	Birth
U2	canonical_address	Địa chỉ ổn định, immutable. Format khai per unit_kind trong vocab metadata (xem §5.4)	1..1	System auto / Agent (theo use case)	Birth
U3	unit_kind	Phân loại nguyên thuỷ — vocab seed controlled-draft, KHÔNG enum hardcode (xem §5.3)	1..1	Agent manual	Birth
U4	lifecycle_status	Trạng thái vòng đời — FK vocab	1..1	System auto (default draft)	Birth
U5	content_anchor_ref	Tham chiếu content (body, file path, KB doc, ...)	1..1	Agent manual hoặc System	Birth
U6	version_anchor_ref	Tham chiếu version	1..1	System auto	Birth
U7	owner_ref	Owner instance (ai tạo unit này)	1..1	Agent manual	Birth
U8	created_at, updated_at, created_by, updated_by	Audit timestamps	1..1 each	System auto	Birth
U9	parent_or_container_ref	Container immediate (publication / workflow / collection)	0..1	Agent manual hoặc System	Birth nếu có parent; NULL hợp lệ cho top-level
U10	conformance_status	UMC anchor cho trạng thái conformance theo SCMR aggregate (Đ44 §3.4). Tier 0 default = open. Status thật được DOT cập nhật dần khi P44-5/Tier 4 active — không hiểu là Tier 0 đã audit đầy đủ.	1..1	System auto (default open) / DOT (Tier 4)	Birth (default open)

Total UMC: 10 elements — hard minimum cho mọi information_unit.

5.3 U3 unit_kind vocab — seed controlled-draft, extensible

Quan trọng (NT4 cấm hardcode): unit_kind KHÔNG phải enum cứng. Là vocab mở rộng qua APR, lưu trong system vocab framework (Đ24 vocab system hoặc dot_config — defer APR), KHÔNG tạo registry độc lập.

Seed values controlled-draft (8 + 1 fallback):

Seed value	Use case	Status
law_unit	Văn bản pháp lý / điều khoản (TAC pipeline đã có)	Seed proposed
sop_step	Bước trong SOP / quy trình	Seed proposed
workflow_step	Bước trong business workflow (Đ34 BPMN)	Seed proposed
knowledge_atom	Sự kiện / định nghĩa trong KB	Seed proposed
claim	Mệnh đề có thể verify (Addendum §2.3)	Seed proposed
decision	Quyết định kèm rationale	Seed proposed
task_instruction	Mô tả công việc	Seed proposed
rule	Validation rule, business rule, constraint	Seed proposed
custom	Fallback tạm khi chưa có vocab value chính thức. DOT phải nhắc chuẩn hoá về vocab chính thức. Không nên dùng dài hạn.	Fallback

Quy tắc mở rộng vocab:

• Thêm value mới qua APR cấp medium + amend unit_kind vocab.
• Future candidates: policy_clause, evidence_unit, risk_signal, customer_instruction, ... (tùy use case phát sinh).
• Vocab framework defer APR (Đ24 hoặc dot_config) — không độc lập.

5.4 U2 canonical_address format per unit_kind

Format canonical_address khác nhau theo unit_kind. Phải khai trong vocab metadata của unit_kind, không hardcode.

Ví dụ logical (defer chi tiết APR per use case):

unit_kind	Format example	Note
law_unit	{document_code}.{section_path} (vd Đ44.§3.2)	TAC pipeline đã có
sop_step	{sop_code}.{step_number} (vd SOP-DEPLOY.05)	(đề xuất)
workflow_step	{workflow_code}.{step_id} (vd WF-ONBOARDING.S03)	(đề xuất)
knowledge_atom	{kb_namespace}.{atom_id} (vd kb.products.atom_42)	(đề xuất)
claim	{source_unit}.{claim_id} (vd Đ44.§3.2.claim_1)	(đề xuất)
decision	{decision_namespace}.{decision_id}	(đề xuất)
task_instruction	{task_code}.{instruction_id}	(đề xuất)
rule	{rule_namespace}.{rule_id}	(đề xuất)
custom	(không format chuẩn — DOT nhắc chuẩn hoá)	Fallback

Quy tắc: vocab metadata unit_kind chứa canonical_address_format_pattern (logical regex/template). Birth gate validate canonical_address match pattern của unit_kind tương ứng.

OPEN P38-X-14: Format chính thức cho non-law unit_kind chốt qua APR per use case khi capability use case ready.

5.5 UMC vs Profile vs Extension

Lớp	Chứa gì	Bắt buộc	Lưu ở đâu
UMC (§5.2)	10 elements universal	Mọi unit, mọi use case	Core columns (chốt qua APR khi physical hoá)
Profile data fields (§7)	identity_v1 + content_v1 + publication_v1 fields	Tier 0 trong scope use case	Profile JSONB
Conformance check contracts (§7)	body_hash_verify_ok, etc.	Derived check, không lưu	Mechanism, không lưu
DOT state fields (§7)	last_check_at, drift_flag	System-managed	DOT writes
Extension capability (§9)	relation, composition, semantic, workflow, checker	Tùy use case	Edge / Profile / DOT state

5.6 UMC cardinality vs Đ44 §3.2

Đ44 G	UMC element cover
G1 Identity	U1 unit_id, U2 canonical_address
G2 Type & Family	U3 unit_kind, family_code = information_unit (context)
G3 Lifecycle & Version	U4 lifecycle_status, U6 version_anchor_ref
G4 Owner & Authority	U7 owner_ref (instance-level); family-level OP-B
G5 Source & Provenance	(cap qua relation Tier 1 — derived_from edge)
G6 Content / Profile	U5 content_anchor_ref (anchor only); profile data ở §7
G7 Relation	(Tier 1, ngoài UMC)
G8 Usage	(Tier 1, ngoài UMC)
G9 BOM	N/A
G10 Vector	(Tier 5, ngoài UMC)
G11 Checker	U10 conformance_status (anchor only)
G12 Audit	U8 timestamps

→ UMC cover G1, G2, G3, G4, G6 (anchor), G11 (anchor), G12 = 7/12 G ở Universal Core scope.

5.7 UMC mapping vào TAC physical

TAC = specialized implementation cho unit_kind = law_unit. Use case khác cần implementation tương đương.

UMC element	TAC physical
U1 unit_id	tac_logical_unit.id (UUID PK)
U2 canonical_address	tac_logical_unit.canonical_address (UNIQUE, immutable)
U3 unit_kind	(chưa có cột tương ứng trong TAC) — mọi tac_logical_unit row đồng nhất unit_kind = law_unit (TAC pipeline chỉ xử lý văn bản pháp lý). Lưu ý: tac_logical_unit.section_type là sub-classification trong scope law_unit (chương / mục / điều / khoản / điểm), KHÔNG phải unit_kind. Implementation: (a) thêm core column unit_kind hoặc (b) suy ra từ table membership theo per-kind pattern (§5.8)
U4 lifecycle_status	tac_logical_unit.lifecycle_status (FK vocab)
U5 content_anchor_ref	tac_unit_version.body (cho law_unit) — UV-level inherit từ LU
U6 version_anchor_ref	tac_unit_version.id reference
U7 owner_ref	TBD (P11A chưa note rõ) — vào identity_profile JSONB nếu chưa có core column
U8 timestamps	tac_logical_unit.created_at etc.
U9 parent_or_container_ref	tac_logical_unit.parent_id hoặc tac_publication_member.publication_id
U10 conformance_status	(chưa có) — DOT state mới, P44-5

Quan sát: 8/10 UMC elements có cột tương ứng trong TAC. U3 chưa có cột (cần thêm core column hoặc suy ra qua per-kind pattern); U10 chưa có (tạo qua P44-5).

5.8 UMC implementation pattern — invariant

Quan trọng: Dù APR chọn pattern nào (single inheritance table information_unit, per-kind tables tac_logical_unit/wf_step_unit/kg_atom_unit/..., hoặc hybrid), UMC contract phải bảo toàn. UMC là invariant; pattern là implementation choice.

Pattern	Mô tả	Trade-off
Single inheritance table	1 master information_unit table, discriminator unit_kind, profile JSONB per role	Đơn giản query cross-kind, JSONB phình to
Per-kind tables	Mỗi unit_kind có table riêng (TAC hiện tại = per-kind cho law_unit)	Tối ưu per-kind, phức tạp cross-kind query
Hybrid	UMC core columns shared (vd information_unit_core) + per-kind specialization tables	Best of both, cần FK 1-1

Mọi pattern đều phải:

• Implement đầy đủ 10 UMC elements (§5.2).
• Bảo toàn UMC cardinality + immutability (U1, U2 immutable).
• Thoả vocab unit_kind extensible (§5.3).
• Cho phép birth gate kiểm UMC + Tier 0 profile required.

OPEN P38-X-12: Implementation pattern chọn final qua APR design phase.

5.9 UMC mapping vào use case khác (illustrative)

Không chốt — chỉ minh hoạ pattern.

Use case	unit_kind	Implementation example
Law unit	law_unit	tac_logical_unit + tac_unit_version (TAC pipeline)
Workflow step	workflow_step	(future) cùng information_unit master hoặc wf_step_unit table riêng
Knowledge atom	knowledge_atom	(future) tương tự
Decision	decision	(future) tương tự

---

§6. Tiered rollout + Progressive enforcement

6.1 6 tier rollout

Tier	Mục tiêu	Capabilities	Pre-condition	Match Đ44 maturity
Tier 0	Sinh được unit đúng	UMC + identity + content + publication + governance	P44-1/2/3 PASS	M2
Tier 1	Quan hệ thông minh	relation + composition	P44-4 PASS	M2-M3
Tier 2	Enrichment ngữ nghĩa	semantic	Đ24 + Đ29 + Đ39 ready	M3
Tier 3	Workflow binding	workflow	Đ34 BPMN active	M3-M4
Tier 4	Tự kiểm tra	checker	P44-5 PASS + Đ35	M3-M4
Tier 5	Self-healing + KG	execution_readiness	Đ22 extend + Đ39 mature	M4

6.2 Progressive enforcement matrix

Tier	Birth gate	DOT mode	Required count	Optional count
Tier 0 (UMC)	block thiếu UMC	block thiếu Universal Core	10 UMC	—
Tier 0 (Profile)	block thiếu profile required	block production / warn draft	5 (3 identity + 2 publication; content all derived)	14 (3 + 5 + 5 + 1 composition_role)
Tier 1 (Relation/Composition)	không block	DOT warn thiếu container; INFO thiếu uses	0	(edges)
Tier 2 (Semantic)	không block	DOT INFO + auto-enrich	0	(Tier 2 fields trong content_v1)
Tier 3 (Workflow)	không block (chỉ khi unit_kind workflow-related)	DOT warn thiếu binding	conditional	(workflow_v1 future)
Tier 4 (Checker)	không block	DOT auto-update state	0	(DOT state fields)
Tier 5 (Self-healing)	không block	DOT auto-correct + auto-enrich	0	(KG projection)

6.3 Quy tắc enforcement

Quy tắc	Diễn giải
Block tối thiểu ở Tier 0	Birth gate chỉ block UMC + Tier 0 profile required = 15 elements strict
DOT mode tăng dần	Tier 1: warn. Tier 2: INFO. Tier 3: warn nếu use case workflow. Tier 4-5: auto.
Family + maturity quyết định mode	Family information_unit ở M2 → mode strict; ở M0 → loose
Use case quyết định Domain Extension	unit_kind workflow_step → bật Tier 3; law_unit → không

6.4 Hệ quả

• Production family (information_unit M2 cho TAC) → birth gate strict UMC + Tier 0; DOT enrich Tier 1+.
• Pilot use case (workflow_step M0-M1) → birth gate chỉ block UMC; mọi extension là INFO.
• Migration phase (capability mới) → mode warn cho tier mới, gradually thành block sau evidence.

---

§7. Tier 0 — 3 Core Profiles (Proposed Tier-0 Baseline)

Đây là Proposed Tier-0 Baseline cho APR cấp medium — KHÔNG phải spec final cưỡng chế. Chốt qua APR khi Đ44 enacted v1.0. Tách rõ Profile Data (lưu, unit khai) vs Conformance Contract (derived check, không lưu) vs DOT State (system-managed).

7.1 Tách rõ 3 loại element

Loại	Lưu ở đâu	Ai khai	Ví dụ	Mechanism
Profile Data Field	Profile JSONB / core column	Agent / DOT enrichment	title, aliases, word_count	INSERT vào record
Conformance Contract Check	KHÔNG lưu — derived check	Không ai khai (system verify)	body_hash_verify_ok	DOT verify, log issue nếu fail
DOT State Field	Hệ thống quản	Không ai khai (DOT writes)	last_check_at, drift_flag	DOT updates

7.2 information_unit_identity_v1 — LU-level (Proposed Tier-0 Baseline)

Profile role: identity | g_groups_covered: {G1, G2}

Profile Data Fields (lưu, agent/DOT khai):

Field	Required/Optional	Fill type	TAC anchor	Note
title	Required	Agent manual	identity_profile JSONB (verify §10.1)	Tiêu đề unit
owner_lookup_ref	Required	Agent manual	identity_profile JSONB	FK ref user/agency
primary_section_type_ref	Required	Agent manual	tac_logical_unit.section_type core column	P11A #7 ✅
composition_role	Optional (default atomic)	Agent manual	identity_profile JSONB	enum {atomic, molecular, composite}
aliases	Optional	Agent assisted	identity_profile JSONB	List tên khác
summary_text	Optional	Agent manual	identity_profile JSONB	≤ 200 chars
description	Optional (recommended)	Agent + System	identity_profile JSONB	Bài học Đ43

Profile data: 7 fields = 3 Required + 4 Optional.

Conformance Contract Checks (không lưu):

Check	G	Mechanism	Action khi fail
canonical_address_format_ok	G1	System verify format theo unit_kind vocab (§5.4)	Block birth
family_code_registered_ok	G2	Verify family_code active trong Family Registry	Block birth

DOT State:

Field	Mechanism	Tier
last_identity_check_at	DOT cặp Schema Conformance Audit	Tier 4

7.3 information_unit_content_v1 — UV-level (Proposed Tier-0 Baseline)

Profile role: content | g_groups_covered: {G3, G6}

Core text unit fields (body, content_hash, lifecycle_status, version_seq, review_state) đã có cột riêng trong tac_unit_version. Profile không duplicate core.

Profile Data Fields (lưu):

Field	Required/Optional	Fill type	TAC anchor	Note
word_count	Optional	DOT derive (NT11)	content_profile JSONB	DOT tính từ body
key_entities	Optional (Tier 2)	Agent assisted (Đ39 KG future)	content_profile JSONB	Entity refs
topics	Optional (Tier 2)	Agent assisted (Đ24 label_rule)	content_profile JSONB	Phải qua Đ24 (LSL-01 v0.4 P3)
claim_extractions	Optional (Tier 2)	DOT derive (Đ39 + Addendum §2.3)	content_profile JSONB	Đ39 future
granularity_level	Optional (default tính từ body length + parent)	DOT derive	content_profile JSONB	Aligned Đ0-B 7 lớp

Profile data: 5 Optional fields. Required nằm ở core column hoặc derived check.

Conformance Contract Checks (không lưu):

Check	G	Mechanism	Action
body_hash_verify_ok	G6	System auto compute hash → verify match content_hash	Block UPDATE
lifecycle_anchor_ok	G3	System verify lifecycle_status ∈ vocab	Block birth
version_seq_consistent	G3	DOT verify version sequence với LU	Log issue
review_state_consistent	G3	DOT verify review_state ↔ lifecycle	Log issue
referenced_entities_resolvable	G6	DOT verify key_entities refs resolve	Log INFO (Tier 2)

DOT State:

Field	Mechanism	Tier
last_content_check_at	DOT daily	Tier 4
drift_flag	DOT detect drift	Tier 4
vector_sync_status	Đ39 sync — đã có trong tac_unit_version	Tier 5
enrichment_status	DOT enrichment progress	Tier 5

7.4 information_unit_publication_v1 — Pub-level (Proposed Tier-0 Baseline)

Profile role: publication | g_groups_covered: {G3, G4, G6}

LSL-01 v0.4 P5: publication lifecycle phải tuân Đ38 §A3 + §B2.1.

Profile Data Fields (lưu):

Field	Required/Optional	Fill type	TAC anchor	Note
publication_authority_ref	Required	Agent manual	publication_profile JSONB	FK owner_agency
publication_type_ref	Required	Agent manual	tac_publication.publication_type core	P11A #1 ✅
kb_anchor_ref	Optional	Agent manual	publication_profile JSONB	KB path
doc_chair	Optional	Agent manual	publication_profile JSONB	Chủ trì
council_score	Optional	Agent manual	publication_profile JSONB	Council review
jurisdiction	Optional	Agent manual	publication_profile JSONB	Phạm vi
description	Optional (recommended)	Agent + System	publication_profile JSONB	Bài học Đ43

Profile data: 7 fields = 2 Required + 5 Optional.

Conformance Contract Checks (không lưu):

Check	G	Mechanism	Action
publication_lifecycle_ok	G3	System verify vocab	Block birth
enacted_at_present_when_enacted	G3	Conditional check	Block transition

DOT State:

Field	Mechanism	Tier
last_publication_audit_at	DOT daily	Tier 4

7.5 Tier 0 baseline summary — 3 lớp tách rõ

Wording chuẩn: phân biệt rõ "unit-facing elements" (unit/agent khai), "conformance contract" (derived, không lưu), "DOT state managed" (system-managed).

Lớp	UMC	identity_v1	content_v1	publication_v1	Tổng
Unit-facing elements (unit khai hoặc agent fill)	10	7	5	7	29
Conformance contract checks (derived, không lưu)	(qua U10 anchor + birth checks)	2	5	2	9
DOT state managed (system-managed)	(qua U10 update + Tier 4 fields)	1	4	1	6

Tổng = 44 baseline contract elements = 29 unit-facing + 9 conformance contract + 6 DOT state managed.

Cách hiểu đúng:

• "44 elements" KHÔNG có nghĩa là agent khai 44 fields.
• Agent/system khai 29 unit-facing (10 UMC + 19 profile data — trong đó nhiều là system auto / DOT derive / agent assisted).
• 9 conformance check là contract (system verify, không lưu).
• 6 DOT state là system-managed (DOT updates, không khai).

Birth gate hard threshold = 15 elements strict:

• 10 UMC (toàn bộ) +
• 5 profile required (3 identity Required + 2 publication Required; content_v1 toàn Optional vì required là derived check).
• 14 Optional profile + 9 conformance + 6 DOT state = DOT manage dần Tier 1-5.

---

§8. DOT Contract Matrix per Capability

Scope P38-XC: chốt responsibility logical. P44-5 handoff: tên DOT cụ thể, schedule, auto-fix policy, recursive audit terminal — chốt ở P44-5.

8.1 DOT Contract Matrix

Capability	Writer responsibility	Checker responsibility	Enrichment responsibility	Drift signal	Reverse-index	P44-5 handoff
identity (Cap-1)	Validate canonical_address format theo unit_kind vocab on INSERT	Periodic check duplicate canonical; verify family registered	Suggest title/alias từ similar units	Identity conflict (duplicate canonical)	—	DOT name + schedule + format validator details
content (Cap-2)	Compute content_hash on INSERT/UPDATE; populate word_count	Verify body_hash_verify_ok; lifecycle_anchor_ok; version_seq; review_state	Auto-extract entities/topics/claims (Tier 2 via Đ39/Đ24)	Hash mismatch / version sequence / review state	—	DOT writer + checker pair name + schedule
publication (Cap-3)	Set publication lifecycle on transition	Verify publication_lifecycle_ok; enacted_at_present	Suggest jurisdiction, council_score	Publication status inconsistency	—	DOT name + transition triggers
relation (Cap-4)	Create edge entries in universal_edges on INSERT	Verify edge target exists; detect orphan/broken edges	Suggest related units via similarity (Tier 2+)	Orphan edge / broken edge / missing reverse	Maintain reverse for Q3, Q5	DOT writer + checker + reverse maintenance pair (P44-4 + P44-5)
composition (Cap-5)	Set composition_role on INSERT; create contains edges	Verify parent_or_container_ref; verify composition_role consistent	Suggest composition role từ body length + parent	Container-member mismatch	Maintain reverse contains for Q3	DOT name + cap composition logic
semantic (Cap-6)	Extract topics/entities/claims (Tier 2 ready)	Verify entity refs resolvable (Đ39); verify topic ∈ Đ24 vocab	Auto-enrich từ KG (Đ39); suggest species (Đ29)	Stale semantic; broken entity ref	—	Đ24/Đ29/Đ39 integration DOTs
workflow (Cap-7)	Set workflow_step_ref on workflow unit INSERT (Tier 3)	Verify input/output unit refs; precondition refs	Suggest next step / decision rule	Workflow input/output mismatch; precondition violation	Maintain reverse step_in	Đ34 BPMN integration DOTs
governance (Cap-8)	Set owner_ref on INSERT	Verify owner exists; family registered	—	Family not registered; owner orphan	—	Birth gate trigger + Family Registry FK
checker (Cap-9)	Update last_check_at after each audit	Self-meta-audit (recursive — DOT audit DOT). Terminal cap: max 1 level recursion (defer P44-5 chốt cap depth)	—	DOT silent (chưa run); DOT failing	—	Recursive audit pattern + terminal cap (P44-5)
execution_readiness (Cap-10)	Set readiness flags on completion	Self-healing loop (Đ22 extend)	KG projection refresh; auto-enrich loop	Readiness regression; KG projection stale	Maintain reverse for self-healing	Đ22 extend + Đ39 KG bidirectional sync

8.2 5 responsibility — định nghĩa

Responsibility	Diễn giải
Writer	Tạo/cập nhật field hoặc edge khi INSERT/UPDATE/transition
Checker	Periodic verify field/edge hợp lệ + consistent
Enrichment	Auto-populate optional fields theo capability mature
Drift signal	Detect khi state lệch (capability hỏng)
Reverse-index	Maintain reverse query cho Q3, Q5 (relation/composition)

8.3 P44-5 handoff — scope tách rõ

P38-XC chốt (logical contract):

• Responsibility per capability (5 loại).
• Pairing pattern (writer + checker tối thiểu).
• Drift signal types per capability.
• Reverse-index responsibility (cho relation/composition).

P44-5 chốt (implementation):

• Tên DOT cụ thể (vd dot_information_unit_identity_writer, dot_information_unit_content_drift_checker).
• Schedule (event-driven / hourly / daily / on-demand).
• Auto-fix policy (Đ22 self-healing extend).
• Recursive audit terminal cap: Cap-9 self-meta-audit max depth (đề xuất 1 level — chốt P44-5).
• Code/trigger implementation.

8.4 DOT Pairing (Đ35 + Đ44 §9.2)

Vai	Trách nhiệm
Động cơ chính (writer + enrichment)	Tạo/cập nhật field/edge; auto-populate khi capability ready
Động cơ phụ (checker + drift signal)	Periodic verify; log drift; escalate

Mỗi capability cần ít nhất 1 cặp DOT — writer (chính) + checker (phụ). Enrichment + drift có thể merge vào checker hoặc tách.

OR principle (Hiến pháp — DOT theo cặp): DOT phụ (checker) IDLE = thiết kế đang ổn định, hệ thống lành. DOT phụ active = capability đang lệch — phải điều tra root cause (Đ22 self-healing loop), KHÔNG xem là "DOT chạy nhiều = hệ thống giàu chức năng". Trạng thái IDLE là target, không phải lỗi. Hệ quả thiết kế: dashboard giám sát phải highlight DOT phụ active như alert, không phải normal traffic.

8.5 Capability mature progression

Tier	DOT capability mature	Hậu quả
Tier 0	identity + content + publication writer/checker	Birth gate strict; checker block production
Tier 1	+ relation + composition writer/checker	Edges populated; reverse query active
Tier 2	+ semantic enrichment (Đ39/Đ24)	Auto-extract entities/topics/claims
Tier 3	+ workflow writer/checker (Đ34)	Workflow binding active
Tier 4	+ checker self-meta-audit (Cap-9 với terminal cap)	DOT audit DOT bounded
Tier 5	+ execution_readiness self-healing (Đ22 + Đ39 KG mature)	Auto-correct + KG bidirectional

→ Architecture additive — Tier mới unlock thêm DOT, không xoá DOT trước.

---

§9. Tier 1+ — Future capability contracts

9.1 Tier 1 — Relation (Cap-4)

Owner law: NĐ-36-01 + Đ44 §5 | P44-4 thiết kế chi tiết

Edge types (match Đ44 §5.3): references, depends_on, uses, derived_from, contradicts, implements, governed_by, supersedes, compatible_with.

Reverse queries: Q3, Q5 (xem §8.3).

9.2 Tier 1 — Composition (Cap-5)

Owner law: Đ44 + Đ0-B 7 lớp

Edge types: contains, belongs_to, part_of_composite.

Profile data: composition_role (identity_v1), granularity_level (content_v1).

KHÔNG sinh object mới — atom/molecule/composite chỉ là field + edge.

9.3 Tier 2 — Semantic (Cap-6)

Owner law: Đ24 + Đ29 + Đ39

Profile data fields (Tier 2 enrich content_v1): topics, species_classification, key_entities, claim_extractions.

KHÔNG đẻ taxonomy mới (LSL-01 v0.4 P3).

9.4 Tier 3 — Workflow (Cap-7)

Owner law: Đ34 BPMN | Capability mới so với P38-X cũ

Profile workflow_v1 (future): workflow_step_ref, process_step_role, input_unit_refs, output_unit_refs, decision_rule_refs, precondition_refs, postcondition_refs.

Edge types: step_in, precondition_for, produces.

9.5 Tier 4 — Checker (Cap-9)

Owner law: Đ35 paired DOT | P44-5 thiết kế chi tiết

DOT state fields: last_check_at, last_check_result, drift_flag, conformance_status, dots_active_for_unit.

9.6 Tier 5 — Self-healing + KG (Cap-10)

Owner law: Đ22 self-healing + Đ39 KG

KG projection bidirectional PG ↔ Qdrant. Self-healing edges: auto_corrected_by, auto_enriched_by, requires_human_review.

Tier 5 = Smart Data "Thông minh" — Living DB Contract trả lời 9/9 câu hỏi tự động.

---

§10. Đối chiếu TAC physical reality (P11A)

TAC là một implementation của UMC, không phải UMC sinh ra từ TAC. UMC §5 độc lập; mapping §5.7 + chi tiết §10.

10.1 tac_logical_unit — identity profile anchor

P11A: id, canonical_address, parent_id, sort_order, section_type, lifecycle_status, identity_profile (JSONB GIN, {}), timestamps.

Field profile identity_v1	Đã có cột?	Vào identity_profile JSONB?
title	VERIFY ❓	Mặc định JSONB
owner_lookup_ref	Không	JSONB
primary_section_type_ref	✅ section_type FK	Core column
composition_role	Không (Tier 1 enrich)	JSONB
aliases, summary_text, description	Không	JSONB

OPEN P38-X-1: Verify tac_logical_unit có cột title/description riêng — read-only DB query.

10.2 tac_unit_version — content profile anchor

P11A: id, body, content_hash, lifecycle_status, review_state, version_label, version_seq, vector_sync_*, content_profile (JSONB GIN, {}), timestamps.

→ 5 profile data fields content_v1 toàn bộ vào content_profile JSONB. 5 conformance checks không lưu.

10.3 tac_publication — publication profile anchor

P11A: id, publication_type, lifecycle_status, publication_profile (JSONB GIN, {}), timestamps.

Field profile publication_v1	Đã có cột?	Vào publication_profile JSONB?
publication_authority_ref	VERIFY ❓	Mặc định JSONB
publication_type_ref	✅ publication_type FK	Core column
kb_anchor_ref, doc_chair, council_score, jurisdiction, description	Không	JSONB

OPEN P38-X-2: Verify tac_publication schema columns — read-only DB query.

10.4 tac_publication_member — không profile

Member là relation row. Theo P44-2 §4.1 Entry 4: G6 N/A. Không cần profile.

Tier 1 P44-4 chốt: lý giải (a) internal containment hay (b) migrate sang universal_edges (OPEN P44-2-δ).

10.5 UMC mapping summary

8/10 UMC có cột physical TAC tương ứng. Còn 2:

• U3 unit_kind — chưa có cột; mọi tac_logical_unit row đồng nhất unit_kind = law_unit (TAC pipeline chỉ xử lý văn bản pháp lý). Lưu ý: section_type (chương / mục / điều / khoản / điểm) là sub-classification trong scope law_unit, KHÔNG phải unit_kind. Implementation chọn (a) thêm core column unit_kind hoặc (b) suy ra qua per-kind table membership (§5.8).
• U10 conformance_status — chưa có; tạo qua P44-5.

---

§11. Đ44 Conformance Clause check (§9.5 C1–C5)

#	Yêu cầu	P38-XC cover	Status
C1	OQC ≥ 3/4	§11.1	✅ 4/4
C2	G1–G12 mapping	§5.6 + §7 + §10	✅
C3	Family Registry entry	§3.1 (OP-B unresolved)	⚠️ partial
C4	Relation Layer integration	§9.1 contract — defer P44-4	⚠️ contract ready
C5	Cơ chế cập nhật ≥ 1 mechanism per LV	§8 DOT Contract Matrix + Living DB Contract §2	✅ 5/5 LV + 4 mở rộng

11.1 OQC compliance (C1)

OQC	Thoả?	Lý do
OQC-1 Persistent Identity	✅	U1 + U2 + canonical_address immutable
OQC-2 Lifecycle ≥ 2 state	✅	U4 lifecycle_status 4+ state
OQC-3 Governance Subject	✅	Đ38 base + Đ44 cross-cutting
OQC-4 Has Relations	✅	tac_publication_member + Tier 1 universal_edges

→ 4/4.

11.2 Cơ chế cập nhật (C5)

LV / Q	Cơ chế (DOT Contract §8)
LV-1 / Q1	identity Cap-1 writer/checker — Tier 0
LV-2 / Q2	composition Cap-5 writer (containment edge) — Tier 1
LV-3 / Q9	semantic Cap-6 enrichment — Tier 2
LV-4 / Q4-Q6	relation Cap-4 writer — Tier 1
LV-5 / Q3, Q5	relation/composition Cap-4/5 reverse-index — Tier 1
Q7	workflow Cap-7 writer — Tier 3
Q8	checker Cap-9 drift signal — Tier 4
Q9	content Cap-2 + semantic Cap-6 enrichment — Tier 2-5

→ 5/5 LV + 4 mở rộng.

---

§12. Proposed Tier-0 Baseline / OPEN / Amendment candidates

12.1 Proposed Tier-0 Baseline (chốt qua APR cấp medium khi Đ44 enacted)

ID	Item	Nature
B-1	Family information_unit đăng ký (P44-1 8 fields)	Proposed
B-2	UMC 10 elements universal core, invariant qua mọi implementation pattern	Proposed
B-3	3 Tier 0 profile entries (identity_v1, content_v1, publication_v1)	Proposed
B-4	44 baseline contract elements = 29 unit-facing (10 UMC + 19 profile data) + 9 conformance contract + 6 DOT state managed	Proposed
B-5	Tách rõ Profile Data vs Conformance Contract vs DOT State	Proposed
B-6	Birth gate hard threshold = 15 elements strict (10 UMC + 5 Required profile); progressive cho rest	Proposed
B-7	DOT enrichment INFO-only cho optional	Proposed
B-8	Living DB Contract 9 câu hỏi sống	Proposed
B-9	Capability set 10 + 4 cấu trúc thực hiện + 4 nhóm scope	Proposed
B-10	DOT Contract Matrix per capability (writer/checker/enrichment/drift/reverse-index) — P44-5 handoff	Proposed
B-11	Tiered rollout 0-5 + Progressive enforcement matrix	Proposed
B-12	UMC độc lập TAC (TAC là 1 implementation cho law_unit)	Proposed
B-13	U3 unit_kind vocab seed controlled-draft + extensible qua APR + DOT nhắc custom chuẩn hoá	Proposed
B-14	U2 canonical_address format per unit_kind trong vocab metadata	Proposed
B-15	U10 conformance_status UMC anchor, Tier 0 default open, DOT update Tier 4	Proposed
B-16	Cap-9 recursive audit terminal cap (max 1 level — defer P44-5 chốt)	Proposed

12.2 OPEN items

ID	Item	Resolve khi
OPEN P38-X-1	Verify tac_logical_unit có cột title/description	Implementation
OPEN P38-X-2	Verify tac_publication columns	Implementation
OPEN P38-X-3	OP-B owner_agency	User chốt
OPEN P38-X-4	Edge structure Tier 1	P44-4
OPEN P38-X-5	Đ39 entity/claim extraction	Đ39 mature
OPEN P38-X-6	Đ24 label_rule integration	Đ24 active
OPEN P38-X-7	Đ29 species cho species_classification	Đ29 active
OPEN P38-X-8	Đ34 BPMN workflow Tier 3	Đ34 active
OPEN P38-X-9	Granularity_level vocab align Đ0-B 7 lớp	Đ0-B refresh
OPEN P38-X-10	Composition_role vocab fine-tune	APR
OPEN P38-X-11	UMC unit_kind vocab final list + framework anchor (Đ24 vs dot_config)	User + APR
OPEN P38-X-12	UMC implementation pattern: single inheritance / per-kind / hybrid	APR design
OPEN P38-X-13	Reverse-index materialized vs on-demand	P44-4 + volume
OPEN P38-X-14	Canonical_address format chính thức cho non-law unit_kind	APR per use case
OPEN P38-X-15	Cap-9 recursive audit terminal cap depth (đề xuất max 1 level)	P44-5

12.3 Amendment candidates (KHÔNG patch trong P38-XC)

Cho P44-*

ID	Candidate	Lý do
AC-44-3-A	P44-3 §6 sketch replace bằng "see P38-XC"	Tránh duplicate
AC-44-info-1	Đ44 §6.A LV-3 mở rộng cho text unit khi Đ39 chưa active	LV-3 depend capability
AC-44-info-2	Đ44 nên có khái niệm "UMC" universal cho mọi family	Sau P38-XC pilot

Cho luật chuyên môn

ID	Candidate	Lý do
AC-38-1	Đ38 version conflict (TD-44-1)	Resolve khi Đ44 enacted
AC-34-1	Đ34 BPMN align Tier 3 workflow capability	Khi Đ34 active
AC-29-1	Đ29 species expose classification capability	Cross-cutting design
AC-39-1	Đ39 KG expose entity/claim extraction	Đ39 mature
AC-24-1	Đ24 vocab system anchor cho unit_kind vocab	Cross-cutting

---

§13. Pre-conditions PASS + bước tiếp

13.1 Để P38-XC PASS

#	Pre-condition	Đã đạt?
1	Reframe universal substrate	✅ §1
2	Living DB Contract 9 câu	✅ §2
3	Capability set 10	✅ §3
4	Base Core vs Extension boundary	✅ §4
5	UMC 10 elements + invariant qua pattern + format per unit_kind	✅ §5
6	U3 vocab seed controlled-draft + extensible	✅ §5.3
7	U10 anchor + Tier 0 default open	✅ §5.2
8	Tiered rollout + Progressive enforcement	✅ §6
9	3 Tier 0 profiles tách Profile/Conformance/DOT state	✅ §7
10	DOT Contract Matrix + P44-5 handoff	✅ §8
11	Cap-9 recursive terminal cap	✅ §8.3
12	Tier 1+ contract roadmap	✅ §9
13	Đối chiếu TAC physical (clarify section_type ≠ unit_kind)	✅ §10
14	Đ44 Conformance check	✅ §11
15	Proposed Tier-0 Baseline (không "Final")	✅ §12
16	Không DDL/code/migration/patch	✅
17	KHÔNG sinh object mới	✅
18	PG First/Native/Driven	✅
19	Wide design + progressive enforcement	✅
20	OR principle "DOT phụ IDLE" §8.4	✅

13.2 Bước tiếp sau upload

GPT đề xuất P44-4 Relation/Composition Edge Conformance trước P44-5, vì Tier 1 relation/composition là nền để Living DB trả lời Q2-Q6. DOT muốn làm dữ liệu sống thì trước hết phải có quan hệ chuẩn để DOT kiểm và enrich.

Sau P38-XC upload:

1. P44-4 — Relation Edge + Composition unlock Tier 1.
2. P44-5 — Update Mechanism + DOT Contract Matrix realize, unlock Tier 4.
3. Implementation Tier 0 sau Đ44 enacted v1.0:
   • APR cấp high cho Family Registry seed.
   • APR cấp medium cho 3 profile entries Tier 0.
   • Populate identity/content/publication JSONB.

---

§14. AP-CLOSE

14.1 Đã làm trong P38-XC final (upload)

1. Nền tảng P38-XB giữ nguyên: universal substrate, UMC độc lập TAC, Living DB Contract 9 câu, capability set 10, DOT Contract Matrix, tier rollout 0-5, wide schema + progressive enforcement.
2. 3 GPT polish (vòng P38-XB → P38-XC) áp dụng:
   • U3 unit_kind vocab seed controlled-draft + extensible qua APR + DOT nhắc custom (§5.3).
   • U10 conformance_status UMC anchor + Tier 0 default open + DOT update Tier 4 (§5.2).
   • DOT Contract Matrix thêm cột "P44-5 handoff" + section §8.3 scope tách rõ.
3. 5 self-rà soát risk fix (vòng P38-XB → P38-XC):
   • Vocab unit_kind lưu trong system vocab framework (Đ24 / dot_config), không độc lập (§5.3).
   • U2 canonical_address format per unit_kind trong vocab metadata (§5.4).
   • Cap-9 recursive audit terminal cap max 1 level — defer P44-5 (§8.3 + §8.5).
   • UMC contract invariant qua mọi implementation pattern (single/per-kind/hybrid) (§5.8).
   • Wording "44 baseline" clarify: 29 unit-facing + 9 conformance contract + 6 DOT state managed (§7.5 + §12.1 B-4).
4. 3 self-rà soát lần cuối trước upload (vòng P38-XC → P38-XC final):
   • Path align dieu44-trien-khai/design/04-information-unit-profile-schema.md để khớp folder triển khai Đ44 (header).
   • Clarify §5.7 + §10.5: tac_logical_unit.section_type (chương/mục/điều/khoản/điểm) là sub-classification trong scope law_unit, KHÔNG phải unit_kind. Mọi TAC row đồng nhất unit_kind = law_unit. Implementation chọn (a) thêm core column hoặc (b) suy ra qua per-kind pattern.
   • Bổ sung OR principle "DOT phụ IDLE = thiết kế tốt" ở §8.4 — align Hiến pháp DOT theo cặp.
5. Cập nhật B-13/B-14/B-15/B-16 trong Proposed Tier-0 Baseline (§12.1).
6. Thêm OPEN P38-X-14 (canonical_address format non-law) + P38-X-15 (Cap-9 terminal cap depth).

14.2 Self-audit theo Hiến pháp + luật

Aspect	Status
NT4 cấm hardcode	✅ U3 vocab extensible, không enum cứng
NT11 khai tối thiểu	✅ 19/29 unit-facing là Optional; required ít
NT12 DOT pairing	✅ DOT Contract Matrix mỗi capability có cặp; OR "DOT phụ IDLE" align §8.4
NT14 thực thi được ngay	✅ Birth gate threshold rõ (15 strict); contract đo được
Đ44 NS-1 SSOT	✅ 1 family, vocab anchor system (Đ24/dot_config)
Đ44 NS-3 profile không phá core	✅ Profile extension không sửa UMC
Đ44 §3.2 G1-G12	✅ UMC cover 7/12 + Tier 1+ cover rest
Đ44 §6.A 5 LV	✅ Living DB Contract = 5 LV + 4 mở rộng
Đ44 §9.5 Conformance C1-C5	✅ 3/5 full + 2/5 partial
LSL-01 v0.4 P3 Đ24 anchor	✅ topics qua Đ24, không taxonomy mới
LSL-01 v0.4 P5 publication Đ38	✅ publication_v1 lifecycle Đ38
LSL-01 v0.4 P7 NĐ-36-01 relation	✅ relation Cap-4 owner NĐ-36-01
LSL-01 v0.4 P9 canonical immutable	✅ U2 immutable
LSL-01 v0.4 P10 DOT mềm	✅ §8 không chốt tên DOT
OR DOT theo cặp	✅ §8.4 ghi rõ DOT phụ IDLE = target
02C3 4 nhóm core	✅ UMC cover Identifier/Status/Timestamps/Classification
02C3 4 loại fill	✅ Match §3.3 + DOT Contract Matrix
02C3 3 tầng kiểm	✅ Birth gate / DOT daily / cross-entry

→ Không phát hiện xung đột với Hiến pháp + luật hiện hành.

14.3 Chưa làm (cố tình)

• ❌ Không DDL/code/migration/mutate.
• ❌ Không patch P44-1/2/3, Đ44, Đ38.
• ❌ Không thiết kế edge chi tiết (P44-4).
• ❌ Không thiết kế DOT cụ thể (P44-5 handoff).
• ❌ Không decision log (chờ User chốt OPEN sau).
• ❌ Không sang P44-4/5.
• ❌ Không chốt physical implementation Tier 1-5.

14.4 P38-XC KHÔNG CHỐT

#	Không chốt	Defer đến
(i)	Storage format JSONB structure	APR + implementation
(ii)	Migration script populate	APR + implementation
(iii)	DOT name + schedule + auto-fix policy + recursive cap	P44-5
(iv)	Edge structure chi tiết Tier 1	P44-4
(v)	Workflow physical schema Tier 3	Đ34 active
(vi)	Đ39 extraction Tier 2	Đ39 mature
(vii)	OP-B owner_agency	User chốt
(viii)	UMC unit_kind vocab final list + framework anchor	User + APR
(ix)	UMC implementation pattern (single/per-kind/hybrid)	APR
(x)	Reverse-index materialized vs on-demand	P44-4
(xi)	Canonical_address format cho non-law unit_kind	APR per use case
(xii)	Cap-9 recursive audit terminal cap depth	P44-5
(xiii)	Thêm core column unit_kind vào TAC vs suy ra qua per-kind pattern	APR design

---

P38-XC final | S190 (2026-05-01) | Soạn: Opus 4.7 | Polish history: P38-XA → P38-XB (5 GPT review điểm) → P38-XC (3 GPT polish + 5 self-rà soát risk fix) → P38-XC final (path align + section_type clarify + OR principle DOT phụ IDLE) | Authority: Đ38 base + extension qua Đ34/Đ29/Đ24/Đ39, conform Đ44 v0.1.2 | Phụ thuộc: P44-0/1/2/3 | Self-audit Hiến pháp + luật: PASS, không phát hiện xung đột | Trạng thái: uploaded knowledge/dev/laws/dieu44-trien-khai/design/04-information-unit-profile-schema.md