C1A — Segmentation Operating Model

Loại: Design note tiền-schema — Điều 38 Text as Code Phase: P2b (Design Phase), tiếp nối C1 (Text Unit) và C2 (Metadata Governance) Trạng thái: DRAFT rev 5 — GPT PASS pending User duyệt Ngày soạn: 2026-04-26 | Phiên: S180 Agent soạn: Opus 4.6 (Desktop) GPT review: vòng 1 (8 patches) → vòng 2 (2 micro-patches) → vòng 3 (1 citation patch) → PASS

1. Mục đích & phạm vi

1.1 Mục đích

C1A trả lời một câu hỏi duy nhất: "Agent cắt tài liệu thành miếng thông tin theo quy tắc gì?"

Cụ thể, C1A mô tả:

Thế nào là một miếng thông tin (logical unit).
Quy tắc cắt chung và quy tắc cho từng loại nội dung đặc thù.
Cách gắn nhãn phân loại (tương thích Đ24).
Cách quản lý độ dài (length management).
Cách lắp ráp bản công bố (publication assembly).
Cách chiếu vector (vector projection) trong khuôn khổ unit_version.
Quyền hạn Agent trong segmentation và projection.

1.2 Phạm vi

Trong phạm vi: Segmentation rules, label assignment, length management, publication assembly, vector projection, agent authority — ở mức design note tiền-schema, đủ chi tiết để P5 schema draft dùng C1A làm input.

Ngoài phạm vi: Schema SQL, tên bảng/cột, trigger, function, DOT, migration, component/BOM (C3), KG runtime, aggregate retrieval implementation.

1.3 Vị trí trong hệ thống tài liệu

C1A cùng cấp C1 và C2 — là design note tiền-schema cho Điều 38. C1 mô tả object model (miếng là gì, sống thế nào). C2 mô tả metadata governance (miếng mang metadata gì, ai quản lý). C1A mô tả segmentation operations (cắt miếng thế nào, xếp miếng ra sao).

2. Inputs pháp lý và thiết kế

#	Tài liệu	Lấy gì cho C1A
1	LSL-01 v0.3 — Doctrine "Miếng thông tin làm trung tâm"	§4 định nghĩa miếng, §6 ba lớp, §8 canonical address, §9 vector projection, §10 agent authority, §11 length rule, §18 NL1–NL4
2	LSL-01 v0.4 — 10 patches	P3 label Đ24, P4 KHO/NÃO, P5 publication Đ38, P8 thuật ngữ, P9 address ≠ structural, P10 DOT mềm
3	Pilot mock (S179) — 24 logical units, 3 tài liệu	Dữ liệu thực tế, edge cases, 6 OD-PILOT, bài học cắt
4	Pilot Review Report (S180) — APPROVE-WITH-MINOR	6 OD-PILOT recommendations, 16 implications, 4 edge cases bổ sung
5	GPT review pilot + GPT review prompt C1A	5 điểm harden bắt buộc, 6 điểm chỉnh prompt
6	C1 — Text Unit Operating Model	Object model, lifecycle, write path, checker path, 14 invariants (I1–I14)
7	C2 — Metadata Governance Operating Model	Core metadata, profile model, field responsibility, validation matrix, controlled vocabulary, 14 invariants (M1–M14)
8	Đ24 — Label Law v1.3	6 facets, taxonomy 3 tầng, entity_labels junction, label_rules, FAC-PROV
9	Đ33 — PG Law v2.1	4 DB, 3 lớp NÃO-KHO-CỔNG, Content = Directus/Lớp KHO, Vector = Qdrant/Lớp NÃO
10	Đ32 — APR (qua C1 §5.4 + LSL-01 §10.2)	Risk tier, approval lifecycle, quorum, change-set

3. Định nghĩa vận hành của miếng thông tin

3.1 Định nghĩa (§4 LSL-01 nguyên văn)

"Miếng thông tin là một ý có title rõ và có thể sửa/review tương đối độc lập."

3.2 Bộ kiểm tra 3 câu

Mỗi đoạn nội dung phải trả lời 3 câu:

Title rõ? — Có thể đặt 1 tên mô tả ý chính mà không cần đọc nội dung không?
Sửa riêng được? — Sửa đoạn này có bắt buộc phải sửa đoạn khác không? Nếu không → tách được.
Không quá khó sửa? — Đoạn có quá dài/phức tạp khiến reviewer phải đọc hết mới hiểu context không? Nếu quá khó → xem xét split thêm.

3.3 Phân biệt 4 khái niệm cốt lõi

Khái niệm	Là gì	Không phải	Ví dụ
Miếng thông tin (logical unit)	Đơn vị nội dung nhỏ nhất có title rõ, sửa riêng được	Không phải document, không phải chunk, không phải publication	"§4 Nguyên tắc thiết kế" trong Đ43
Phiên bản miếng (unit version)	Nội dung cụ thể của miếng tại 1 thời điểm	Không phải miếng (miếng có nhiều version)	v1.0 draft → v1.0 enacted → v1.1 draft
Vector chunk	Mảnh text nhỏ embed vào Qdrant để tìm kiếm	Không phải miếng (chunk là projection, không có authority)	1 đoạn 300 từ từ unit version, mang metadata kế thừa
Publication	Bản công bố gộp nhiều miếng thành tài liệu hoàn chỉnh	Không chứa content inline, chỉ chứa references đến unit versions	PUB-D43-v1.2 gồm 8 units enacted

3.4 Bốn nguyên tắc lõi (NL1–NL4, §18 LSL-01 nguyên văn)

NL1 — Unit-Centric. Miếng thông tin là trung tâm. Mọi thứ khác (label, publication, vector) chạy theo nó.
NL2 — Semantic Unit Rule. Cắt khi: title rõ + sửa được riêng + không quá khó sửa.
NL3 — Risk-tiered Authority. Agent finalize được cho draft/internal/knowledge low-risk theo policy + audit + qua birth gate hợp pháp. Law/policy/constitution chỉ propose, cần approval. Owner không tự hạ risk của high/highest.
NL4 — Length as Trigger. Độ dài không cắt; chỉ cảnh báo. Hard limit: draft không block, publish/enact phải có decision (split / re-segment / exception approved). Cấm A/B/C cơ học.

4. Segmentation rules — quy tắc cắt chung

SR-1: Mỗi section có title rõ và sửa riêng được → 1 logical unit

Rule: Nếu một section/paragraph có thể đặt title mô tả ý chính, và sửa nó không bắt buộc sửa section khác, thì nó là 1 logical unit.

Rationale: Đây là áp dụng trực tiếp §4 LSL-01 (NL2 Semantic Unit Rule). Title rõ = addressable. Sửa riêng = independent.

Ví dụ (pilot): Đ43 §3–§4 (Nguyên tắc thiết kế) — có title rõ "Nguyên tắc", sửa nguyên tắc không nhất thiết sửa schema → 1 unit.

SR-2: Không đặt được title rõ → là mảnh của unit cha

Rule: Nếu một đoạn text không thể đặt title mô tả ý chính mà không trùng/chồng lấp title unit cha, thì nó là body text của unit cha, không phải unit riêng.

Rationale: Title rõ là điều kiện cần (§4 LSL-01). Không có title = không có identity = không addressable.

Ví dụ (pilot): Một câu dẫn nhập "Dưới đây là chi tiết..." giữa hai section — không có title riêng, là body text.

SR-3: Sửa A luôn kéo theo sửa B → gộp thành 1 unit

Rule: Nếu hai section có quan hệ sửa liên đới bắt buộc (sửa A mà không sửa B sẽ gây mâu thuẫn logic), thì gộp thành 1 unit.

Rationale: Sửa riêng được là điều kiện cần (§4 LSL-01). Liên đới bắt buộc = không sửa riêng được = không nên tách.

Ví dụ (pilot): Đ43 §1 mục tiêu + §2 phạm vi — scope gắn chặt mục tiêu, sửa scope thường phải cập nhật mục tiêu. Pilot gộp hợp lý.

SR-4: Section quá ngắn và không có authority → gộp

Rule: Nếu section <50 từ, không có authority/governance role (không phải heading luật, không phải definition, không phải principle), thì gộp vào unit cha hoặc sibling gần nhất.

Rationale: Tránh fragmentation không cần thiết. Miếng quá nhỏ mất ngữ cảnh, tạo noise trong tìm kiếm.

Ví dụ: Một paragraph 2 câu "Xem thêm §X" hoặc "Ghi chú: áp dụng từ S180" — gộp vào unit chứa nó.

SR-5: Cắt theo nghĩa, không cắt cơ học

Rule: Không bao giờ cắt theo token count, số ký tự, số câu, hay bất kỳ metric cơ học nào. Cắt theo semantic boundary (nơi ý thay đổi, nơi chủ đề chuyển, nơi sửa riêng được).

Rationale: §11.1 LSL-01 (NL4) — length rule là trigger review, không phải lệnh cắt. Cắt cơ học phá nghĩa, tạo miếng vô nghĩa.

Ví dụ: Một bảng 2000 từ nhưng là 1 ý liền mạch (truth table, comparison matrix) → KHÔNG cắt đôi dù vượt threshold.

SR-6: Title phải mô tả ý, cấm A/B/C cơ học

Rule: Tên unit phải mô tả nội dung: "Nguyên tắc thiết kế context pack", không phải "§5 Part A" hay "Schema phần 1/2". Cấm đặt tên cơ học (§11.3 LSL-01).

Rationale: Tên cơ học không addressable — "Part A" không cho biết nội dung gì. Agent khác đọc tên phải hiểu ý mà không cần mở unit.

Ví dụ sai: "LU-D43-005-A: Schema phần trên" — không cho biết phần trên chứa gì.

Ví dụ đúng: "Context trigger sources — object definition" — rõ nội dung.

SR-7: Mỗi unit có đúng 1 canonical parent trong structural tree

Rule: Mỗi logical unit thuộc đúng 1 unit cha trong canonical structural tree. ROOT unit là gốc cây canonical. Không có unit mồ côi (không parent), không có unit 2 parent. Canonical structural tree độc lập với publication — publication có thể xếp units theo render_order khác mà không ảnh hưởng canonical parent.

Rationale: C1 I4 (cây dọc tách graph ngang), C1 I5 (parent cùng scope). Cây canonical quyết định identity (address generation), publication quyết định trình bày (render order).

Ví dụ: Đ43 ROOT → LU-D43-001 (metadata), LU-D43-002 (rationale), ... Mỗi unit có đúng 1 canonical parent = ROOT. Nếu publication xếp LU-D43-002 trước LU-D43-001, canonical parent không đổi.

5. Edge-case rules — quy tắc cho nội dung đặc thù

5.1 OD-PILOT-01: Code/config block

Proposed rule: Code block, config example, SQL snippet, YAML mẫu — MẶC ĐỊNH là body của unit cha. Chỉ nâng thành unit riêng nếu: (a) được tham chiếu độc lập bởi ≥2 nơi khác trong hệ thống, HOẶC (b) có lifecycle riêng (version independently so với unit cha), HOẶC (c) có thể test/reuse riêng.

Rationale: Code block thường gắn chặt ngữ cảnh unit cha. Tách ra mất ngữ cảnh, reviewer phải đọc 2 nơi. Nhưng code library, shared config, reusable template cần lifecycle riêng.

Exception: Code block là unit riêng khi đáp ứng ≥1 trong 3 điều kiện (a), (b), (c). Ghi rõ lý do trong unit metadata. Default + exception đều hợp pháp — C1A không biến default thành luật cứng loại trừ exception.

Open question: Threshold "tham chiếu ≥2 nơi" có phải cứng không? Có case nào tham chiếu 1 nơi nhưng vẫn cần tách? → Chuyển P5.

5.2 OD-PILOT-02: Heading-only section

Proposed rule: Heading-only section (heading có text nhưng không có body paragraph) ĐƯỢC là logical unit NẾU heading có authority/governance role: heading luật (tên điều, tên article), changelog header, definition header. KHÔNG ĐƯỢC nếu heading chỉ là navigation/render hint.

Rationale: Heading luật là "địa chỉ pháp lý" — xóa heading = xóa cả cây con. Heading navigation chỉ là render hint, không có identity.

Exception: Heading navigation dùng làm parent grouping (structural role) mà không có content riêng → structural node, không phải content unit. Cách xử lý tùy P5 schema.

Open question: Structural node không có content có cần unit_version không? → Chuyển P5.

5.3 OD-PILOT-03: Mission block / instruction block SOP

Proposed rule: Mission block (khối lệnh copy/paste cho agent), instruction block (khối hướng dẫn chi tiết cho operator) — GIỮ ATOMIC dù có thể dài. section_type = instruction_block.

Rationale: UX yêu cầu copy nguyên khối. Sửa mission block phải sửa nguyên khối vì constraints gắn chặt mục tiêu. Tách sẽ phá UX và consistency nội bộ. Exception hợp pháp theo §11.4 LSL-01.

Exception: Nếu mission block >3000 từ VÀ có thể chia thành ≥2 mission con độc lập (mỗi mission con tự chạy được) → split thành 2+ instruction_block units. Nhưng không cắt cơ học giữa chừng.

5.4 OD-PILOT-04: section_type vocabulary mapping

Proposed rule: section_type là controlled vocabulary field/value trên logical unit. C1A đề xuất candidate values (Mục 6). Đăng ký chính thức qua C2 §8 + Council duyệt. Mock section_type trong pilot KHÔNG phải chính thức.

Rationale: P3 v0.4 — label phải tương thích Đ24. Tự tạo registry song song = vi phạm.

Exception: Không có exception — vocabulary phải đi qua quy trình đăng ký.

5.5 OD-PILOT-05: Hard-limit matrix/table

Proposed rule: Khi matrix/table vượt hard-limit, MẶC ĐỊNH semantic split theo dimension chính (mỗi object family/category/tầng thành 1 unit). Exception khi matrix PHẢI đọc nguyên khối để hiểu (truth table, comparison where tách mất nghĩa) → xin length exception, Council approve per-case.

Rationale: Matrix thường có dimension rõ (rows = object families, columns = attributes). Mỗi row family sửa riêng được, title rõ → đáp ứng §4 LSL-01.

Exception: Matrix so sánh (A vs B vs C) mà tách A riêng mất so sánh → giữ nguyên + length exception.

Open question: Threshold "phải đọc nguyên khối" ai quyết? Reviewer hay Owner? → Đề xuất: Owner quyết, reviewer có quyền phản biện.

5.6 OD-PILOT-06: C2 field responsibility matrix

Proposed rule: Split theo object family. Mỗi object family (Document, Logical unit, Unit version, Component, Relation, Change-set, Published snapshot) có thể thành 1 unit.

Rationale: Mỗi object family sửa riêng được (thêm field cho Component không ảnh hưởng Document), title rõ ("Field responsibility — Document").

Exception: Nếu matrix có ≤3 object families VÀ tổng <500 từ → giữ nguyên 1 unit.

5.7 Edge cases bổ sung

Table/list trong tài liệu: Default là body của unit cha. Nâng thành unit riêng chỉ khi table/list (a) có title riêng mô tả ý độc lập, VÀ (b) sửa riêng được. Ví dụ: bảng "Danh sách facets Đ24" trong giới thiệu → body. Bảng "Field responsibility matrix" chiếm cả section → unit riêng.

Changelog: Luôn là unit riêng, section_type = changelog. Changelog sửa riêng (thêm entry mới), title rõ ("Changelog Đ43"), lifecycle gắn với document nhưng nội dung độc lập.

Bootstrap/appendix multi-step: Threshold heuristic (không phải luật cứng): ≤5 bước cho phép giữ 1 unit. 6–15 bước: xem xét split theo cụm chức năng (prepare/execute/verify). >15 bước: bắt buộc split. Agent có thể đề xuất khác nếu có rationale.

Crosswalk/reference mapping: section_type reference_mapping cho bảng crosswalk thuần (mapping A→B). section_type governance_process cho quy trình có hành động. Phân biệt: bảng chỉ tra cứu → reference_mapping; bảng mô tả "ai làm gì khi nào" → governance_process.

Tail sections (cuối tài liệu): Mỗi ý cuối tài liệu vẫn phải qua 3 câu kiểm tra. Không gộp "vì gần cuối". Ví dụ: self-healing, invariants, open decisions ở cuối C2 — mỗi cái là unit riêng vì title rõ, sửa riêng được.

Heading luật (tên điều, tên article): Heading là unit nếu heading có authority. "Điều 43" = heading có authority → unit. "§5" chỉ là numbering → structural node.

6. section_type controlled vocabulary — ĐỀ XUẤT

CẢNH BÁO: Danh sách dưới đây là CANDIDATE VALUES từ pilot và review. KHÔNG phải registry chính thức. Số lượng và đăng ký chính thức do C2 §8 + Đ24 + Council quyết định. Agent KHÔNG được coi danh sách này là chốt.

Bản chất section_type: section_type là unit metadata (thuộc tính của logical unit), phân loại mục đích/vai trò của unit trong tài liệu. section_type KHÔNG phải classification label (Đ24 entity_labels). Tuy nhiên, giá trị section_type cần tương thích vocabulary hệ thống — nếu cần map sang Đ24 làm facet, việc đó thuộc P5 quyết định, không chốt ở C1A.

#	Candidate code	Mô tả	Áp cho
1	`heading`	Heading có authority (tên điều, tên article)	Law, design note
2	`article`	Nội dung article/điều khoản trong luật	Law
3	`paragraph`	Đoạn văn bản thường	All
4	`definition`	Định nghĩa thuật ngữ	Law, design note
5	`principle`	Nguyên tắc/doctrine	Law, design note
6	`rationale`	Lý do/bối cảnh amend	Law
7	`process`	Quy trình multi-step	All
8	`technical_spec`	Đặc tả kỹ thuật (schema, contract, API)	Design note
9	`governance_process`	Quy trình có governance (ai làm gì khi nào)	Design note, SOP
10	`checklist`	Danh sách kiểm tra	SOP, design note
11	`instruction_block`	Khối lệnh copy/paste cho agent/operator	SOP
12	`reference_mapping`	Bảng crosswalk/mapping thuần	All
13	`matrix`	Bảng ma trận đa chiều	Design note
14	`invariant_list`	Danh sách invariants/ràng buộc	Design note
15	`open_decision_list`	Danh sách quyết định mở	Design note
16	`appendix`	Phụ lục	All
17	`changelog`	Nhật ký thay đổi	All

7. Label assignment rules — tương thích Đ24

7.1 Ba lớp label tách biệt

Lớp	Mục đích	Ví dụ	Quản lý bởi
Identity	Định danh bất biến	`canonical_address`	C1 §4 + LSL-01 §8
Structural	Xếp vị trí trong cây	`parent_unit_id`, `sort_order`	C1 I4 + I5
Classification	Phân loại đa chiều	`doc=Đ43`, `topic=schema`, `layer=law`	Đ24 entity_labels

Ba lớp tách biệt: identity không đổi khi re-classify, structural không đổi khi re-label, classification không đổi khi re-order.

7.2 Mapping classification labels vào Đ24

Classification labels cho logical unit sẽ dùng Đ24 entity_labels junction table. Logical unit có code → map tự nhiên vào entity_labels.entity_code.

Đ24 hiện có 6 facets (taxonomy_facets). Một số facets có thể phù hợp cho logical unit, ví dụ: nếu có facet doc thì map unit vào doc=Đ43; nếu có facet topic thì map vào topic=schema. Nếu Đ24 chưa có facet phù hợp, hoặc cần facet mới cho logical unit → đề xuất đăng ký qua Đ24, KHÔNG tự tạo trong C1A. Việc xác nhận facets nào thực sự áp dụng thuộc P5 sau khi rà soát Đ24 registry thực tế.

Ghi rõ: label doc=Đ43 là classification, KHÔNG đồng nghĩa publication membership (§6.3 LSL-01, CI-4).

7.3 Description provenance

Khi Agent sinh description cho logical unit → gán FAC-PROV theo Đ24: PROV-AI nếu AI sinh, PROV-HUMAN nếu human review, PROV-DOT nếu DOT template.

7.4 Cấm tạo registry song song

C1A KHÔNG tạo label system riêng. Mọi classification label phải đi qua Đ24 taxonomy → taxonomy_facets → entity_labels. Bất kỳ vocabulary mới nào (kể cả section_type nếu dùng làm classification) phải đăng ký qua C2 §8 + Đ24.

8. Length management

8.1 Length flag

Mỗi unit_version mang 1 length flag trong profile metadata:

normal — nội dung ≤ soft threshold
soft-limit — nội dung vượt soft threshold, cần attention nhưng không block
hard-limit — nội dung vượt hard threshold, cần decision trước enacted

8.2 Threshold (calibration tạm từ pilot, KHÔNG phải luật cứng)

Flag	Default threshold	Ghi chú
normal	≤500 từ	Hầu hết units
soft-limit	500–1500 từ	Trigger review, không block draft
hard-limit	>1500 từ	Cần decision trước enacted

Threshold có thể khác theo section_type: appendix/changelog cho phép cao hơn; instruction_block cho phép cao hơn vì UX atomic. Con số chính xác sẽ chốt tại P5/P6 sau thêm dữ liệu thực tế. Agent KHÔNG được biến threshold tạm thành luật cứng.

8.3 Draft không block

§11.2 LSL-01: Hard-limit WARN ở birth (ghi flag vào metadata), KHÔNG block draft creation. Agent vẫn tạo unit draft dù vượt threshold.

8.4 Publish/enact gate — 3 decisions

Trước enacted, unit hard-limit BẮT BUỘC 1 trong 3 decisions:

Semantic split — cắt thành ≥2 units con theo quy tắc C1A.
Re-segment — nhập lại vào unit cha và cắt lại toàn bộ section.
Length exception approved — giữ nguyên với length_exception_reason trong profile metadata, approve theo risk tier (Đ32).

Không có option 4 "để nguyên không quyết" — phải chọn 1 trong 3.

8.5 Cấm cắt cơ học

§11.3 LSL-01: KHÔNG cắt miếng thành A/B/C theo số từ. KHÔNG đặt tên "Part 1", "Part 2". Mỗi miếng phải có title mô tả ý (SR-6).

9. Publication assembly

9.1 Publication không chứa content inline

Publication = bản công bố hoàn chỉnh. Publication chỉ chứa: governance metadata (lifecycle, version, owner, quorum) + references đến unit_versions. Content sống ở unit_version, không copy vào publication.

9.2 Draft/proposed publication

Mock/proposed publication MAY reference draft unit_versions. Đây là trạng thái hợp pháp trong quá trình soạn thảo. Pilot mock là ví dụ: PUB-D43-MOCK trỏ v1.draft.

9.3 Enacted publication — chỉ enacted/current versions

Enacted publication MUST ONLY reference enacted/current unit_versions. Không bao giờ trỏ draft hay deprecated version. Đây là C1 I8, không có exception.

9.4 Label ≠ membership

Label doc=Đ43 (classification qua Đ24) ≠ publication membership. Draft unit có label doc=Đ38 chưa chắc nằm trong PUB-Đ38-V3.0-ENACTED. Label phân loại "tài liệu này nói về Đ38". Membership khẳng định "unit này là phần chính thức của bản công bố Đ38 v3.0".

9.5 Published snapshot

published_snapshot = tập (logical_unit_id, unit_version_id). Mỗi logical unit tối đa 1 version trong snapshot. Snapshot bất biến sau enacted (C1 I2) — muốn đổi thì tạo version mới.

9.6 Render order

render_order = thuộc tính publication, có thể khác canonical sort_order. Ví dụ: canonical sort_order = thứ tự soạn, render_order = thứ tự trình bày cho reader. render_order không thay đổi canonical parent/sort_order.

9.7 Publication lifecycle (concept-level)

Vòng đời publication ở mức concept: PROPOSED → ENACTED → SUPERSEDED (khi version mới enacted) → RETIRED (optional). Bản cũ bất biến, version mới qua amend, retire không mất history. Enum chính thức và mapping vào Đ4 lifecycle sẽ được chốt tại P5 — C1A chỉ mô tả concept, không chốt enum values.

10. Vector projection rules

10.1 Canonical chunk trong đúng 1 unit_version

Mỗi canonical vector chunk nằm trong đúng 1 unit_version. KHÔNG gộp nhiều unit_versions vào 1 chunk. KHÔNG chia 1 chunk ra nhiều unit_versions.

10.2 Chunk không phải miếng

Vector chunk là projection — không có authority, không có lifecycle riêng, không vote, không approve. Chunk phục vụ retrieval (Lớp NÃO), miếng phục vụ governance (Lớp KHO).

10.3 Metadata kế thừa

Chunk inherit metadata từ unit_version và logical_unit: doc_code, canonical_address, logical_unit_id, unit_version_id, section_type, lifecycle_status, và mọi classification labels.

Chunk chỉ có projection metadata riêng: chunk_id, span_start/end, chunk_index, embedding, embedding_model, synced_at.

10.4 Sync rules (§9.5 LSL-01)

Content thay đổi → re-embed (tạo embedding mới).
Metadata-only thay đổi → update payload (cập nhật metadata trong Qdrant), KHÔNG re-embed.
PG = SoT, Qdrant = projection. Khi drift → PG thắng.

10.5 Authority phân tách

Content layer = Directus / Lớp KHO (Đ33 §0.1). Vector layer = Qdrant / Lớp NÃO (Đ33 §0.1). Không trộn authority: Qdrant không quyết content, Directus không quyết embedding.

10.6 Aggregate retrieval

Aggregate retrieval views (context pack, cross-unit retrieval) — cho phép nhưng: KHÔNG gọi là canonical chunk. KHÔNG có authority riêng. PHẢI có provenance (biết kết quả gộp từ chunks nào). C1A chỉ ghi ràng buộc/concept; KHÔNG thiết kế implementation (thuộc phase riêng).

11. Agent authority model

11.1 Segmentation authority

Agent được: đề xuất segmentation tree, tạo logical_unit + draft unit_version qua birth gate hợp pháp, gắn classification labels qua Đ24, đặt section_type (từ vocabulary đã đăng ký).

Agent KHÔNG được: tự finalize units cho tài liệu high/highest risk mà không có approval.

11.2 Projection authority

Agent/worker được: cắt vector chunks trong khuôn khổ unit_version, gắn metadata kế thừa, gọi re-embed khi content thay đổi. Projection authority KHÁC segmentation authority — projection không tạo logical unit mới.

11.3 Risk-tiered finalization (proposal — không sửa Đ32)

Bảng dưới đây là đề xuất phân loại risk tier cho segmentation. Đây là operating interpretation của C1A dựa trên §10.2 LSL-01, KHÔNG thay thế hoặc sửa Đ32. Nếu Đ32 có quy định khác, Đ32 thắng.

Document type	Risk tier (đề xuất)	Finalize by
Constitution, core law	Highest	Council + User approval
Law (Điều luật)	High	Council + User approval
SOP, runbook	Medium	Owner approval (có thể delegate)
Design note (C1, C2, C1A...)	Medium (đề xuất)	Council review + Owner approval
Knowledge article, memo, report	Low	Agent finalize theo policy + audit + birth gate

11.4 Override risk tier

Nâng tier: Owner có quyền (ví dụ: nâng knowledge article thành medium vì chứa sensitive policy).
Hạ high/highest: cần authority hợp pháp qua Đ32 APR.

11.5 Enacted publication — không tự re-segment

Agent KHÔNG tự re-segment units trong enacted publication. Structural change (tách/gộp/xóa unit) qua change-set + APR (Đ32). Content update (sửa nội dung unit) qua unit version mới + publication version mới.

11.6 Birth gate đồng đều

Mọi miếng mới phải qua birth gate (C1 §6.1, L4). Không có đường tắt: không tạo unit "tạm" rồi bỏ qua birth, không tạo unit "draft" mà không đăng ký canonical_address.

12. Invariants

Code	Statement	Nguồn
CI-1	Miếng thông tin là đơn vị SSOT nội dung nhỏ nhất	NT15 / §5 LSL-01
CI-2	Vector chunk nằm trong đúng 1 unit_version, inherit metadata	§9.1 LSL-01
CI-3	Publication không chứa content inline — chỉ references đến unit_versions	§6.3 LSL-01
CI-4	Label `doc=X` ≠ publication membership	§6.3 LSL-01
CI-5	Enacted publication chỉ chứa enacted/current unit_versions	C1 I8
CI-6	Canonical address bất biến cho cùng logical_unit	§8.4 LSL-01, C1 I3
CI-7	Draft không block ở birth; publish/enact phải có length decision	§11.2 LSL-01
CI-8	Cấm cắt cơ học A/B/C — title phải mô tả ý	§11.3 LSL-01
CI-9	Label layer tương thích Đ24, không registry song song	P3 v0.4
CI-10	Content = Directus/Lớp KHO, Vector = Qdrant/Lớp NÃO — không trộn authority	P4 v0.4, Đ33 §0.1
CI-11	Mỗi unit có đúng 1 canonical parent trong structural tree	C1 I4, I5
CI-12	Mọi miếng mới qua birth gate, không đường tắt	C1 §6.1, L4

13. Open decisions — chuyển P5/P6

Code	Câu hỏi	Impact nếu chốt sai	Phase
OD-C1A-01	Length threshold chính xác theo section_type	Quá thấp → forced split phá logic. Quá cao → units quá dài.	P5
OD-C1A-02	section_type vocabulary đăng ký chính thức (17 candidates → bao nhiêu enacted?)	Thiếu → Agent không biết phân loại. Thừa → fragmentation vocabulary.	P5 (C2 §8 + Đ24)
OD-C1A-03	Label facet mới cho logical unit nếu cần (ngoài doc/topic/layer)	Facet sai → label noise, query khó.	P5 (Đ24)
OD-C1A-04	Storage model cho label assignment: ưu tiên Đ24 `entity_labels`; nếu cần technical extension (scale, performance) thì KHÔNG được phá Đ24 SSOT	entity_labels scale issue nếu millions units. Nhưng table riêng phá Đ24 unity → extension phải giữ Đ24 là SSOT.	P5
OD-C1A-05	canonical_address generation rule chi tiết (format, reservation, collision prevention)	Format lỗi → address collision → CI-6 vi phạm.	P5
OD-C1A-06	publication_type vocabulary (law, sop, design_note, knowledge...)	Sai → publications lẫn lộn type.	P5
OD-C1A-07	Render_order storage model (column trong snapshot? separate table?)	Column → giới hạn. Table → join cost.	P5
OD-C1A-08	Publication membership storage model: membership lưu thế nào và phân biệt ra sao với Đ24 label `doc=X`? Điểm sống còn P5 — nhầm label với membership sẽ phá CI-4.	P5
OD-C1A-09	Structural node (heading navigation không có content) cần unit_version không?	Có → overhead. Không → gap trong version history.	P5
OD-C1A-10	Code block threshold "tham chiếu ≥2 nơi" có cứng không?	Cứng quá → miss case. Mềm quá → Agent tùy ý.	P5
OD-C1A-11	Matrix "phải đọc nguyên khối" — ai quyết: reviewer hay owner?	Reviewer → chậm. Owner → bias giữ nguyên.	P5
OD-C1A-12	Bootstrap multi-step threshold (5/15) cần calibrate lại?	Threshold sai → split sai.	P6
OD-C1A-13	Aggregate retrieval implementation (context pack chunking strategy)	Sai → retrieval quality kém. Thuộc phase riêng.	P6+

Ghi chú cuối

C1A là design note tiền-schema. Mọi rule, threshold, vocabulary đều ở mức concept + operational guideline. P5 schema draft sẽ dùng C1A (cùng C1, C2) làm input để chuyển thành DDL/migration/DOT.

Thứ tự hiệu lực khi mâu thuẫn: LSL-01 thắng ở tầng doctrine (supremacy clause §12 LSL-01). C1 giữ hiệu lực cho object model và lifecycle. C2 giữ hiệu lực cho metadata governance và vocabulary. C1A là operating interpretation — cung cấp quy tắc vận hành cụ thể hóa doctrine LSL-01, bổ sung (không thay thế) C1/C2 ở phần segmentation operations.

C1A — Segmentation Operating Model | DRAFT rev 5 | S180 | 2026-04-26 | Opus 4.6 GPT review: vòng 1 (8 patches) → vòng 2 (2 micro-patches) → vòng 3 (1 citation patch) → PASS Inputs: LSL-01 v0.3/v0.4, Pilot mock, Pilot Review, GPT reviews, C1, C2, Đ24, Đ33 Word count: ~4700 từ