P44-2 — Schema Conformance Mapping Registry (SCMR) Design

Trạng thái: P44-2A polish — uploaded | Phiên: S190 (2026-05-01) Authority: Đ44 v0.1.2 controlled DRAFT (chưa enacted) — §3.2, §3.4, §8, §9.3, §9.5 Path: knowledge/dev/laws/dieu44-trien-khai/design/02-schema-conformance-mapping-design.md Phụ thuộc: P44-0 README rev 1, P44-1 Family Registry Design rev 1 Polish: GPT-5.5 review 6 điểm — (1) số liệu pilot TAC dùng số đúng 48 cells; (2) bỏ rò storage implementation; (3) status entry-level 4 thay vì 5 (bỏ not_applicable); (4) làm rõ "required G" xét aggregate family-level; (5) thêm cột OPEN trong gap summary; (6) AP-CLOSE thêm dòng "không chốt". Review: GPT-5.5 PASS — GPT review path

---

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

1. SCMR là logical capability bắt buộc theo Đ44 §3.4 — mọi physical table implement family PHẢI có entry. Không có entry = physical không hợp pháp (NS-1 + NS-4).
2. 9 field logic tối thiểu cho 1 SCMR entry: scmr_id, family_code, physical_target_ref, g_mapping, not_applicable_groups, conformance_status, gap_classification, last_audit_*, timestamps. Per-table entry (1 entry / 1 physical target), không per-family.
3. 4 trạng thái conformance entry-level: open, compliant, partial, non_compliant. N/A là per-G group (qua not_applicable_groups), không phải status entry. Family conformance = aggregation entries thuộc family.
4. Pilot mapping TAC family (4 bảng → G1–G12): tổng 48 cells = 12 A + 8 B + 3 C + 4 D + 0 E + 4 OPEN + 17 N/A. Lắp được (A+B+C) 23/48 = 48%.
5. Schema Conformance Audit logical: 2 chiều kiểm — physical thiếu SCMR entry / SCMR mapping không match physical. DOT cặp pattern, không chốt tên DOT.

---

§1. Mục đích + ranh giới

1.1 SCMR để làm gì

Vai trò	Diễn giải
Bản đồ physical → logical	Đ44 quy định 12 nhóm field logic (G1–G12). SCMR nói rõ: physical column nào trong physical table nào hiện thực hoá nhóm logic nào. Không có bản đồ = không thể audit conformance.
Cửa 3 trong quy trình đăng ký family	P44-1 §3.1 đã chốt: APR + Đ44 Conformance + SCMR entry = 3 cửa. SCMR là cửa physical-side. Cửa 1+2 là logical/governance.
Anchor cho DOT Schema Conformance Audit	Đ44 §9.3. DOT đối chiếu physical thực tế với SCMR entry. Lệch = log issue.
Cho phép đánh dấu N/A hợp pháp per-G group	Đ44 §3.4 yêu cầu: "Đánh dấu nhóm field không áp dụng (vd: G9 BOM với text unit)" — tránh false-negative khi audit. Không có chỗ đánh dấu = audit báo sai liên tục.
Log audit trail conformance	last_audit_at, last_audit_result → DOT audit có evidence.
Xác định khi nào physical không hợp pháp	Theo §3.4: "Không có SCMR entry = physical table không hợp pháp." SCMR là cổng pháp lý cho physical.

1.2 Ranh giới P44-2 (rất quan trọng — risk sa đà cao hơn P44-1)

P44-2 LÀM:

• Định nghĩa logical contract khung SCMR (9 field).
• Định nghĩa 4 trạng thái conformance entry-level + 5 gap classification (A–E) per-G group + N/A per-G group + OPEN per-G group.
• Mô tả Schema Conformance Audit ở mức logical (2 chiều kiểm + DOT cặp pattern).
• Pilot mapping TAC family: 4 bảng → G1–G12, đối chiếu P11A.
• Meta-conformance hypothetical cho SCMR tự nó.
• Đề xuất resolve OPEN cụ thể trong decision proposal (chưa tạo decision log).

P44-2 KHÔNG LÀM (cố tình — risk sa đà cao):

• ❌ KHÔNG thiết kế Family Registry — đã làm P44-1. Chỉ tham chiếu family_code.
• ❌ KHÔNG thiết kế Profile Registry — P44-3. SCMR có thể tham chiếu schema_profile_binding từ Family Registry, nhưng KHÔNG mô tả profile schema có gì.
• ❌ KHÔNG thiết kế Relation Edge — P44-4. Mapping G7 chỉ ghi "edge ra qua universal_edges", KHÔNG thiết kế edge structure.
• ❌ KHÔNG thiết kế Update Mechanism — P44-5. DOT cặp pattern chỉ là logical reference, không tên DOT cụ thể, không trigger code.
• ❌ KHÔNG DDL, code, migration, mutate production.
• ❌ KHÔNG chốt tên bảng vật lý SCMR — Đ44 §3.4 NON-NORMATIVE EXAMPLE đề cập tac_object_mapping/universal_object_mapping, chốt qua APR.
• ❌ KHÔNG chốt storage format cho g_mapping / not_applicable_groups / gap_classification — đó là physical concern, defer P44-3 + APR.
• ❌ KHÔNG quyết định D/E gap items phải migration nào — Đ44 §8.3 nói "items D/E xử lý sau pilot, xem Appendix A". P44-2 chỉ đánh dấu, không lập migration plan.

Phép thử nhanh: nếu thấy đang định nghĩa profile schema field / edge structure / DOT name / DDL / migration script / storage format (JSONB / table) — lỗi sa đà, báo lại.

---

§2. Logical contract khung SCMR

2.1 9 field logic tối thiểu cho 1 SCMR entry

Quyết định kiến trúc quan trọng: Per-table entry (1 SCMR entry tương ứng 1 physical target), không per-family. Lý do: match wording §3.4 Đ44 ("Mọi physical table … PHẢI có 1 entry"); normalize tốt hơn; family conformance = aggregation. GPT-5.5 review PASS.

#	Logical field	Cardinality	Kiểu logical	Ràng buộc	Tham chiếu
S1	scmr_id	1..1	identifier (logical, abstract)	PK, unique, immutable	Đ44 §3.4
S2	family_code	1..1	FK reference	FK → Family Registry (P44-1 F1)	P44-1, Đ44 §4.1
S3	physical_target_ref	1..1	reference to physical artifact (logical, abstract)	unique trong tổ hợp với family_code	Đ44 §3.4
S4	g_mapping	1..1	structured logical mapping G1..G12 → physical column reference	thoả invariant INV-S2 (xem §2.4)	Đ44 §3.2, §3.4
S5	not_applicable_groups	0..1	logical set của G ∈ {G1..G12} marked N/A cho entry này	mỗi G chỉ thuộc đúng 1 trong 3 trạng thái: g_mapping / N/A / OPEN	Đ44 §3.4
S6	conformance_status	1..1	enum {open, compliant, partial, non_compliant}	not null, default open	Đ44 §3.4
S7	gap_classification	0..1	per-G logical map G → gap code {A, B, C, D, E, OPEN}	only cho group có g_mapping; OPEN = chưa resolve evidence	Đ44 §8.1 + P44-2 ext
S8	last_audit_at, last_audit_result	0..1	audit timestamp + result detail	DOT cặp Schema Conformance Audit ghi	Đ44 §9.3
S9	created_at, created_by, updated_at, updated_by	1..1 each	timestamp + user FK	NT11 (PG tự suy ra)	G12 Đ44

2.2 Field-by-field rationale

S1 — scmr_id

Identifier logical. Logical contract: ổn định, immutable, unique. Storage scheme defer APR/P44-5.

S2 — family_code

FK chính sang Family Registry. Mọi entry SCMR phải có family. SCMR entry không có family = vi phạm NS-1 (không thuộc family nào = không hợp pháp).

Kết hợp với P44-1 INV-4: family status = active ⇒ phải có ≥ 1 SCMR entry. SCMR entry có thể tồn tại trước khi family active (trong giai đoạn proposed).

S3 — physical_target_ref

Logical reference đến physical artifact. KHÔNG chốt physical artifact đó là gì (có thể là PG table, Qdrant collection, file path, … tuỳ family). Logical contract: định danh duy nhất 1 physical target trong toàn hệ thống.

OPEN P44-2-α: format chuẩn cho physical_target_ref (URI scheme: pg.schema.table, qdrant.collection.x, fs.path, …) defer P44-5 / APR. P44-2 chỉ yêu cầu logical contract "định danh duy nhất 1 physical artifact", không chốt scheme.

S4 — g_mapping

Mapping G1..G12 → physical column/field. Đây là trái tim của SCMR. Logical contract:

• Cardinality per G group: 0..* fields (1 group có thể map vào nhiều cột; 1 cột có thể map vào nhiều group nếu cột composite).
• Mỗi entry G chứa danh sách physical column reference + ref doc (link tới design source).

Storage format (JSONB / table riêng / mixed / khác) defer P44-3 + APR. Logical chỉ yêu cầu "structured logical mapping", không quy định cách physical hoá.

S5 — not_applicable_groups

Tập con của {G1..G12} mà entry này không áp dụng. Bắt buộc để tránh audit báo sai liên tục.

Ví dụ logical:

• TAC family tac_logical_unit: G9 N/A (text unit không có BOM).
• Vector projection family: G9 + G3 N/A (projection không có lifecycle riêng — kế thừa từ source unit).

Constraint logical (INV-S2): với mỗi G ∈ {G1..G12}, phải nằm ở đúng 1 trong 3 trạng thái:

• Có trong g_mapping[G] (đã map);
• Có trong not_applicable_groups (đã đánh dấu N/A);
• Trong gap_classification[G] = OPEN (chưa resolve evidence).

Không được vắng cả 3.

Storage format defer APR/P44-3.

S6 — conformance_status ⚡ — 4 trạng thái entry-level

Trạng thái	Định nghĩa logical	Khi nào
open	Chưa audit hoặc còn G ở trạng thái OPEN chưa resolve	Default cho entry mới
compliant	Mọi G required (xét aggregate family-level — xem §2.3) đều có physical column tương ứng + gaps chỉ A	Audit PASS toàn diện
partial	Có G missing nhưng family vẫn function được; gaps là B/C (không nghiêm trọng); hoặc có gap D nhưng đã có migration plan	Đa số TAC entries hiện tại
non_compliant	Thiếu G required nghiêm trọng (G1, G12 thiếu hoặc missing identity) HOẶC có gap D không có resolution path	Block birth gate, escalation cần thiết

Lưu ý: bỏ not_applicable cấp entry vì entry mà tất cả G đều N/A không có lý do tồn tại. N/A là per-G group (qua not_applicable_groups), không phải status entry.

Quy tắc transition: open → compliant/partial/non_compliant sau audit đầu tiên. compliant ↔ partial theo evolution (gap thay đổi). non_compliant cần escalation/migration.

Note: status non_compliant KHÔNG nghĩa là entry phải xoá. Nghĩa là cần escalation/migration. Đ44 không cấm non_compliant tồn tại có chủ đích — chỉ cấm bỏ qua không xử lý.

S7 — gap_classification

Per-G logical map G → gap code (Đ44 §8.1 + P44-2 mở rộng):

Code	Meaning	Action
A	Có và đang dùng production	OK
B	Có schema chưa proof	Pilot/populate
C	Lắp được không cần migration	Cấu hình
D	Cần migration	Đ44 §8.3 — sau pilot
E	Defer	Aspirational
OPEN	Chưa resolve evidence (vd: G4 owner_agency cho TAC family — chờ OP-B)	Đợi decision

Ràng buộc: chỉ áp cho group có trong g_mapping. Group N/A không có gap code.

S8 — Audit metadata

DOT cặp Schema Conformance Audit ghi vào. Cardinality 0..1 vì entry mới chưa audit. Sau audit đầu tiên thành 1..1.

S9 — Audit timestamps

NT11 + Đ44 G12 — PG tự suy ra. Agent KHÔNG khai.

2.3 "Required G" — xét aggregate family-level, không per-table

Đây là điểm thiết kế quan trọng (làm rõ theo GPT review polish):

2.3.1 Đ44 §3.2 quy định cardinality 1..1 ở mức nào?

Đ44 §3.2 ghi cardinality 1..1 cho G1, G2, G3, G12 — nhưng cardinality này áp ở logical family/object level, KHÔNG máy móc bắt mỗi physical table phải có đủ.

2.3.2 Quy tắc xét "required" cho per-table SCMR

Với per-table architecture:

• Required G được xét theo role của table trong family.
• Family-level conformance = aggregate qua tất cả entries thuộc family.
• 1 family có thể có nhiều bảng, mỗi bảng đảm trách 1 phần G. Family conformant nếu tổng hợp cover đủ G required.

Ví dụ TAC family information_unit:

G required	LU	UV	Pub	Member	Aggregate family
G1 Identity	A	A	A	A	✅
G2 Type & Family	A	inherit	A	A	✅
G3 Lifecycle	A (LU-level)	A (version-level)	A (pub-level)	N/A (relation row)	✅ — covered ở LU/UV/Pub
G12 Timestamps	B	B	B	B	⚠️ B aggregate

→ G3 N/A ở tac_publication_member là OK vì family đã có G3 ở LU/UV/Pub. Đây không phải vi phạm.

OPEN P44-2-ε: định nghĩa rõ "G required per-family" theo role + profile. Defer P44-3 (Profile Registry) + Family Registry đăng ký phải khai required G theo family.

2.4 Logical invariants

ID	Invariant	Kiểm bằng
INV-S1	scmr_id unique	DB constraint
INV-S2	Mỗi G ∈ {G1..G12} phải nằm ở đúng 1 trong 3: g_mapping[G] HOẶC not_applicable_groups HOẶC gap_classification[G] = OPEN	Validation logic
INV-S3	family_code phải tồn tại trong Family Registry	FK
INV-S4	(family_code, physical_target_ref) unique (tránh duplicate entry cho cùng physical target)	DB constraint
INV-S5	gap_classification[G] chỉ tồn tại nếu G có trong g_mapping	Validation logic
INV-S6	conformance_status = compliant ⇒ tất cả G required (theo family role + aggregate) cover qua g_mapping hoặc N/A hợp lệ	DOT audit
INV-S7	Family status = active (P44-1 INV-4) ⇒ phải có ≥ 1 SCMR entry với conformance_status ∈ {compliant, partial}	DOT audit

2.5 OPEN — alternative architecture

Phương án thay thế: Per-family SCMR entry với multi-physical refs

Thay vì 1 entry / 1 physical target, dùng 1 entry / 1 family với physical_target_refs[] array.

	Per-table (đề xuất, GPT PASS)	Per-family (alternative)
1 family có 4 bảng	4 SCMR entries	1 SCMR entry với 4 refs
Add bảng mới vào family	thêm entry	update entry, append ref
Audit per-table	1 entry, focused	phải parse array
Family conformance	aggregate từ entries	direct read
Match Đ44 §3.4 wording	✅ "Mọi physical table … PHẢI có 1 entry"	⚠️ phải interpret rộng

Đề xuất Opus: Phương án per-table. GPT review PASS — chốt cho P44-2.

OPEN P44-2-β (đã được GPT review giải quyết — chốt per-table). Giữ ghi nhận để traceability.

---

§3. Schema Conformance Audit (logical)

3.1 3 tầng audit (đối chiếu Đ44 §9.1)

SCMR Conformance Audit hoạt động trong khuôn khổ §9.1 Đ44 (Completeness/Correctness/Consistency):

Tầng	Khi kiểm	SCMR Audit cụ thể
Completeness	Khi physical table tạo mới	Có SCMR entry tương ứng chưa? Thiếu = block (Đ44 §3.4)
Correctness	Định kỳ (daily)	Cột trong g_mapping có thực sự tồn tại trong physical schema không?
Consistency	Cross-entry	2 entries cho cùng (family_code, physical_target_ref) không? Trong cùng family, các entries có conflict mapping không? Aggregate family có đủ G required không?

3.2 2 chiều kiểm (Đ44 §9.3)

Đ44 §9.3 chỉ định 2 chiều kiểm:

Chiều A: physical → SCMR

Quét tất cả physical table thuộc scope Đ44. Với mỗi table:

• Có SCMR entry với physical_target_ref tương ứng?
• Không có → log issue: "physical table không có SCMR entry" → block birth, escalate.

Chiều B: SCMR → physical

Quét tất cả SCMR entry. Với mỗi entry:

• Cột trong g_mapping[G].fields có tồn tại trong physical schema?
• Cột tồn tại nhưng có đúng kiểu/constraint không?
• Không tồn tại / sai kiểu → log issue: "SCMR mapping không match physical".

3.3 DOT cặp pattern

Theo NT12 + Đ44 §9.2:

Vai	Trách nhiệm
Động cơ chính (writer)	INSERT/UPDATE SCMR entry khi physical table mới được tạo / khi schema thay đổi. Có thể là Agent qua APR, hoặc trigger-driven.
Động cơ phụ (checker)	Định kỳ chạy 2 chiều kiểm (§3.2). Log issue. Không tự fix — escalate.

Lưu ý: P44-2 KHÔNG chốt:

• Tên DOT cụ thể (P44-5).
• Schedule (daily? hourly? on-demand?) — defer P44-5.
• Hành động khi log issue (auto-fix? escalate? quarantine?) — defer P44-5.

3.4 Tích hợp với Đ44 Conformance Clause (§9.5)

Mỗi family đăng ký mới (qua APR + C1–C5) phải có C2 — G1–G12 mapping. Mapping này = SCMR entry contract.

Quan hệ logical:

• Design doc family chứa C2 mapping → là proposal cho SCMR entry.
• Sau APR PASS + physical hoá, SCMR entry được tạo từ C2 mapping.
• DOT cặp tiếp tục audit.

---

§4. Pilot mapping TAC family

Mục đích: validate logical contract SCMR (§2) bằng cách map 4 bảng TAC vào G1–G12. Đối chiếu §3.2 + §8.2 Đ44 + P11A. Đặc biệt quan trọng: đây là cầu nối thực tế quay về Miếng thông tin (P44-0 §5).

4.1 SCMR entries cho TAC family

⚠️ PROPOSED CONTROLLED-DRAFT MAPPING — đề xuất pilot, chưa phải SCMR entry hợp pháp. Chỉ trở thành SCMR entry sau Đ44 ENACTED + APR PASS + physical hoá Family Registry/SCMR.

Family: information_unit, owner_law_code = NRM-LAW-38. 4 SCMR entries:

Entry 1: tac_logical_unit — LU-level identity + family + lifecycle anchor

Field	Giá trị logical
family_code	information_unit
physical_target_ref	pg.directus.tac_logical_unit (logical example, scheme defer)
conformance_status	partial (đa số A/B, không có gap D nghiêm trọng cho LU-level)

g_mapping per G:

G	Fields	Gap	Note
G1 Identity	id (PK), canonical_address (UNIQUE)	A	P11A #1, #5
G2 Type & Family	section_type (FK vocab)	A	P11A #7. family_code = information_unit từ context entry.
G3 Lifecycle (LU-level)	lifecycle_status (FK vocab)	A	P11A #9
G4 Owner & Authority	(chưa có)	OPEN	OP-B P44-1 chưa resolve
G5 Source & Provenance	—	—	N/A ở LU-level
G6 Content/Profile	identity_profile (logical reference, GIN-indexed currently empty)	B	P11A #14
G7 Relation (out)	—	—	N/A ở LU-level (relations qua universal_edges)
G8 Usage (in)	—	—	N/A ở LU-level
G9 BOM	—	—	N/A (text unit)
G10 Vector Projection	—	—	N/A ở LU-level (projection per-version)
G11 Checker/DOT	(fn_tac_log_checker_issue exists; drift checker chưa)	D	P11A #27
G12 Timestamps & Audit	timestamps có; audit fields incomplete	B	P11A note

not_applicable_groups: {G5, G7, G8, G9, G10}

Tổng Entry 1: 3 A + 2 B + 0 C + 1 D + 0 E + 1 OPEN + 5 N/A = 12 cells ✓

Entry 2: tac_unit_version — content + version + vector tracking

Field	Giá trị logical
family_code	information_unit
physical_target_ref	pg.directus.tac_unit_version
conformance_status	partial

g_mapping per G:

G	Fields	Gap	Note
G1 Identity	id (PK)	A
G2 Type & Family	(kế thừa từ LU qua FK)	A	logical inheritance
G3 Lifecycle/Version	lifecycle_status, review_state, version_label, version_seq	A	P11A #9
G4 Owner & Authority	(chưa có)	OPEN	OP-B
G5 Source & Provenance	—	—	N/A (provenance ở edge level)
G6 Content	body, content_hash, content_profile (logical reference)	B	P11A #8, #15 — schema có, populate empty
G7 Relation	—	—	N/A ở UV-level
G8 Usage	—	—	N/A
G9 BOM	—	—	N/A
G10 Vector Projection	vector_sync_status, vector_synced_at, vector_chunk_count	B	P11A #10 — tracking exists, sync not proven
G11 Checker/DOT	(drift checker chưa có)	D
G12 Timestamps & Audit	timestamps có	B	audit fields incomplete

not_applicable_groups: {G5, G7, G8, G9}

Tổng Entry 2: 3 A + 3 B + 0 C + 1 D + 0 E + 1 OPEN + 4 N/A = 12 cells ✓

Entry 3: tac_publication — container + publication-level metadata

Field	Giá trị logical
family_code	information_unit (hoặc document/publication — xem OPEN P44-2-γ)
physical_target_ref	pg.directus.tac_publication
conformance_status	partial

g_mapping per G:

G	Fields	Gap	Note
G1 Identity	id (PK)	A	P11A #1
G2 Type & Family	(publication_type FK vocab)	A
G3 Lifecycle	lifecycle_status (FK)	A
G4 Owner & Authority	(chưa có)	OPEN	OP-B
G5 Source & Provenance	(qua publication_profile)	C	có thể dùng JSONB profile hiện có
G6 Content/Profile	publication_profile (logical reference)	B	P11A #16
G7 Relation (contains)	qua tac_publication_member	C	P11A #4 — internal containment
G8 Usage	—	—	N/A
G9 BOM	—	—	N/A
G10 Vector Projection	—	—	N/A publication-level
G11 Checker/DOT	chưa có	D
G12 Timestamps & Audit	timestamps có	B

not_applicable_groups: {G8, G9, G10}

Tổng Entry 3: 3 A + 2 B + 2 C + 1 D + 0 E + 1 OPEN + 3 N/A = 12 cells ✓

OPEN P44-2-γ: Đ44 §4.2 family seed liệt kê document / publication chung cho 1 family hoặc 2 family riêng — không rõ. P44-1 §4.1 audit đã ghi cùng family information_unit (provisional). Nếu User chốt tách thành 2 family riêng → Entry 3 chuyển sang family_code = publication. Defer cho P44-1 decision Q4.

Entry 4: tac_publication_member — relation infrastructure (contains edges)

Field	Giá trị logical
family_code	information_unit (relation table cho family)
physical_target_ref	pg.directus.tac_publication_member
conformance_status	partial

g_mapping per G:

G	Fields	Gap	Note
G1 Identity	id (PK)	A	P11A #4
G2 Type & Family	(relation between LU and Publication)	A	implicit
G3 Lifecycle	—	—	N/A (relation row có/không, không lifecycle riêng — covered ở family aggregate qua LU/UV/Pub)
G4 Owner	(chưa có)	OPEN
G5 Source & Provenance	(chưa có riêng)	C	có thể thêm JSONB nếu cần
G6 Content	—	—	N/A (relation không có content body)
G7 Relation (chính nó)	publication_id + unit_id + sort_order	A	self-referential — relation row chính là edge contains
G8 Usage	—	—	N/A
G9 BOM	—	—	N/A
G10 Vector	—	—	N/A
G11 Checker/DOT	chưa có	D
G12 Timestamps & Audit	timestamps có	B

not_applicable_groups: {G3, G6, G8, G9, G10}

Tổng Entry 4: 3 A + 1 B + 1 C + 1 D + 0 E + 1 OPEN + 5 N/A = 12 cells ✓

Quan trọng: G3 N/A ở Entry 4 là hợp lệ aggregate — family information_unit đã có G3 ở LU/UV/Pub. Đây không phải vi phạm required G3 = 1..1 (Đ44 §3.2). Xem §2.3.

4.2 Gap summary cho TAC family — 4 entries tổng hợp (có cột OPEN)

Gap	Entry 1 LU	Entry 2 UV	Entry 3 Pub	Entry 4 Member	Tổng
A	3	3	3	3	12
B	2	3	2	1	8
C	0	0	2	1	3
D	1	1	1	1	4
E	0	0	0	0	0
OPEN	1	1	1	1	4
N/A	5	4	3	5	17
Total cells (12 G × 4 entries)	12	12	12	12	48

Phân tích:

• Lắp được không cần migration (A+B+C): 12 + 8 + 3 = 23/48 = 48%.
• Cần migration (D): 4/48 (G11 drift checker × 4 entries — 1 D nhất quán mọi entry).
• Defer (E): 0/48 (TAC pilot không touch E items).
• OPEN: 4/48 (G4 owner_agency × 4 entries — chờ OP-B resolve).
• N/A: 17/48 — đáng kể, hợp lý vì text unit không cần BOM (G9), relation row không có content (G6) ở Entry 4, ...

Đối chiếu §8.3 Đ44: §8.3 Đ44 đếm 30 items trong scope rộng hơn (toàn P11A). P44-2 pilot riêng TAC family = 48 cells qua 4 entries — không phải subset trực tiếp của 30 items §8.3. Hai con số đo trên 2 thước khác nhau, không so sánh trực tiếp được.

→ TAC family partial conformance ổn định. Không có entry non_compliant (không thiếu G1/G12).

4.3 Quan sát quan trọng

4.3.1 tac_publication_member vs universal_edges

P11A #17 ghi: universal_edges 2199 rows nhưng không có TAC edges. Trong khi đó, tac_publication_member đang lưu quan hệ contains theo bảng riêng, không qua universal_edges.

Đây là conflict tiềm năng với Đ44 §5.1: "Mọi quan hệ giữa Object thuộc Đ44 phải đi qua universal_edges (NĐ-36-01). Đ44 KHÔNG đẻ bảng mới."

3 cách lý giải:

#	Lý giải	Hệ quả
(a) tac_publication_member là internal relation (intra-family containment 1:1 strict), không phải edge logic chéo family → ngoài scope NĐ-36-01	Hiện trạng OK, chỉ cần SCMR entry
(b) tac_publication_member nên migrate sang universal_edges với edge_type = contains	Migration plan (gap D) — ngoài scope P44-2
(c) tac_publication_member là physical materialization của edge contains cho performance, vẫn cần entry tương ứng trong universal_edges	Dual representation — phức tạp

Đề xuất Opus: lý giải (a) — đây là intra-family containment với cardinality 1:1 strict (publication chứa units), không cần universal_edges abstraction. Nhưng cần ghi rõ trong SCMR entry rằng đây là internal relation.

OPEN P44-2-δ: chốt lý giải (a) vs (b) vs (c) — defer P44-4 Edge Conformance Design.

4.3.2 Profile schema là mỏ vàng — vẫn empty toàn bộ

3 logical profile references (P11A #14-16) — schema ready (GIN-indexed), populate = 0. Đây là gap B nhất quán trong cả 3 entries (LU/UV/Pub) cho G6.

P44-2 KHÔNG quy định cách populate (P44-3 + P44-5). Chỉ ghi rõ trong SCMR entry: gap_classification[G6] = B.

4.3.3 Drift checker D nhất quán

Cả 4 entries đều có gap_classification[G11] = D. P11A #27: fn_tac_log_checker_issue exists nhưng "no drift/consistency checkers". Đây là deliverable rõ ràng cho P44-5.

4.3.4 G4 owner_agency OPEN nhất quán 4 entries

OP-B P44-1 — chờ resolve (hoặc User chốt phương án B+C đề xuất, hoặc tạm dùng Architecture Council). Cả 4 entries TAC đều OPEN cho G4. Đây là single bottleneck — resolve OP-B sẽ unlock 4 OPEN cells cùng lúc.

---

§5. Meta-conformance hypothetical cho SCMR

5.1 SCMR tự nó có phải object-family không?

Có. Khi physical hoá thành 1 logical entity, SCMR là 1 family với family_code = 'schema_conformance_mapping' (hoặc tên tương tự, chốt qua APR).

5.2 OQC check (Đ44 §2.2)

OQC	SCMR thoả?	Lý do
OQC-1 Persistent Identity	✅	scmr_id ổn định
OQC-2 Lifecycle ≥ 2 state	✅	conformance_status 4 trạng thái
OQC-3 Governance Subject	✅	Đ44 quản (NRM-LAW-44), APR cấp medium duyệt amend entry
OQC-4 Has Relations	✅	FK → Family Registry; physical_target_ref link sang physical artifact

→ 4/4 OQC. SCMR thoả điều kiện object-family.

5.3 G1–G12 hypothetical mapping

⚠️ Hypothetical — full check khi physical hoá qua APR.

G	SCMR có	Status
G1 Identity	S1 scmr_id	A
G2 Type & Family	self-reference: family_code = 'schema_conformance_mapping'	A
G3 Lifecycle	S6 conformance_status (4 trạng thái)	A
G4 Owner & Authority	owner = Đ44 (Architecture Council per Đ37 mapping)	A
G5 Source & Provenance	—	N/A (SCMR entries tạo qua APR/proposal)
G6 Content/Profile	S4 g_mapping + S5 not_applicable_groups + S7 gap_classification	A
G7 Relation	S2 → Family Registry; S3 → physical artifact	A
G8 Usage	reverse: family conformance aggregate	C (cần aggregation logic)
G9 BOM	—	N/A
G10 Vector Projection	—	N/A
G11 Checker/DOT	DOT cặp Schema Conformance Audit (chính nó!)	OPEN — recursive, P44-5 chốt
G12 Timestamps & Audit	S9	A

Recursive note: SCMR audit chính SCMR entries (audit của audit) — pattern hợp lệ nhưng cần thiết kế cẩn thận trong P44-5.

Tổng: 6 A + 1 C + 1 OPEN + 4 N/A = 12 cells. SCMR passes meta-conformance hypothetical.

5.4 Bootstrap

Tương tự P44-1: entry SCMR đầu tiên phải là (family_code = 'schema_conformance_mapping', physical_target_ref = <SCMR target itself>) — self-referential. Insert qua init seed khi physical hoá. Defer APR design phase.

---

§6. OPEN / Technical Debt phát sinh trong P44-2

ID	Item	Ảnh hưởng	Resolve khi
OPEN P44-2-α	Format chuẩn cho physical_target_ref (URI scheme)	Chưa chốt → mỗi entry phải tự định format	P44-5 / APR design phase
OPEN P44-2-β	Per-table vs per-family entry architecture — GPT review PASS per-table. Đóng.	—	Đóng (ghi nhận traceability)
OPEN P44-2-γ	document / publication cùng family information_unit hay tách 2 family	Ảnh hưởng SCMR Entry 3 family_code	P44-1 Q4
OPEN P44-2-δ	tac_publication_member lý giải (a/b/c) — nội bộ vs migrate universal_edges	Ảnh hưởng SCMR Entry 4 architecture	P44-4 Edge Conformance Design
OPEN P44-2-ε	"G required" theo family role + profile — định nghĩa rõ aggregate family-level	Ảnh hưởng quy tắc transition compliant	P44-3 Profile Registry + Family Registry đăng ký
TD P44-2-1	TAC profile JSONB populate = 0 (P11A #14-16)	3 entries có gap B nhất quán cho G6	P44-3 + P44-5 + LSL-01 procedure
TD P44-2-2	TAC drift checker chưa có (P11A #27)	4 entries có gap D nhất quán cho G11	P44-5 + Đ35 paired design
TD P44-2-3	TAC edges trong universal_edges = 0	Entry 4 lý giải treo + Entry 1/2/3 G7 N/A	P44-4 + Đ44 Appendix A G6
TD P44-2-4	Recursive audit pattern (SCMR audit SCMR)	G11 OPEN cho meta-entry	P44-5 thiết kế DOT cặp recursive-safe
TD P44-2-5	G4 owner_agency OPEN nhất quán 4 entries TAC — single bottleneck với OP-B P44-1	4 OPEN cells unlock cùng lúc khi OP-B resolve	User chốt OP-B P44-1

---

§7. Pre-conditions PASS + cầu nối P44-3

7.1 Để P44-2 PASS

#	Pre-condition	Đã đạt?
1	9 logical field tối thiểu định nghĩa rõ	✅ (§2.1, §2.2)
2	4 trạng thái conformance entry-level + 5 gap classification + OPEN per-G + N/A per-G	✅ (§2.2 S6, S7, §2.3)
3	"Required G" làm rõ aggregate family-level	✅ (§2.3)
4	7 logical invariants	✅ (§2.4)
5	Schema Conformance Audit logical (3 tầng + 2 chiều + DOT cặp pattern)	✅ (§3)
6	Pilot mapping TAC family — 4 entries đầy đủ với cột OPEN	✅ (§4)
7	Gap summary có cột OPEN, totals đúng (48 cells)	✅ (§4.2)
8	Meta-conformance hypothetical (4/4 OQC + G1-G12)	✅ (§5)
9	OPEN/TD ghi rõ ràng	✅ (§6)
10	Không DDL, không code, không physical SCMR table name cứng	✅
11	Không sa đà sang Profile / Edge / Mechanism / storage format	✅ (kiểm §1.2 ranh giới)

7.2 Cần User/GPT chốt

#	Quyết định	Đề xuất Opus	Block P44-3?
Q1	Architecture per-table — GPT review PASS	Đóng	—
Q2	physical_target_ref format scheme (OPEN P44-2-α)	Defer P44-5 / APR	Không
Q3	TAC family Entry 3 — document / publication 1 hay 2 family (OPEN P44-2-γ)	Đợi P44-1 Q4	Không
Q4	tac_publication_member lý giải (OPEN P44-2-δ)	Đề xuất (a) — defer P44-4	Không
Q5	Path upload	knowledge/dev/laws/dieu44-trien-khai/design/02-schema-conformance-mapping-design.md	—

→ Không có quyết định nào block P44-3.

7.3 Cầu nối P44-3

P44-2 cung cấp cho P44-3:

• Concept "structured logical mapping" (S4 g_mapping) — P44-3 sẽ chốt cách physical hoá structured map.
• Profile schema (G6 reference trong SCMR) — P44-3 thiết kế Profile Registry, định nghĩa profile schema cho từng family.
• Pilot TAC mapping cho thấy content_profile reference là gap B nhất quán → P44-3 có thể propose schema cho information_unit family.
• Concept "G required theo family aggregate" (OPEN P44-2-ε) → P44-3 + Family Registry đăng ký phải định nghĩa rõ.

→ Cầu nối rõ ràng. P44-3 có thể bắt đầu sau khi P44-2 PASS.

---

§8. AP-CLOSE

8.1 Đã làm trong P44-2

1. Định nghĩa logical contract khung SCMR: 9 field (S1–S9) + 7 invariant (INV-S1..7), không tên bảng vật lý, không DDL, không storage format.
2. Định nghĩa 4 trạng thái conformance entry-level (open/compliant/partial/non_compliant) + 5 gap classification + N/A per-G group + OPEN per-G group + quy tắc transition.
3. Làm rõ "required G xét aggregate family-level**", không máy móc per-table.
4. Mô tả Schema Conformance Audit logical: 3 tầng (Đ44 §9.1) + 2 chiều kiểm (Đ44 §9.3) + DOT cặp pattern (không tên cụ thể).
5. Pilot mapping TAC family: 4 SCMR entries (LU, UV, Pub, Member) × 12 G groups = 48 cells. Tổng: 12 A + 8 B + 3 C + 4 D + 0 E + 4 OPEN + 17 N/A.
6. Đối chiếu §8.3 Đ44 — ghi rõ scope khác (30 items P11A-wide vs 48 cells TAC pilot, không so sánh trực tiếp).
7. 4 quan sát quan trọng: tac_publication_member vs universal_edges; profile schema mỏ vàng; drift checker D nhất quán; G4 OPEN single bottleneck.
8. Meta-conformance hypothetical SCMR: 4/4 OQC + G1-G12 (6 A + 1 C + 1 OPEN recursive + 4 N/A).
9. Liệt kê 5 OPEN + 5 TD.
10. Cầu nối rõ tới P44-3.

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

• ❌ Không thiết kế Family Registry (đã làm P44-1).
• ❌ Không thiết kế Profile Registry (P44-3).
• ❌ Không thiết kế Relation Edge (P44-4).
• ❌ Không thiết kế Update Mechanism (P44-5).
• ❌ Không DDL, code, mutate production, physical SCMR table name.
• ❌ Không tạo decision log (chờ User chốt riêng sau upload).
• ❌ Không sang P44-3.
• ❌ Không lập migration plan cho gap D items (Đ44 Appendix A scope).

8.3 P44-2 KHÔNG CHỐT (kỷ luật scope — ghi rõ)

P44-2 cố tình không chốt 3 thứ sau, defer cho phase/doc tương ứng:

#	Không chốt	Defer đến
(i)	physical_target_ref URI scheme (vd pg.schema.table vs khác)	P44-5 / APR design phase
(ii)	Storage format cho g_mapping, not_applicable_groups, gap_classification (JSONB / table riêng / mixed / khác)	P44-3 / APR design phase
(iii)	TAC tac_publication_member edge policy (lý giải a/b/c)	P44-4 Edge Conformance Design

8.4 Cần User + GPT review

5 quyết định cần chốt (xem §7.2):

1. Q1 — Architecture per-table: ✅ GPT PASS — đóng.
2. Q2 — physical_target_ref format: defer P44-5 (PASS).
3. Q3 — Family Entry 3: phụ thuộc P44-1 Q4 (defer).
4. Q4 — tac_publication_member: đề xuất (a) defer P44-4.
5. Q5 — Path upload: knowledge/dev/laws/dieu44-trien-khai/design/02-schema-conformance-mapping-design.md.

8.5 Sau khi PASS

• Upload artifact thành KB doc tại path Q5. ← đã upload
• Không tạo decision log nào ngay lúc upload.
• Dừng P44-2.
• Đề xuất bắt đầu P44-3 — Profile Registry Design (cầu nối quay về Miếng thông tin).

---

P44-2 DRAFT — P44-2A polish | S190 (2026-05-01) | Soạn: Opus 4.7 | Polish: 6 sửa theo GPT review (1) số liệu pilot 48 cells, (2) bỏ rò storage implementation S4/S5/S7, (3) status entry-level 4 (bỏ not_applicable), (4) "required G" aggregate family-level, (5) thêm cột OPEN gap summary, (6) AP-CLOSE thêm dòng "không chốt" 3 thứ | Authority: Đ44 v0.1.2 controlled DRAFT (chưa cưỡng chế) | Phụ thuộc: P44-0 README rev 1, P44-1 rev 1 | Trạng thái: uploaded