LSL-01 v0.4 Patch Note

Phạm vi: patch note cho LSL-01 — Luật sửa luật: Miếng thông tin làm trung tâm v0.3. Trạng thái: DỰ THẢO để Opus + GPT + User review. Nguyên tắc: không rewrite LSL-01 v0.3; chỉ đề xuất 10 patch hardening cross-law consistency đã thống nhất Council.

Executive summary

LSL-01 v0.3 giữ nguyên doctrine chính: miếng thông tin là đơn vị trung tâm; label, publication, vector, quan hệ, review và change-set đều xoay quanh logical unit thay vì xoay quanh trang, file hoặc bảng. v0.3 đã PASS về hướng kiến trúc. v0.4 không đổi doctrine này, không thay mô hình ba lớp, không đưa thêm schema, không khóa tên bảng/cột/DOT, và không thay thế Đ24, Đ32, Đ33, Đ38, NĐ-36-01 hoặc các design note L1-L5/C1-C2.

Mục tiêu của v0.4 chỉ là harden tính nhất quán liên luật. Các patch dưới đây vá các điểm dễ gây hiểu nhầm khi LSL-01 được dùng như luật sửa luật kiểu doctrine: phiên bản Hiến pháp, NT14/NT15, lớp label theo Đ24, phân vai Directus/Qdrant theo Đ33, publication level theo Đ38, quorum theo Đ32, hạ tầng quan hệ ngữ nghĩa theo NĐ-36-01, mapping thuật ngữ text unit/logical unit, địa chỉ định danh so với quan hệ cấu trúc, và wording DOT mềm theo Đ35/Đ33.

Không có patch nào nhằm chốt schema runtime. Content layer vẫn là Directus/Lớp KHO; vector layer vẫn là Qdrant/Lớp NÃO; cổng runtime và write path hợp pháp vẫn phải đi theo luật hiện hành. LSL-01 v0.4 chỉ làm rõ thẩm quyền và ranh giới để khi bước sang pilot, hệ thống không tạo registry song song, không bypass quorum, không biến vector thành nguồn authority, và không chốt hạ tầng trước các giai đoạn thiết kế/pilot.

P1 — Cập nhật authority Hiến pháp và sửa câu "cõi tạm"

Vị trí: §1 phần mở đầu/nền tảng authority và §13 phần bảng conflict/authority của LSL-01 v0.3.

Lý do: LSL-01 v0.3 còn dấu vết tham chiếu Hiến pháp v4.6.2 trong khi authority hiện hành là Hiến pháp v4.6.3. Cụm "cõi tạm" ở §1 dễ bị đọc như một hình ảnh thay cho authority pháp lý, làm yếu vai trò Hiến pháp.

Đoạn thay thế: Thay mọi tham chiếu "Hiến pháp v4.6.2" trong §13 bằng "Hiến pháp v4.6.3". Tại §1, thay câu có cụm "cõi tạm" bằng:

LSL-01 được ban hành theo Hiến pháp Kiến trúc Hệ thống Incomex v4.6.3. Mọi override hoặc diễn giải trong LSL-01 chỉ có hiệu lực trong phạm vi luật này được giao xử lý; authority tối cao vẫn thuộc Hiến pháp hiện hành và các điều luật nền tảng chưa bị override hợp lệ.

Mức độ: High.

P2 — Làm rõ NT14/NT15: doctrine trước, runtime sau

Vị trí: §2 phạm vi doctrine, §12/§13 về override, và §15 lộ trình pilot của LSL-01 v0.3.

Lý do: NT14 yêu cầu luật có khả năng mô phỏng được, nhưng LSL-01 hiện là luật doctrine. Cần nói rõ v0.4 chưa miễn nghĩa vụ pilot, đồng thời NT15 chỉ áp ở mức doctrine cho đến khi amend Hiến pháp chính thức sau pilot giai đoạn 4.

Đoạn bổ sung: Bổ sung cuối §2 hoặc đầu §15:

LSL-01 tuân thủ NT14 ở cấp doctrine: luật xác định đơn vị trung tâm, authority, ranh giới lớp và điều kiện pilot, nhưng chưa chốt schema, runtime, tên DOT, tên bảng hoặc write path. Trước khi áp dụng vào production runtime, LSL-01 phải đi qua pilot theo lộ trình đã nêu, đặc biệt là gate sau giai đoạn 4. NT15 trong LSL-01 chỉ được hiểu là ưu tiên doctrine trong phạm vi mâu thuẫn trực tiếp đã liệt kê; việc nâng NT15 thành hiệu lực runtime hoặc amend Hiến pháp phải chờ amend Hiến pháp chính thức sau pilot giai đoạn 4.

Mức độ: High.

P3 — Label layer phải dùng Đ24, không tạo registry song song

Vị trí: §6 label layer và §13 conflict matrix của LSL-01 v0.3.

Lý do: LSL-01 dùng label như lớp mô tả/nhóm. Nếu wording không ràng về Đ24, người đọc có thể hiểu LSL-01 tạo một label registry mới cạnh taxonomy_facets, label_rules, entity_labels.

Đoạn bổ sung: Bổ sung cuối phần label layer:

Label layer của LSL-01 phải dùng và tương thích Đ24. Các nhãn, facet, rule và quan hệ entity-label hiện hành vẫn thuộc hệ thống Đ24; LSL-01 không tạo label registry song song. Khi cần gắn label vào logical unit, thiết kế pilot phải map vào hạ tầng nhãn hiện hành hoặc mở amend/crosswalk riêng, không định nghĩa kho nhãn độc lập trong LSL-01.

Mức độ: High.

P4 — Tách rõ content layer và vector layer theo Đ33

Vị trí: §7 content/vector layer và §18 bốn nguyên tắc lõi của LSL-01 v0.3.

Lý do: Đ33 xác lập kiến trúc 4 database + 3 lớp NÃO-KHO-CỔNG. LSL-01 cần nói rõ content authority nằm ở Directus/Lớp KHO; Qdrant/Lớp NÃO là projection/search, không phải nguồn authority. Không được chốt bảng.

Đoạn thay thế: Thay đoạn mô tả content/vector bằng:

Content layer của LSL-01 thuộc Directus/Lớp KHO: đây là nơi lưu nội dung canonical và metadata quản trị theo write path hợp pháp. Vector layer thuộc Qdrant/Lớp NÃO: đây là projection phục vụ tìm kiếm, so khớp, gợi ý và retrieval; vector không tự tạo authority, không override content canonical, và không quyết định trạng thái pháp lý của logical unit. LSL-01 không chốt bảng, cột, index hoặc cơ chế đồng bộ cụ thể; các chi tiết đó thuộc thiết kế/pilot theo Đ33 và luật triển khai liên quan.

Mức độ: High.

P5 — Áp Đ38 §A3 + §B2.1 cho publication level

Vị trí: §8 publication/addressing và §13 conflict matrix của LSL-01 v0.3.

Lý do: Đ38 v3.0 quy định vòng đời văn bản, version, retire và publication behavior. LSL-01 cần gắn publication level vào Đ38 để tránh tự định nghĩa đường vòng đời văn bản.

Đoạn bổ sung: Bổ sung vào cuối phần publication level:

Khi một unit_version nằm trong published_snapshot của một publication đã enacted, amend hoặc retire publication phải tuân thủ Đ38 §A3 và §B2.1 ở publication level: bản cũ bất biến, version mới được tạo qua quy trình amend, retire không làm mất lịch sử, và document enacted chỉ chứa unit có trạng thái hợp lệ. LSL-01 không tự mở lifecycle publication riêng ngoài Đ38.

Mức độ: High.

P6 — Quorum cao nhất: high + User direct approval

Vị trí: §10 review/change-set approval, §12 hardening, và §15 pilot gate của LSL-01 v0.3.

Lý do: Các thay đổi ở cấp unit có thể làm thay đổi nghĩa luật. Với mức highest, cần áp dụng đầy đủ Đ32 §4.3: phân loại high, đủ quorum, và User direct approval. Không được hạ xuống checklist mềm.

Đoạn thay thế: Thay đoạn mô tả highest approval bằng:

Mọi change-set ở mức highest được phân loại tối thiểu là high theo Đ32 và phải có User direct approval. Hardening Đ32 §4.3 áp dụng đầy đủ: phân loại rủi ro, quorum phù hợp, review nội dung, review tác động cross-law, và approval cuối cùng trước khi enact hoặc bật production path. LSL-01 không tạo ngoại lệ để bypass APR hoặc hạ cấp quyết định làm thay đổi nghĩa luật.

Mức độ: High.

P7 — Tham chiếu NĐ-36-01 cho aliases/entity_relations gắn logical_unit

Vị trí: §17 phần crosswalk/hạ tầng quan hệ và phụ lục liên luật của LSL-01 v0.3.

Lý do: NĐ-36-01 sở hữu hạ tầng nhận diện, alias, relation mềm, provenance chuẩn và candidate resolution. LSL-01 cần gắn logical_unit vào hạ tầng đó thay vì mở quan hệ ngữ nghĩa riêng.

Đoạn bổ sung: Bổ sung vào §17:

Quan hệ alias, entity relation, disambiguation và relation dictionary liên quan đến logical_unit phải tham chiếu NĐ-36-01. LSL-01 chỉ xác định rằng logical_unit là đối tượng có thể được gắn quan hệ; hạ tầng nhận diện quan hệ, alias, provenance và candidate resolution thuộc NĐ-36-01. Nếu pilot cần trường hoặc connector mới để gắn aliases/entity_relations với logical unit, nội dung đó phải đi qua thiết kế/pilot của NĐ-36-01 và Đ38, không được chốt trong LSL-01.

Mức độ: Medium.

P8 — Chuẩn hóa thuật ngữ: đoạn = text unit = logical unit = miếng

Vị trí: §4 định nghĩa, §18 tóm tắt cho Agent, và mọi nơi LSL-01 v0.3 dùng lẫn "đoạn", "text unit", "logical unit", "miếng".

Lý do: LSL-01 có chủ đích unit-centric, nhưng nhiều thuật ngữ đồng nghĩa dễ khiến Agent tưởng là nhiều loại entity khác nhau.

Đoạn bổ sung: Bổ sung vào §4:

Trong LSL-01, các thuật ngữ 'đoạn', 'text unit', 'logical text unit', 'logical unit' và 'miếng thông tin' được dùng đồng nghĩa khi nói về đơn vị nội dung có nghĩa độc lập trong văn bản. Các thuật ngữ 'phiên bản đoạn', 'text unit version', 'unit version' và 'phiên bản miếng' được dùng đồng nghĩa khi nói về bản nội dung cụ thể của một miếng tại một thời điểm. Nếu cần phân biệt về UI, import hoặc render, tài liệu triển khai phải ghi rõ đó là biến thể trình bày hoặc xử lý, không phải entity pháp lý mới.

Mức độ: Medium.

P9 — Phân biệt canonical_address với parent_unit/sort_order

Vị trí: §8.4 addressing, §9 structure/relations, và crosswalk với C2 Metadata Governance.

Lý do: v0.3 đã sửa canonical_address thành identity field, nhưng cần harden để không mâu thuẫn C2. canonical_address là địa chỉ định danh ổn định; parent_unit/sort_order là quan hệ cấu trúc có thể thay khi render/assembly hợp pháp.

Đoạn thay thế: Thay đoạn giải thích addressing bằng:

canonical_address là identity/address bất biến của logical_unit trong văn bản và không được dùng như nhãn cấu trúc thường. parent_unit và sort_order thuộc nhóm identity/structural metadata gắn logical_unit theo tinh thần C2, nhưng là structural relation có integrity rule riêng, không phải identity immutable như canonical_address. Thay đổi parent_unit hoặc sort_order trong cây canonical là structural change và phải đi qua change-set/approval theo risk tier; render_order hoặc alternative position của một publication có thể khác canonical order nhưng không làm đổi canonical parent/sort_order. Quy tắc này tương thích C2 Metadata Governance: cùng là metadata gắn logical_unit, nhưng schema phase có thể lưu canonical_address, parent_unit và sort_order bằng cơ chế khác nhau để bảo toàn constraint và audit.

Mức độ: High.

P10 — Wording DOT mềm, không chốt tên đơn vị DOT

Vị trí: §15 pilot, §16 DOT/checker, và §18 tóm tắt cho Agent của LSL-01 v0.3.

Lý do: LSL-01 cần nói tới DOT để bảo đảm mô phỏng và kiểm tra, nhưng không được chốt tên DOT/bảng/cột trước Đ35/Đ33 paired design. Wording cứng dễ tạo hạ tầng sai authority.

Đoạn thay thế: Thay wording cứng về DOT bằng:

Pilot LSL-01 phải có cơ chế DOT/checker phù hợp Đ35 và Đ33 theo nguyên tắc paired governance. LSL-01 chỉ yêu cầu có đường kiểm tra hợp pháp cho logical unit, change-set, publication và relation; không chốt dot-unit-* như tên DOT bắt buộc, không chốt tên bảng/cột, và không cho phép runtime path nào vượt qua gateway hợp pháp của Đ33.

Mức độ: Medium.

Phụ lục — Changelog v0.3 → v0.4

Patch	Thay đổi	Tác động
P1	Cập nhật authority HP v4.6.3 và sửa câu "cõi tạm"	Giữ supremacy Hiến pháp
P2	Làm rõ NT14 doctrine/runtime và NT15 sau pilot giai đoạn 4	Tránh hiểu v0.4 là runtime-ready
P3	Ràng label layer vào Đ24	Không tạo registry song song
P4	Tách Directus/Lớp KHO và Qdrant/Lớp NÃO	Giữ authority content, vector chỉ projection
P5	Gắn publication level vào Đ38 §A3 + §B2.1	Không mở lifecycle publication riêng
P6	Highest = high + User direct approval theo Đ32 §4.3	Không bypass quorum
P7	Tham chiếu NĐ-36-01 cho alias/relation	Không mở hạ tầng quan hệ riêng
P8	Chuẩn hóa thuật ngữ unit	Tránh nhân đôi entity
P9	Tách identity address và structural relation	Tương thích C2
P10	DOT wording mềm theo Đ35/Đ33	Không chốt hạ tầng trước pilot

Note: v0.4 rev2 sau Council vòng 3: P5/P8/P9 hardened theo GPT review.

Disagreement / Alternative

Không có disagreement trong bản ghi này. Các patch giữ đúng hướng dẫn: harden v0.3 thành v0.4, không rewrite luật, không thiết kế schema, không patch luật khác, và chờ Opus + GPT + User review trước mọi bước upload KB.