Đặt vấn đề sửa IU

Trạng thái: DRAFT / non-authorizing.
Vị trí: knowledge/dev/laws-new/new-iu/dat-van-de-sua-iu.md
Vai trò: Tài liệu đặt vấn đề, đứng trước tài liệu giải pháp de-bai-mieng-thong-tin-moi-lego.md.
Không phải: thiết kế triển khai, approval, enactment, migration, schema, DOT, runtime authorization.

1. Vì sao phải đặt lại vấn đề IU

Thiết kế “miếng thông tin” cũ có nhiều điểm mạnh: định danh logic, version, current/head, quan hệ ngữ nghĩa, khả năng phục vụ Text-as-Code, context cho agent, render/reconstruct, vector boundary và traceability. Tuy nhiên, nếu tiếp tục phát triển theo hướng một IU engine riêng, nó có nguy cơ đi ngược định hướng tái cấu trúc trong /laws-new/.

Vấn đề chính không phải là “IU không có giá trị”, mà là cách tổ chức IU cũ có xu hướng trở thành một vương quốc riêng.

2. Các vấn đề đang gặp phải

2.1 IU có nguy cơ quá cồng kềnh

Nếu IU tự có registry, staging, command catalog, governance, approval, axis, graph, DOT, render và lifecycle riêng, nó sẽ trở thành một hệ thống độc lập khó hoàn thành dứt điểm. Mỗi phần lại kéo theo một phần hạ tầng khác, tạo vòng “quả trứng con gà”: đang làm thông tin thì vướng governance; đang làm governance thì vướng axis; đang làm axis thì vướng KG; đang làm KG thì vướng promote/checker.

2.2 IU có nguy cơ đi ngược triết lý Lego của `/laws-new/`

/laws-new/ đang chuyển hệ thống sang hướng lắp ráp Lego: mỗi phần nhỏ có IO Contract, checker, stamp, promote, rollback, owner gate và reuse-first. IU mới phải nằm trong triết lý đó. Nếu IU tự tạo một pipeline riêng, nó sẽ không còn là một “miếng Lego”, mà thành một nhà máy riêng.

2.3 IU có nguy cơ trùng việc PG/collection/cell đã làm tốt

PG và collection đã rất mạnh ở các việc: lưu trữ, schema, constraint, join, FK, view, count, pivot, carrier, audit/changelog, render surface. Nếu IU tự làm lại các việc này, chi phí tăng mạnh và độ tin cậy giảm. Nguyên tắc mới phải là: PG/collection/cell làm carrier chính; IU không rebuild những gì PG làm tốt.

2.4 IU có nguy cơ tạo governance island

IU cũ từng có dấu hiệu tách riêng: owner_ref free-text, command catalog riêng, relation/axis riêng, conformance mở, các báo cáo live snapshot chưa được current-pass verify. Nếu tiếp tục tự quản owner, approval, DOT, axis hoặc KG, IU sẽ phá nguyên tắc One-Roof Governance.

2.5 IU có nguy cơ chọn sẵn substrate trước khi đủ bằng chứng

Các phần như KG edge, staging store, axis model, vector boundary, Directus/Nuxt surface và promote path chưa nên được coi là đã chọn xong. Tài liệu mới phải phân biệt rõ: DRAFT direction, documentary snapshot, current-pass live proof, technical readiness và Owner/Governance decision.

3. Câu hỏi trung tâm

Câu hỏi cần trả lời không phải là “có giữ IU hay bỏ IU”. Câu hỏi đúng là:

PG/collection/cell có thể thay IU đến đâu, và IU chỉ nên bổ sung lớp contract nào mà PG không xử lý đủ tốt?

Nếu một phần có thể để PG/collection/cell làm an toàn, đáng tin cậy và dễ kiểm chứng hơn, thì để PG làm. IU mới chỉ nên giữ phần giá trị logic mà PG thuần không đủ tốt: stable logical subject, current/head semantics, supersession, Text-as-Code traceability, semantic relation, context pack, impact, release, stale/superseded detection và integration với KG/governance chung.

4. Hướng giải quyết được chọn làm giả thuyết

Giả thuyết làm việc hiện tại:

New IU = lớp Subject Contract mỏng trên PG/Matrix/Lego/One-Roof, không phải một hệ thống riêng.

Nói cách khác:

PG/collection/cell là carrier chính.
Matrix/Lego IO Contract là giao tiếp chung.
Checker/stamp/promote/rollback là envelope chung.
Governance/owner/approval là One-Roof chung.
KG/semantic relation là hệ graph chung hoặc projection được governed, không phải KG riêng của IU.
DOT/event/issue/registry dùng hệ chung, không tạo catalog riêng.
IU chỉ giữ logical subject contract và các invariant Text-as-Code cần thiết.

5. Nguyên tắc thiết kế New IU

PG-first: không làm lại storage, schema, constraint, join, count, pivot, view nếu PG làm tốt.
Reuse-first: khảo sát và tận dụng tối đa tài sản IU cũ, nhưng không reuse AS_IS nếu còn nợ governance, axis, conformance, proof hoặc island risk.
Thin-contract: IU là lớp contract logic, không phải control plane.
Lego-compatible: mọi phần phải ghép được bằng IO Contract, checker, stamp, promote, rollback.
One-Roof: không governance riêng, không approval riêng, không owner riêng.
Shared birth: không khai sinh riêng; candidate/stamp/promote phải theo hệ chung.
Shared KG: không graph SoT thứ hai; KG substrate phải được verify trước khi chọn.
No hardcode: không giữ mô hình axis cứng nếu trái hướng open-axis/matrix/cell.
No duplicate registry: command catalog, DOT, event, issue, registry phải dùng hệ chung hoặc read-only compatibility projection.
Giữ invariant, không giữ mechanism bằng mọi giá: stable identity, current semantics, traceability, provenance, reversible change là điều cần giữ; table/function cũ chỉ giữ nếu còn phù hợp.

6. Quan hệ với tài liệu đề bài hiện tại

Tài liệu này là phần đặt vấn đề. Tài liệu tiếp theo là phần đề bài/giải pháp định hướng:

knowledge/dev/laws-new/new-iu/de-bai-mieng-thong-tin-moi-lego.md

Quan hệ giữa hai file:

dat-van-de-sua-iu.md trả lời: vì sao phải sửa IU, vấn đề cũ là gì, mục tiêu đặt lại là gì.
de-bai-mieng-thong-tin-moi-lego.md trả lời: đề bài New IU nên được tổ chức thế nào theo PG-first / Lego / One-Roof / thin contract.

7. Kết luận

Không bỏ giá trị của miếng thông tin cũ. Nhưng cũng không tiếp tục xây IU như một hệ riêng.

Hướng đúng là:

Giữ điểm mạnh của IU cũ ở tầng invariant và Text-as-Code, nhưng triển khai lại như một lớp contract mỏng, dùng PG/collection/cell làm carrier, dùng Lego/IO Contract làm giao tiếp, dùng One-Roof làm governance, dùng hệ chung cho birth/KG/DOT/event/approval.

Mọi bước tiếp theo phải đi chậm, theo lát nhỏ, read-only/design-first, và chỉ chuyển sang runtime khi có đủ technical proof và Owner/Governance authorization.