C1 — TEXT UNIT OPERATING MODEL

Design Note tiền-schema — Điều 38 Text as Code

Trạng thái: DỰ THẢO — GPT review vòng 2 PASS, chờ User duyệt Loại: Design note (operating model), KHÔNG phải schema Phase: P1 trong Design Phase (P1–P7) Inputs pháp lý: L1 (Text Unit Governance), L3 (Metadata Governance), L4 (Birth Gate Extension), L5 (Unit-level Review + Change-set) Soạn: Opus 4.6 Review: GPT vòng 1 (14 chỉnh + 4 khuyến nghị) → GPT vòng 2 PASS Ngày: 2026-04-25

1. Mục đích

Mô tả cách hệ thống vận hành text unit từ khi sinh ra đến khi retire — ai làm gì, khi nào, theo trình tự nào, kiểm tra gì, lỗi gì phải chặn. Đây là "bản mô tả nhà máy": nguyên liệu vào cửa nào, qua bao nhiêu trạm, ra thành phẩm ở đâu.

C1 đủ chi tiết để design phase sau (P5) có thể chuyển thành schema PG mà không cần hỏi lại "cái này nghĩa là gì". Nhưng C1 chưa phải schema — không có tên bảng, tên cột, SQL, trigger, hay DOT.

2. Phạm vi

2.1 Bao gồm

Document envelope: bao bì văn bản, chứa metadata tổng, sở hữu tập text units.
Logical text unit: danh tính logic, giữ canonical address, tồn tại xuyên suốt các version.
Unit version: bản nội dung cụ thể của logical unit tại một thời điểm.
Canonical address + section code: định danh kỹ thuật bất biến (gắn logical unit) + alias đọc hiểu.
Parent-child tree: cây cấu trúc dọc trong cùng document.
Horizontal relation: tham chiếu ngang giữa units bất kỳ (qua universal_edges).
Change-set: gom nhiều thay đổi, review theo unit, approve theo change-set qua APR Đ32.
Change-set snapshot + published snapshot: đóng băng bằng chứng + tập unit versions enacted.
Document version aggregate: document bump version khi change-set enacted.
Write path: tạo/sửa/retire unit.
Checker path: phát hiện lỗi cấu trúc.
Hot path vs cold path: ghi PG ngay vs enrichment async.

2.2 Không bao gồm

Component/BOM (thuộc C3).
Metadata schema cụ thể — tên cột, kiểu dữ liệu (thuộc P5).
SQL, trigger, function, DOT list (thuộc P5/P6).
Migration plan (thuộc P7).
Workflow engine, UI, KG/vector implementation.

3. Inputs pháp lý

Input	Lấy gì cho C1
L1 — Text Unit Governance	Định nghĩa text unit, document envelope, addressing, cây dọc, ref ngang, lifecycle, version, change-set, species, 9 nguyên tắc bắt buộc
L3 — Metadata Governance	Core metadata 4 nhóm + core-equivalent, profile 2 tầng, field responsibility 4 loại fill, 3 tầng kiểm tra (completeness/correctness/consistency), controlled vocabulary
L4 — Birth Gate Extension	Birth gate cho text_unit: 8 nhóm kiểm tra core, required profile, derived fields không kiểm tại birth, enforcement mode config-driven, legacy/grandfather
L5 — Unit-level Review + Change-set	Review gắn unit, change-set lifecycle (draft→submitted→review_passed→approval_passed→enacted), snapshot đóng băng, document approval aggregate, quorum Đ32

4. Object model concept

4.1 Document envelope

Bao bì của một văn bản quản trị. Chứa metadata tổng: tên, loại, version, lifecycle status, council score, owner. KHÔNG chứa nội dung chi tiết — nội dung sống trong unit versions.

Một document envelope sở hữu một tập logical text units. Mỗi logical unit biết mình thuộc document nào. Document envelope là "cái hộp", logical units là "các ngăn bên trong", unit versions là "các tờ giấy trong ngăn".

Trong giai đoạn hiện hành, document envelope có thể map/neo với normative_registry; thiết kế chi tiết xác định ở schema phase.

Lifecycle của document: Tuân thủ Đ4 — draft → enacted → superseded → retired. Document version bump khi change-set enacted/applied theo rule (xem §6.5).

4.2 Logical text unit vs unit version

Đây là phân biệt quan trọng nhất của C1.

4.2.1 Logical text unit (logical unit)

Danh tính logic của một đơn vị thông tin. Logical unit:

Giữ canonical address (bất biến, L1 §4.3).
Biết mình thuộc document nào.
Có vị trí trong cây parent-child.
Tồn tại xuyên suốt mọi version — logical unit là "cái ngăn", version là "tờ giấy được thay vào ngăn".

Nôm na: logical unit giống "địa chỉ nhà" — nhà có thể sửa, sơn lại, xây thêm tầng (= version mới), nhưng địa chỉ nhà không đổi.

4.2.2 Unit version

Bản nội dung cụ thể của logical unit tại một thời điểm. Unit version:

Có version identity riêng (tách biệt canonical address).
Chứa nội dung thực: body, title, metadata snapshot.
Có lifecycle riêng: draft → enacted → superseded → retired.
Enacted version = bất biến. Sửa = tạo version mới.

4.2.3 Quan hệ logical unit ↔ unit version

1 logical unit → nhiều unit versions (theo thời gian).
Tại bất kỳ thời điểm: tối đa 1 version enacted/current cho 1 logical unit.
Canonical address gắn với logical unit identity. Version mới giữ canonical address nhưng có version identity riêng.
Published snapshot chứa unit versions, không phải logical units trực tiếp (xem §4.10).

4.2.4 Sơ đồ quan hệ

Document envelope (VD: Đ38)
├── Logical unit A (address: D38-S1)
│   ├── Version A.1 (draft)
│   ├── Version A.2 (enacted/current) ← trong published snapshot
│   └── Version A.3 (superseded)
├── Logical unit B (address: D38-S2)
│   ├── Version B.1 (enacted/current) ← trong published snapshot
│   └── (chưa có version mới)
└── Logical unit C (address: D38-S3)
    └── Version C.1 (draft) ← KHÔNG trong published snapshot

Published snapshot = {Version A.2, Version B.1}

4.3 Canonical address

Định danh kỹ thuật duy nhất toàn hệ thống cho mỗi logical unit. Dạng: {doc_code}-{section_path} (VD: D43-S2-P2-1).

Đặc tính	Mô tả	Nguồn
Unique toàn hệ thống	Không 2 logical unit nào cùng address	L1 §3.4
Bất biến	Canonical address không đổi suốt vòng đời logical unit. Đổi nội dung = version mới, giữ address.	L1 §4.3
Gắn logical unit	Address gắn với logical unit identity, KHÔNG gắn với unit version.	GPT review #3
Có thể system-auto	Address có thể do system cấp tại birth path. Nếu system-auto cấp thì phải được cấp hoặc reserved trước commit theo rule thiết kế, tránh race condition.	L4 §4.2

4.4 Section code

Human-readable alias cho vị trí đọc hiểu (VD: §2.2.1). Section code có thể đổi theo render hoặc cấu trúc đọc — KHÔNG dùng làm định danh kỹ thuật.

Phân tách rõ: canonical address = kỹ thuật (bất biến, gắn logical unit), section code = hiển thị (có thể đổi).

4.5 Parent-child tree (cây cấu trúc dọc)

Logical units tổ chức theo cây parent-child trong cùng document.

Quy tắc	Mô tả	Nguồn
1 parent duy nhất	Cây thuần, không phải DAG	L1 §3.5
Cùng document	Parent phải cùng document. Không nhúng unit từ document khác vào cây.	L1 §3.5
Sort order	Thứ tự con xác định bởi sort_order	L1 §3.5
Xử lý khi retire parent	Retire parent → con phải được xử lý (cảnh báo hoặc cascade theo rule). Không tự cascade enacted children nếu chưa có rule/approval.	L1 §3.5, GPT review #8
Không giới hạn tầng	Thực tế Incomex: 4–6 tầng	L1 §3.5
1 canonical parent	Logical unit có thể xuất hiện trong nhiều rendered views, nhưng chỉ có 1 parent trong cây gốc	L1 §3.5

4.6 Horizontal relation (tham chiếu ngang)

Liên kết giữa units bất kỳ (có thể khác document) — quản bằng universal_edges, KHÔNG bằng parent-child pointer.

Quy tắc phân tách (L1 §3.6):

Quan hệ dọc (cấu trúc) KHÔNG chạy qua universal_edges.
Quan hệ ngang (ngữ nghĩa) KHÔNG dùng parent-child pointer.
2 kênh tách biệt, không trộn.

Ví dụ quan hệ ngang: "Đ38 §3 tham chiếu Đ4 §2", "SOP-001 unit 5 liên kết L1 §3.4".

4.7 Change-set

Container gom nhiều thay đổi ở nhiều unit versions, review chung, approve chung qua APR Đ32.

Đặc điểm (L5 §3.3):

Có scope rõ: liệt kê logical unit nào thay đổi, thay đổi gì (tạo version mới / sửa draft version / retire logical unit).
Có lifecycle riêng — TÁCH BIỆT APR lifecycle Đ32.
Có owner.
Thông thường gắn 1 document; cross-document change-set có thể xảy ra.
Phải self-contained: đọc change-set hiểu scope mà không truy ngoài luồng.

4.8 Change-set snapshot

Snapshot = tập object_id + version_id + diff/evidence tại thời điểm submit (L5 §3.4).

Vai trò: Bằng chứng đóng băng — reviewer và approver đánh giá trên snapshot, không phải trên object sống. Khi change-set submitted → snapshot đóng băng → không sửa lén. Sửa tiếp = withdraw/re-submit.

4.9 Published snapshot

Tập các unit versions enacted/current thuộc 1 document tại 1 thời điểm. Đây là "bản chính thức" của document — chỉ chứa enacted/current unit versions, không chứa draft versions.

Quy tắc (L5 §6.3): Document enacted chỉ bao gồm tập unit versions enacted/current thuộc published snapshot. Draft versions có thể tồn tại ngoài published snapshot, nhưng KHÔNG được lọt vào published snapshot. DOT kiểm điều này.

Lưu ý: Published snapshot chứa unit versions, không phải logical units trực tiếp. Mỗi logical unit có tối đa 1 version trong published snapshot (version enacted/current).

4.10 Split/merge unit

Split/merge unit là structural change lớn, không phải sửa version thường:

Split: 1 logical unit → 2+ logical units mới (mỗi cái có canonical address mới).
Merge: 2+ logical units → 1 logical unit mới (address mới hoặc giữ 1 trong các address cũ).

Split/merge phải qua change-set + APR. Không phải write path thông thường. Successor relation giữa address cũ và mới phải được ghi nhận.

5. Lifecycle model

5.1 Unit version lifecycle

Mỗi unit version tuân thủ Đ4:

draft → enacted → superseded → retired

Trạng thái	Mô tả	Chuyển khi nào
draft	Version mới tạo, chưa approve. Có thể sửa tại chỗ.	Mặc định tại birth
enacted	Đã approve qua change-set + APR. Bất biến.	Change-set enacted/applied
superseded	Version cũ bị thay thế bởi version mới enacted. Giữ lại cho audit.	Version mới enacted
retired	Logical unit không còn hiệu lực. Version cuối cùng chuyển retired. Giữ lại cho audit.	Quyết định retire logical unit qua change-set

Quy tắc chuyển trạng thái:

draft → enacted: chỉ khi version nằm trong change-set đã enacted/applied (L5 §5.2).
enacted → superseded: tự động khi version mới enacted cho cùng logical unit.
enacted → retired: qua change-set + APR (vì đây là thay đổi trạng thái enacted).
Không có đường ngược: enacted không quay lại draft. Sửa = version mới.

5.2 Logical unit lifecycle

Logical unit có trạng thái hiệu lực phái sinh từ version hiện hành:

Logical unit "active" = có ít nhất 1 version enacted/current.
Logical unit "retired" = version cuối cùng retired, không còn version enacted.
Logical unit "draft-only" = chỉ có draft versions, chưa bao giờ enacted.

Trạng thái logical unit có thể là derived (tính từ versions) hoặc explicit — quyết định cụ thể thuộc schema phase (OD).

5.3 Change-set lifecycle

Tách biệt APR lifecycle. Chi tiết theo L5 §5.2:

draft → submitted → review_passed → approval_passed → enacted/applied
                  ↘ rejected / withdrawn

Trạng thái	Mô tả
draft	Đang soạn. Unit versions có thể thay đổi. Chưa tạo APR.
submitted	Snapshot đóng băng. Tạo hoặc liên kết APR qua DOT theo Đ32.
review_passed	Tất cả units đã review pass (hoặc batch pass theo rule).
approval_passed	APR đã pass quorum Đ32. Chờ apply step.
enacted/applied	APR applied hoặc apply step thành công. Thay đổi chính thức. Unit versions → enacted. Document bump version theo rule.
rejected	APR bị reject. Có thể sửa và re-submit.
withdrawn	Owner rút trước khi approval hoàn tất.

5.4 Quan hệ change-set lifecycle ↔ APR lifecycle

Change-set lifecycle và APR lifecycle là 2 chuỗi trạng thái song song:

Change-set	APR (Đ32)	Ai trigger
draft	Chưa tạo APR	—
submitted	APR pending	System/DOT tạo APR khi submit
review_passed	APR pending (vẫn chờ quorum)	Reviewers cập nhật review state trên units
approval_passed	APR approved	Quorum đạt
enacted/applied	APR applied	Apply step thành công
rejected	APR rejected	Quorum reject
withdrawn	APR cancelled/withdrawn	Owner rút

Điểm mấu chốt: APR approved cho phép change-set chuyển approval_passed. APR applied hoặc apply step thành công mới cho phép change-set enacted/applied. Không nhảy từ approved thẳng sang enacted — phải qua apply step. APR vẫn tuân thủ Đ32 lifecycle riêng — L5/C1 không thay đổi cơ chế lõi APR.

5.5 Document lifecycle

Document envelope cũng tuân thủ Đ4: draft → enacted → superseded → retired. Document version bump system-driven theo rule khi change-set enacted/applied (xem §6.5).

5.6 Review state trên unit

Mỗi unit có review state riêng (metadata theo L3):

unreviewed → in_review → review_passed / review_failed → needs_re_review

Review state chuyển bởi reviewer (agent hoặc human). Review parent ≠ approve children — không cascade (L1 §4.6, L5 §4.3).

6. Write path

6.1 Tạo unit mới

Nôm na: Một người muốn thêm 1 đoạn mới vào văn bản → tạo 1 logical unit mới + 1 draft version đầu tiên.

Trình tự:

Agent/human xác định document đích và parent logical unit trong cây.
Chuẩn bị nội dung: body, title, section_type, owner, description + required profile fields.
Birth gate (L4): Hệ thống kiểm 8 nhóm core metadata:
- Canonical address (system-auto cấp hoặc agent cung cấp) — unique toàn hệ thống. Nếu system-auto cấp thì phải được cấp hoặc reserved trước commit theo rule thiết kế, tránh race condition.
- doc_code trỏ document envelope tồn tại + hợp lệ.
- Parent tồn tại + cùng document (nếu không phải root). Sort_order có giá trị.
- Content payload hợp lệ theo section_type.
- Section_type thuộc controlled vocabulary.
- Owner có giá trị.
- Description có giá trị.
- Lifecycle status = draft (system auto).
- Required profile fields có giá trị (theo config).
Enforcement: Birth gate pass → logical unit + draft version đầu tiên vào PG. Birth gate fail → block/warn/escalate theo config.
Draft version nằm ngoài published snapshot.
Hot path hoàn tất. Cold path (vector sync, KG enrichment) chạy async sau.

6.2 Sửa draft version

Nôm na: Sửa 1 đoạn đang nháp, chưa ai approve.

Trình tự:

Unit version phải ở status draft. Nếu enacted → xem §6.3.
Agent/human sửa nội dung (body, title, metadata).
Hệ thống kiểm integrity cơ bản: parent vẫn tồn tại + cùng document, canonical address không đổi, section_type hợp lệ.
Cập nhật PG. Derived fields (body_hash, tier) tính lại bởi system auto / DOT derive.
Review state có thể chuyển sang needs_re_review nếu đã từng review.

Đặc biệt: Sửa draft KHÔNG tạo version mới — draft version có thể sửa tại chỗ. Chỉ enacted version mới bất biến.

6.3 Sửa enacted unit (→ version mới)

Nôm na: Muốn sửa 1 đoạn đã được duyệt chính thức — phải tạo "bản nháp mới" trong cùng logical unit.

Trình tự:

Version hiện tại ở status enacted — bất biến, không sửa đè (L1 §4.2).
Agent/human tạo version mới của logical unit. Version mới:
- Giữ canonical address (vì address gắn logical unit, bất biến).
- Có version identity riêng.
- Status = draft.
- Kế thừa parent, sort_order (có thể thay đổi nếu cần).
Version mới phải qua birth/creation validation tương ứng (L4 §9.2).
Draft version mới nằm ngoài published snapshot.
Để version mới enacted → phải gom vào change-set → review → APR approve → apply step → enacted.
Khi version mới enacted → version cũ tự động chuyển sang superseded.

Lưu ý: Version mới giữ canonical address trong cùng logical unit hoặc successor relation theo rule. Không tạo canonical address mới trừ split/merge/structural change được change-set chấp thuận (xem §4.10).

6.4 Retire unit

Nôm na: Xóa bỏ hiệu lực 1 đoạn — không xóa khỏi PG, chỉ đánh dấu hết hiệu lực.

Trình tự:

Retire logical unit (có enacted version) = thay đổi trạng thái enacted → phải qua change-set + APR (L1 §4.2).
Agent/human tạo change-set ghi rõ: logical unit X retire.
Hệ thống kiểm: logical unit X có con không? Có ref ngang trỏ vào không? → Cảnh báo impact.
Không tự cascade enacted children. Nếu logical unit X có con đã enacted, phải có rule hoặc approval rõ ràng cho từng con: retire cascade, re-parent, hoặc giữ nguyên với cảnh báo. Không tự động cascade mà bỏ qua authority.
Change-set submit → snapshot → review → APR approve → apply → enacted.
Version enacted cuối cùng của logical unit chuyển sang retired. Logical unit trở thành retired.
Ref ngang trỏ vào logical unit retired → DOT daily phát hiện "ref gãy" (xem §7.2).

6.5 Document version bump

Nôm na: Khi 1 change-set được duyệt và applied, "cái hộp" (document) có thể tăng số version.

Document version bump = system-driven theo rule khi change-set enacted/applied (L5 §6.2).
Ví dụ mặc định: minor bump (sửa text, thêm section), major bump (thay đổi cấu trúc — thêm/xóa article, merge/split document). Phân loại = config, không chốt pháp lý ở C1.
Lưu ý: Metadata-only hoặc non-published change-set có thể không bump hoặc chỉ bump patch theo rule. Không phải mọi change-set đều bump document version.
Document version bump cập nhật published snapshot: thêm unit versions enacted mới, loại unit versions superseded/retired.

7. Checker path

Checker path = các kiểm tra DOT daily/event-driven để phát hiện lỗi cấu trúc + metadata. Thuộc tầng correctness + consistency (L3 §7.2, §7.3). Khác birth gate (birth gate = completeness tại INSERT, L4).

7.1 Parent sai document

Lỗi: Logical unit có parent trỏ tới logical unit thuộc document khác.

Phát hiện: DOT daily quét: so sánh document của unit vs document của parent. Không khớp → log issue.

Xử lý: Draft version → self-healing nếu rule cho phép (sửa parent hoặc escalate). Enacted version → escalate, không auto-fix nội dung (L3 §8.6).

7.2 Ref gãy (broken reference)

Lỗi: Quan hệ ngang (universal_edges) trỏ tới logical unit không tồn tại, hoặc logical unit đã retired/superseded mà không có version kế thừa.

Phát hiện: DOT daily/event-driven: quét edges, kiểm target tồn tại + status hợp lệ.

Xử lý: Log issue. Nhắc reviewer/owner xử lý. Nếu target superseded → gợi ý cập nhật ref theo successor/current version nếu rule cho phép và authority chấp thuận. Không mặc định auto-update ref. Nếu target retired → gợi ý xóa ref hoặc tìm thay thế.

7.3 Draft version lọt published snapshot

Lỗi: Published snapshot của document enacted chứa unit version ở status draft — vi phạm quy tắc "published snapshot chỉ chứa enacted/current unit versions" (L5 §6.3).

Phát hiện: DOT daily: quét published snapshot, kiểm tất cả unit versions trong snapshot có status enacted/current. Bất kỳ draft version → critical issue.

Xử lý: Escalate ngay. Đây là lỗi nghiêm trọng — published snapshot phải chỉ chứa enacted/current unit versions.

7.4 Address collision

Lỗi: 2 logical units trùng canonical address — vi phạm tính unique (L1 §3.4).

Phát hiện: Birth gate chặn tại INSERT (kiểm unique). DOT daily quét toàn bộ (phòng trường hợp race condition hoặc bypass).

Xử lý: Nếu phát hiện collision tồn tại → critical issue. Escalate. Không auto-fix — cần human quyết định logical unit nào giữ address.

7.5 Lifecycle mismatch

Lỗi: Trạng thái lifecycle không nhất quán giữa các object liên quan. Ví dụ:

Document enacted nhưng published snapshot chứa draft version.
Change-set enacted nhưng unit versions trong change-set vẫn draft.
Unit review_passed nhưng change-set rejected → cần re-review.
Unit version enacted nhưng document đã retired.

Phát hiện: DOT daily: cross-check status unit version ↔ document ↔ change-set.

Xử lý: Log issue. Draft objects → self-healing nếu rule cho phép. Enacted objects → escalate.

7.6 Duplicate enacted version cho cùng logical unit

Lỗi: Cùng 1 logical unit có 2+ versions ở status enacted/current trong cùng published snapshot — vi phạm quy tắc "tối đa 1 version enacted/current per logical unit" (§4.2.3).

Phát hiện: DOT daily: quét published snapshot, group by logical unit, kiểm mỗi logical unit chỉ có 1 version.

Xử lý: Critical issue. Escalate. Cần human quyết định version nào giữ.

7.7 Orphan draft version

Lỗi: Draft version tồn tại quá lâu (sau threshold) mà không thuộc change-set nào — có thể là draft bị quên.

Phát hiện: DOT daily/weekly: quét draft versions không thuộc change-set nào, kiểm thời gian tạo > threshold.

Xử lý: Warn (INFO level). Nhắc owner review/xóa/gom vào change-set. Không auto-delete.

8. Hot path vs cold path

8.1 Hot path — ghi PG ngay

Khi tạo/sửa/retire unit, những việc sau xảy ra ngay trong transaction PG (hoặc ngay sau commit):

Việc	Mô tả
Ghi nội dung	Body, title, metadata vào PG
Birth gate check	Kiểm completeness tại INSERT (L4)
Integrity check cơ bản	Parent tồn tại + cùng document, address unique, section_type hợp lệ
Status transition	draft → enacted (khi change-set enacted/applied), enacted → superseded
System-auto fields	Timestamps, lifecycle status mặc định, canonical address (nếu system cấp), body_hash

Về published snapshot update: Snapshot transition/update là PG-native critical path khi apply/enact change-set. Transaction boundary cụ thể thuộc schema/implementation phase — có thể cùng transaction hoặc tách transaction tùy thiết kế.

Nguyên tắc: Hot path = PG native. Latency budget cụ thể xác định ở schema/implementation phase. Mục tiêu: ghi xong, integrity đảm bảo, trước khi trả kết quả (L1 §4.9, QĐ5).

8.2 Cold path — enrichment async

Chạy sau hot path, không block transaction ghi:

Việc	Mô tả	Cơ chế
Vector sync	Đẩy unit version content sang Qdrant cho retrieval	PG NOTIFY → sync worker
KG enrichment	Gợi ý/cập nhật projection hoặc tạo proposed edges. Authoritative edges/bindings phải qua write path hợp pháp — KG enrichment KHÔNG tự sửa truth.	DOT event-driven hoặc scheduled
DOT daily checks	Correctness, consistency (§7)	Cron schedule
Derived metadata	Tier (tính từ cây), binding count, species count	DOT derive
Optional enrichment	Nhắc fill optional profile fields	DOT daily (INFO level)

Nguyên tắc: PG unit version = gốc (SSOT). Vector/Qdrant = projection phục vụ retrieval (L1 §4.7). Cold path fail → unit version vẫn tồn tại trong PG, chỉ thiếu enrichment. Retry/self-healing xử lý.

9. Invariants bắt buộc

Những quy tắc KHÔNG BAO GIỜ được vi phạm, bất kể hoàn cảnh:

#	Invariant	Nguồn
I1	PG unit là SSOT. Mọi nội dung văn bản quản trị sống trong PG dưới dạng unit versions. File/KB = backup.	L1 §4.1, HP NT1, NT13
I2	Enacted version = bất biến. Unit version đã enacted không sửa đè. Thay đổi = version mới + change-set + APR.	L1 §4.2, Đ4
I3	Canonical address bất biến, gắn logical unit. Address không đổi suốt vòng đời logical unit. Version mới giữ address, có version identity riêng.	L1 §4.3
I4	Cây dọc tách graph ngang. Parent-child = cấu trúc. Edges = ngữ nghĩa. Không trộn.	L1 §4.4
I5	Parent cùng document. Không nhúng unit từ document khác vào cây.	L1 §3.5
I6	Review gắn unit, không cascade. Review parent ≠ approve children.	L1 §4.6, L5 §4.1
I7	Mọi unit mới qua birth gate. Không đường tắt vào PG bỏ qua birth gate.	L4 §9.1
I8	Published snapshot chỉ chứa enacted/current unit versions. Draft version không lọt vào published snapshot. Mỗi logical unit tối đa 1 version trong published snapshot.	L5 §6.3
I9	Change-set submitted → snapshot đóng băng. Không sửa lén khi chờ approve.	L5 §5.3
I10	Mọi approval qua APR Đ32. Change-set approve qua APR pipeline. Agent không tự approve enacted content change.	L5 §10.3, §10.7
I11	Review result và APR decision không xóa/ghi đè. Re-review = cycle/record mới.	L5 §3.1
I12	Hot path PG, enrichment async. Ghi PG + integrity check trước. Vector/KG sau. KG enrichment không tự sửa truth.	L1 §4.9, QĐ5
I13	Controlled vocabulary cho classification. doc_type, section_type = FK config. Không free-form.	L3 §8.9
I14	Derived-first cho metadata cấu trúc. Tier, counts = tính từ data. Agent đề xuất, system/DOT xác nhận.	L3 §8.7, NT11

10. Open decisions — chuyển sang schema phase

Những quyết định chưa chốt ở C1, cần giải quyết khi thiết kế schema (P5) hoặc implementation (P6):

#	Open decision	Ghi chú	Risk ref
OD1	Tên trạng thái lifecycle enum cụ thể. C1 dùng "draft / enacted / superseded / retired" nhưng enum PG cần chuẩn hóa chính xác (có thể có trạng thái phụ).	Cần đối chiếu Đ4 enum hiện hành.	R1
OD2	Map change-set lifecycle ↔ APR lifecycle. C1 mô tả song song (§5.4) nhưng cơ chế trigger/event giữa 2 lifecycle + apply step cần chốt ở schema.	Điểm phức tạp nhất.	R2, R6
OD3	Profile fields cụ thể cho text_unit. C1 biết có required vs optional profile nhưng danh sách fields cụ thể = config data, seed ở P5.	Liên quan C2.	R3
OD4	Enforcement mode cụ thể per birth check. C1 biết block/warn/escalate nhưng check nào mode nào = config.	Cần matrix chi tiết.	R4
OD5	Review state enum cụ thể. C1 dùng "unreviewed / in_review / review_passed / review_failed / needs_re_review" — cần chuẩn hóa.	Có thể gộp/tách tùy implementation.	R7
OD6	Canonical address generation. System-auto hay agent cung cấp? Format chính xác? Reservation mechanism?	Ảnh hưởng birth path + race condition.	—
OD7	Cross-document change-set handling. C1 thừa nhận có thể xảy ra nhưng cơ chế chi tiết (multi-document version bump, authority) cần chốt.	Edge case quan trọng.	—
OD8	Version numbering scheme. Semantic (major.minor.patch) hay sequential? Document vs unit?	Ảnh hưởng version bump rule.	R6
OD9	Retire cascade policy. Retire parent → con retire cascade hay re-parent? Config hay cứng? Enacted children cần rule/approval riêng.	Ảnh hưởng checker + write path.	—
OD10	Latency budget cho hot path. Bao nhiêu ms cho birth gate + integrity check trong transaction?	Performance constraint.	—
OD11	Snapshot storage model. Snapshot = copy data hay reference (object_id + version_id)?	Storage vs query tradeoff.	—
OD12	Logical unit vs unit version storage model. 1 bảng (unit + version cùng row) hay 2 bảng (logical unit riêng, version riêng)? Đây là open decision quan trọng nhất trước P5.	Ảnh hưởng toàn bộ schema design.	—

11. Ranh giới — C1 không làm gì

Không làm	Lý do
Không viết SQL	Schema thuộc P5
Không chốt tên bảng/cột	Schema thuộc P5
Không viết trigger/function	Implementation thuộc P5/P6
Không viết DOT list/config	Implementation thuộc P6
Không viết migration plan	Thuộc P7
Không định nghĩa component/BOM	Thuộc C3
Không chốt metadata schema cụ thể	Thuộc C2 + P5
Không chốt workflow engine/UI	Ngoài scope
Không chốt KG/vector implementation	Cold path concept only, implementation thuộc riêng
Không thay đổi Đ32 APR lõi	L5 đã clarify, C1 chỉ mô tả interaction
Không thay đổi Đ0-G lõi	L4 đã mở rộng scope, C1 chỉ mô tả birth flow

12. Điều kiện PASS

#	Điều kiện
1	C1 phân biệt rõ logical unit, unit version và published snapshot membership. Logical unit = danh tính + address. Unit version = nội dung + lifecycle. Published snapshot = tập unit versions.
2	Object model (§4) nhất quán với L1 định nghĩa: document envelope, logical unit, unit version, addressing, cây dọc, ref ngang, change-set, snapshot
3	Lifecycle model (§5) nhất quán với Đ4 + L5: unit version lifecycle, change-set lifecycle, map change-set ↔ APR (bao gồm apply step)
4	Write path (§6) cover 4 thao tác: tạo mới, sửa draft, sửa enacted (→ version mới), retire — mỗi thao tác bám đúng L1/L4/L5
5	Checker path (§7) cover 7 loại lỗi: parent sai document, ref gãy, draft lọt published snapshot, address collision, lifecycle mismatch, duplicate enacted version, orphan draft
6	Hot/cold path (§8) nhất quán với QĐ5 + L1 §4.9: ghi PG trước, enrichment async sau. KG enrichment không tự sửa truth.
7	Invariants (§9) trích xuất đúng từ L1/L3/L4/L5, không thêm invariant tự sáng tác
8	Open decisions (§10) cover 7 rủi ro design (R1–R7) + OD12 (logical unit vs unit version storage model)
9	Không trượt sang SQL/tên bảng/cột/trigger/DOT/migration
10	Không mâu thuẫn với L1, L3, L4, L5, Đ4, Đ0-G, Đ32, Đ33, Đ39, HP
11	Đủ chi tiết để P5 (schema draft) có thể bắt tay mà không cần hỏi lại "cái này nghĩa là gì"
12	GPT review PASS + User duyệt