LSL-01 — LUẬT SỬA LUẬT: MIẾNG THÔNG TIN LÀM TRUNG TÂM

Tên đầy đủ: Luật sửa luật và sửa Hiến pháp về Miếng thông tin làm trung tâm Mã: LSL-01 Phiên bản: v0.3 — BẢN CUỐI (sửa từ v0.2 theo GPT review, 6 điểm) Loại văn bản: Luật sửa luật (amendment law) Cơ chế: Luật cũ vẫn còn hiệu lực. LSL-01 thắng trong phạm vi mâu thuẫn theo §3, §12, §13. Folder upload KB: knowledge/dev/laws/dieu38-trien-khai/ Hội đồng (Council): User (Huyên) + Opus + GPT Soạn: Opus 4.7 Ngày: 2026-04-25 Trạng thái: v0.3 — Council PASS, upload KB.

§1. Mục đích

LSL-01 chuyển hệ thống từ document-centric sang unit-centric trong phạm vi quản lý nội dung văn bản, mà không yêu cầu rewrite toàn bộ Hiến pháp, Đ38 v3.0, L1–L5, C1–C2 hay các tài liệu thiết kế đang soạn.

Tinh thần nền:

Tất cả các luật và Hiến pháp hiện hành là cõi tạm. Đích cuối là một hệ thống mà mọi văn bản, luật, SOP, knowledge, memo đều sống dưới dạng các miếng thông tin trong PostgreSQL, với label để pivot và publication để công bố. File, KB markdown, document inline đều là backup/import/export, không phải nguồn sự thật.

LSL-01 chốt doctrine để Agent (Opus, GPT, Codex, Claude CLI...) được phép chuẩn bị segmentation theo LSL-01 ngay từ bây giờ trong môi trường pilot/mock/ETL stub. Việc ghi PG thật chỉ được thực hiện khi birth gate + write path hợp pháp đã được thiết kế, duyệt và triển khai sau pilot. LSL-01 không cho phép Agent bypass write path để đẩy data vào PG production.

LSL-01 KHÔNG chốt schema, KHÔNG viết SQL/trigger/DOT, KHÔNG là C1A đầy đủ. Đây là tầng nguyên tắc, không phải tầng thiết kế.

§2. Phạm vi áp dụng

LSL-01 áp dụng trong các phạm vi sau:

Định nghĩa và quản trị miếng thông tin (information unit / logical unit / unit version).
Cơ chế label (nhãn) để phân loại, pivot, gom nhóm miếng.
Publication (bản công bố) như loại object governance bao trùm document/luật/SOP/knowledge.
Vector/Qdrant projection trong khuôn khổ miếng.
Quyền segmentation của Agent — cắt và tạo miếng vào PG (qua write path hợp pháp).

LSL-01 KHÔNG áp dụng trực tiếp vào: schema PG, trigger, DOT implementation, KG runtime, retrieval engine. Những phần đó tuân thủ doctrine LSL-01 nhưng được thiết kế chi tiết ở các phase sau (pilot → C1A → schema P5).

§3. Hiệu lực ưu tiên (Supremacy Clause)

Quy tắc 1. Luật cũ vẫn còn hiệu lực ở phần không mâu thuẫn với LSL-01.

Quy tắc 2. Nếu LSL-01 mâu thuẫn với Hiến pháp hiện hành, Đ38 v3.0, L1–L5, C1–C2, hoặc các tài liệu thiết kế đang soạn (C3, ...), trong phạm vi §2 thì LSL-01 được ưu tiên áp dụng.

Quy tắc 3. Ngoài phạm vi §2, các luật cũ giữ nguyên hiệu lực.

Quy tắc 4. Mọi tài liệu mới (luật, design note, schema, DOT) ban hành sau LSL-01 phải bám theo doctrine LSL-01. Nếu đi ngược, phải có amend LSL-01 hoặc luật sửa luật mới (LSL-02...).

Quy tắc 5. LSL-01 KHÔNG làm mất hiệu lực hồi tố của L1–L5 / C1–C2 / các tài liệu thiết kế cũ. Các tài liệu cũ tiếp tục dùng được ở phần không mâu thuẫn. LSL-01 cung cấp interpretation override cho design/pilot mới và cho các lần amend tiếp theo.

§4. Định nghĩa miếng thông tin

Định nghĩa vận hành (operational definition):

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

Đây là định nghĩa duy nhất để Agent áp dụng. Không dùng 6 test, 12 test hay flowchart phức tạp như điều kiện bắt buộc. Các checklist phụ trợ nếu có chỉ hỗ trợ Agent khi nghi ngờ, không thay thế định nghĩa vận hành.

Bộ kiểm tra 3 câu mà Agent dùng khi cắt:

Tôi đặt được title rõ cho đoạn này không?
Nếu sửa đoạn này, có phải sửa các đoạn bên cạnh cùng lúc không?
Đoạn này có quá dài đến mức việc sửa/review trở nên khó khăn không?

Quy tắc:

Title rõ + sửa được riêng + không quá khó sửa → một miếng.
Không đặt được title rõ, hoặc sửa luôn kéo theo các đoạn xung quanh → không phải miếng riêng, là một mảnh của miếng cha.

Hệ quả:

Một miếng có thể là 1 câu (nếu là một nguyên tắc quan trọng được tham chiếu nhiều nơi).
Một miếng có thể dài (nếu là một lập luận liền mạch không tách được mà giữ nghĩa).
Độ dài KHÔNG quyết định miếng. Title + tính độc lập sửa/review quyết định.

Lớp khái niệm:

Miếng thông tin (logical unit) = danh tính, có địa chỉ canonical, sống xuyên versions.
Phiên bản miếng (unit version) = nội dung cụ thể tại một thời điểm. Đây là nơi chứa content authoritative.

§5. NT15 — Information Unit First (bổ sung Hiến pháp)

LSL-01 bổ sung vào Hiến pháp một nguyên tắc mới:

NT15 — Information Unit First

Miếng thông tin là đơn vị SSOT nội dung nhỏ nhất của hệ thống.

Nội dung quản trị authoritative không sống trong file, KB markdown, document envelope inline, hay Qdrant. Nó sống trong unit_version trong PostgreSQL.

Mọi văn bản, luật, SOP, knowledge, topic, lớp, view, và bản công bố đều được tổ chức bằng cách gắn label, xếp thứ tự, và công bố các miếng thông tin.

Vector chunks, file backup, KB exports, rendering output là projection — không được thay thế miếng thông tin làm nguồn sự thật.

Phạm vi áp dụng của NT15:

NT15 đứng ngang hàng NT1 (SSOT), NT11 (Khai tối thiểu), NT13 (PG First). NT15 được ưu tiên áp dụng khi có mâu thuẫn trực tiếp trong phạm vi §2 — tức về SSOT nội dung, information unit, label, publication và vector projection.

Lưu ý: NT15 KHÔNG tự động đè NT1, NT11, NT13 hay các NT khác ở các phạm vi ngoài §2. Ví dụ: NT11 (Khai tối thiểu) áp dụng cho schema metadata vẫn theo nguyên tắc cũ. NT13 (PG First) vẫn áp cho các cơ chế ngoài content layer.

§6. Ba lớp nền

LSL-01 chốt mô hình 3 lớp tách biệt, không trộn:

6.1 Content layer — Lớp nội dung

Chứa miếng thông tin và phiên bản miếng. Đây là nơi duy nhất chứa content authoritative.

logical_unit — danh tính miếng, có canonical address, ổn định xuyên versions.
unit_version — nội dung cụ thể tại một thời điểm. Lifecycle riêng (draft / enacted / superseded / retired).

Mọi truy vấn nội dung cuối cùng đều phải về Content layer.

6.2 Label layer — Lớp nhãn

Chứa các nhãn gắn vào miếng để phân loại, pivot, gom nhóm.

Một miếng mang nhiều label cùng lúc.
Label có thể có cha/con nhiều tầng (label hierarchy).

Hai loại label:

Loại	Mô tả	Ví dụ	Quy tắc
Structural relation/label	Có vai trò cấu trúc, gắn với integrity rule	`parent_unit`, `sort_order`	KHÔNG free-form; sửa qua structural change-set
Classification label	Phân loại/pivot tự do trong vocabulary đã đăng ký	`doc`, `topic`, `layer`, `family`, `tag`	Free-form trong vocabulary; có thể thêm/sửa theo policy registry

Identity field — không phải label thường:

canonical_address là identity field của logical_unit, KHÔNG phải structural label ngang hàng parent_unit/sort_order, cũng KHÔNG phải classification label. Nó được sinh/assign từ structural context (canonical parent chain + canonical doc label) tại birth, có integrity rule riêng (unique toàn hệ thống, ổn định xuyên versions của cùng logical_unit), không free-form. Quy tắc đầy đủ về address ở §8.4.

Lifecycle của label:

Label KHÔNG có content lifecycle như unit_version (label không phải SoT nội dung).
Tuy nhiên label value có registry status — active / deprecated / retired — theo controlled vocabulary governance (C2 §8). LSL-01 không thay đổi điều này.
Label membership (việc một miếng được gắn label X) có thể có audit/effective interval nếu design phase yêu cầu.

Ví dụ trên một miếng cụ thể (concept-level):

Miếng X (logical_unit_id = U-12345)
  Identity:
    - canonical_address = D38-S2-P3
  Structural relation/label:
    - parent_unit = U-12340
    - sort_order = 3
  Classification labels:
    - doc = Đ38
    - topic = segmentation
    - layer = design
    - family = law

Pivot theo label (concept-level, không phải schema):

"Đọc Đ38" — pivot theo classification label doc=Đ38, sắp xếp theo sort_order (canonical) hoặc render_order (publication-specific).
"Đọc topic segmentation xuyên doc" — pivot theo classification label topic=segmentation.
"Đọc layer design" — pivot theo classification label layer=design.

Cách lưu/query cụ thể (table, FK, join) thuộc design phase, không chốt ở LSL-01.

6.3 Publication layer — Lớp bản công bố

Chứa các bản công bố (publication) — tập miếng được xếp thứ tự để công bố, có authority, lifecycle, snapshot.

Bản công bố KHÔNG chứa content inline. Nó chỉ chứa governance metadata + reference đến tập unit_versions tham gia.

Ví dụ bản công bố:

"Đ38 v3.0 enacted ngày 2026-04-17" — một publication.
"SOP-Deploy v2.1" — một publication.
"Hiến pháp v4.6.2" — một publication.
"Knowledge-Pack-Onboarding-Q2" — một publication.

Mỗi publication có:

doc_code (ví dụ Đ38, SOP-Deploy, HP).
doc_type (law, policy, sop, constitution, knowledge, ...).
version (3.0, 2.1, 4.6.2, ...).
lifecycle (draft → enacted → superseded → retired).
authority (ai ban hành, council score, enacted_at).
published_snapshot (tập (logical_unit_id, unit_version_id) tại thời điểm enacted).
render_order (thứ tự đọc — có thể khác canonical order của miếng).
audit trail.

Phân biệt label doc=X và publication membership (quan trọng):

Một miếng có classification label doc=Đ38 KHÔNG đồng nghĩa với việc miếng đó nằm trong publication "Đ38 v3.0 enacted".

Label doc=Đ38 chỉ là classification/pivot — nói "miếng này có liên quan đến Đ38". Một miếng draft đang được soạn có thể có label doc=Đ38 nhưng chưa được duyệt vào bản công bố nào.

Publication membership mới là authority cho bản công bố chính thức. Một unit_version chỉ được coi là "thuộc Đ38 v3.0 enacted" nếu nó nằm trong published_snapshot của publication đó.

Đây là rào chắn cốt lõi để draft không lọt vào enacted publication dù có cùng label.

Một miếng nằm trong nhiều publication:

Một miếng có thể nằm trong nhiều publication cùng lúc. Ví dụ: miếng "Định nghĩa SSOT" được công bố trong Hiến pháp v4.5, đồng thời được dùng lại trong Đ38 v3.0 và trong KB-Memo-Onboarding-v2. Cả 3 publication đều trỏ về cùng một unit_version_id. Nếu định nghĩa được sửa thành V2, các publication đang dùng V1 vẫn giữ snapshot cũ; publication mới có thể chọn dùng V2 hay giữ V1.

§7. Document/Publication — đổi bản chất

Trước LSL-01 (theo Đ38 v3.0 + L1):

Document envelope là cái hộp chứa text units. Unit thuộc document qua FK doc_code. Cây parent-child sống bên trong document.

Sau LSL-01 (Unit-Centric View Model):

Document/luật/SOP/knowledge KHÔNG còn là content container. Chúng là một loại publication — bản công bố — được dựng từ các unit_versions.

Document object vẫn tồn tại như một publication object nhẹ. Vẫn có doc_code, vẫn có version, vẫn có lifecycle, vẫn có authority, vẫn có published_snapshot. Nhưng không chứa nội dung inline.

Nôm na: Trước đây "Đ38" là một cuốn sách dày có chữ bên trong. Bây giờ "Đ38" là một mục lục có authority — nó nói "bản công bố Đ38 v3.0 gồm các miếng X1, X2, X3, ... xếp theo thứ tự này, ban hành ngày này". Chữ thật sống ở miếng.

§8. Label layer — chi tiết structural

8.1 Một miếng mang nhiều label

Không hạn chế số label. Một miếng có thể có:

1 identity field canonical_address (sinh tại birth)
1 structural label parent_unit=...
1 structural label sort_order=...
N classification label (doc, topic, layer, family, ...)

canonical_address được liệt kê tách biệt vì nó là identity field, không phải label thường. Xem §6.2 và §8.4.

8.2 Label hierarchy

Classification label có thể có cha/con. Ví dụ: family=law là cha của doc=Đ38, doc=Đ43, doc=Đ39. Label con kế thừa ngữ cảnh của label cha theo rule đăng ký.

Cây label dùng cho:

Phân loại đa tầng (family → doc → article → paragraph).
Pivot theo nhiều mức (đọc cả family law, hoặc chỉ một doc trong đó).
Hệ thống label có thể tự do mở rộng — không phải amend luật mỗi lần thêm label mới.

8.3 Canonical parent — structural relation

parent_unit KHÔNG phải free-form classification label. Nó là structural relation xác định cây cấu trúc canonical của miếng — có integrity rule, có vai trò trong address generation, có hệ quả trong split/merge.

Quy tắc:

Mỗi miếng có đúng 1 canonical parent — cha gốc, được sinh ra cùng văn bản gốc tại birth.
Canonical parent ổn định (stable). KHÔNG phải bất biến tuyệt đối.
Canonical parent chỉ được đổi qua structural change-set + approval theo risk tier (xem §10.2). Re-parent, split, merge đều là structural change.
Một miếng có thể có N alternative positions trong các publication khác — alternative positions là tự do (publication có thể tổ chức lại miếng theo render order khác). Nhưng canonical parent giữ nguyên (trừ structural change-set).

8.4 Canonical address — identity, không phải position

Canonical address là identity của logical unit tại birth, không phải render position trong publication.

Address được sinh/assign tại birth từ canonical parent chain + canonical doc label.
Address giữ format hiện tại cho tương thích: {doc_code}-{section_path} (ví dụ D38-S2-P3-1).
Một miếng dùng trong nhiều publication vẫn giữ cùng một canonical address. Render position trong mỗi publication là thuộc tính của publication, không thay đổi address.

Quy tắc bất biến của address:

Canonical address của cùng một logical_unit KHÔNG đổi sau birth.
Khi split: logical_unit cũ được retire/superseded; các logical_unit mới sinh ra với canonical address mới. Successor relation ghi cũ → mới.
Khi merge: các logical_unit cũ retire/superseded; logical_unit gộp mới sinh ra với canonical address mới. Successor relation ghi cũ → mới.
Re-parent thông thường (đổi parent_unit của một logical_unit đã enacted) KHÔNG tự đổi canonical_address của logical_unit đó. Re-address migration nếu có là exception risk cao, cần approval theo Đ32.

Tóm lại: không "đổi address" của cùng logical_unit; thường là tạo logical_unit mới với address mới + retire unit cũ + ghi successor relation.

Hệ quả: Khi miếng X được tham chiếu (ref ngang), ref trỏ vào canonical address của X. Ref không phụ thuộc publication nào đang chứa X. Đây là cơ chế reuse content xuyên publication.

8.5 Label không phải SoT nội dung

Label là cách phân loại, không phải nội dung. Khi label đổi (deprecated, retired, sửa value), miếng không đổi nội dung. Khi miếng đổi nội dung (version mới), label vẫn nguyên cho đến khi có quyết định gắn lại.

§9. Vector/Qdrant — chạy theo miếng

LSL-01 chốt Unit-Centric Principle cho vector:

9.1 Canonical chunk

Một canonical vector chunk luôn nằm trong đúng 1 unit_version. Không gộp nhiều miếng vào một chunk.

9.2 Khi miếng dài → cắt nội bộ (vector projection authority)

Nếu một unit_version dài, vector worker hoặc Agent có quyền projection cắt thành nhiều chunks trong khuôn khổ unit_version đó:

unit_version V của miếng X (3000 ký tự)
  ├── chunk A: span 0–1000
  ├── chunk B: span 1000–2000
  └── chunk C: span 2000–3000

Cả 3 chunks đều thuộc cùng unit_version_id = V, cùng logical_unit_id = X.

Quan trọng — phân biệt 2 loại quyền:

Vector chunking KHÔNG phải segmentation. Vector chunking là projection authority — chỉ ảnh hưởng cách content được embed cho retrieval, KHÔNG tạo logical unit mới, KHÔNG thay đổi address, KHÔNG thay đổi cây canonical.

Quyền segmentation (cắt thành miếng mới) thuộc Agent + governance theo §10.

9.3 Inherit metadata

Chunks inherit/cache governance metadata từ unit_version và logical_unit:

doc_code (label canonical)
canonical_address
logical_unit_id
unit_version_id
section_type
doc_type
lifecycle_status
version_number
owner
review_state
... (mọi label authoritative)

Chunks chỉ có projection metadata kỹ thuật riêng:

chunk_id
span_start, span_end
chunk_index
embedding (vector)
embedding_model
projection_version
synced_at

9.4 PG là SoT, Qdrant là projection

Nếu Qdrant payload drift khỏi PG → PG thắng. Sync worker re-push từ PG. Qdrant không có authority.

9.5 Sync rules

Loại thay đổi	Qdrant xử lý
Metadata đổi, content không đổi	Update payload, không re-embed
Content/body đổi → version mới	Tạo chunks mới cho version mới + re-embed
Lifecycle V1 enacted → superseded	Update payload của chunks V1 (mark superseded)
V2 enacted	Create chunks V2
Logical unit retired	Mark chunks của tất cả versions là retired

9.6 Aggregate retrieval — concept, không implementation

Cho phép aggregate retrieval views (context pack, section-level summary embedding) phủ nhiều unit_versions, với điều kiện:

KHÔNG gọi là canonical chunk.
KHÔNG có authority/lifecycle/review riêng.
KHÔNG là SoT.
Phải có provenance đầy đủ: list unit_version_ids + spans.
Có thể tái tạo từ unit_versions bất cứ lúc nào.

Implementation aggregate retrieval thuộc phase sau pilot. LSL-01 chỉ chốt khái niệm.

9.7 Cấm tuyệt đối

Vector chunk gộp 2+ unit_versions → CẤM (canonical).
Vector chunk được gọi là "miếng thông tin" → CẤM.
Vector chunk có lifecycle riêng tách khỏi unit_version → CẤM.
Qdrant trở thành SoT → CẤM.

§10. Agent segmentation authority

10.1 Quyền chung — segmentation

Agent (Opus, GPT, Claude CLI, Codex, Gemini, ...) được quyền trong scope segmentation:

Đề xuất segmentation tree cho văn bản mới hoặc văn bản import.
Tạo logical_unit + unit_version (draft) trong PG qua birth gate hợp pháp.
Gắn classification labels cho miếng.
Đề xuất canonical address (theo rule sinh address — chi tiết schema).

Lưu ý: Vector chunking thuộc projection authority (xem §9.2), KHÔNG thuộc segmentation authority. Hai quyền khác nhau, không gộp.

10.2 Risk-tiered finalization

Quyền finalize (đưa miếng/publication tới enacted) phụ thuộc loại publication. Phân loại mặc định:

Loại publication	doc_type	Mức rủi ro	Agent finalize?	Approval bắt buộc
Hiến pháp	constitution	Highest	KHÔNG	User + Council
Luật / Điều	law	High	KHÔNG, chỉ propose	Council + User
Chính sách	policy	High	KHÔNG, chỉ propose	Owner + reviewer
SOP	sop	Medium	Propose + cắt; finalize cần owner approve khi enact	Owner
Knowledge note (có publish)	knowledge	Low-Medium	Có thể finalize theo policy đăng ký, có audit trail, qua birth gate	Owner khi conflict
Internal memo / working note / draft	memo, draft, working	Low	Agent finalize theo policy đăng ký, có audit trail, qua birth gate hợp pháp	Không bắt buộc human approval per-publication
Agent output (analysis, report)	report	Low	Agent finalize theo policy + audit	Không bắt buộc

Quy tắc bắt buộc cho mọi tier: Birth gate + write path + audit trail vẫn áp dụng cho tất cả. "Agent finalize" KHÔNG có nghĩa là bypass governance — chỉ có nghĩa là không cần human approval per-publication. Mọi đường đi vào PG đều qua write path hợp pháp.

Override risk tier:

Owner của publication có thể đề xuất nâng/hạ risk tier per-publication.
Nâng risk (ví dụ: SOP bảo mật nâng từ medium → high) có thể do owner quyết theo policy đã đăng ký — đây là chiều an toàn hơn.
Hạ risk của publication thuộc tier high hoặc highest (law, policy, constitution) cần authority hợp pháp theo Đ32/LSL-01, KHÔNG do owner tự quyết. Đây là rào chắn chống bypass approval.

10.3 Enacted publication

Một khi một publication ở trạng thái enacted, các miếng trong published_snapshot không được tự re-segment bởi Agent. Mọi structural change (split/merge logical_unit, đổi parent canonical, đổi section_type) phải qua change-set + APR (Đ32).

10.4 Birth gate vẫn áp dụng

Mọi miếng mới (logical_unit + draft unit_version) phải qua birth gate theo L4 hiện hành. LSL-01 không thay đổi cơ chế birth gate. Birth gate kiểm completeness, không kiểm "boundary đúng/sai về nghĩa" — boundary là phán đoán Agent + owner.

§11. Length rule — độ dài là trigger

11.1 Nguyên tắc

Độ dài không phải dao cắt. Độ dài là trigger để xem lại boundary.

Hệ thống KHÔNG tự cắt miếng theo token, ký tự, hay số câu.

11.2 Soft limit / Hard limit — phân tầng theo lifecycle

Soft limit (cảnh báo, mọi lifecycle):

DOT daily phát hiện miếng dài bất thường so với loại của nó.
Log INFO, đưa vào review queue cho owner.
Không block.

Hard limit ở birth (draft):

Birth gate WARN, không block draft. Miếng dài vẫn vào PG draft được.
Lý do: cho phép Agent nháp nhanh, không cản workflow.

Hard limit trước publish/enact:

Trước khi publication chứa miếng vượt hard limit được enacted/published, bắt buộc phải có một trong 3 quyết định:
1. Semantic split: tìm các ý con có title rõ và nâng thành miếng con.
2. Re-segment: nếu phát hiện thực ra là nhiều miếng độc lập, cắt thành các miếng cùng cấp.
3. Length exception approved: giữ miếng dài, ghi rõ length_exception_reason vào metadata profile, được approve theo risk tier (low-risk có thể auto-approve qua policy; high-risk cần human).
Nếu chưa có decision nào trong 3 → publication không enacted được.

Số liệu cụ thể: thuộc config (đăng ký theo loại miếng), không hardcode trong LSL-01. Pilot calibrate.

11.3 Quy tắc tách semantic

Khi phải tách:

Đúng:

Miếng "Quản trị segmentation" (quá dài)
  → tách thành:
    - Khái niệm miếng thông tin
    - Quy tắc đặt tên miếng
    - Quy tắc độ dài
    - Đồng bộ Qdrant theo miếng
    - Quyền quyết định của Agent

Sai (cấm):

Miếng "Quản trị segmentation" (quá dài)
  → tách thành:
    - Segmentation A
    - Segmentation B
    - Segmentation C

Lý do cấm: A/B/C cơ học không có title rõ riêng, không đứng được, vi phạm §4.

11.4 Khi không tìm được ý con

Nếu một miếng dài nhưng không tìm được ý con có title rõ (ví dụ: một lập luận liền mạch, một bảng đối chiếu phải đọc liền, một định nghĩa phức hợp) → giữ dài và xin length exception. Đây là exception hợp pháp khi được approve theo risk tier.

§12. Mapping luật cũ → tinh thần mới

Bảng này giúp Agent không bị lẫn khi đọc luật cũ:

Khái niệm/quy tắc cũ	Hiểu lại theo LSL-01
Document envelope chứa nội dung	Document/publication KHÔNG chứa content inline. Là một loại publication object nhẹ — quản version/lifecycle/authority/snapshot/render order.
Unit thuộc document qua FK `doc_code` cứng	Unit mang labels (trong đó `doc=Đ38` là một classification label). Một unit có thể có nhiều `doc` labels. Lưu ý: label `doc=X` ≠ membership trong publication enacted của X (xem §6.3).
Cây parent-child "trong document"	Cây parent là structural label với integrity rule (xem §8.3). Mỗi miếng có 1 canonical parent + N alternative positions trong publication khác.
Address `{doc_code}-{section_path}`	Address vẫn giữ format hiện tại (D38-S3-P2-1) cho tương thích. Hiểu lại: address là identity của logical unit tại birth, không phải render position. Sau này có thể tổng quát hóa.
KB markdown / file là nguồn nội dung	KB/file là backup, import, export, render output — không phải SoT. Nội dung sống trong PG `unit_version`.
Vector chunk có thể hiểu là chunk độc lập	Vector chunk là projection trong khuôn khổ unit_version. Không độc lập. Không có authority.
"Document version" bump khi change-set enacted	Bản công bố version bump. Document = publication. Version vẫn bump khi change-set enacted.
Published snapshot của document	Publication snapshot — tập `(logical_unit_id, unit_version_id)` tại thời điểm enacted. Bản chất giống cũ.
Birth gate text_unit (L4)	Vẫn áp dụng nguyên. Chỉ hiểu lại: kiểm metadata của miếng, không phụ thuộc khái niệm "thuộc document" như cũ.
Change-set + APR (L5)	Vẫn áp dụng nguyên. Change-set gom thay đổi nhiều miếng. Apply → publication snapshot update.

Quy tắc đọc luật cũ: Khi gặp từ "document envelope" trong L1/C1/C2, hiểu là "publication object". Khi gặp "text unit thuộc document", hiểu là "miếng thông tin có classification label doc=...". Khi gặp "vector chunk", hiểu là "chunk projection trong unit_version".

§13. Luật/tài liệu bị override theo §3

Tài liệu	Phần bị override	LSL-01 thay bằng
Hiến pháp (HP v4.6.2)	Bổ sung NT15 (Information Unit First)	§5 LSL-01
Đ38 v3.0	"Document-centric" tinh thần ngầm	"Unit-centric" — §6, §7 LSL-01
L1 §3.3 (Quan hệ document ↔ unit "document sở hữu units")	Hiểu lại: publication tham chiếu unit_versions, không sở hữu	§6, §7 LSL-01
L1 §3.5 ("Parent phải cùng document")	Hiểu lại: canonical parent + alternative positions	§8.3 LSL-01
L1 §4 nguyên tắc 5 ("Mọi unit bình đẳng về cấu trúc")	Vẫn đúng về governance, nhưng làm rõ: bình đẳng quản trị, KHÔNG bình đẳng về content type	§6.1 LSL-01
C1 §4.1 ("Document envelope... sở hữu một tập logical text units")	Hiểu lại: publication tham chiếu, không sở hữu	§7 LSL-01
C1 §8.2 ("Vector sync... cho retrieval")	Cụ thể hóa: canonical chunk ≤ unit_version, inherit metadata	§9 LSL-01
C2 §4.2.1 (Document envelope core-equivalent)	Hiểu lại: publication core-equivalent	§6.3 LSL-01

Phần KHÔNG bị override (tiếp tục áp dụng nguyên):

L1 §3.4 (canonical address) — giữ format, hiểu là identity (§8.4 LSL-01).
L1 §3.7 (lifecycle theo unit, Đ4).
L1 §3.8 (version theo unit, enacted bất biến).
L4 (birth gate cơ chế).
L5 (review + change-set + APR).
C1 §5 (lifecycle model).
C1 §6 (write path) — cần bổ sung context label nhưng cơ chế giữ.
C1 §7 (checker path).
C2 §6 (field responsibility matrix) — chi tiết cụ thể vẫn áp.
C2 §7 (validation 3 tầng).
C2 §8 (controlled vocabulary governance) — áp cho label registry.
Đ32 (APR).
Đ4 (lifecycle).
Đ29 (species).
Đ33 (PG First).
Đ39 (KG) — LSL-01 thực ra đẩy hệ thống tới gần Đ39 hơn.

§14. Ranh giới — LSL-01 KHÔNG làm gì

Không làm	Lý do
Không chốt schema PG (tên bảng, cột, kiểu dữ liệu)	Thuộc P5 sau pilot
Không viết SQL/trigger/function	Thuộc P5/P6
Không liệt kê DOT cụ thể	Thuộc P6
Không viết C1A đầy đủ	Sau pilot mới biết C1A cần gì
Không pilot trong văn bản này	Pilot là task riêng sau khi LSL-01 ban hành
Không amend trực tiếp Đ38 v3.0 thành v4.0	Cơ chế "luật sửa luật" không yêu cầu rewrite
Không rewrite L1/C1/C2	Sẽ rewrite sau pilot nếu cần
Không định nghĩa label registry chi tiết	Thuộc thiết kế sau
Không định nghĩa publication storage	Thuộc P5
Không định nghĩa aggregate retrieval implementation	Phase sau pilot
Không calibrate soft/hard limit cụ thể	Pilot calibrate
Không cho phép Agent ghi PG production trước khi write path hợp pháp được duyệt	Bảo vệ governance giai đoạn chuyển tiếp

§15. Lộ trình triển khai sau LSL-01

LSL-01 chỉ là viên gạch đầu tiên. Lộ trình tiếp theo:

Giai đoạn 1 — Council approve LSL-01. User + Opus + GPT review. Sửa nếu cần. Ban hành v0.3 hoặc bản tiếp theo.

Giai đoạn 2 — Pilot 3 tài liệu (mock/ETL stub). Tài liệu pilot:

Đ43 v1.2 (luật vừa) hoặc Đ41 — luật có cấu trúc rõ.
Một SOP nhiều bước — TBD by User.
C2 Metadata Governance Operating Model — đại diện use case "AI soạn tài liệu dài, tự cắt vào PG".

Pilot dùng JSON/YAML/Markdown table (mock/ETL stub), chưa ghi PG production. Mục tiêu: cắt thử, áp 3 câu kiểm tra của §4, áp 3 lớp của §6, kiểm length rule, kiểm Agent authority, kiểm vector mapping.

Giai đoạn 3 — Pilot review report. Ghi nhận: cắt đúng không, độ dài có vấn đề không, label hierarchy đủ không, edge cases mới phát hiện, schema cần gì.

Giai đoạn 4 — Quyết định amendment scope. Sau pilot, Council quyết định:

Cần amend Hiến pháp chính thức không (NT15 đã có ở LSL-01)?
Cần rewrite C1/C2 không?
Cần amend L1/L4/L5 không?
Cần viết C1A đầy đủ không?
Hay LSL-01 + pilot + minor amend là đủ?

Giai đoạn 5 — Schema P5 + write path hợp pháp. Chỉ sau khi LSL-01 + pilot + decisions giai đoạn 4 hoàn tất → mới P5 schema + thiết kế write path hợp pháp cho miếng.

Giai đoạn 6 — Implementation P6 + migration P7. Theo schema. DOT, trigger, sync workers, vector projection. Lúc này Agent mới được phép ghi PG production qua write path đã duyệt.

§16. Điều kiện PASS

LSL-01 v0.3 được Council approve nếu thỏa mãn:

✅ Định nghĩa miếng thông tin dễ áp dụng cho Agent (1 câu + 3 câu kiểm tra; checklist phụ trợ là tùy chọn).
✅ 3 lớp (Content / Label / Publication) tách biệt rõ, không trộn.
✅ Phân biệt structural label vs classification label vs identity field rõ ràng.
✅ Phân biệt label doc=X vs publication membership rõ ràng.
✅ Vector projection theo Unit-Centric, vector chunking ≠ segmentation.
✅ Agent authority có risk tier rõ, low-risk tự finalize được nhưng luôn qua birth gate + audit.
✅ Owner không tự hạ risk của publication high/highest — phải qua authority hợp pháp.
✅ Length rule chỉ là trigger; draft không block, nhưng publish/enact phải có decision.
✅ Address quy tắc rõ: address không đổi cho cùng logical_unit; split/merge tạo unit mới + address mới + retire cũ.
✅ Supremacy clause rõ (§3) — Agent biết luật nào thắng khi mâu thuẫn.
✅ NT15 phạm vi giới hạn trong §2 — không lan ra ngoài.
✅ Mapping luật cũ rõ (§12) — Agent đọc luật cũ không bị lẫn.
✅ Phạm vi override rõ (§13) — biết LSL-01 đụng vào đâu, không đụng vào đâu.
✅ Không vi phạm NT14: doctrine không chốt thứ chưa mô phỏng được; pilot là bước bắt buộc tiếp theo.
✅ Văn bản ngắn gọn (6–9 trang nội dung chính), không phình thành C1A.
✅ Mục tiêu rõ: Agent có thể bắt đầu cắt và đưa miếng vào PG draft (qua write path hợp pháp) sau pilot.
✅ Council (User + Opus + GPT) đồng thuận.

§17. Liên hệ với các luật hiện hành

Luật/Tài liệu	Quan hệ với LSL-01
Hiến pháp	Bổ sung NT15. Các NT khác giữ nguyên. NT15 phạm vi giới hạn trong §2.
Đ4 (Lifecycle)	Vẫn áp. Lifecycle áp cho miếng và publication.
Đ29 (Species)	Vẫn áp. text_unit / information_unit là species. Có thể đổi tên trong design phase.
Đ32 (APR)	Vẫn áp. Change-set + APR cho enacted publication và structural change.
Đ33 (PG First)	LSL-01 củng cố. Miếng trong PG = SoT.
Đ38 v3.0	Bị override tinh thần (document-centric → unit-centric). Cơ chế cụ thể (text unit, lifecycle, version) vẫn áp.
Đ39 (KG)	LSL-01 đẩy hệ thống tới gần Đ39 hơn — entity + label + relation. Không mâu thuẫn.
Đ43 (Bản đồ Hệ thống)	Tương thích — Đ43 đã có khái niệm labels, render layer.
Đ0-G (Birth Registry)	Vẫn áp. Birth gate cho miếng theo L4.
L1–L5	Phần bị override theo §13. Phần còn lại vẫn áp. KHÔNG invalid hồi tố.
C1, C2	Phần bị override theo §13. Phần còn lại vẫn áp. C3 đang soạn → phải bám LSL-01.
NT14 (mô phỏng được)	LSL-01 tuân thủ — chỉ chốt doctrine, không chốt schema/runtime; pilot là bước bắt buộc tiếp theo.

§18. Phụ lục — 4 nguyên tắc lõi (tóm gọn cho Agent)

Để Agent áp dụng nhanh, 4 nguyên tắc lõi của LSL-01:

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.

§19. Changelog

v0.1 → v0.2 (GPT review v0.1, 12 điểm)

#	Mục	Sửa gì
1	§1, §14	Bỏ "đưa vào PG ngay từ bây giờ"; thay bằng "pilot/mock first, ghi PG production phải qua write path hợp pháp sau pilot".
2	§5	NT15 phạm vi giới hạn rõ "trực tiếp trong §2"; không tự động đè NT1/NT11/NT13 ngoài §2.
3	§6.2	Phân biệt "content lifecycle" (label không có) vs "registry status" (label value có). Không mâu thuẫn C2 §8.
4	§6.2, §8.3	Phân biệt structural label vs classification label.
5	§6.2	Bỏ pseudo-SQL; thay bằng mô tả concept-level.
6	§6.3, §12	Thêm: "Doc label ≠ publication membership".
7	§8.3	Canonical parent "ổn định" thay vì "bất biến tuyệt đối".
8	§8.4	Thêm: address là identity tại birth, không phải render position.
9	§10.2	Bỏ "Agent finalize tự do"; thay bằng "theo policy đăng ký, audit trail, qua birth gate".
10	§9.2, §10.1	Tách vector projection authority khỏi segmentation authority.
11	§11.2	Hard limit: WARN ở birth (không block draft); decision bắt buộc trước publish/enact.
12	§3	Thêm Quy tắc 5: LSL-01 không invalid hồi tố.

v0.2 → v0.3 (GPT review v0.2, 6 điểm)

#	Mục	Sửa gì
1	Header	Sửa "§3 và §15" → "§3, §12, §13" (§15 là lộ trình, không phải phạm vi override).
2	§4	Sửa câu "Không có 6 test, 12 test"; cho phép checklist phụ trợ khi nghi ngờ, không như điều kiện bắt buộc.
3	§6.2, §8.1	Tách `canonical_address` khỏi danh sách structural label; xếp riêng thành identity field.
4	§8.4	Sửa quy tắc address change: address của cùng logical_unit không đổi; split/merge tạo unit MỚI + address MỚI + retire cũ + successor relation. Re-address là exception risk cao.
5	§10.2	Owner đề xuất nâng/hạ risk; hạ risk high/highest cần authority hợp pháp, không do owner tự quyết.
6	§15	SOP pilot ghi "TBD by User".