P44-4 — Relation/Composition Edge Conformance Design

Trạng thái: P44-4A POLISH FINAL — uploaded | Phiên: S190 (2026-05-02) Authority: Đ44 v0.1.2 controlled DRAFT (chưa enacted) — §5 Relation Layer + §11.5 TD-44-2/TD-44-3 Path đề xuất: knowledge/dev/laws/dieu44-trien-khai/design/05-relation-edge-conformance-design.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, P38-XC final rev 1 Nguồn nền: Đ0-B v3.1 (7 lớp cấu tạo + cơ chế sống), NĐ-36-01 v1.2 Phần 1 (9 MT semantic relationships), Đ44 §5 + §11.5 Outline: P44-4 outline PASS (S190) — GPT review 6 guardrails + Q1-Q7 trả lời + yêu cầu đọc Đ0-B trước Workflow: outline PASS → full draft → GPT review (P44-4A polish 5 điểm) → User+GPT xác nhận → upload (KHÔNG upload trước xác nhận) P44-4A polish (S190 2026-05-02) áp dụng 5 chỉnh sửa GPT: (1) OPEN P44-4-γ tự đề xuất default rule, không đẩy User; (2) siết "universal_edges là SSOT, helper không bao giờ thành SSOT"; (3) thêm anti-drift invariant 2 chiều cho Dual; (4) sunset path 4 conditions explicit + 2 exit paths; (5) P1 reverse-index siết wording không default production. P44-4A final micro-fix (S190 2026-05-02): §15.4 dòng (v) sửa wording cũ "OPEN P44-2-δ chốt cuối (b) vs (c) | User clarify Đ0-B §I-C" → "OPEN P44-2-δ final enforcement path: default = (c) Dual transitional; final implementation path/sunset status sẽ được quyết qua APR khi Đ44 enacted và/hoặc sau benchmark." Đồng nhất với §7.7 default ruling.

---

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

1. P44-4 chốt logical contract cho Relation/Composition Edge Conformance — unlock Tier 1 Living DB (Q2-Q6 trong P38-XC). KHÔNG code, KHÔNG DDL, KHÔNG tên DOT cụ thể.
2. Phân biệt 2 namespace tách rõ: Đ44 §5 Object Edges (object↔object) vs NĐ-36-01 Semantic Relationships (concept↔concept) — cảnh báo edge name clash (vd contradicts).
3. Edge type vocab: 8 Core + 3 Candidate (Đ44 §5.3) + 8 logical fields tối thiểu E1-E8 + provenance contract bắt buộc cho edge mới post-Đ44.
4. Composition Cap-5 contract align Đ0-B 7 lớp (Lớp 0 + 6 cấp 1-6); composition_role atomic/molecular/composite; CYCLE detection + depth ≤ 4.
5. Resolve OPEN P44-2-δ (tac_publication_member): default ruling = (c) Dual transitional với universal_edges là SSOT duy nhất, FK/M2M là enforcement helper KHÔNG phải SSOT. Anti-drift invariant 2 chiều bắt buộc. Sunset path 4 conditions explicit. KHÔNG default (a) Internal-only. Audit plan TD-44-2/TD-44-3 logical, KHÔNG execute.

---

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

1.1 P44-4 LÀM (12 việc)

#	Việc	Tham chiếu	Section
1	Phân biệt + tách namespace Đ44 §5 vs NĐ-36-01	NĐ-36-01 ranh giới sở hữu, Đ44 §5.1	§2
2	Edge type vocab logical: 8 Core + 3 Candidate + extension policy	Đ44 §5.3	§3
3	Minimum logical fields cho 1 edge entry (E1-E8)	Đ44 §5.2	§4
4	Composition Cap-5 contract align Đ0-B 7 lớp + cơ chế sống	Đ0-B v3.1, P38-XC §9.2	§5
5	Reverse-index responsibility logical (Q3, Q5 Living DB)	P38-XC §8.1, OPEN P38-X-13	§6
6	Resolve OPEN P44-2-δ (tac_publication_member) — phản biện 2 vòng	P44-2 §4.3.1	§7
7	Audit plan TD-44-2 (relation_edge lifecycle ≥ 2 state) — logical, không execute	Đ44 §11.5 TD-44-2	§8
8	Audit plan TD-44-3 (legacy edges retrofit) — 4 phase logical	Đ44 §11.5 TD-44-3, Appendix A G6	§9
9	Edge Conformance Audit pattern logical — 4 audit chiều	Đ44 §9.2-9.3	§10
10	Meta-conformance hypothetical cho relation_edge family	Đ44 §2.2 OQC	§11
11	Tier 1 unblock criteria cho P38-XC Living DB Q2-Q6	P38-XC §2.1	§12
12	OPEN/TD phát sinh + cầu nối P44-5	—	§13-14

1.2 P44-4 KHÔNG LÀM (6 guardrails GPT — kỷ luật scope nghiêm)

6 guardrails từ GPT review outline (S190 2026-05-02) — em áp dụng nguyên văn, không lỏng.

1. Đ44 Object Edges và NĐ-36-01 Semantic Relationships PHẢI tách namespace rõ. Nếu cùng dùng/read qua universal_edges, vẫn phải tách bằng: endpoint type, edge_type namespace, owner law, writer DOT, checker DOT, provenance rule. Đặc biệt cẩn thận với edge name giống nhau như contradicts.
2. OPEN P44-2-δ tac_publication_member: phân tích đủ 3 phương án, KHÔNG default hợp thức hóa "internal relation riêng" như exception vĩnh viễn. Hướng ưu tiên: universal_edges SSOT dài hạn → Migrate (b) hoặc Dual transitional (c). (a) Internal-only chỉ chấp nhận nếu lý do cực mạnh + có sunset/exception policy.
3. TD-44-2 audit: chỉ logical plan trong P44-4. KHÔNG execute query, kể cả read-only. Nếu cần audit thật → prompt agent riêng sau khi User cho phép.
4. TD-44-3 retrofit: giữ 4 phase logical plan, KHÔNG viết migration script.
5. P44-5 handoff phải rõ: P44-4 chốt logical contract; P44-5 mới chốt DOT name, schedule, auto-fix policy, reverse-index implementation, recursive audit, code/trigger.
6. KHÔNG DDL, KHÔNG code, KHÔNG mutate production, KHÔNG tên DOT cụ thể, KHÔNG upload first draft.

1.3 Phép thử nhanh sa đà

Nếu thấy P44-4 đang viết một trong các thứ sau → dừng + báo lại:

• Schema chi tiết entity_relations / abbreviation_dict / alias (NĐ-36-01 scope, KHÔNG xâm phạm)
• DDL CREATE TABLE / ALTER TABLE / function code
• Tên DOT cụ thể (vd dot_universal_edges_writer) — defer P44-5
• Audit script execute trên production (kể cả read-only)
• Migration script cho 2199 legacy edges
• Đ39 KG export, Qdrant projection edge structure

---

§2. Phân biệt 2 namespace — Đ44 §5 Object Edges vs NĐ-36-01 Semantic Relationships

Tại sao đặt ngay đầu: nếu nhầm 2 layer thì toàn bộ P44-4 sai hướng. NĐ-36-01 và Đ44 §5 cùng nói về "relation/edge" nhưng thuộc 2 tầng hoàn toàn khác — phải tách rõ ngay từ đầu, theo guardrail 1 GPT.

2.1 So sánh 2 layer — bảng đầy đủ

Tiêu chí	Đ44 §5 Object Edges (P44-4 scope)	NĐ-36-01 Semantic Relationships (out-of-scope)
Đối tượng đầu cuối	Object thoả OQC ≥ 3/4 (Đ44 §2.2): information_unit, publication, dot_checker, vector_projection, ...	Concept ngữ nghĩa: "Doanh thu" ≡ "Revenue", "NV" ↔ "Nhân viên", semantic_concept species
Endpoint identity	object_id (PREFIX-NNN hoặc UUID)	concept_id (alias-bound entity hoặc semantic_concept entry)
Mục đích	Audit Object dependencies, traceability, Living DB Q2-Q6, Đ44 cross-cutting SSOT	Entity Linking (MT1), Đ38 binding, Đ39 KG node merging
Edge types	8 Core: contains, references, depends_on, uses, implements, supersedes, contradicts, compatible_with + 3 Candidate: derived_from, governed_by, published_in (§3)	NĐ-36-01 vocab: synonym, near_synonym, hyponym, hypernym, abbreviation_of, contradicts (semantic), code_switch_alias
Edge type namespace	(chốt §2.3) đề xuất prefix obj. hoặc owner_layer D44	đề xuất prefix sem. hoặc owner_layer ND36
Owner law	Đ44 §5 (vocab + minimum fields) + NĐ-36-01 (infrastructure)	NĐ-36-01 toàn phần
Writer	DOT Cap-4 relation writer + Cap-5 composition writer (P44-5 chốt tên)	NĐ-36-01 Pipeline NLP (Phần 5 — chưa soạn)
Checker	DOT Cap-4/Cap-5 checker	NĐ-36-01 disambiguation_log + Active Learning loop
Provenance rule	Bắt buộc post-Đ44 enacted (Đ44 §5.4)	Bắt buộc per annotation, có 5 fields (NĐ-36-01 MT4)
Lifecycle	edge entry có valid_time + status ≥ 2 state	alias/relation có effective_from/to + revision (temporal)
3 vùng dữ liệu	Đ44 không quy định cho Object edges	NĐ-36-01: approved / candidate / quarantine
Concurrency	Đ44 không quy định	pg_advisory_xact_lock(entity_id) cho merge/split (NĐ-36-01)

2.2 Cảnh báo edge name clash — contradicts là ví dụ điển hình

GPT đặc biệt cảnh báo: cẩn thận với edge name giống nhau giữa 2 layer.

contradicts xuất hiện ở cả 2 layer nhưng nghĩa hoàn toàn khác:

Layer	contradicts nghĩa gì	Ví dụ
Đ44 §5.3.A Object edge	2 Object có nội dung mâu thuẫn về logic/quy định	Đ38 v2.3 enacted vs Đ38 v3.0 draft — cùng owner law, conflict version
NĐ-36-01 MT2 Semantic relation	2 concept có ngữ nghĩa đối lập	"Miễn phí" vs "Có phí", "Chấp thuận" vs "Từ chối"

Hệ quả nếu lẫn lộn:

• DOT Cap-4 checker không biết entry contradicts thuộc layer nào → audit sai
• Pipeline NLP NĐ-36-01 đọc Object edge contradicts như semantic input → KG nhiễu
• Living DB Q4 ("Tôi dùng ai?") trả về cả semantic concept → lệch ngữ cảnh

Cảnh báo các edge name khác có thể clash trong tương lai:

• references (Đ44: object→object reference) vs có thể NĐ-36-01 thêm references (alias references) — cần tránh.
• derived_from (Đ44 Candidate: provenance object) vs Đ39 KG có thể có derived_from (concept derivation) — đã flag trong outline OPEN P44-4-ζ.

2.3 Hệ quả thiết kế — namespace separation 5 chiều

Theo guardrail 1 GPT: tách namespace bằng 5 chiều — KHÔNG chỉ qua edge_type value.

Chiều tách	Đ44 §5 Object Edges	NĐ-36-01 Semantic	Cơ chế enforce
Endpoint type	Object instance ID (verified qua OQC)	Concept ID (semantic_concept species hoặc canonical entity)	Validation logic on INSERT
edge_type namespace	đề xuất prefix obj. (vd obj.contains, obj.references) hoặc tag owner_law=NRM-LAW-44	đề xuất prefix sem. (vd sem.synonym, sem.contradicts) hoặc tag owner_law=NĐ-36-01	vocab metadata tag
Owner law tag	owner_law_code = NRM-LAW-44 trên edge entry	owner_law_code = NĐ-36-01 trên edge entry	edge field tag
Writer DOT	Cap-4/Cap-5 (P44-5 chốt tên, vd dot_universal_edges_object_writer)	NĐ-36-01 pipeline (vd dot_semantic_linking_pipeline)	DOT registry tag
Checker DOT	Cap-4/Cap-5 checker (P44-5)	NĐ-36-01 disambiguation_log audit	DOT registry tag
Provenance rule	Đ44 §5.4: bắt buộc post-Đ44	NĐ-36-01 MT4: 5 fields (extraction_method, match_score, confidence, resolved_by, source_context)	provenance schema

OPEN P44-4-α: chốt scheme namespace cho edge_type (prefix obj./sem. vs tag owner_layer vs cả hai). Defer APR khi chốt vocab framework cho universal_edges.

2.4 Vùng giao thoa — universal_edges chứa cả 2

Theo NĐ-36-01: "universal_edges = read-model + discovery backbone". Theo Đ44 §5.1: "Đ44 KHÔNG đẻ bảng mới". → Cùng dùng universal_edges là đúng, KHÔNG phá ranh giới.

Nhưng edge entry trong universal_edges phải tag rõ:

• owner_layer (Đ44 vs NĐ-36-01)
• edge_type (theo namespace tương ứng)
• Validation logic enforce: edge obj.contains chỉ chấp nhận source/target là Object; edge sem.synonym chỉ chấp nhận concept

Ranh giới vĩnh viễn:

• Edge giao layer (Object → Concept hoặc ngược lại) — CHƯA ĐỊNH NGHĨA, defer Đ39 mature + APR.
• KHÔNG được tự ý tạo edge giao layer trong P44-4.

---

§3. Edge type vocab — 8 Core + 3 Candidate + extension policy

Phạm vi: chỉ Đ44 §5 Object Edges. NĐ-36-01 vocab nằm ngoài scope P44-4.

3.1 8 Core edge types (Đ44 §5.3.A)

Council PASS trong Đ44 v0.1.2 — không revisit trong P44-4. P44-4 chỉ chuẩn hoá định nghĩa logical + reverse + family thường dùng.

edge_type	Định nghĩa logical	Reverse type	Family thường dùng (source → target)	Provenance requirement
contains	Container chứa member (composition mạnh, lifecycle phụ thuộc)	belongs_to	publication → information_unit, document → component, composite → atomic_unit	Bắt buộc post-Đ44
references	Source tham chiếu target (read-only, không phụ thuộc lifecycle)	referenced_by	information_unit → information_unit, claim → information_unit	Bắt buộc post-Đ44
depends_on	Source phụ thuộc target (functional dependency, broken nếu target retired)	depended_on_by	component → component, dot_checker → vocab_entry	Bắt buộc post-Đ44
uses	Source dùng target (instance-level usage)	used_by	publication → component, workflow → information_unit	Bắt buộc post-Đ44
implements	Source implement spec target	implemented_by	component → spec_information_unit, dot → policy_information_unit	Bắt buộc post-Đ44
supersedes	Source thay thế target (1 chiều, version succession)	(1 chiều, dùng reverse query)	information_unit_v2 → information_unit_v1, family_v2 → family_v1	Bắt buộc post-Đ44
contradicts	Source mâu thuẫn target về logic/quy định (đối xứng)	(đối xứng)	information_unit ↔ information_unit (conflict version), decision ↔ decision	Bắt buộc post-Đ44
compatible_with	Source tương thích target (đối xứng)	incompatible_with	component ↔ component, dot_version ↔ dot_version	Bắt buộc post-Đ44

3.2 3 Candidate edge types (Đ44 §5.3.B)

Đ44 v0.1.2 đề xuất, chờ User ban hành v1.0. P44-4 đề xuất giữ nguyên + ghi rõ default-state.

edge_type	Định nghĩa logical	Reverse type	Family thường dùng	Lý do Đ44 đề xuất	Default state
derived_from	Target sinh ra source (provenance)	(1 chiều)	vector_projection → information_unit, claim → information_unit_section	Phải biết projection từ object nào → audit/recompute	Candidate
governed_by	Source chịu governance của target (law/agency)	governs	information_unit → law_normative_registry, family → agency	Authority Map cần lưu ai/luật nào quản object	Candidate
published_in	Source được publish trong target	publishes	information_unit → publication, dot_release → release_bundle	Liên kết unit ↔ publication ngoài containment	Candidate

3.3 Extension policy — qua APR

Edge type ngoài 11 (8 Core + 3 Candidate) không được tự ý tạo. Quy trình thêm:

1. Đề xuất qua APR cấp medium (Đ32).
2. Justify: tại sao không dùng được edge type hiện hữu?
3. Định nghĩa logical + reverse + family thường dùng + provenance requirement.
4. APR PASS → amend edge_type vocab framework (xem §2.3 OPEN P44-4-α).
5. DOT Cap-4 checker mở hỗ trợ edge type mới.

Cấm hardcode edge_type list trong code — phải đọc từ vocab framework (NT4).

3.4 Reverse mapping summary

Pattern	Edge types thoả
Có reverse rõ ràng (source → target có reverse target → source khác tên)	contains ↔ belongs_to, references ↔ referenced_by, depends_on ↔ depended_on_by, uses ↔ used_by, implements ↔ implemented_by, compatible_with ↔ incompatible_with, derived_from ↔ (reverse query), governed_by ↔ governs, published_in ↔ publishes
1 chiều (chỉ có forward, reverse query)	supersedes
Đối xứng (source ↔ target cùng nghĩa)	contradicts, compatible_with (compatible_with có thể dùng cả 2 — đối xứng theo nghĩa, asymmetric về incompatible)

---

§4. Minimum logical fields cho edge entry — E1-E8

Logical contract, KHÔNG DDL. Tên field là logical name. Tên cột physical chốt qua APR khi enacted.

4.1 8 logical fields tối thiểu

#	Logical field	Cardinality	Kiểu logical	Ràng buộc	Tham chiếu
E1	edge_id	1..1	identifier (logical, abstract)	PK, unique, immutable	Đ44 §5.2
E2	source_ref	1..1	composite reference {collection, id, code} (xem §4.2)	not null, validate qua OQC	Đ44 §5.2 + Addendum §4
E3	target_ref	1..1	composite reference {collection, id, code}	not null, validate qua OQC	Đ44 §5.2
E4	edge_type	1..1	FK tới vocab framework (Đ24/dot_config)	not null, ∈ {8 Core + 3 Candidate + extension}	Đ44 §5.3
E5	confidence	0..1	decimal [0.0, 1.0]	default 1.0 cho structural edges; <1.0 cho semantic-derived	NĐ-36-01 MT4 (loose adopt)
E6	provenance	1..1 (post-Đ44)	structured logical {creator, method, source_context, timestamp}	bắt buộc post-Đ44 enacted	Đ44 §5.4
E7	status	1..1	enum {proposed, active, deprecated, retired} ≥ 2 state thực	not null, default active cho structural, proposed cho derived	OQC-2 + TD-44-2
E8	valid_time + timestamps	1..1 each	{valid_from, valid_to (nullable), created_at, updated_at, created_by, updated_by}	NT11 PG tự suy ra timestamps	Đ44 §5.2 + G12

4.2 Composite reference structure (E2/E3)

Tại sao composite: source_ref và target_ref phải định danh rõ ràng + resolvable + type-safe.

Sub-field	Mục đích	Ví dụ
ref.collection	Family code + scope (vd information_unit.tac_logical_unit)	information_unit.tac_logical_unit
ref.id	Object instance ID trong collection	UUID hoặc PREFIX-NNN
ref.code	Optional canonical code (immutable identifier)	Đ44.§3.2

Validation logic (DOT Cap-4 writer):

1. ref.collection phải tồn tại trong Family Registry (P44-1) hoặc SCMR (P44-2).
2. ref.id phải tồn tại trong physical target.
3. ref.code (nếu có) phải match canonical address của Object.
4. Object phải thoả OQC ≥ 3/4 (Đ44 §2.2) để là endpoint hợp lệ.

4.3 Provenance contract (E6) — bắt buộc post-Đ44

Theo Đ44 §5.4: "Edge mới (post-Đ44 enactment): bắt buộc có provenance."

Provenance structure logical (defer storage format APR):

Sub-field	Mục đích	Ví dụ
provenance.creator	Ai tạo edge: DOT name, agent name, hoặc human user	dot_universal_edges_writer, agent.opus, user.huyen
provenance.method	Phương thức tạo: structural (FK), derived (computed), manual (human)	structural, derived, manual
provenance.source_context	Source artifact tạo edge (nếu có)	migration_2026_05_05, tac_birth_trigger, apr_decision_xyz
provenance.timestamp	Khi tạo	ISO 8601
provenance.confidence_method	Cách tính confidence (cho derived edges)	pg_trgm_score=0.92, embedding_cosine=0.85

Quy tắc:

• Edge mới post-Đ44 thiếu provenance → block birth (Đ44 §9.4).
• Edge legacy pre-Đ44 → retrofit theo §9 (TD-44-3).

4.4 Lifecycle ≥ 2 state thực (E7) — connected to TD-44-2

E7 status phải có ≥ 2 state thực có rows trong production. Đây là điểm OQC-2 audit (xem §8 audit plan).

4 state đề xuất:

• proposed: edge mới tạo bởi derived method, chưa verify
• active: edge đã verify hợp lệ, đang dùng
• deprecated: edge cũ bị supersede nhưng giữ lại để audit trail
• retired: edge sẽ xoá sau grace period

Transition rules:

• proposed → active sau DOT checker verify hoặc human review.
• active → deprecated khi có edge mới supersede (qua supersedes edge type).
• deprecated → retired sau grace period (defer post-pilot).

4.5 Logical invariants

ID	Invariant	Kiểm bằng
INV-E1	edge_id unique	DB constraint
INV-E2	source_ref và target_ref đều resolve được tới Object hợp lệ	DOT Cap-4 checker
INV-E3	edge_type ∈ vocab framework hợp lệ + match namespace (Đ44 vs NĐ-36-01)	Validation logic
INV-E4	Edge mới post-Đ44 ⇒ provenance đầy đủ	Birth gate (Đ44 §9.4)
INV-E5	status ∈ {proposed, active, deprecated, retired}; ≥ 2 state có rows thực trong production (OQC-2)	DOT periodic audit
INV-E6	Đối xứng edges (contradicts, compatible_with) ⇒ phải có 2 entries (forward + reverse) hoặc DOT reverse-index materialize	DOT Cap-4 checker
INV-E7	Edge với edge_type ∈ {contains, belongs_to} ⇒ source_ref và target_ref cùng family hoặc family hợp lệ chứa nhau	DOT Cap-5 composition checker
INV-E8	CYCLE detection: chain contains không được cycle (Đ0-B §IV)	Recursive CTE check, depth ≤ 4

---

§5. Composition Cap-5 contract — align Đ0-B 7 lớp + cơ chế sống

Cap-5 composition là 1 trong 2 capability Tier 1 (Cap-4 relation + Cap-5 composition). Đ0-B v3.1 là nguồn nền — em đọc đầy đủ trước khi viết section này.

5.1 Đ0-B 7 lớp cấu tạo — recap

Lớp	Tên	Có ID?	Composition_role mapping	Status
Lớp 0	Hạ nguyên tử (Quark)	Không	(không gán)	Out-of-scope Đ44 (config/value)
Lớp 1	Nguyên tử (Atom)	Có	atomic	M2 production
Lớp 2	Phân tử (Molecule)	Có	molecular	M2 production
Lớp 3	Hợp chất (Compound)	Có	composite	M2 production
Lớp 4	Vật liệu (Material)	(chưa)	(chưa map)	M0 — chưa physical
Lớp 5	Sản phẩm (Product)	(chưa)	(chưa map)	M0 — chưa physical
Lớp 6	Công trình (Building)	(chưa)	(chưa map)	M0 — chưa physical

Quan trọng (terminology): Đ0-B header ghi "6 cấp cấu tạo" — đó là 6 cấp chính (Lớp 1-6). Lớp 0 Hạ nguyên tử ngoài 6 cấp (vì không có ID, không quản trị riêng). Tổng cộng 7 layers (0 + 6) nếu count Lớp 0. P38-XC §1.2 ghi "Đ0-B 7 lớp" — đúng nếu count Lớp 0.

5.2 composition_role — mapping P38-XC §7.2

P38-XC information_unit_identity_v1 có field composition_role với 3 values: atomic, molecular, composite. Map trực tiếp Lớp 1/2/3 (Đ0-B):

composition_role	Đ0-B Lớp	Định nghĩa	Ví dụ TAC
atomic	Lớp 1 (Nguyên tử)	Đơn vị nhỏ nhất, không chứa unit khác	tac_logical_unit đã segment đến điểm cuối (vd "Đ44.§3.2.a")
molecular	Lớp 2 (Phân tử)	Chứa atomic units, không có quy trình/logic	tac_logical_unit mức điều/khoản chứa nhiều điểm
composite	Lớp 3 (Hợp chất)	Chứa molecular + atomic + có logic/quy trình	tac_publication chứa nhiều điều/khoản + có lifecycle/transition

Quy tắc nâng cấp (Đ0-B §II): cho phép NÂNG CẤP composition_role khi complexity tăng (atomic → molecular → composite). KHÔNG hạ. Ghi WCR.

OPEN P44-4-η (đã flag outline): Lớp 4-6 (Material/Product/Building) chưa physical → composition_role chưa cần extend. Defer khi cần.

5.3 granularity_level — Đ0-B Lớp number

P38-XC information_unit_content_v1 có field granularity_level (Optional, DOT derive). Map trực tiếp Đ0-B Lớp:

granularity_level	Đ0-B Lớp	Tự động derive bằng
0	Hạ nguyên tử	(không applicable cho information_unit)
1	Nguyên tử	body length nhỏ + không chứa sub-unit
2	Phân tử	có sub-unit nhưng không có lifecycle riêng
3	Hợp chất	có sub-unit + có lifecycle/transition logic
4-6	Material/Product/Building	(chưa apply)

OPEN P44-4-η refined: granularity_level vocab cần align Lớp 1-6 explicit, KHÔNG dùng số tự do. Defer APR khi enacted.

5.4 Edge types cho Composition — contains, belongs_to, part_of_composite

Edge type	Đ0-B layer mapping	Cardinality	Ví dụ
contains	Lớp N → Lớp N-1 hoặc thấp hơn	1 source : N targets	tac_publication (Lớp 3) contains tac_logical_unit (Lớp 1-2)
belongs_to	Reverse contains	N sources : 1 target	tac_logical_unit belongs_to tac_publication
part_of_composite	Special: member của composite (Lớp 3) khi cần preserve composite logic	N members : 1 composite	(defer use case)

part_of_composite đã list trong P38-XC §9.2 nhưng chưa có use case rõ trong TAC. Defer chốt khi family Lớp 3 phức tạp xuất hiện.

5.5 Bootstrap order — composition

Khi 1 family physical hoá:

1. Tạo entries Lớp 1 (atomic units) trước.
2. Tạo entries Lớp 2 (molecular) sau, link contains xuống Lớp 1.
3. Tạo entries Lớp 3 (composite) cuối, link contains xuống Lớp 2 + Lớp 1.
4. DOT Cap-5 writer set composition_role tự động từ aggregation.

5.6 CYCLE detection + depth ≤ 4 (Đ0-B §IV requirement)

Đ0-B §IV cơ chế "sống" yêu cầu CYCLE detection bắt buộc + depth ≤ 4 guardrail.

Áp dụng cho Composition:

• Recursive CTE traversing contains chain phải có CYCLE detection (PG 14+ CYCLE id SET is_cycle USING path).
• Depth ≤ 4: WHERE depth <= 4.
• Nếu phát hiện cycle → DOT Cap-5 checker log issue → escalate.

Áp dụng cho Relation:

• references, depends_on, uses cũng có thể tạo cycle (vd 2 unit cross-reference vô hạn).
• Recursive CTE traversal phải có CYCLE detection.
• supersedes chain phải verify không cycle (1 version không thể supersede chính nó qua chain).

5.7 Cơ chế "sống" Đ0-B §IV map vào Living DB Q2-Q5

Đ0-B §IV query	Living DB Q (P38-XC)	Edge cơ chế	Ai trả lời
"Tôi thuộc ai?"	Q2	belongs_to outgoing hoặc reverse contains	composition Cap-5
"Ai thuộc tôi?"	Q3	reverse contains (Q3 reverse-index)	composition Cap-5 reverse-index
"Tôi dùng ai?"	Q4	uses, references, depends_on outgoing	relation Cap-4
"Ai dùng tôi?"	Q5	reverse uses/references/depends_on	relation Cap-4 reverse-index
"Bắc cầu"	(không có Q tương ứng)	Recursive CTE	Living DB advanced — defer
"Cùng loại"	(không có Q tương ứng)	family_code aggregation	Living DB advanced — defer
"Tôi sinh từ đâu?"	Q6	derived_from	relation Cap-4

→ Đ0-B §IV và P38-XC Living DB Q2-Q6 align hoàn toàn, không xung đột. Tier 1 composition + relation unlock cả 2.

5.8 Composition vs Relation — phân tách logical

Tiêu chí	Composition (Cap-5)	Relation (Cap-4)
Bản chất	Lifecycle phụ thuộc — container retire ⇒ member retire (cascade)	Lifecycle độc lập — source retire ⇒ target không bị ảnh hưởng
Edge types	contains, belongs_to, part_of_composite	references, depends_on, uses, implements, derived_from, governed_by, published_in
Đ0-B reference	Cấu trúc (FK/M2M native ưu tiên)	Chức năng (entity_dependencies hoặc universal_edges)
Cardinality typical	1:N (container : members)	N:N
CYCLE risk	Cao (parent → child → grandparent có thể cycle nếu wrong design)	Trung bình
Living DB Q	Q2 (thuộc ai), Q3 (ai thuộc)	Q4 (dùng ai), Q5 (ai dùng), Q6 (sinh từ đâu)

→ P44-4 chốt 2 capability tách trong P38-XC §9.1 + §9.2. KHÔNG gộp.

---

§6. Reverse-index responsibility logical — Q3, Q5

6.1 Vấn đề

Q3 ("Ai thuộc tôi?") và Q5 ("Ai dùng tôi?") cần reverse query. Trong universal_edges:

• SELECT * FROM universal_edges WHERE target_ref.id = X AND edge_type = 'contains' → reverse query OK nếu có index trên target_ref.id.
• Performance: với scale lớn, cần materialized view hoặc cached reverse-index.

6.2 3 patterns implementation

Pattern	Mô tả	Ưu	Nhược	Khi nên dùng
(P1) On-demand	Reverse query trực tiếp trên universal_edges với index	Đơn giản, real-time	Performance kém scale lớn (>1M edges)	Pilot, scale nhỏ
(P2) Materialized view	PG materialized view refresh định kỳ	Performance ổn định	Stale data; refresh cost	Scale trung bình
(P3) Trigger-driven cache	Bảng cache, trigger update mỗi INSERT/UPDATE/DELETE edge	Real-time + fast	Phức tạp consistency; trigger overhead	Scale lớn, query frequency cao

6.3 P44-4 quyết định logical

P44-4 chốt logical:

• DOT Cap-4 và Cap-5 phải có reverse-index responsibility (P38-XC §8.1).
• Pattern implementation (P1/P2/P3) defer P44-5 + volume measurement.

Wording siết về P1 — KHÔNG default production:

• P1 On-demand chỉ chấp nhận cho pilot khi đồng thời: (i) edge count nhỏ (vd <10K edges per family), (ii) đã có index/plan kiểm tra cơ bản trên target_ref + edge_type, (iii) query frequency thấp (không phải hot path).
• P1 KHÔNG phải default production dài hạn. Khi edge count tăng, query frequency tăng, hoặc P99 latency vượt threshold (defer chốt threshold) → bắt buộc xem xét P2 (materialized view) hoặc P3 (trigger-driven cache).
• TAC pilot hiện tại (3 publications, 86 units) đáp ứng (i)(ii)(iii) → P1 chấp nhận cho pilot, không cho production scale.
• Khi Tier 1 PASS + scale tăng → APR đánh giá lại + chọn (P2)/(P3).

OPEN P44-4-β: chốt pattern reverse-index per scale tier + threshold điều kiện chuyển P1 → P2/P3. Defer P44-5 + pilot evidence.

6.4 DOT responsibility

P38-XC §8.1 đã chốt logical (em copy + làm rõ):

Capability	Reverse-index responsibility	P44-5 chốt gì
Cap-4 relation	Maintain reverse query/cache cho references, uses, depends_on, derived_from (Q5, Q6 reverse)	DOT name, schedule refresh, code
Cap-5 composition	Maintain reverse query/cache cho contains, belongs_to (Q3)	DOT name, schedule, recursive depth handling

---

§7. Resolve OPEN P44-2-δ — tac_publication_member — phản biện 2 vòng

Section quan trọng nhất P44-4 — GPT đặc biệt yêu cầu phản biện 2 vòng + KHÔNG default (a) Internal-only. Em refine quan điểm sau khi đọc Đ0-B (lần 3).

7.1 Reframe vấn đề sau khi đọc Đ0-B

tac_publication_member là FK/M2M table (P11A #4) lưu quan hệ tac_publication ↔ tac_logical_unit. Theo Đ0-B §I-C: ưu tiên FK/M2M native cho structural relations.

→ Conflict tiềm năng giữa 2 luật:

• Đ0-B §I-C: ưu tiên FK/M2M native (cấu trúc, DB enforce 100%)
• Đ44 §5.1: "Mọi quan hệ giữa Object thuộc Đ44 phải đi qua universal_edges. Đ44 KHÔNG đẻ bảng mới."

Câu hỏi cốt lõi: 2 luật này có thực sự conflict không? Hay là 2 góc nhìn khác nhau cùng tồn tại?

7.2 6 dimensions phân tích

Dimension	(a) Internal-only	(b) Migrate sang universal_edges	(c) Dual representation
D1: Đ44 §5.1 strict reading	❌ Vi phạm wording	✅ Tuân chính xác	⚠️ Tuân về SSOT, vẫn có bảng riêng
D2: Đ0-B §I-C FK/M2M priority	✅ Tuân (FK trực tiếp)	❌ Mất FK constraint enforcement	✅ Có FK + có universal_edges entry
D3: Performance (Q2/Q3 query)	✅ Tốt nhất (FK direct)	⚠️ JOIN universal_edges (chậm hơn)	✅ Tốt (query FK), thêm consistency cost
D4: Living DB Q2/Q3 SSOT cleanness	❌ Phải union 2 nguồn cho generic Q3	✅ Single source query	⚠️ universal_edges là SSOT, FK là enforcement
D5: Migration complexity	✅ Không cần migration	⚠️ Migrate 86 unit × 3 pub = ~86 rows + drop tac_publication_member	⚠️ Cần dual-write trigger + initial backfill
D6: Tier 1 generic pattern	❌ TAC special case → precedent xấu cho family khác	✅ Generic	⚠️ Generic cho query, special cho enforcement

7.3 Insight từ Đ0-B §I-C — phân biệt cấu trúc vs chức năng

Đ0-B §I-C nói rõ:

• Cấu trúc (Structural): FK/M2M native — "A chứa B" — DB enforce 100%.
• Chức năng (Functional): entity_dependencies — cross-type — soft DOT scan.

→ Đ0-B nói về entity_dependencies vs FK, KHÔNG nói trực tiếp về universal_edges. Vậy:

• entity_dependencies (Đ0-B chức năng) ≠ universal_edges (Đ44 SSOT relation)?
• Hay entity_dependencies LÀ một cách triển khai trên universal_edges?

Em tra lại P11A: universal_edges và entity_dependencies có thể là 2 bảng khác nhau (P11A #17 ghi universal_edges 2199 rows; entity_dependencies có thể là alias hoặc bảng riêng). Defer verify — không quan trọng cho P44-4 logical.

Insight: Đ0-B §I-C có thể được hiểu là:

• FK/M2M = enforcement layer (DB-level structural constraint)
• universal_edges = SSOT layer (cross-cutting query/audit)
• 2 layer không loại trừ nhau — có thể cùng tồn tại trong (c) Dual representation.

7.4 Đ44 §5.1 strict vs flexible reading

Strict reading: "Mọi quan hệ qua universal_edges. KHÔNG đẻ bảng mới." → Phương án (b) Migrate là đúng nhất.

Flexible reading: "universal_edges là SSOT cho relation query. FK enforcement có thể giữ làm DB-level constraint." → Phương án (c) Dual cũng hợp lệ nếu universal_edges là SSOT cho audit/query.

GPT chỉ đạo: "universal_edges là SSOT dài hạn, còn tac_publication_member nếu giữ thì chỉ nên là transitional/materialized/helper representation, có DOT kiểm đồng bộ, không phải nguồn sự thật độc lập."

→ Match flexible reading. (c) Dual là transitional, KHÔNG vĩnh viễn.

7.5 Vòng 1 — Conclusion

Phương án xếp hạng (vòng 1):

1. (b) Migrate sang universal_edges — best long-term, match Đ44 §5.1 strict.

   • Pros: Single SSOT, generic pattern, không precedent xấu.
   • Cons: Mất FK enforcement, performance cần optimize sau scale.
   • Migration scope nhỏ (~86 rows), 1 lần.

2. (c) Dual transitional — pragmatic short-term, match GPT chỉ đạo.

   • Pros: Giữ FK enforcement (Đ0-B priority), universal_edges là SSOT, performance tốt.
   • Cons: Phức tạp consistency, cần DOT sync, ngắn hạn.
   • Sunset path: sau khi universal_edges performance proven + materialized view stable → migrate (b).

3. (a) Internal-only — không khuyến nghị.

   • Lý do duy nhất chấp nhận: performance critical scale 10M+ rows VÀ universal_edges không thể optimize.
   • Sunset/exception policy bắt buộc: ghi rõ điều kiện exception, audit định kỳ, plan migrate khi điều kiện thay đổi.
   • Hiện tại TAC scale 86 rows — KHÔNG đáp ứng condition exception.

Vòng 1 đề xuất: (c) Dual transitional với sunset path → (b) Migrate khi điều kiện chín.

7.6 Vòng 2 — Phản biện vòng 1

Phản biện 1: (c) Dual có risk consistency drift. Nếu DOT sync fail → 2 nguồn lệch nhau → Living DB Q2/Q3 ra kết quả khác nhau tùy nguồn query.

• Counter: DOT cặp NT12 (Đ44 §9.2) — writer + checker. Checker phát hiện drift sớm. Đ22 self-healing extend cho edge consistency.
• Vẫn còn risk: Bug trong DOT sync hoặc race condition. Mitigate bằng transaction-based dual write (cùng commit).

Phản biện 2: (c) tạo 2 source of truth → vi phạm NS-1 SSOT?

• Counter: KHÔNG. SSOT là universal_edges. FK chỉ là enforcement constraint, không phải source of truth. Phân biệt rõ vai trò.
• Vẫn cần ghi rõ ràng trong P44-4: "FK = enforcement; universal_edges = SSOT".

Phản biện 3: Sunset path từ (c) → (b) thực tế có xảy ra không? Hay (c) sẽ vĩnh viễn?

• Counter quan trọng: nếu không có trigger điều kiện rõ ràng để sunset, (c) sẽ thành (a) lén. Phải định nghĩa:
  • Trigger condition: universal_edges performance benchmark PASS + materialized view stable.
  • Migration plan ready trước khi (c) deploy.
  • Audit định kỳ check trigger condition.

Phản biện 4: (b) Migrate ngay có realistic không cho 86 rows + 3 publications?

• Counter: Có. 86 rows × 1 migration = nhỏ. Risk chính là DOT cập nhật để đọc universal_edges thay vì tac_publication_member.
• Nếu DOT chưa ready → tạm thời (c) trong vài ngày, sau đó migrate.

Phản biện 5 (đặc biệt quan trọng — em nhận thêm sau Đ0-B): Đ0-B §I-C ưu tiên FK/M2M cho cấu trúc. Nếu Migrate (b), TAC không có FK enforce → vi phạm Đ0-B?

• Counter: Đ0-B không cấm dùng universal_edges. Đ0-B nói "ưu tiên FK/M2M khi có thể". universal_edges có UNIQUE constraint trên (source_ref, target_ref, edge_type) cũng là enforcement. Nhưng yếu hơn FK trực tiếp.
• Resolution: nếu Đ0-B priority là cứng → (c) Dual; nếu Đ0-B là khuyến nghị → (b) Migrate OK.
• Cần User clarify: Đ0-B §I-C wording "ưu tiên" có phải hard rule?

7.7 Default ruling P44-4 — (c) Dual transitional

Polish P44-4A: P44-4 tự đề xuất default rule pháp lý, KHÔNG đẩy decision về User clarify Đ0-B §I-C. Theo OR: "chưa có luật → đề xuất bổ sung". P44-4 đứng trên evidence luật hiện hành để chốt default.

7.7.1 Default ruling pháp lý cho Đ0-B §I-C

Mặc định pháp lý P44-4:

Đ0-B §I-C "ưu tiên FK/M2M cho structural relations" được hiểu là ưu tiên ENFORCEMENT LAYER (DB-level constraint), KHÔNG được hiểu là cho phép tạo SSOT relation riêng ngoài universal_edges.

Lập luận:

• Đ0-B §I-C nói rõ "FK/M2M = cấu trúc, DB enforce 100%; entity_dependencies = chức năng, DOT scan soft". Vai trò là enforcement vs scan, không phải SSOT vs SSOT.
• Đ44 §5.1 NS-1 "Mọi quan hệ qua universal_edges + KHÔNG đẻ bảng mới" — định nghĩa SSOT layer.
• 2 luật không conflict khi hiểu Đ0-B = enforcement layer, Đ44 = SSOT layer. Conflict chỉ xảy ra nếu hiểu Đ0-B = SSOT riêng → wording sai.

→ Default rule P44-4: FK/M2M = enforcement helper; universal_edges = SSOT cho query/audit/governance. KHÔNG cần User phân xử "hard rule vs khuyến nghị".

7.7.2 Lựa chọn chuẩn cho tac_publication_member — (c) Dual transitional

Default: (c) Dual transitional:

• tac_publication_member giữ vai trò enforcement helper (FK constraint DB-level) HOẶC materialized/helper representation (performance optimization).
• universal_edges là SSOT duy nhất cho query/audit/governance.
• DOT cặp sync 2 nguồn (transaction-based dual write) + anti-drift invariant 2 chiều (xem §7.7.3).

universal_edges là SSOT — siết wording cứng:

tac_publication_member KHÔNG PHẢI SSOT.

• KHÔNG có bất kỳ query Living DB chính thức nào đọc trực tiếp tac_publication_member như nguồn sự thật.
• Nếu giữ tac_publication_member, nó chỉ có 1 trong 2 vai trò: (i) enforcement helper (FK constraint), HOẶC (ii) materialized/helper representation (performance cache).
• Mọi truy vấn chuẩn Q2/Q3 (Living DB) phải đi qua universal_edges HOẶC reverse-index sinh từ universal_edges.
• Cấm patterns: "query union 2 nguồn", "fallback to tac_publication_member khi universal_edges thiếu data", "compare 2 nguồn để chọn".

7.7.3 Anti-drift invariant 2 chiều — bắt buộc cho Dual

Polish P44-4A: nếu thiếu anti-drift invariant 2 chiều, Dual sẽ trượt thành 2 nguồn thật (2 SSOT) → vi phạm NS-1.

INV-DUAL-1 (FK/M2M → universal_edges):

• Mỗi row hợp lệ trong tac_publication_member PHẢI có đúng một edge tương ứng trong universal_edges với:
  • source_ref = tac_publication_member.publication_id (qua composite ref)
  • target_ref = tac_publication_member.unit_id
  • edge_type = contains (hoặc namespace tương ứng)
  • status ∈ {active, proposed} (không retired/deprecated trừ khi helper cũng vậy)

INV-DUAL-2 (universal_edges → FK/M2M):

• Mỗi universal_edges composition edge giữa publication ↔ logical_unit (edge_type = contains namespace Đ44) PHẢI có row helper tương ứng trong tac_publication_member NẾU helper còn tồn tại (tức nếu chưa migrate sang phương án (b)).

INV-DUAL-3 (Drift detection bắt buộc):

• DOT Cap-5 composition checker periodic kiểm 2 chiều INV-DUAL-1 + INV-DUAL-2.
• Lệch 2 chiều → DOT PHẢI flag drift, KHÔNG được âm thầm bỏ qua.
• Drift severity:
  • High: row helper không có universal_edges entry → block production query, escalate.
  • High: universal_edges entry không có row helper (helper còn tồn tại) → escalate.
  • Medium: status mismatch (vd helper active, edge deprecated) → log, schedule sync.

INV-DUAL-4 (Transaction atomicity):

• Mọi INSERT/UPDATE/DELETE liên quan composition edge PHẢI là transaction-based dual write (cùng commit, cùng rollback).
• Race condition + partial failure → drift → INV-DUAL-3 flag.

7.7.4 Sunset path — 4 conditions explicit

Polish P44-4A: sunset không phải lời hứa chung — phải có 4 trigger conditions cụ thể + 2 exit paths khi conditions hết.

Dual transitional CHỈ ĐƯỢC TỒN TẠI khi còn ÍT NHẤT MỘT trong 4 lý do sau:

Condition	Định nghĩa cụ thể	Cách verify
C1: Cần FK enforcement	universal_edges chưa có UNIQUE constraint hoặc CHECK validation tương đương FK strength	Schema audit
C2: Cần performance helper	Query Q2/Q3 qua universal_edges + reverse-index không đáp ứng latency requirement (P99 > threshold)	Benchmark đo
C3: DOT writer/checker chưa đủ ổn định	DOT Cap-5 writer/checker chưa pass 30-day stability test (no incidents)	DOT audit log
C4: Migration full chưa có benchmark an toàn	Chưa có evidence universal_edges + reverse-index thay thế hoàn toàn helper mà không mất integrity	Migration test plan

Khi 4 conditions đều hết, BẮT BUỘC chuyển sang một trong 2 hướng exit:

Exit path	Khi nào dùng	Hành động
E1: Bỏ helper hoàn toàn	universal_edges + reverse-index đủ thay thế FK enforcement + performance	Migrate (b): drop tac_publication_member, populate universal_edges đầy đủ
E2: Giữ helper như materialized representation	Vẫn cần performance cache nhưng KHÔNG cần FK enforcement (vd universal_edges đã có UNIQUE constraint mạnh)	Helper retained, ghi rõ là materialized representation, có DOT checker bắt drift, KHÔNG là SSOT

Audit định kỳ sunset conditions:

• Mỗi 6 tháng re-evaluate 4 conditions.
• Decision qua APR cấp medium.
• Documentation: ghi rõ trong Family Registry entry rationale + sunset condition status.

7.7.5 KHÔNG đề xuất (a) Internal-only

Vi phạm guardrail 2 GPT, vi phạm Đ44 §5.1 wording, tạo precedent xấu. Xem §7.8 exception policy framework — hiện không family nào thoả conditions exception.

7.8 Exception policy framework (cho trường hợp tương lai)

Theo guardrail 2 GPT: nếu (a) Internal-only chấp nhận trong tương lai, phải có sunset/exception policy.

Conditions for (a) acceptance (đề xuất):

1. Performance benchmark: universal_edges + materialized view không thể đáp ứng scale (vd >10M edges per family hoặc query latency >1s p99).
2. Migration plan ready: nếu sau này điều kiện thay đổi, có path migrate sang (b) hoặc (c).
3. Audit định kỳ: every 6 months re-evaluate condition. Nếu điều kiện không còn → migrate.
4. Exception decision qua APR cấp high (Đ32) + Đ44 Conformance Clause C5 (cơ chế cập nhật).
5. Documentation: ghi rõ trong Family Registry entry + SCMR entry rationale + sunset condition.

Hiện tại không có family nào thoả conditions exception. (a) không được chấp nhận cho bất kỳ family nào trong P44-4 scope.

---

§8. Audit plan TD-44-2 — relation_edge lifecycle ≥ 2 state — LOGICAL ONLY

Theo guardrail 3 GPT: chỉ logical plan trong P44-4. KHÔNG execute query, kể cả read-only.

8.1 Câu hỏi gốc (Đ44 §11.5 TD-44-2)

universal_edges có status field, nhưng có ≥ 2 state thực hay không? Nếu chỉ 1 state dominant → fail OQC-2 → relation_edge không phải Object → seed §4.2 Đ44 cần amend.

8.2 Logical audit plan — 6 step

Step	Action	Tiêu chí PASS
1	Liệt kê distinct values của status field trong universal_edges	≥ 2 distinct values
2	Đếm rows per status	≥ 2 status có rows ≥ 1
3	Verify state transitions có thực sự xảy ra (audit log/timestamps)	Có evidence transitions
4	Check nếu chỉ 1 state dominant (vd 99% active, 1% deprecated)	Đa state phân bố hợp lý — không 99/1
5	Verify status có ý nghĩa lifecycle (không phải flag hay phân loại khác)	Status là lifecycle thực
6	Cross-check với DOT registry: có DOT writer/checker tương tác status không	DOT logic dùng status để decide

8.3 Tiêu chí PASS / FAIL OQC-2

Outcome	Hệ quả
PASS (≥ 2 state thực + transitions thực + ý nghĩa lifecycle)	relation_edge thoả OQC-2 → là Object → giữ trong seed §4.2 Đ44
FAIL (chỉ 1 state hoặc state không phải lifecycle)	relation_edge KHÔNG thoả OQC-2 → KHÔNG là Object → amend candidate cho Đ44 §4.2 (loại bỏ khỏi seed)
PARTIAL (≥ 2 state nhưng phân bố lệch)	Audit lý do — có thể schema có nhưng workflow chưa dùng → cần action plan để dùng đầy đủ

8.4 Hệ quả

Nếu FAIL:

• relation_edge không là Object → ngoài scope Đ44 → universal_edges là infrastructure (NĐ-36-01 quản), không phải object family.
• Edge entry không cần qua Family Registry.
• P44-4 phải reframe: edge entries là records trong infrastructure, không phải Object instances.

Nếu PASS:

• relation_edge là Object family → có Family Registry entry → có SCMR entry.
• Edge có thể là endpoint của edge khác (vd governed_by trên 1 edge entry).

8.5 Defer execute — KHÔNG trong P44-4

Lý do defer:

• P44-4 scope là logical contract.
• Execute query (kể cả read-only) thuộc 1 prompt agent riêng.
• Cần User cho phép trước khi agent query universal_edges production.

Plan execute (sau P44-4 PASS, nếu User cho phép):

• Soạn prompt agent riêng theo OR công thức (mục tiêu mở + tiêu chí PASS/FAIL + ràng buộc luật).
• Agent execute 6 step audit.
• Báo kết quả → User chốt amend Đ44 §4.2 nếu FAIL.

OPEN P44-4-δ: User chốt khi nào execute audit. Defer.

---

§9. Audit plan TD-44-3 — Legacy edges retrofit — LOGICAL POLICY ONLY

Theo guardrail 4 GPT: 4 phase logical plan, KHÔNG migration script.

9.1 Vấn đề (Đ44 §11.5 TD-44-3)

universal_edges hiện có ~2199 edges pre-Đ44. Đ44 §5.4 yêu cầu edge mới post-Đ44 bắt buộc provenance. Legacy edges thiếu provenance → cần retrofit dần theo Đ44 Appendix A G6.

9.2 4 phase logical retrofit policy

Phase 0 — Audit baseline

Action	Output
Đếm edges per edge_type	Distribution table
Đếm edges thiếu provenance	Count rows missing
Phân loại edges theo provenance_method (manual / structural / derived)	Breakdown
Identify high-priority edge types (vd contains > references)	Priority list

Phase 1 — Bootstrap provenance generic

Action	Logic
Tạo provenance entry generic cho mọi legacy edges thiếu	provenance.creator = 'legacy_pre_d44_enactment_2026'; provenance.method = 'unknown_legacy'; provenance.source_context = 'pre_d44_audit_baseline'
Mark edges có provenance "legacy"	DOT phân biệt edge legacy vs edge post-Đ44
Edge legacy không bị block birth gate (grace period)	Đ44 §5.4

Phase 2 — Per-type retrofit (chính xác hơn)

Priority	Edge type	Retrofit method
Cao	contains, belongs_to	Detect từ FK relations trong physical schema → retrofit provenance.method = 'structural_fk'
Cao	governed_by	Retrofit từ owner_law/agency mapping
Trung	references, uses	Detect từ source/target context → retrofit provenance.method = 'derived_context'
Thấp	compatible_with, contradicts	Manual review (low volume)

Phase 3 — Quarantine policy post-Đ44

Action	Logic
Edge mới post-Đ44 thiếu provenance	Block birth gate (Đ44 §9.4) — KHÔNG insert
Edge legacy đã retrofit Phase 1/2	Active state, full audit trail
Edge legacy chưa retrofit + còn dùng	Quarantine area, escalate

9.3 Defer execute — Đ44 Appendix A G6 scope

P44-4 LÀM: 4 phase logical policy. P44-4 KHÔNG LÀM:

• Migration script
• Execute retrofit
• Chốt grace period chính xác (defer pilot evidence)

OPEN P44-4-ε: grace period default cho legacy edges. Đ44 §5.4 nói "audit + retrofit dần" nhưng không define timeline. Defer Đ44 Appendix A G6.

---

§10. Edge Conformance Audit pattern logical — 4 audit chiều

10.1 4 audit chiều

Theo Đ44 §9.3 + P38-XC §8.1:

Chiều	Mục đích	Tiêu chí FAIL	Action
A1: Orphan source	Verify source_ref resolve được	source object không tồn tại / retired	Log issue, mark edge quarantine
A2: Orphan target	Verify target_ref resolve được	target object không tồn tại / retired	Log issue, mark edge quarantine
A3: Missing reverse	Verify edges đối xứng (contradicts, compatible_with) có cả 2 entries hoặc reverse-index	Chỉ có 1 chiều cho symmetric edge	Log issue, DOT auto-create reverse hoặc escalate
A4: Vocab violation	Verify edge_type ∈ vocab framework hợp lệ + match namespace	edge_type không trong vocab hoặc cross namespace sai	Block edge, escalate

10.2 DOT responsibility (P38-XC §8.1 — copy + làm rõ cho P44-4)

Capability	Responsibility	Audit chiều cover
Cap-4 relation writer	Create edge entries với valid source/target/edge_type/provenance trên INSERT	(gián tiếp A1, A2, A4 qua validation)
Cap-4 relation checker	Periodic 4 chiều audit (A1-A4)	Tất cả
Cap-4 enrichment	Auto-suggest related edges qua similarity (Tier 2+)	Tăng cường, không audit
Cap-4 reverse-index	Maintain reverse index cho Q3, Q5	A3 ngầm
Cap-5 composition writer	Set parent + create contains edge trên INSERT	(validation A1, A2)
Cap-5 composition checker	Verify parent_or_container_ref consistent + composition_role match	A1 ngầm cho composition
Cap-5 reverse-index	Maintain reverse contains cho Q3	A3 ngầm

10.3 P44-5 handoff explicit

P44-4 chốt logical:

• 4 audit chiều (A1-A4).
• Responsibility per capability (writer/checker/enrichment/reverse-index).
• Pairing pattern (writer + checker tối thiểu, NT12).

P44-5 chốt (defer):

• Tên DOT cụ thể (vd dot_universal_edges_relation_writer).
• Schedule (event-driven trên INSERT/UPDATE; daily checker).
• Auto-fix policy (Đ22 self-healing extend cho edges).
• Reverse-index implementation (P1/P2/P3 — xem §6.3).
• Recursive audit terminal cap (P38-XC OPEN P38-X-15).
• Code/trigger thực thi.

---

§11. Meta-conformance hypothetical — relation_edge family

Hypothetical proof. Full check khi:

1. TD-44-2 audit PASS (relation_edge thoả OQC-2)
2. universal_edges physical hoá với entries đầy đủ
3. APR design phase

11.1 OQC check (Đ44 §2.2)

OQC	relation_edge thoả?	Lý do
OQC-1 Persistent Identity	✅	E1 edge_id ổn định, immutable
OQC-2 Lifecycle ≥ 2 state	⚠️ TD-44-2 audit pending	E7 status có ≥ 2 state {proposed, active, deprecated, retired} — cần verify thực
OQC-3 Governance Subject	✅	NĐ-36-01 + Đ44 §5 quản, APR amend vocab
OQC-4 Has Relations	✅	Edge có thể là target của edge khác (vd governed_by lên edge entry)

→ 3.5/4 OQC (OQC-2 conditional). Nếu TD-44-2 PASS → 4/4.

11.2 G1-G12 hypothetical mapping

G	relation_edge có	Status
G1 Identity	E1 edge_id	A
G2 Type & Family	family_code = relation_edge, owner_law = NĐ-36-01 + Đ44	A
G3 Lifecycle	E7 status (4 state pending TD-44-2)	OPEN-TD-44-2
G4 Owner & Authority	NĐ-36-01 + Đ44 (cross-cutting)	A
G5 Source & Provenance	E6 provenance post-Đ44	A (post-Đ44) / OPEN (legacy)
G6 Content/Profile	(edge không có content body, chỉ structural)	N/A
G7 Relation	E2 + E3 (edge chính nó là relation)	A — self-referential
G8 Usage	reverse query universal_edges với edge entry as target	C (cần reverse-index)
G9 BOM	—	N/A
G10 Vector Projection	(edge không project sang KG vector)	N/A
G11 Checker/DOT	DOT Cap-4/Cap-5 (P44-5 chốt)	OPEN
G12 Timestamps & Audit	E8 timestamps	A

Tổng: 6 A + 2 OPEN + 1 C + 3 N/A = 12 cells. relation_edge passes meta-conformance hypothetical với 2 conditional (OQC-2 + DOT).

11.3 Bootstrap — universal_edges chứa edges cho chính nó?

Câu hỏi: edge entries trong universal_edges có edge governed_by trỏ về NĐ-36-01 + Đ44? Edge tự reference?

Đề xuất logical: Không bắt buộc. Edge governed_by cho relation_edge family là family-level (1 entry trong universal_edges trỏ relation_edge family → NĐ-36-01 + Đ44), không phải per-edge instance.

Bootstrap order:

1. Family Registry entry relation_edge insert (sau Đ44 enacted + APR PASS).
2. SCMR entry cho universal_edges physical table.
3. universal_edges entries bắt đầu populate.
4. (Optional) family-level governed_by edge cho relation_edge.

OPEN P44-4-ζ (đã flag outline): edge derived_from semantic — Đ44 §5.3.B (Object provenance) vs có thể NĐ-36-01/Đ39 (concept derivation). Defer cross-check khi Đ39 mature.

---

§12. Tier 1 unblock criteria — Living DB Q2-Q6

Đây là deliverable chính của P44-4 cho Living DB Tier 1.

12.1 Per-Q checklist

Polish P44-4A: siết wording — mọi truy vấn chuẩn Q2-Q5 phải đi qua universal_edges (SSOT). KHÔNG query trực tiếp helper như tac_publication_member.

Q	Câu hỏi	Edge type cần	Field cần	Cap	Source query (SSOT)	Tier 1 PASS criteria
Q2 "Tôi thuộc ai?"	parent/container	contains (incoming) hoặc belongs_to (outgoing)	E2 source_ref hoặc UMC U9 parent_or_container_ref	Cap-5	universal_edges (SSOT) hoặc reverse-index sinh từ universal_edges. KHÔNG đọc trực tiếp helper.	(1) Edge type vocab có; (2) writer set parent on INSERT vào universal_edges; (3) at least 1 edge populated cho TAC family; (4) helper sync (nếu Dual) qua INV-DUAL-1
Q3 "Ai thuộc tôi?"	reverse contains	reverse query của contains	reverse-index	Cap-5	reverse-index sinh từ universal_edges. KHÔNG đọc trực tiếp helper.	(1) Reverse-index pattern chọn (P1 pilot only/P2/P3); (2) reverse-index maintainer DOT logical chốt
Q4 "Tôi dùng ai?"	outgoing usage	uses, references, depends_on, derived_from	E2 source_ref + E3 target_ref + E4 edge_type	Cap-4	universal_edges (SSOT)	(1) Edge types vocab có; (2) writer create edges on INSERT; (3) at least 1 edge per type populated cho TAC family
Q5 "Ai dùng tôi?"	reverse usage	reverse query của uses/references/depends_on	reverse-index	Cap-4	reverse-index sinh từ universal_edges	(1) Reverse-index pattern chọn; (2) reverse-index maintainer DOT logical chốt
Q6 "Tôi sinh từ đâu?"	provenance	derived_from (Candidate Đ44 §5.3.B)	E2 + E3 với edge_type=derived_from	Cap-4	universal_edges (SSOT)	(1) derived_from Candidate đăng ký vào vocab; (2) writer set on derivation event

Anti-pattern Living DB query (cấm):

• ❌ SELECT * FROM tac_publication_member WHERE unit_id = X → đây là helper, KHÔNG SSOT
• ❌ UNION 2 nguồn (universal_edges + tac_publication_member)
• ❌ LEFT JOIN fallback to helper khi universal_edges thiếu

Pattern đúng:

• ✅ SELECT * FROM universal_edges WHERE target_ref = X AND edge_type = 'contains'
• ✅ SELECT * FROM ue_reverse_index WHERE target_id = X (reverse-index sinh từ universal_edges)

12.2 Tier 1 PASS criteria — checklist 6 items

Tier 1 PASS ⟺ tất cả:

#	Item	Owner	Status
1	Edge_type vocab chốt (8 Core + 3 Candidate active)	Đ44 enacted + APR	Chờ Đ44 enacted
2	universal_edges minimum fields E1-E8 đầy đủ + valid in production	APR + implementation	Chờ APR
3	TAC family populate ≥ 1 edge mỗi loại Q2-Q6 (proof relation hoạt động)	TAC pipeline + DOT writer	Chờ Cap-4/5 active
4	DOT Cap-4/Cap-5 writer + checker đăng ký	P44-5 + Đ35	Chờ P44-5
5	Reverse-index pattern chọn (P1 chấp nhận pilot, P2/P3 sau scale)	P44-5 + pilot	Chờ P44-5
6	Provenance contract apply cho edge mới (post-Đ44)	Đ44 enacted + DOT writer	Chờ Đ44 enacted

12.3 Necessary vs sufficient

P44-4 chốt logical (necessary):

• Item 2 (E1-E8 fields)
• Item 5 (reverse-index responsibility logical)
• Item 6 (provenance contract logical)

Cần thêm cho sufficient (chờ):

• Item 1 (Đ44 enacted)
• Item 3 (TAC populate — execution)
• Item 4 (P44-5 chốt DOT)

→ P44-4 = necessary but not sufficient cho Tier 1. Cần P44-5 + Đ44 enacted + execution để sufficient.

---

§13. OPEN / Technical Debt phát sinh trong P44-4

13.1 OPEN items

ID	Item	Resolve khi
OPEN P44-4-α	Scheme namespace edge_type (prefix obj./sem. vs tag owner_layer vs cả hai)	APR khi chốt vocab framework universal_edges
OPEN P44-4-β	Reverse-index pattern (P1/P2/P3) chọn per scale tier	P44-5 + pilot volume measurement
OPEN P44-4-γ	OPEN P44-2-δ chốt cuối — P44-4A đề xuất default ruling = (c) Dual transitional (xem §7.7). User có thể accept default hoặc đề xuất thay thế qua APR. KHÔNG đẩy decision pháp lý cho User clarify Đ0-B §I-C.	Optional: User đồng thuận default; bắt buộc: APR khi enacted
OPEN P44-4-δ	TD-44-2 audit execute timing	User cho phép
OPEN P44-4-ε	Grace period default cho legacy edges retrofit	Đ44 Appendix A G6 + pilot
OPEN P44-4-ζ	Edge derived_from semantic giao Đ44/Đ39	Đ39 mature
OPEN P44-4-η	Lớp 4-6 (Material/Product/Building) composition_role + granularity_level vocab extension	Khi family Lớp 4-6 xuất hiện
OPEN P44-4-θ	Exception policy framework cho (a) Internal-only — apply cho family nào trong tương lai	Sau pilot Tier 1

13.2 Technical Debt

ID	Item	Ảnh hưởng	Resolve khi
TD P44-4-1	Edge type vocab framework anchor (Đ24 vocab system vs dot_config) — đồng vấn đề OPEN P38-X-11	Vocab edge_type + unit_kind + composition_role cùng phụ thuộc framework	Cross-cutting APR
TD P44-4-2	TAC edges trong universal_edges = 0 (P11A) — không có edge nào để Tier 1 PASS Item 3	TAC pipeline phải tạo edges	Sau Đ44 enacted + DOT Cap-4 active
TD P44-4-3	OPEN P44-2-δ default ruling = (c) Dual transitional (P44-4A §7.7) — tac_publication_member design có thể proceed với default; sunset path có 4 conditions explicit	Default applied; sunset re-evaluate mỗi 6 tháng
TD P44-4-4	TD-44-2 audit chưa execute → meta-conformance OQC-2 cho relation_edge còn conditional	Family registration cho relation_edge chưa final	User cho phép execute
TD P44-4-5	TD-44-3 retrofit chưa execute → 2199 legacy edges chưa có provenance đầy đủ	Audit chưa clean	Đ44 Appendix A G6
TD P44-4-6	Đ44 §5.1 strict vs flexible reading wording — cần clarify trong v1.0 enacted	Ảnh hưởng (b) vs (c) lựa chọn	Đ44 amend khi enacted

---

§14. Pre-conditions PASS + cầu nối P44-5

14.1 Pre-conditions PASS cho P44-4

#	Pre-condition	Đã đạt?
1	Reading list 5 nguồn GPT yêu cầu đã đọc	✅
2	Đ0-B v3.1 đầy đủ (GPT yêu cầu trước khi viết full)	✅
3	2 layer Đ44 §5 vs NĐ-36-01 tách namespace 5 chiều	✅ §2
4	Cảnh báo edge name clash (contradicts example)	✅ §2.2
5	8 Core + 3 Candidate edge types định nghĩa logical + reverse + family	✅ §3
6	Minimum logical fields E1-E8 + 8 invariants	✅ §4
7	Composition Cap-5 align Đ0-B 7 lớp + composition_role + CYCLE detection	✅ §5
8	Reverse-index responsibility logical + 3 patterns + DOT pattern	✅ §6
9	OPEN P44-2-δ phản biện 2 vòng + KHÔNG default (a) Internal-only	✅ §7
10	TD-44-2 audit plan logical (KHÔNG execute)	✅ §8
11	TD-44-3 retrofit 4 phase logical (KHÔNG migration script)	✅ §9
12	Edge Conformance Audit pattern 4 chiều + DOT responsibility + P44-5 handoff	✅ §10
13	Meta-conformance relation_edge family hypothetical	✅ §11
14	Tier 1 unblock criteria Living DB Q2-Q6	✅ §12
15	OPEN/TD ghi rõ ràng (8 OPEN + 6 TD)	✅ §13
16	Không DDL/code/migration script/tên DOT cụ thể/upload first draft	✅
17	6 guardrails GPT áp dụng nghiêm	✅ §1.2

14.2 P44-5 handoff scope

P44-4 chốt logical contract. P44-5 chốt realization:

Aspect	P44-4 chốt	P44-5 sẽ chốt
Edge type vocab	8 Core + 3 Candidate logical	Vocab framework anchor (Đ24 vs dot_config)
E1-E8 fields	Logical contract	Physical column names + storage format
Provenance	Logical structure	JSONB schema + storage format
DOT Cap-4 writer	Responsibility logical	Tên DOT, schedule, code/trigger
DOT Cap-4 checker	Responsibility logical	Tên DOT, schedule, audit query
DOT Cap-5 writer/checker	Responsibility logical	Tên DOT, schedule, code
Reverse-index	Pattern P1/P2/P3 logical + responsibility	Implementation chọn + materialized view DDL
Audit 4 chiều	Pattern logical	Audit query + escalation policy
Recursive audit	Terminal cap pattern (P38-XC)	Cap depth chính thức
Auto-fix policy	(chưa)	Đ22 self-healing extend cho edges

---

§15. AP-CLOSE

15.1 Đã làm trong P44-4A polish (S190 2026-05-02)

P44-4A polish 5 chỉnh sửa GPT (không rewrite lớn, giữ nguyên 14 sections nền):

1. §7.7 — Default ruling tự đề xuất (chỉnh sửa #1): P44-4 tự đề xuất default rule pháp lý cho Đ0-B §I-C ("ưu tiên enforcement layer, KHÔNG cho phép tạo SSOT riêng ngoài universal_edges"), KHÔNG đẩy decision về User clarify. OPEN P44-4-γ refactor: User có thể accept default hoặc đề xuất thay thế qua APR.
2. §7.7.2 + §12.1 — Siết "universal_edges là SSOT" (chỉnh sửa #2): ghi rõ tac_publication_member KHÔNG bao giờ là SSOT (kể cả Dual). Mọi truy vấn chuẩn Q2/Q3 phải đi qua universal_edges hoặc reverse-index sinh từ universal_edges. Anti-pattern Living DB query liệt kê (UNION 2 nguồn, fallback to helper — cấm).
3. §7.7.3 — Anti-drift invariant 2 chiều (chỉnh sửa #3): thêm INV-DUAL-1/2/3/4 (FK→universal_edges, universal_edges→FK, drift detection bắt buộc, transaction atomicity). Không có invariant này, Dual trượt thành 2 nguồn thật → vi phạm NS-1.
4. §7.7.4 — Sunset path 4 conditions explicit (chỉnh sửa #4): 4 trigger conditions C1-C4 cụ thể (FK enforcement / performance helper / DOT stability / migration benchmark) + 2 exit paths E1/E2 + audit định kỳ 6 tháng + APR cấp medium decision.
5. §6.3 — Siết P1 reverse-index (chỉnh sửa #5): P1 chỉ chấp nhận pilot khi đồng thời (i) edge count nhỏ, (ii) có index/plan kiểm tra cơ bản, (iii) query frequency thấp. P1 KHÔNG default production dài hạn; bắt buộc xem xét P2/P3 khi scale tăng.

P44-4A final micro-fix (S190 2026-05-02) — 1 dòng:

• §15.4 dòng (v) sửa wording cũ "OPEN P44-2-δ chốt cuối (b) vs (c) | User clarify Đ0-B §I-C" → "OPEN P44-2-δ final enforcement path: default = (c) Dual transitional; final implementation path/sunset status sẽ được quyết qua APR khi Đ44 enacted và/hoặc sau benchmark." Đồng nhất với §7.7 default ruling.

Full draft P44-4 (S190 2026-05-02 trước polish) — 14 sections nền giữ nguyên, không rewrite:

1. Phân biệt 2 namespace Đ44 §5 vs NĐ-36-01 — 5 chiều tách + cảnh báo edge name clash (contradicts example) (§2).
2. Edge type vocab logical: 8 Core + 3 Candidate + extension policy + reverse + family (§3).
3. Minimum logical fields E1-E8 + 8 invariants + composite reference structure + provenance contract (§4).
4. Composition Cap-5 contract align Đ0-B 7 lớp + composition_role + granularity_level + CYCLE detection + cơ chế sống Đ0-B §IV map Living DB (§5).
5. Reverse-index responsibility logical + 3 patterns (P1/P2/P3) + DOT responsibility (§6).
6. Phản biện 2 vòng OPEN P44-2-δ + 6 dimensions analysis + insight Đ0-B §I-C structural vs functional (§7.1-7.6).
7. Exception policy framework cho (a) Internal-only — chỉ 5 conditions strict, hiện không family nào thoả (§7.8).
8. TD-44-2 audit plan logical 6 step + tiêu chí PASS/FAIL/PARTIAL + defer execute (§8).
9. TD-44-3 retrofit 4 phase logical (§9).
10. Edge Conformance Audit pattern 4 chiều (A1-A4) + DOT responsibility + P44-5 handoff explicit (§10).
11. Meta-conformance hypothetical relation_edge family (§11).
12. Tier 1 unblock criteria Living DB Q2-Q6 (§12).
13. 8 OPEN + 6 TD phát sinh (§13).
14. Pre-conditions PASS + P44-5 handoff scope (§14).

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

Aspect	Status
NT4 cấm hardcode	✅ edge_type vocab extensible, không enum cứng; namespace tag config-driven
NT9 vĩnh viễn vs tạm	✅ §7.8 exception policy framework rõ; (c) Dual có sunset path explicit
NT11 khai tối thiểu	✅ E5/E6 default values; provenance auto từ context
NT12 DOT pairing	✅ Cap-4/Cap-5 writer + checker pair (§10.2)
NT13 PG-anchored	✅ universal_edges là PG-anchored SSOT
NT14 thực thi được ngay	✅ Tier 1 PASS criteria 6 items đo được
Đ44 NS-1 SSOT	✅ universal_edges là SSOT cho Object edges; FK = enforcement, không source of truth
Đ44 §5.1 universal_edges	✅ tuân + clarify "SSOT cho query/audit", FK enforcement có thể đồng tồn tại transitional
Đ44 §5.4 provenance	✅ post-Đ44 mandatory; legacy retrofit policy
Đ0-B §I-C FK/M2M priority	✅ phương án (c) Dual giữ FK enforcement + universal_edges SSOT
Đ0-B §IV cơ chế sống	✅ map trực tiếp Living DB Q2-Q5 + CYCLE detection + depth ≤ 4
Đ0-B 6 cấp + Lớp 0	✅ composition_role atomic/molecular/composite map Lớp 1/2/3
NĐ-36-01 ranh giới sở hữu	✅ §2.1 + §2.3 không xâm phạm scope NĐ-36-01
LSL-01 v0.4 P7 NĐ-36-01 owner	✅
Công thức soạn prompt OR	✅ outline → review → full draft (đang đây) → review → polish → upload
5-GATE OR	✅ G1 đọc luật đủ (Đ44 §5, Đ0-B, NĐ-36-01); G2 không cần count cho logical; G3 đối chiếu Đ44/Đ0-B/NĐ-36-01/P38-XC; G4 namespace chuẩn; G5 không sa đà — phép thử §1.3
6 guardrails GPT	✅ áp dụng nghiêm — §1.2

→ Không phát hiện xung đột với Hiến pháp + luật + 6 guardrails GPT.

15.3 Chưa làm (cố tình — kỷ luật scope)

• ❌ Không patch Đ44, NĐ-36-01, Đ0-B, P44-1/2/3, P38-XC.
• ❌ Không thiết kế NĐ-36-01 entity_relations chi tiết (NĐ-36-01 đã ban hành Phần 1, Phần 5 chưa soạn).
• ❌ Không thiết kế Đ39 KG semantic edges (defer Đ39 mature).
• ❌ Không DDL, không code, không migration script, không mutate production, không tạo edge entries.
• ❌ Không tên DOT cụ thể (P44-5).
• ❌ Không execute TD-44-2 audit (defer prompt agent riêng).
• ❌ Không execute TD-44-3 retrofit (defer Đ44 Appendix A G6).
• ❌ Không upload KB (chờ User + GPT review polish thành P44-4A).

15.4 P44-4 KHÔNG CHỐT (defer table)

#	Không chốt	Defer đến
(i)	Storage format E6 provenance JSONB structure	APR + implementation
(ii)	Physical column names cho universal_edges	APR
(iii)	DOT name + schedule + auto-fix policy + recursive cap	P44-5
(iv)	Reverse-index pattern (P1/P2/P3) chọn cuối	P44-5 + pilot volume
(v)	OPEN P44-2-δ final enforcement path: default = (c) Dual transitional; final implementation path/sunset status sẽ được quyết qua APR khi Đ44 enacted và/hoặc sau benchmark.	APR + benchmark
(vi)	Edge type vocab framework anchor	OPEN P38-X-11 + cross-cutting APR
(vii)	Exception policy framework cho (a) — chỉ logical, chưa apply	Sau pilot Tier 1
(viii)	TD-44-2 audit execute	User cho phép
(ix)	TD-44-3 retrofit execute	Đ44 Appendix A G6
(x)	Lớp 4-6 composition_role/granularity_level vocab extension	Khi family Lớp 4-6 xuất hiện
(xi)	Edge derived_from semantic giao Đ44/Đ39	Đ39 mature
(xii)	Đ44 §5.1 wording strict vs flexible — clarify	Đ44 v1.0 enacted amend

15.5 Sau khi User + GPT xác nhận P44-4A polish

Workflow (theo Q7 GPT trả lời + 5 chỉnh sửa polish đã apply):

1. User + GPT xác nhận P44-4A polish đủ điều kiện upload.
2. Upload KB vào path knowledge/dev/laws/dieu44-trien-khai/design/05-relation-edge-conformance-design.md.
3. KHÔNG tạo decision log ngay (default ruling §7.7 đã chốt logical, decision pháp lý thực sự sẽ qua APR khi Đ44 enacted).
4. Dừng P44-4.
5. Đề xuất bắt đầu P44-5 — Update Mechanism + DOT Contract Matrix realize.

Không upload trước khi User + GPT xác nhận P44-4A đủ điều kiện (theo guardrail 6 GPT).

---

P44-4A POLISH FINAL | S190 (2026-05-02) | Soạn: Opus 4.7 | Outline PASS S190 → Full draft S190 → P44-4A polish 5 chỉnh sửa GPT (default ruling tự đề xuất, siết SSOT, anti-drift invariant 2 chiều, sunset 4 conditions, P1 không default production) → P44-4A final micro-fix §15.4(v) đồng nhất default ruling | Authority: Đ44 v0.1.2 controlled DRAFT | Phụ thuộc: P44-0/1/2/3 + P38-XC final + Đ0-B v3.1 | Self-audit Hiến pháp + luật + 6 guardrails + 5 polish + 1 micro-fix: PASS, không phát hiện xung đột | Trạng thái: uploaded knowledge/dev/laws/dieu44-trien-khai/design/05-relation-edge-conformance-design.md