Incomex AI Portal
KB-50B6

Roadmap Cải tiến — Matrix Assembly + Stamp Governance (đường đi trước khi viết checker/pilot)

16 min read Revision 1
laws-newmatrix-assemblystamp-governanceroadmapsystem-substrate-checkpromote-checkeratomic-promotedraftnot-enacted2026-06-14

Roadmap Cải tiến — Matrix Assembly + Stamp Governance

Trạng thái: DRAFT — KHÔNG PHẢI BAN HÀNH. Tài liệu lập đường đi (roadmap), không phải luật mới, không phải checker, không phải mở pilot. Ngày: 2026-06-14 · Track: knowledge/dev/laws-new/ · Không sửa knowledge/dev/laws/.

Đọc cùng 3 SSOT: matrix-refactor-implementation-plan.md · matrix-refactor-quick-rules.md · matrix-stamp-governance-addendum.md. Cấu hình dấu: required-stamps.v0.1.json. Spec checker: promote-checker-v0.1-spec.md. Hướng cũ Module-Contract-First / Federated-Registry: chỉ archive-2026-06-12/, reference-only, KHÔNG phục hồi.

1. Executive summary

Hướng Matrix Assembly + Stamp Governance + Minimal Birth + Promote Checker đã đúng về lifecycle: tách pre-promote stamp store khỏi post-promote stamp store; checker verdict-only; atomic promote transaction tách khỏi checker; candidate packet bind bằng candidate_id + packet_hash; cleanup TTL/fail-safe; không mở pilot khi chưa có atomic promote rehearsal.

Nhưng chưa đủ để triển khai. Codex audit trước trả STATUS: BLOCKED; sau khi sửa tài liệu ở mức thiết kế, đã PASS về tài liệu/lifecycle nhưng HOLD về kiểm tra thực tế substrate. Chưa viết checker, chưa mở pilot.

Roadmap này dùng để kiểm tra thực tế trước khi viết checker/pilot, gỡ các HOLD do Codex nêu, và tránh lặp lại thất bại của hướng khai sinh cũ (đẩy mọi thứ vào khai sinh → P0 phình → lặp vô hạn).

Phân loại trạng thái hiện tại

Hạng mục Trạng thái
Documentation lifecycle PASS
System substrate HOLD (chưa xác nhận iu_core.iu_staging_record / iu_staging_payload)
Checker implementation NOT STARTED
Pilot BLOCKED UNTIL CHECKER + ATOMIC PROMOTE REHEARSAL

HOLD chính còn lại (carried forward từ addendum §2b, §7b, checker-spec §2.1, §7)

  • HOLD-1 (SYSTEM CHECK): iu_core.iu_staging_record / iu_core.iu_staging_payload có tồn tại không? schema/lifecycle/status/TTL đủ để lưu candidate packet + pre-promote stamps không? có bind được rollback proof / validator result theo candidate_id không? có thiết kế được atomic promote transaction không?
  • HOLD-2 (ATOMIC PROMOTE): chưa có atomic promote transaction thật + rehearsal proof (staging, FIX7 style) → CHƯA mở pilot promote live.

Đường đi tóm tắt

docs fixed → system check → candidate packet → checker selftest
→ atomic promote rehearsal → Codex confirm → pilot

2. Các nguyên tắc khóa (locked principles)

Ghi rõ để không trôi (đồng bộ quick-rules S1–S14, addendum §2b/§7b):

  1. Khai sinh không gánh toàn bộ governance — chỉ cấp căn cước tối thiểu (8 câu gốc / 8 cột birth_registry đã ban hành).
  2. Object kho tạm có TEMP_ID_STAMP, KHÔNG có BIRTH_STAMP canonical. Hai căn cước tách biệt, không dùng một dấu cho hai nghĩa.
  3. BIRTH_STAMP và PROMOTE_STAMP chỉ là OUTPUT sau khi promote pass (promote_outputs), không phải precondition — tránh circular.
  4. Checker chỉ kiểm MỘT candidate packet (bind candidate_id + packet_hash), không scan toàn hệ, không tự suy từ artifact rời rạc.
  5. PROMOTE_OK chỉ là verdict, KHÔNG phải mutation. Checker không sinh birth, không ghi canonical, không đóng dấu.
  6. Atomic promote transaction mới tạo birth/canonical/stamp + consume staging — all-or-nothing, tách khỏi checker.
  7. Scanner chỉ liệt kê (missing stamps / orphan / promote-blocked), không sửa toàn hệ, không thay checker, không thành governance macro.
  8. Không mở pilot nếu chưa chứng minh "sai thì xóa được" (delete-ability staging + rollback proof).
  9. Fail-closed: thiếu 1 dấu bắt buộc → PROMOTE_BLOCKED; nghi ngờ → escalate Tier 3. Class blast-radius COMPUTED, không tự khai.
  10. Production/kernel vẫn governance nặng — Matrix/Stamp chỉ tăng tốc workspace + promote nội bộ; KHÔNG dùng để né production/kernel gate (Mức 3 / Đ32).

3. Roadmap theo giai đoạn

Tối thiểu 6 giai đoạn. Mỗi phase có mục tiêu + output + trạng thái cổng. Tất cả Phase 1 trở đi là read-only/design cho tới khi có grant riêng.

Phase 0 — Freeze tài liệu nền

Mục tiêu:

  • Xác nhận 7 file active đã đồng bộ, không còn mâu thuẫn lifecycle.
  • required-stamps.v0.1.json là nguồn cấu hình dấu duy nhất (checker đọc file này, không hardcode).
  • promote-checker-v0.1-spec.md chỉ là spec, chưa triển khai.

Checklist nhất quán (làm ngay trong roadmap, không cần file riêng):

Mục kiểm Kỳ vọng OK?
7 file active hiện diện README + de-bai + plan + quick-rules + addendum + required-stamps + checker-spec ✅ (listed)
Số dấu lõi 7 (≤ trần 8–10): TEMP_ID · BIRTH · CELL · IO · VALIDATION · ROLLBACK · PROMOTE ✅
precond ≠ output precond = TEMP_ID+CELL+IO+VALIDATION+ROLLBACK; output = BIRTH+PROMOTE ✅
Verdict set thống nhất PROMOTE_OK / PROMOTE_BLOCKED / ESCALATE_L3 ✅
Hai stamp store tách biệt pre-promote (staging metadata) vs post-promote (birth_registry) ✅
HOLD đã ghi rõ substrate check + atomic promote rehearsal ✅
Hướng cũ archive-only Module-Contract-First/Federated-Registry không drive ✅

Output: checklist trên (inline trong roadmap). Không tạo file riêng nếu không cần. Cổng: Phase 0 PASS = không có mâu thuẫn lifecycle còn lại → mở Phase 1.

Phase 1 — System substrate check (READ-ONLY)

Mục tiêu: trả lời HOLD-1. Kiểm tra thực tế substrate, chỉ đọc, không mutate, không tạo bảng.

Bề mặt cần kiểm (read-only):

iu_core.iu_staging_record
iu_core.iu_staging_payload
sandbox_tac
candidate / workspace metadata
event_outbox
registry_changelog
system_issues
validator result storage (FIX7 artifacts)
rollback proof storage (PROVEN_IN_STAGING)
TTL / cleanup mechanism
governance_candidate_state (SB-10, design-only)

Câu hỏi phải trả lời:

  1. Có iu_staging_record không? Có iu_staging_payload không?
  2. Có status lifecycle không (draft / ready_for_check / promote_ok / consumed / expired / quarantined)?
  3. Có TTL / expires_at không?
  4. Metadata có đủ chỗ lưu pre-promote stamps (TEMP_ID/CELL/IO/VALIDATION/ROLLBACK) không?
  5. Có packet_hash hoặc cách hash packet ổn định không?
  6. Có candidate_id ổn định không?
  7. Có bind được IO Contract / validator result / rollback proof cùng candidate_id không?

Output: system-substrate-check-report (read-only, không file mới nếu có thể ghi inline; nếu cần file thì DRAFT trong laws-new/). Trạng thái cổng: GO / PARTIAL / HOLD / BLOCKED.

  • GO/PARTIAL acceptable → Phase 2.
  • HOLD/BLOCKED → dừng, đề xuất substrate tối thiểu, không tự tạo bảng.

Phase 2 — Candidate packet design (chỉ sau Phase 1)

Mục tiêu: chốt nơi lưu + hình dạng candidate packet, dựa trên kết quả substrate thực tế.

Sơ bộ (đồng bộ checker-spec §2.1 matrix_candidate_packet.v0.1):

matrix_candidate_packet.v0.1:
  candidate_id:        string
  workspace_id:        string | null
  cell_id:             { layer, species, collection, domain }
  stamps:              { TEMP_ID_STAMP, CELL_STAMP, IO_STAMP, VALIDATION_STAMP, ROLLBACK_STAMP }
  io_contract_ref:     string
  validator_result_ref: string
  rollback_proof_ref:  string
  created_at:          timestamp
  expires_at:          timestamp
  status:              draft|ready_for_check|promote_blocked|promote_ok|consumed|expired|quarantined
  packet_hash:         sha256

Yêu cầu:

  • KHÔNG tạo registry mới.
  • Ưu tiên dùng staging payload (iu_staging_payload) nếu Phase 1 = GO/PARTIAL.
  • Nếu substrate không đủ → đề xuất staging JSON tối thiểu (sandbox-local Đ41), không vội tạo bảng.
  • KHÔNG dùng system_issues làm ledger chính (chỉ cho lỗi).
  • KHÔNG dùng meta_catalog làm per-candidate store (xung đột per-object ledger).
  • KHÔNG ghi birth_registry canonical ở staging.

Output: candidate-packet-v0.1-sketch (design-only). Cổng: packet storage đã chốt + hash ổn định + bind theo candidate_id chứng minh được → Phase 3.

Phase 3 — Promote checker selftest design

Mục tiêu: thiết kế selftest, chưa viết checker thật nếu chưa được duyệt.

Checker phải (đồng bộ checker-spec §3–§5): đọc 1 candidate packet; đọc required-stamps.v0.1.json; kiểm preconditions; trả verdict; không mutate; không sinh birth; không ghi canonical; không scan toàn hệ.

Selftest tối thiểu (checker-spec §6):

Case Verdict kỳ vọng
Đủ preconditions nhưng chưa có BIRTH/PROMOTE PROMOTE_OK
Thiếu từng precondition (drop từng dấu) PROMOTE_BLOCKED đúng tên dấu thiếu, no fail-open
cell_id UNKNOWN/PENDING PROMOTE_BLOCKED
Packet tamper / packet_hash sai PROMOTE_BLOCKED (hoặc quarantined)
Expired / stale (quá expires_at) PROMOTE_BLOCKED
High-risk thiếu GOV/OWNER ESCALATE_L3 hoặc PROMOTE_BLOCKED
Artifact khác candidate_id (cross-candidate) PROMOTE_BLOCKED, no self-assemble

Output: promote-checker-selftest-plan (design-only). Cổng: selftest plan được duyệt + (nếu được grant riêng) checker thật chạy selftest PASS fail-closed → điều kiện cần để Phase 4 có ý nghĩa.

Phase 4 — Atomic promote transaction design

Mục tiêu: thiết kế sơ bộ transaction, chưa chạy thật. Transaction chỉ chạy sau PROMOTE_OK.

Phải all-or-nothing (addendum §7b):

1. lock staging record (SELECT FOR UPDATE)
2. verify packet hash / status / TTL (chưa expired/consumed)
3. create canonical birth_id / entity_code (nếu cần)
4. write canonical object → kho chính
5. close BIRTH_STAMP   (post-promote store)
6. close PROMOTE_STAMP (post-promote store)
7. mark staging record = consumed
8. write audit/provenance (register-before-emit: event_outbox / registry_changelog / governance_audit_log)
9. nếu BẤT KỲ bước nào fail → ROLLBACK toàn bộ transaction

Negative states phải test (FORBIDDEN — transaction phải chặn):

  • birth-only (có BIRTH_STAMP, thiếu canonical write / PROMOTE_STAMP)
  • promote-stamp-only (có PROMOTE_STAMP, thiếu birth)
  • canonical write thiếu ROLLBACK_STAMP pass
  • staging consumed nhưng canonical write fail
  • canonical write pass nhưng staging chưa consumed (double-promote risk)

Output: atomic-promote-v0.1-sketch (design-only). Cổng: design all-or-nothing + đủ negative states → điều kiện cần cho rehearsal Phase 5.

Phase 5 — Rehearsal on clone/staging (KHÔNG đụng production)

Mục tiêu: trả lời HOLD-2 — chứng minh atomic promote chạy được trên clone/staging.

Yêu cầu:

  • BEGIN ... ROLLBACK rehearsal.
  • Production-shaped PG clone nếu có (secret-free, isolated).
  • FIX7-style rollback proof nếu phù hợp.
  • Negative tests (5 trạng thái forbidden ở Phase 4).
  • Cleanup safety test (TTL/fail-safe).
  • No canonical mutation, no production contact.

Output: atomic-promote-rehearsal-report. Cổng: rehearsal PASS + rollback proven + cleanup fail-safe PASS → điều kiện cần cho quyết định pilot.

Phase 6 — Pilot readiness decision

Chỉ quyết định pilot khi có ĐỦ:

  • system substrate check PASS / PARTIAL acceptable (Phase 1)
  • candidate packet design accepted (Phase 2)
  • checker selftest pass (Phase 3)
  • atomic promote rehearsal pass (Phase 5)
  • TTL / cleanup fail-safe pass
  • Codex re-audit không còn blocker

Output: quyết định PILOT_GO / PILOT_HOLD / PILOT_BLOCKED. Mặc định: PILOT_HOLD cho tới khi tất cả điều kiện trên đạt + có grant owner.

4. Codex checkpoints

Chỉ gọi Codex ở chốt rủi ro cao để tiết kiệm quota — KHÔNG gọi ở mọi bước nhỏ.

Checkpoint Sau Phase Codex audit cái gì
Codex Checkpoint 1 Phase 1–2 substrate check report + candidate packet design (binding candidate_id/packet_hash, store split đúng)
Codex Checkpoint 2 Phase 3–4 checker selftest plan + atomic promote design (verdict-only, all-or-nothing, negative states)
Codex Checkpoint 3 Sau Phase 5 (rehearsal report) quyết định có mở pilot không (rehearsal proof, cleanup fail-safe, không còn blocker)

5. Risk register

# Rủi ro Mitigation ngắn
R1 staging substrate không tồn tại hoặc schema không đủ Phase 1 read-only check trước; nếu thiếu → staging JSON tối thiểu sandbox-local, không tự tạo bảng
R2 candidate packet không bind được artifact Phase 2 chốt binding candidate_id + packet_hash; fail-closed nếu cross-candidate
R3 packet hash không ổn định Phase 1 câu hỏi #5; chọn cơ chế hash canonical (sha256 nội dung chuẩn hóa) trước khi viết checker
R4 validator result không bind được candidate_id Phase 1 câu hỏi #7; nếu không bind được → PARTIAL, không lên Phase 3
R5 rollback proof chưa có ROLLBACK_STAMP là precondition; không có proof → PROMOTE_BLOCKED
R6 atomic promote không all-or-nothing Phase 4 design + Phase 5 rehearsal negative-state tests bắt buộc
R7 cleanup xóa nhầm candidate đang promote TTL + fail-safe: chỉ xóa draft/expired/quarantined; cấm xóa checking/promote_ok-unconsumed/approved; nghi ngờ → không xóa (quick-rule S14)
R8 checker phình thành scanner toàn hệ Checker đọc 1 packet, verdict-only; scanner tách riêng chỉ liệt kê (addendum §6)
R9 stamp phình quá 8–10 Trần v0.1 = 7; thêm dấu MANDATORY mới = đổi Tier 3; inspector mịn nằm dưới dấu lõi
R10 domain biến thành ontology lớn Domain v0.1 = controlled tag (domain_code·name·owner·scope·allowed_species), không cây phức tạp
R11 production / kernel gate bị né Matrix/Stamp chỉ tăng tốc workspace+promote; chạm production/kernel → Mức 3 / Đ32 nguyên vẹn
R12 "paper lane" (lane trên giấy không ai chạy) No lane before checker: chỉ tuyên bố lane khi checker fail-closed + block-mode + selftest PASS
R13 hai SSOT (module vs matrix) Hướng cũ archive-only reference; matrix là SSOT primary

6. Decision gates

Đủ để VIẾT CHECKER khi:

  • Phase 1 substrate check pass/acceptable;
  • candidate packet storage đã chốt (Phase 2);
  • required-stamps.v0.1.json config được xác nhận;
  • checker selftest plan được duyệt (Phase 3).

Đủ để MỞ PILOT khi:

  • checker selftest chạy pass;
  • atomic promote rehearsal pass (Phase 5);
  • cleanup fail-safe pass;
  • Codex checkpoint không còn blocker.

CHƯA BAO GIỜ đủ để PRODUCTION nếu:

  • chưa qua governance Mức 3 / Đ32 / production gate hiện hành.
  • (Matrix/Stamp không bao giờ là đường tắt qua production/kernel gate.)
Immediate next action:
  Run Phase 1 system substrate check (READ-ONLY).
  Do not write checker yet.
  Do not open pilot yet.
  Do not mutate DB / production.

Cụ thể: xác minh read-only iu_core.iu_staging_record / iu_core.iu_staging_payload (tồn tại? schema? status lifecycle? TTL? bind candidate_id?) → ghi system-substrate-check-report với verdict GO/PARTIAL/HOLD/BLOCKED → nếu GO/PARTIAL, sang Phase 2 (candidate packet design), rồi Codex Checkpoint 1.

Roadmap thực dụng: docs fixed → system check → candidate packet → checker selftest → atomic promote rehearsal → Codex confirm → pilot. Không enact, không production, không governance monster mới.