Incomex AI Portal
KB-55FF

Draft Amend/Clarification - Đ38/Đ39 Text as Code v6 - 2026-04-24

9 min read Revision 1
codextext-as-code-v6dieu38dieu39legal-architecture

DRAFT - Amend/Clarification Đ38, Đ39 và luật nền cho Text as Code v6

  • Ngày: 2026-04-24
  • Trạng thái: DRAFT, không ban hành, không thay thế luật enacted
  • Nguồn: knowledge/dev/reports/codex-review-d38-d39-text-as-code-v6-alignment-2026-04-24.md

0. Làm sạch trạng thái Đ38

Chèn đầu knowledge/dev/laws/dieu38-normative-document-law.md hoặc tạo clarification riêng:

## TRẠNG THÁI PHÁP LÝ CỦA BẢN NÀY

Bản v3.x này là DRAFT AMENDMENT cho Điều 38. Bản này KHÔNG tự thay thế Điều 38 v2.3 đã ban hành cho tới khi hoàn tất Đ32/Đ37: APR hợp lệ, quorum/authority pass, provenance đầy đủ, validation pass, và bản enact mới được ghi nhận trong `normative_registry`.

Mọi triển khai dựa trên bản này trước khi enact chỉ là thiết kế/khảo sát/pilot, không phải căn cứ pháp quy chuẩn.

Loại: clarification-only.

1. Đ38 - scope mới

Thay câu MT1 hiện tại:

Mọi văn bản pháp quy (hiến pháp, luật, chính sách, quy định quản trị công ty...) được chia nhỏ...

bằng:

Mọi văn bản quản trị có hiệu lực vận hành - bao gồm Hiến pháp, luật, quy định nội bộ, chính sách, SOP, quy trình, hướng dẫn, template/hợp đồng/biên bản và các văn bản quản trị khác khi đã được đưa vào phạm vi quản trị - phải được chia thành đơn vị có cấu trúc và quản lý bằng PG ở mức tối đa có thể.

Raw chat, ghi chú phiên, report nháp, hoặc nội dung chưa qua promotion không tự động trở thành văn bản quản trị chuẩn. Các nguồn này chỉ là input/evidence cho pipeline Đ38/Đ39 cho tới khi được nâng cấp qua rule auto/manual, provenance, authority và validation.

Loại: scope-amendment.

2. Đ38 - Text as Code boundary

Chèn sau MT1:

## MT0 - Ranh giới Text as Code

Text as Code trong Điều 38 KHÔNG có nghĩa là LLM đọc text rồi tự do sinh code, sửa workflow, hoặc ban hành config.

Text as Code có nghĩa là văn bản được chuẩn hóa thành dữ liệu quản trị có cấu trúc:

1. `human_text`: câu chữ con người đọc.
2. `machine_semantics`: loại quy tắc, đối tượng áp dụng, hành động, điều kiện, ngưỡng, hiệu lực, thẩm quyền, mức bắt buộc.
3. `binding/provenance/effectivity`: liên kết tới PG/table/field/query/config/workflow/tool, nguồn, authority, valid_time, confidence, reviewer hoặc rule auto-approve.
4. `render_view`: bản trình bày sinh ra cho người đọc; render view không phải SSOT.

Chỉ phần mechanical/hard đã có machine semantics và binding hợp lệ mới được map sang code/config/guard/workflow qua DOT/trigger/flow/APR hợp pháp. Phần ngữ nghĩa mềm hoặc chưa chắc đúng chỉ được tạo proposal/candidate, không được tự thực thi.

Loại: wording-amendment.

3. Đ38 - Component governance

Chèn thêm mục tiêu:

## MT4 - SSOT Catalog + Component Registry + Reuse Governance

Điều 38 là nền cho việc quản trị văn bản theo tư duy component và assembly.

Mỗi đơn vị văn bản quản trị có thể được quản lý như component có vòng đời, authority, compatibility, dependency và traceability. Hệ thống phải hỗ trợ:

1. SSOT Catalog: document/revision/section/atom/binding/reference/annotation/render template.
2. Component Registry: component tái dùng được ở tầng text, code/config, workflow và knowledge scaffold.
3. Reuse Governance: trước khi tạo mới phải kiểm tra reuse/extend/variant từ component hiện có.
4. BOM/dependency chain: văn bản hoặc workflow sinh ra phải biết đang lắp từ component nào, version nào, dependency nào.
5. Compatibility matrix: version/variant nào tương thích hoặc cấm kết hợp.
6. Golden path/reference assembly: đường lắp ráp chuẩn định nghĩa bằng PG data, không bằng text hardcode.
7. Traceability: từ text atom -> binding -> code/config/guard/workflow -> KG edge/proposal phải truy ngược được.

Registry/Catalog KHÔNG được khai lại metadata vật lý mà PG/Directus/runtime đã biết. FK, trigger, constraint, table/field metadata, runtime artifact hash phải ưu tiên đọc từ PG catalog, Directus metadata, Git/runtime artifacts hoặc DOT scan. Registry chỉ khai lớp PG không tự biết: ý nghĩa nghiệp vụ, authority, lifecycle, semantic role, compatibility, reuse policy và assembly rule.

Loại: wording-amendment + cross-law-alignment.

4. Đ38 - PG Driven runtime và NT14

## MT5 - PG Driven Runtime

Điều 38 không chỉ dùng PG để lưu văn bản. PG phải điều khiển hành vi runtime qua: reuse policy, compatibility matrix, authority model, golden path definitions, assembly rules, routing metadata, thresholds/status/auto-manual rules, binding whitelist, render config, validation profiles và failure handling/escalation rules.

Không có config trong PG = không được hardcode trong agent/script. Cần ngoại lệ thì phải qua Đ32/Đ33/Đ35 và có expiry/audit.

## MT6 - Paired Check và NT14

Mọi capability cốt lõi của Điều 38 phải có cặp writer/builder và validator/auditor độc lập: atomize/verify, bind/verify, render/verify, assemble/assembly-verify, compat-check/compat-audit, trace-build/trace-audit.

Mỗi mục tiêu triển khai phải trả lời 6 câu NT14: data ở đâu, ai ghi, ai kiểm, khi nào chạy, kiểm bằng gì, sai thì làm gì. Không trả lời đủ = chưa enact/production.

Loại: cross-law-alignment.

5. Đ39 - ranh giới Workflow, Knowledge, Registry

Chèn sau §0:

## §0.1. Ranh giới cứng với Workflow và Component Registry

1. Knowledge Graph không phải workflow engine.
2. KG không sinh state transition, execution routing, retry logic, error handling hoặc choreography thực thi. Các phần này thuộc Workflow engine/Điều 34 hoặc luật vận hành tương ứng.
3. Workflow trace/event/outcome chỉ là evidence/input cho KG. Workflow trace không tự động trở thành tri thức chuẩn.
4. Knowledge layer mặc định là proposal/reasoning/explainability layer. Không có rule auto/manual trong PG = không auto-promote.
5. Chỉ khi có provenance, source_authority, temporal validity, validation và authority rule hợp lệ thì knowledge mới được nâng cấp thành truth chuẩn trong Catalog/Registry.
6. Component Registry và SSOT Catalog phục vụ reuse/assembly ở tầng Text-Code-Workflow. KG tiêu thụ, giải thích, suy luận và đề xuất; KG không thay registry/catalog.

Loại: clarification-only.

6. Đ39 - sửa câu dễ hiểu lệch

Sửa B2:

B2 | Customer Journey | Journey Orchestration | KG+AI đề xuất context/priority/next-best-action cho hành trình bất định; workflow engine vẫn là nơi thực thi choreography khi cần state/routing/retry/error handling

Sửa C1:

C1 | Scaffold Graph | TBox/ABox, Ontology Organizing | Đ38 semantic annotation + binding đã validate -> DOT-KG-SCAFFOLD-BUILD tạo graph khung; AI chỉ propose khi thiếu chắc chắn và không tự publish TBox

Sửa §7B ABox thường:

| ABox thường (link, weight, intent) | AI/DOT chỉ được auto-write trong phạm vi `kg_auto_approve_rules` đang active, có provenance + source_authority + validation; ngoài rule = candidate/APR | Nguyên tắc vàng + Đ32 |

7. Cross-law clarification

Đ33

Sửa §14.2 theo hướng:

PG_USER_DIRECTUS=directus          # runtime/application user cho DB directus
PG_USER_AGENT=incomex              # runtime user cho incomex_metadata qua Agent Data
PG_USER_ADMIN=workflow_admin       # admin/owner/emergency role nếu cần

Thêm:

Các bảng governance hiện hành, bao gồm `knowledge_documents`, `normative_registry`, `governance_*`, `kg_*`, `dot_*`, `meta_catalog`, nằm trong DB `directus`. Không đọc/chỉnh governance từ `incomex_metadata`; `incomex_metadata` chỉ là Agent Data document store/vector-adjacent store theo gateway riêng.

Đ32

Request/action cho `law_clarification` và `amend_law` phải có handler_ref hoặc DB gate rõ. Nếu handler chưa implement, chỉ được tạo report/draft; không được chuyển status approved/applied.

Payload tối thiểu: source law, current version, proposed version, patch text, reason, impacted laws, constitution check, quorum evidence, validation plan, rollback/supersede plan.

Hiến pháp/Điều 1

Không cần amend semantic. Nếu dọn wording: “Điều 1 | 14 Nguyên tắc Nền tảng”. Có thể thêm note owner/admin role khác runtime/application user.

Đ43

Sau khi v6 được duyệt, có thể thêm pattern hẹp cho approved Text-as-Code design docs vào context pack; không add toàn bộ knowledge__dev__reports__%.

8. Trình tự an toàn

  1. Publish report và draft dưới knowledge/dev/reports/.
  2. Owner/Hội đồng chốt status Đ38 hiện hành.
  3. Tạo APR law_clarification hoặc amend_law nếu muốn sửa luật.
  4. Soạn Đ38 amendment và Đ39 clarification, giữ DRAFT tới khi APR pass.
  5. Dọn Đ33 runtime user clarification.
  6. Chạy paired validation: constitution check, Đ38/Đ39 boundary check, NT11 anti-dup, NT14 implementability.
  7. Chỉ khi pass mới enact/supersede trong normative_registry.