P44-1 — Family Registry Design

Trạng thái: P44-1A polish PASS, uploaded | Phiên: S190 (2026-05-01) Authority: Đ44 v0.1.2 controlled DRAFT (chưa enacted) — §4 (Object Family Registry) + §9.5 (Conformance Clause) Path: knowledge/dev/laws/dieu44-trien-khai/design/01-family-registry-design.md Phụ thuộc: P44-0 README rev 1 Review: GPT-5.5 PASS với 4+2 polish (P44-1A) — GPT review path

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

Family Registry là logical capability bắt buộc theo Đ44 §4.1 — chưa chốt tên bảng vật lý.
Chứa 8 field logic tối thiểu: family_code, family_name, owner_law_code, owner_agency_code, schema_profile_binding, maturity_level, status, timestamps.
Quy trình đăng ký family mới: APR cấp high (Đ32) + Đ44 Conformance Clause C1–C5 (§9.5) + SCMR entry (§3.4) — 3 cửa song song, thiếu 1 = reject.
Family seed audit 11 family từ §4.2 Đ44: phân loại hợp pháp / provisional / OPEN sau đối chiếu P11A.
Meta-conformance: Family Registry tự nó là 1 object-family (family_code = 'object_family') phải tự conform Đ44 — proof ở P44-1 là hypothetical, full check khi physical hoá qua APR.

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

1.1 Family Registry để làm gì

Vai trò	Diễn giải
Sổ hộ khẩu object family	Mọi family được phép tồn tại trong Incomex phải có entry ở Family Registry. Không có entry = không hợp pháp (NS-1 + NS-4).
Liên kết family ↔ luật chuyên môn	Mỗi family có `owner_law_code` (FK normative_registry) → Đ38, Đ39, Đ24, … là người quản nội dung/nghiệp vụ; Đ44 chỉ quản schema logic chung.
Liên kết family ↔ tổ chức quản trị	Mỗi family có `owner_agency_code` (FK Đ37) → cơ quan nào duyệt amendment, ai nhận escalation.
Cổng vào cho APR	Đăng ký family mới phải qua APR cấp high (Đ32). Family Registry là entity nhận entry sau APR PASS.
Anchor cho SCMR + Profile Registry	SCMR (P44-2) tham chiếu `family_code`. Profile Registry (P44-3) tham chiếu `family_code`. Nếu Family Registry chưa stable → SCMR + Profile redo.
Anchor cho `governed_by` edge	Edge type Candidate `governed_by` (§5.3.B Đ44) trỏ object → family/law/agency. Family Registry là 1 đầu của edge này.

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

P44-1 LÀM:

Định nghĩa logical schema khung Family Registry (8 field).
Định nghĩa quy trình đăng ký family (workflow, không code).
Đối chiếu family seed §4.2 Đ44 với P11A → phân loại.
Đề xuất resolve OP-A + OP-B trong decision log.
Meta-conformance hypothetical proof.

P44-1 KHÔNG LÀM (cố tình, để tránh sa đà):

❌ KHÔNG định nghĩa SCMR — đó là P44-2. Nói "family phải có SCMR entry" thì OK, nhưng KHÔNG nói SCMR có field gì.
❌ KHÔNG thiết kế Profile Registry — đó là P44-3. Field schema_profile_binding chỉ define logical, không quyết physical.
❌ KHÔNG định nghĩa Relation Edge — đó là P44-4. Nói governed_by edge tồn tại thì OK, không thiết kế cấu trúc edge.
❌ KHÔNG thiết kế Update Mechanism — đó là P44-5.
❌ KHÔNG DDL, code, migration, mutate production.
❌ KHÔNG chốt tên bảng vật lý — Đ44 §4.1 nói "chốt qua APR".

Phép thử nhanh: nếu trong khi đọc P44-1 anh thấy nó đang định nghĩa cấu trúc của SCMR / Profile / Edge / Mechanism — đó là lỗi sa đà. Báo lại.

§2. Logical schema khung Family Registry

2.1 8 field logic tối thiểu

Đây là logical contract, không phải DDL. Tên field là logical name, không phải tên cột PG. Tên bảng cứng chốt qua APR.

#	Logical field	Cardinality	Kiểu logical	Ràng buộc	Tham chiếu
F1	`family_code`	1..1	identifier (snake_case, ≤ 64 chars)	PK, unique, immutable	Đ44 §4.1
F2	`family_name`	1..1	localized text (vi + en)	not null, mutable	L3 §4.1 pattern
F3	`owner_law_code`	1..1	FK reference	FK → normative_registry, format `NRM-LAW-XX`	Đ44 §4.1, normative_registry
F4	`owner_agency_code`	0..1	FK reference	FK → Đ37 agency entity, 0..1 vì TD-44-? OP-B chưa resolve cho TAC	Đ37, OP-B
F5	`schema_profile_binding`	0..1	binding to profile schema (logical, abstract)	có ràng buộc khi family yêu cầu profile	Đ44 §4.1 ("config, không code")
F6	`maturity_level`	1..1	enum {M0, M1, M2, M3, M4}	not null, default M0, provisional cho đến khi audit	Đ44 §6.C
F7	`status`	1..1	enum {proposed, active, deprecated, retired}	not null, default `proposed`	L3 lifecycle pattern
F8	`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

F1 — `family_code`

Identifier ổn định, immutable. Nếu cần đổi, phải tạo family mới + supersede (edge supersedes).
Format snake_case, ≤ 64 chars — match L3 vocab pattern + dễ đọc + an toàn cho mọi physical encoding.
Ví dụ hợp lệ: information_unit, document, vector_projection, dot_checker, object_family (meta).
Cấm: prefix luật (d44_information_unit ❌); identifier chứa version (information_unit_v2 ❌ — version đi kèm status + supersedes).

F2 — `family_name`

Tên hiển thị bằng tiếng Việt + tiếng Anh (Đ43 NT2 multi-language). Localized text (JSONB {vi: "...", en: "..."}) là pattern HP đã dùng.
Mutable (đổi tên hiển thị không phá identity).
Ví dụ: {vi: "Miếng thông tin", en: "Information Unit"}.

F3 — `owner_law_code`

FK chính sang normative_registry (đã verify format NRM-LAW-XX).
1 family bắt buộc có 1 owner law. Không có = vi phạm Đ44 §0.2 ("Đ44 quản schema logic chung; nội dung/nghiệp vụ thuộc luật chuyên môn").
Family information_unit → owner_law_code = NRM-LAW-38.
Family vector_projection → owner_law_code = NRM-LAW-39.
Family dot_checker → owner_law_code = NRM-LAW-35.
Family object_family (meta) → owner_law_code = NRM-LAW-44.

OPEN P44-1-α: Đ38 version conflict (TD-44-1 trong Đ44 §11.5) chưa resolve. Family information_unit ghi owner_law_code = NRM-LAW-38 nhưng version v2.3 (HP) hay v3.0 (file) là user decision. Defer — không block P44-1.

F4 — `owner_agency_code`

FK sang Đ37 agency entity.
Cardinality 0..1 (không 1..1) vì OP-B của Đ44: TAC family chưa có agency rõ. Nếu đặt 1..1 thì family information_unit không thể đăng ký được — block production. Đặt 0..1 + DOT cặp nhắc agency TBD / unassigned = thoả Đ44 §9.1 "Optional Enrichment".
Hiện tại Đ37 v3.3 có 5 agency. Đối chiếu nhanh:

Family	Agency có thể owner (đề xuất, chưa chốt)	Lý do
`information_unit`, `document`, `publication`	Architecture Council (tạm) hoặc Legal/Compliance Directorate (chưa có trong Đ37)	TAC pipeline thuộc legal governance; Đ37 hiện chưa có Legal directorate riêng → tạm Architecture Council, defer Legal
`vector_projection`, `knowledge_node`	Knowledge Graph Council	Đ37 đã có "Knowledge Graph" agency (theo seed search)
`dot_checker`	Architecture Council	Đ37 owner Đ35
`workflow`	Operations System (theo TD-GOV-MORE-AGENCIES seed)	Phù hợp BPMN
`species`, `label_rule`	Architecture Council	Đ24, Đ29 đều cross-cutting

OPEN P44-1-β (resolve OP-B Đ44): tạm dùng Architecture Council cho TAC family + DOT nhắc thiếu owner_agency riêng. Đề xuất feedback Đ37: cần thêm Legal/Compliance Directorate (agency thứ 6) để chuyển TAC sang. Đề xuất này không patch trực tiếp Đ37 — phải qua amendment process Đ37 (ngoài scope folder này).

F5 — `schema_profile_binding`

Tên logical trung lập về implementation. Field này khai rằng "family này có một binding tới schema profile" — KHÔNG quy định binding đó được physical hoá thế nào.

Cách physical hoá binding — FK đến Profile Registry, inline JSONB snapshot, hoặc hybrid (FK + JSONB cache) — sẽ do P44-3 Profile Registry Design quyết định, không chốt ở P44-1.

3 cách physical hoá khả dĩ (chỉ liệt kê, không chốt)

Cách	Mô tả ngắn	Phù hợp khi
(a) FK ref	`schema_profile_binding` → entry trong Profile Registry (P44-3)	Profile schema reuse được giữa families; cần version hoá độc lập
(b) Inline JSONB	`schema_profile_binding` chứa toàn bộ profile schema dưới dạng config JSONB	Family Registry tự đứng được; profile đơn giản, ít reuse
(c) Hybrid	FK ref là source of truth + inline snapshot JSONB cho audit/cache	Cần cả reuse + audit fast

Đ44 §4.1 wording hiện tại ("profile field schema — config, không code") không cấm cả 3 cách — đây là implementation choice thực sự, không phải logical choice.

OPEN P44-1-γ: Defer chốt cách physical hoá sang P44-3. P44-1 chỉ định nghĩa logical field schema_profile_binding ở mức cardinality 0..1, kiểu trừu tượng "binding to profile schema". Đủ cho khung Family Registry không bị block.

F6 — `maturity_level`

Đ44 §6.C định nghĩa M0..M4. Đ44 nói rõ là "provisional" cho đến khi audit per-family riêng.
P44-1 chỉ chứa field này; audit per-family không thuộc scope P44-1.
Default M0 cho family mới đăng ký.
OP-G (threshold M3/M4) — defer post-pilot.

F7 — `status`

Lifecycle ≥ 2 state (thoả OQC-2). Default proposed.
Transition: proposed → active (sau APR PASS). active → deprecated (khi có family kế thừa qua supersedes). deprecated → retired (sau grace period).
L3 đã có pattern này — không reinvent.

F8 — Audit timestamps

NT11 + Đ44 G12 — PG tự suy ra (DEFAULT NOW(), trigger), agent KHÔNG khai.

2.3 Logical constraints + invariants

ID	Invariant	Kiểm bằng
INV-1	`family_code` unique toàn hệ thống	DB constraint (UNIQUE)
INV-2	`owner_law_code` phải tồn tại trong normative_registry	FK
INV-3	`owner_agency_code` (nếu có) phải tồn tại trong Đ37 agency	FK
INV-4	`status = active` ⇒ phải có SCMR entry tương ứng (P44-2)	DOT cặp Schema Conformance Audit
INV-5	`maturity_level ≥ M2` ⇒ phải có DOT cặp NT12 đăng ký	DOT audit, ref Đ44 §9.2
INV-6	`family_code = 'object_family'` (meta) phải tồn tại + self-reference	Init seed, Đ44 NS-1 (SSOT)

Các invariant chỉ là logical. Cách enforce (CHECK, trigger, DOT) chốt khi physical hoá qua APR.

§3. Quy trình đăng ký family mới

3.1 Pre-conditions — 3 cửa song song, thiếu 1 = reject

Đây là enforcement Đ44 §4.1 + §9.5:

Cửa	Yêu cầu	Tham chiếu
Cửa 1: APR cấp high	Family đăng ký phải qua APR (Đ32) cấp high	Đ44 §4.1
Cửa 2: Đ44 Conformance Clause C1–C5	Design doc family phải có mục "Đ44 Conformance" thoả 5 yêu cầu	Đ44 §9.5
Cửa 3: SCMR entry	Physical implementation (nếu có) phải có entry trong SCMR	Đ44 §3.4

Logic 3 cửa:

Cửa 1 + Cửa 2 = bắt buộc trước khi status = active.
Cửa 3 = bắt buộc sau khi physical hoá. Family ở trạng thái proposed chưa physical thì Cửa 3 chưa apply.

3.2 Workflow đăng ký family (logical, không code)

[Step 0] Đề xuất family
  ├─ Người đề xuất chuẩn bị design doc family
  └─ Design doc PHẢI có mục "Đ44 Conformance" (C1–C5)

[Step 1] Pre-screen (logical, không code)
  ├─ Check OQC: family có thoả ≥ 3/4 OQC không? (Đ44 §2.2)
  ├─ Check trùng: family_code đã tồn tại?
  └─ Check normative_registry: owner_law_code có hợp lệ?

[Step 2] APR cấp high (Đ32)
  ├─ Council review design doc + Đ44 Conformance C1–C5
  ├─ Council vote
  └─ PASS → entry insert với status = proposed

[Step 3] Physical hoá (sau Đ44 ENACTED)
  ├─ APR design phase chốt physical schema
  ├─ Implementation tạo SCMR entry (P44-2)
  └─ DOT cặp NT12 đăng ký

[Step 4] Activation
  ├─ Verify SCMR entry tồn tại + valid
  ├─ Verify DOT cặp active
  └─ Transition status: proposed → active

3.3 Audit + amend family

Hành động	Cơ chế	Tham chiếu
Sửa `family_name`	Update trực tiếp (không phá identity)	F2 mutable
Sửa `owner_law_code`	APR cấp high (đổi luật quản = thay đổi authority)	Đ32
Sửa `owner_agency_code`	APR cấp medium (đổi agency = thay reporting line, không đổi pháp lý)	Đ32
Sửa `schema_profile_binding`	APR cấp medium + version bump profile	P44-3 sẽ chốt cách physical hoá
Promote `maturity_level`	Audit per-family + DOT proof + APR cấp medium	Đ44 §6.C
Deprecate family	APR cấp high + tạo family kế thừa + edge `supersedes`	§5.3.A Đ44
Retire family	Sau grace period (≥ 1 năm) + verify không còn object thuộc family	TBD post-pilot

§4. Family seed audit

4.1 Đối chiếu §4.2 Đ44 với P11A production state

⚠️ PROPOSED CONTROLLED-DRAFT SEED — bảng dưới đây là đề xuất audit ban đầu, đối chiếu §4.2 Đ44 (bản thân §4.2 cũng là illustrative) với P11A. CHƯA phải legal/active registry seed. Registry seed hợp pháp chỉ tồn tại sau: (1) Đ44 ENACTED v1.0; (2) Family Registry physical hoá qua APR; (3) Mỗi entry vào registry qua APR cấp high + Đ44 Conformance C1–C5 + SCMR entry. Mọi family code, owner_law_code, maturity_level dưới đây là provisional, không ép cưỡng chế Agent / Production.

11 family illustrative trong §4.2 Đ44, cộng thêm object_family (meta) = 12. Audit phân loại:

family_code	owner_law_code	Maturity provisional	P11A evidence	Phân loại P44-1	OPEN
`information_unit`	NRM-LAW-38	M2	TAC core 14 tables enacted, 86 units, 3 publications	Provisional	OP-B owner_agency, OP P44-1-α version
`document` / `publication`	NRM-LAW-38	M2	3 publications in tac_publication	Provisional	OP-B
`component`	NRM-LAW-38 (L2)	M0	L2 design only, no physical	OPEN	E gap
`relation_edge` ★	NRM-LAW-NĐ-36-01	needs audit	universal_edges 2199 rows, OQC-2 lifecycle ≥ 2 state cần verify	OPEN — TD-44-2	TD-44-2
`knowledge_node`	NRM-LAW-39	M1	Đ39 design enacted, no physical proof	OPEN	D/E
`vector_projection`	NRM-LAW-39	M0–M1	tac_unit_version.vector_sync_* tracking columns có, Qdrant config chưa trong PG	Provisional	D
`workflow`	NRM-LAW-34	M0	engine chưa active, DB workflow rỗng	OPEN	E
`dot_checker`	NRM-LAW-35	M2–M3	Đ35 v5.2 enacted, 28 checks 17s end-to-end	Provisional	drift checker per-family OPEN
`collection`	NRM-LAW-36	M2	Đ36 v4.0 enacted, 17 health checks	Provisional	self-healing pattern dùng được
`label_rule`	NRM-LAW-24	M2	Đ24 v1.0 enacted, 6 facets × 6 layers	Provisional	populate gap, OP-A borderline
`species`	NRM-LAW-29	M2	Đ29 enacted, 33 species, 7 dimensions	Provisional	M3 self-healing chưa proven
`object_family` (meta)	NRM-LAW-44	M0	Family Registry chưa physical	Provisional (meta)	Bootstrap problem — xem §5

4.2 Phân loại 3 mức

Mức	Tiêu chí	Family thuộc mức
Provisional	Có physical schema + ≥ 1 evidence trong P11A	8: information_unit, document/publication, vector_projection, dot_checker, collection, label_rule, species, object_family (meta)
OPEN	Không có physical schema HOẶC TD nghiêm trọng chưa resolve	4: component (E), relation_edge (TD-44-2), knowledge_node (D/E), workflow (E)

Tỷ lệ: 8/12 (67%) đã có ground để pre-screen ngay khi Đ44 enacted. 4/12 (33%) cần audit thêm.

4.3 Quan sát + cảnh báo

Không có family nào ở trạng thái active trong logical Family Registry — vì Đ44 chưa enacted. Tất cả là proposed hoặc provisional. Đây là đúng — không phải lỗi.
relation_edge lifecycle audit là blocker thực tế — nếu universal_edges không có ≥ 2 state (TD-44-2), thì relation_edge không qua được OQC-2 → không phải Object → không thuộc Đ44 → có thể phải amend Đ44 §4.2 seed list.
component là M0 nhất quán M2 láng giềng — nếu không có pilot L2 sớm, component family sẽ stuck. Đây là feedback Đ44 §11.4 candidate (đề xuất amend seed list).
Bootstrap problem với object_family (meta) — Family Registry chưa physical, nhưng entry object_family phải là entry đầu tiên trong Family Registry. Giải quyết qua init seed khi physical hoá (§5.4).

§5. Meta-conformance check

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

Có. Family Registry là entity chứa các object family — nhưng bản thân Family Registry, khi physical hoá thành 1 bảng PG, là 1 object family với family_code = 'object_family'.

→ Đây là self-reference: bảng Family Registry chứa entry với family_code = 'object_family' trỏ về chính nó (qua FK). Pattern hợp lệ trong relational design.

5.2 OQC check (Đ44 §2.2)

OQC	Family Registry thoả?	Lý do
OQC-1 Persistent Identity	✅	Mỗi entry có `family_code` PK ổn định, không tái sử dụng
OQC-2 Lifecycle ≥ 2 state	✅	F7 `status` = {proposed, active, deprecated, retired} = 4 state
OQC-3 Governance Subject	✅	Đ44 quản (owner law NRM-LAW-44), APR cấp high duyệt amend
OQC-4 Has Relations	✅	Liên kết `owner_law_code` → normative_registry; `owner_agency_code` → Đ37; `governed_by` edge từ object → family

→ 4/4 OQC. Family Registry thoả điều kiện trở thành object-family.

5.3 G1–G12 mapping (logical, hypothetical)

⚠️ Đây là hypothetical proof vì Family Registry chưa physical. Full conformance check phải đợi APR khi enacted.

G	Group	Family Registry có	Status
G1	Identity	F1 `family_code` (canonical address = family_code)	A
G2	Type & Family	self-reference: `family_code = 'object_family'`	A
G3	Lifecycle & Version	F7 `status`, version qua `supersedes` edge	A
G4	Owner & Authority	F3 `owner_law_code = NRM-LAW-44`, F4 owner_agency = Architecture Council (đề xuất)	A
G5	Source & Provenance	(chưa apply — Family Registry không có "source" externally)	N/A
G6	Content / Profile	F5 `schema_profile_binding` (cách physical hoá chốt ở P44-3)	OPEN
G7	Relation	edge `governed_by` (Candidate) ra; edge `contains` (Core) tới objects của family	C (cần SCMR + edge populate)
G8	Usage / Used-by	reverse query	C
G9	Compatibility / BOM	(không apply — Family Registry không phải vật thể có BOM)	N/A
G10	Vector / KG Projection	(không apply ngay; có thể project sang KG later)	N/A (now), OPEN (future)
G11	Checker / DOT Status	DOT cặp Schema Conformance Audit (Đ44 §9.3) — sẽ apply	OPEN — ref P44-5
G12	Timestamps & Audit	F8 timestamps + audit	A

Tổng: 6 A + 1 OPEN (G6 phụ thuộc P44-3) + 2 N/A + 3 cần apply post-physical (G7/G8/G11). Family Registry passes meta-conformance hypothetical với điều kiện P44-3 + P44-5 PASS.

5.4 Bootstrap solution — entry đầu tiên

Vấn đề: entry object_family phải tồn tại trong Family Registry trước khi family khác có thể đăng ký (vì F2 owner_law_code FK đòi NRM-LAW-44 đã ở normative_registry, F4 owner_agency_code FK đòi Đ37 ổn định, INV-6 đòi family_code = 'object_family' phải tồn tại).

Giải pháp (logical, sẽ chốt qua APR):

Init seed cho Family Registry tại physical creation: insert ngay 1 row family_code = 'object_family'.
Sau đó các family khác mới đăng ký được.

OPEN P44-1-δ: bootstrap order phụ thuộc thứ tự physical hoá normative_registry vs Đ37 vs Family Registry. Defer sang APR design phase.

§6. Decision log OPEN items

6.1 OP-A — OQC borderline (vocab row / label rule / registry entry)

Câu hỏi gốc (Đ44 §2.3): vocab row, label rule, registry entry là Object hay Config?

Phân tích

Đ44 §2.3 đã list:

Object: thoả ≥ 3/4 OQC
Config: thoả ≤ 2/4 OQC + có owner

Borderline cases — áp 4 OQC vào 3 ví dụ:

Ví dụ	OQC-1 Identity	OQC-2 Lifecycle ≥ 2 state	OQC-3 Governance Subject	OQC-4 Has Relations	Tổng	Phân loại đề xuất
vocab row (vd: `lifecycle_status_vocab`)	✅ (PK ổn định)	❌ (vocab thường active/deprecated nhưng nhiều khi chỉ active)	⚠️ (Đ24 quản)	❌ (vocab dùng làm value, không liên kết object khác)	1.5/4	Config
label rule (vd: facet rule)	✅	✅ (active/deprecated)	✅ (Đ24 quản, có owner)	✅ (rule áp lên object → relation)	4/4	Object (family `label_rule`)
registry entry chung (vd: dot_config row)	✅	❌ thường (1 state)	⚠️ (registry-level)	❌ thường	1.5/4	Config

Đề xuất Opus

Phân loại theo bảng trên:

vocab row → Config, ngoài Đ44.
label rule → Object (family label_rule, đã trong seed §4.2 Đ44 với owner Đ24).
registry entry chung → Config, ngoài Đ44 (trừ khi entry đó tự nó là Object — vd entry trong Family Registry là Object meta).

Quy tắc nhận diện chung: nếu entry/row có lifecycle ≥ 2 state riêng (active/deprecated, draft/published, …) VÀ có quan hệ outgoing/incoming → Object. Nếu chỉ là cặp key-value tĩnh → Config.

OP-A status: đề xuất đầu tiên, chờ User chốt. Nếu User PASS, ghi vào decision log + propose feedback Đ44 §11.4 (amend §2.3 thêm bảng OQC-borderline reference).

6.2 OP-B — owner_agency cho TAC family

Câu hỏi gốc (Đ44 §3.3 + §11.5): TAC family có owner_agency là cơ quan nào?

Phân tích

Đ37 v3.3 hiện có 5 agency (theo TD-GOV-MORE-AGENCIES seed):

Architecture Council
Knowledge Graph Council
Operations System
(?)
(?)

Không có agency riêng cho Legal/Compliance — trong khi TAC pipeline (text-as-content cho luật pháp) thuộc legal governance.

3 phương án

#	Phương án	Ưu	Nhược
A	Tạm dùng Architecture Council cho TAC family	Không block, có agency	Architecture Council không phải chuyên môn pháp lý → governance lệch
B	Để `owner_agency_code` ở trạng thái `TBD / unassigned` (cardinality 0..1) + DOT nhắc	Trung thực, không lệch	Family thiếu authority cho amendment cho đến khi resolve
C	Đề xuất feedback Đ37: thêm Legal/Compliance Directorate (agency thứ 6)	Đúng chuyên môn	Phải qua amendment Đ37 — ngoài scope folder Đ44

Đề xuất Opus

Phương án kết hợp B + C:

Trong P44-1: F4 owner_agency_code cardinality 0..1, TAC family ở trạng thái TBD / unassigned owner_agency until Đ37 owner-agency được resolve.
DOT cặp Schema Conformance Audit (P44-5) nhắc TAC family thiếu owner_agency — INFO không block (Đ44 §9.1 Optional Enrichment).
Decision log riêng (sau khi User chốt): feedback Đ37 đề xuất thêm Legal/Compliance Directorate. Không patch Đ37 trong folder Đ44.

Phương án A bị tôi không khuyến nghị vì governance lệch — tạm dùng dễ thành vĩnh viễn (NT9 "vĩnh viễn hay tạm").

OP-B status: đề xuất đầu tiên (B+C), chờ User chốt.

6.3 OP-A + OP-B → cách ghi nhận

Trong P44-1 (artifact này): OP-A và OP-B là proposed resolution — đề xuất của Opus, chưa phải decision đã chốt. Ghi trong §6.1 và §6.2.

Trình tự đúng để chốt:

Upload P44-1 (artifact này) vào KB.
User chốt OP-A + OP-B (sau khi review).
Sau khi User chốt, mới tạo:
- decisions/op-a-oqc-borderline-2026-05-01.md — ghi resolution OP-A đã chốt.
- decisions/op-b-tac-owner-agency-2026-05-01.md — ghi resolution OP-B đã chốt + propose feedback Đ37 amend.
Không sửa Đ44 trực tiếp (NT9). Khi Đ44 enacted v1.0, gom các decision này vào v1.1 amend qua §11.4.

Cấm: tạo decision log trước khi User chốt = ghi sai trạng thái (ghi đã chốt khi mới đề xuất).

§7. OPEN / Technical Debt phát sinh trong P44-1

ID	Item	Ảnh hưởng	Resolve khi
OPEN P44-1-α	Đ38 version conflict (TD-44-1 Đ44) ảnh hưởng `owner_law_code` cho TAC family	Family `information_unit` ghi NRM-LAW-38 nhưng version chưa rõ	User decision riêng (TD-44-1)
OPEN P44-1-β	OP-B TAC owner_agency — đề xuất B+C, chờ User chốt	Family `information_unit` cardinality F4 ở trạng thái `TBD / unassigned`	User chốt phương án + propose Đ37 amend
OPEN P44-1-γ	F5 `schema_profile_binding` — cách physical hoá (FK / JSONB / hybrid) chốt ở P44-3	Field F5 logical name OK, physical chưa final	P44-3 chốt khung Profile Registry
OPEN P44-1-δ	Bootstrap order Family Registry vs normative_registry vs Đ37	Init seed sequence	APR design phase khi enacted
OPEN P44-1-ε	`relation_edge` lifecycle audit (TD-44-2) — nếu fail OQC-2, family này phải remove khỏi seed	Seed §4.2 Đ44 có thể cần amend	P44-4 audit universal_edges
TD P44-1-1	OP-A đề xuất xong, chờ User chốt → propose feedback Đ44 §11.4 amend §2.3	Đ44 amend candidate	User PASS OP-A
TD P44-1-2	OP-B propose Đ37 amend (Legal/Compliance Directorate) — ngoài scope folder	Đ37 amend candidate	Đ37 amendment process

§8. Pre-conditions PASS + cầu nối P44-2

8.1 Để P44-1 PASS

#	Pre-condition	Đã đạt?
1	8 logical field tối thiểu định nghĩa rõ	✅ (§2)
2	Quy trình đăng ký family mới (3 cửa + 4 step) định nghĩa rõ	✅ (§3)
3	Family seed audit 12 family + phân loại	✅ (§4)
4	Meta-conformance hypothetical proof (4/4 OQC + G1-G12)	✅ (§5)
5	Decision log OP-A + OP-B đề xuất	✅ (§6)
6	Không DDL, không code, không physical name cứng	✅
7	Không sa đà sang SCMR / Profile / Edge / Mechanism	✅ (kiểm §1.2 ranh giới)
8	OPEN/TD ghi rõ ràng	✅ (§7)

8.2 Cần User/GPT chốt

#	Quyết định	Đề xuất Opus	Block P44-2?
Q1	OP-A: vocab/registry = Config, label rule = Object	PASS đề xuất	Không block (P44-2 không cần OP-A)
Q2 OP-B	F4 cardinality 0..1, TAC owner_agency `TBD / unassigned`, propose Đ37 amend	Không
Q3 F5	F5 `schema_profile_binding` — physical implementation defer P44-3	Không
Q4	Family seed phân loại (8 provisional + 4 OPEN)	PASS phân loại	Không block

→ Không có quyết định nào block P44-2. Sau khi P44-1 PASS, P44-2 (SCMR Design) có thể bắt đầu.

8.3 Cầu nối P44-2

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

family_code ổn định (8 family provisional có thể map SCMR ngay; 4 family OPEN defer).
owner_law_code + owner_agency_code (cardinality 0..1) → SCMR có thể tham chiếu khi audit.
Quy trình 3 cửa → SCMR là 1 trong 3 cửa (Cửa 3) → P44-2 phải mô tả Cửa 3 chi tiết.
Meta-conformance pattern → P44-2 sẽ làm meta-conformance cho SCMR tự nó.

→ Cầu nối rõ ràng. P44-2 sẵn sàng bắt đầu sau khi P44-1 PASS.

§9. AP-CLOSE

9.1 Đã làm trong P44-1

Định nghĩa logical schema khung Family Registry: 8 field (F1–F8) + 6 invariant (INV-1..6), không tên bảng vật lý, không DDL.
Định nghĩa quy trình đăng ký family mới: 3 cửa song song + 4 step workflow + 7 audit/amend action.
Audit 12 family seed (11 từ §4.2 Đ44 + 1 meta object_family): 8 provisional, 4 OPEN.
Meta-conformance check Family Registry: 4/4 OQC PASS + G1-G12 hypothetical mapping (6 A + 1 OPEN + 2 N/A + 3 cần post-physical).
Decision log OP-A (vocab=Config, label_rule=Object, registry entry=Config trừ meta) + OP-B (cardinality 0..1 + propose Đ37 amend).
Liệt kê 5 OPEN + 2 TD phát sinh trong P44-1.
Cầu nối rõ ràng tới P44-2 — không có decision nào block.

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

❌ Không định nghĩa SCMR (P44-2).
❌ 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 table name.
❌ Không tạo decision log OP-A/OP-B (chờ User chốt riêng sau upload).
❌ Không sang P44-2.

9.3 Cần User + GPT review

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

Q1 — OP-A: PASS đề xuất Config/Object?
Q2 — OP-B: PASS B+C (TBD/unassigned + propose Đ37)?
Q3 — F5: PASS defer cách physical hoá sang P44-3?
Q4 — Family seed phân loại: PASS 8 provisional + 4 OPEN?
Q5 — Path upload: knowledge/dev/laws/dieu44-trien-khai/design/01-family-registry-design.md đúng chưa?

9.4 Sau khi PASS

Upload artifact thành KB doc tại path Q5.
Không tạo decision log OP-A/OP-B ngay lúc upload — vì OP-A/OP-B vẫn là proposed resolution, chưa phải decision đã chốt.
Sau khi User chốt OP-A + OP-B (riêng, sau upload), mới tạo 2 decision log files trong decisions/.
Dừng P44-1.
Đề xuất bắt đầu P44-2 — SCMR Design.

P44-1 DRAFT — P44-1A polish | S190 (2026-05-01) | Soạn: Opus 4.7 | Polish: 4 sửa theo GPT review (1) field F5 → schema_profile_binding, (2) "NULL tạm" → "TBD/unassigned", (3) decision log chỉ tạo sau User chốt, (4) family seed marked PROPOSED CONTROLLED-DRAFT | + 2 sửa sót §8.2 Q2 + Q3 (P44-1A round 2) | Authority: Đ44 v0.1.2 controlled DRAFT (chưa cưỡng chế) | Phụ thuộc: P44-0 README rev 1 | Trạng thái: uploaded

P44-1 — Family Registry Design

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

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

1.1 Family Registry để làm gì

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

§2. Logical schema khung Family Registry

2.1 8 field logic tối thiểu

2.2 Field-by-field rationale

F1 — family_code

F2 — family_name

F3 — owner_law_code

F4 — owner_agency_code

F5 — schema_profile_binding

3 cách physical hoá khả dĩ (chỉ liệt kê, không chốt)

F6 — maturity_level

F7 — status

F8 — Audit timestamps

2.3 Logical constraints + invariants

§3. Quy trình đăng ký family mới

3.1 Pre-conditions — 3 cửa song song, thiếu 1 = reject

3.2 Workflow đăng ký family (logical, không code)

3.3 Audit + amend family

§4. Family seed audit

4.1 Đối chiếu §4.2 Đ44 với P11A production state

4.2 Phân loại 3 mức

4.3 Quan sát + cảnh báo

§5. Meta-conformance check

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

5.2 OQC check (Đ44 §2.2)

5.3 G1–G12 mapping (logical, hypothetical)

5.4 Bootstrap solution — entry đầu tiên

§6. Decision log OPEN items

6.1 OP-A — OQC borderline (vocab row / label rule / registry entry)

Phân tích

Đề xuất Opus

6.2 OP-B — owner_agency cho TAC family

Phân tích

3 phương án

Đề xuất Opus

6.3 OP-A + OP-B → cách ghi nhận

§7. OPEN / Technical Debt phát sinh trong P44-1

§8. Pre-conditions PASS + cầu nối P44-2

8.1 Để P44-1 PASS

8.2 Cần User/GPT chốt

8.3 Cầu nối P44-2

§9. AP-CLOSE

9.1 Đã làm trong P44-1

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

9.3 Cần User + GPT review

9.4 Sau khi PASS

F1 — `family_code`

F2 — `family_name`

F3 — `owner_law_code`

F4 — `owner_agency_code`

F5 — `schema_profile_binding`

F6 — `maturity_level`

F7 — `status`