Stamp-based Governance Addendum for Matrix Assembly Refactor

Trạng thái: DRAFT — KHÔNG PHẢI BAN HÀNH. Tài liệu khảo sát + đề xuất, không tự ủy quyền bất kỳ thay đổi production / DB thật / knowledge/dev/laws/ nào. Ngày: 2026-06-13 · Soạn: Claude (khảo sát read-only KB) · Vị trí: knowledge/dev/laws-new/matrix-stamp-governance-addendum.md Đọc kèm: matrix-refactor-implementation-plan.md (kế hoạch chính) · matrix-refactor-quick-rules.md (rule ngắn) Phạm vi: bổ sung mô hình "đóng dấu kiểm soát" (stamp-based governance) vào track ma trận. Không thay 4 chiều, không thay One-Roof, không mở cổng production.

1. Executive Summary

Kết luận: GO (ADJUST framing) — nên đưa stamp-based governance vào kế hoạch chính. Mô hình KHẢ THI, ĐƠN GIẢN HƠN module-track, và TẬN DỤNG nhiều hệ cũ hơn — vì nó không phải khái niệm mới, mà là tổng quát hóa một cơ chế đã chạy thật: PEN/STAMP/GATE của Điều 0-G.
Bằng chứng quyết định: bảng birth_registry (Điều 0-G v1.0, S157) đã có sẵn cột dấu vật lý: inspect_pen, inspect_stamp, inspect_gate — mỗi cột là một dấu, do một DOT inspector độc lập đóng, và certified=true CHỈ khi đủ dấu. Cơ chế mở rộng đã ban hành: "thêm cột = thêm inspector, KHÔNG SỬA CODE; DOT cũ vẫn chạy". Đây chính xác là "đóng dấu dần bởi DOT chuyên trách".
Snapshot P2B-INV (2026-05-05): 162 birth trigger đang sống (31 trg_birth_* DOT-119 v2 + 131 legacy). Cơ chế khai sinh tối thiểu + chấm dấu sau-khai-sinh KHÔNG phải thiết kế mới — nó đang chạy ở quy mô production.
Khai sinh hiện tại đã tối thiểu đúng tinh thần đề bài: trigger chỉ ghi entity_code, collection_name, species_code, composition_level, dot_origin, governance_role, born_at, status='born' — đúng 8 câu hỏi căn cước. Các dấu kiểm soát (inspect_*) đã được thiết kế để điền SAU, độc lập, không nhồi vào khai sinh.
Object thiếu dấu đã không làm vỡ hệ trong mô hình hiện hành: record certified=false chỉ nằm trong danh sách idx_birth_uncertified chờ kiểm; inspector fail → entity_audit_queue / system_issues (fn_log_issue), không vô hiệu hóa entity. Đây đã là "liệt kê/cảnh báo, không sửa hệ ngay".
Cơ quan quét thiếu dấu đã có nền: Điều 23 DOT Scanning (inverse-check UNMONITORED/UNREGISTERED → system_issue severity HIGH) + orphan/phantom detection của Đ0-G §2.5 + dot_tools.coverage_status (103/309 null = bề mặt "thiếu dấu" sẵn có). Không cần xây scanner mới.
Không cần bảng mới cho v0.1. Ledger của post-promote/canonical stamp = các cột inspect_* của birth_registry (mở rộng = ALTER ADD COLUMN inspect_xxx, cơ chế đã ban hành); pre-promote stamp nằm ở candidate/workspace staging metadata (§2b), KHÔNG trên birth_registry. Cả hai KHÔNG phải tạo governance_stamp_ledger. Chỉ đề xuất bảng mới nếu xuất hiện nhu cầu chấm dấu per-object TRƯỚC khai sinh trong kho tạm — và kể cả khi đó, ưu tiên governance_candidate_state (SB-10, đã thiết kế) thay vì bảng thứ ba.
Khớp Matrix 4+3: stamp = lớp vận hành "Governance state" của ô/object (§3.2 kế hoạch chính), KHÔNG phải chiều thứ năm. BIRTH/SPECIES/COLLECTION stamp xác nhận tọa độ cell_id; các dấu còn lại = độ-đầy-đủ của khai báo ô §3.4.
Khớp governance 3 mức (§10 kế hoạch chính): mức = tập dấu bắt buộc ở mỗi cổng. Mức 1 kho tạm = chỉ TEMP_ID_STAMP (tối thiểu); Mức 2 promote = preconditions (TEMP_ID+CELL+IO+VALIDATION+ROLLBACK) → outputs (BIRTH+PROMOTE, đóng sau khi pass); Mức 3 canonical = đủ dấu + packet đầy đủ. Promote fail-closed nếu thiếu dấu bắt buộc.
Rủi ro chính cần phản biện (đã xử lý ở §11): stamp phình thành registry mới (→ tái dùng cột birth_registry, cấm bảng mới mặc định); stamp trùng GCOS (→ stamp = grain per-object mà GCOS candidate-state group-grain KHÔNG phủ; hai cái BỔ SUNG); stamp làm mất an toàn (→ dấu là additive, thiếu dấu = liệt kê/quarantine-khỏi-promote, KHÔNG vô hiệu hóa entity đang chạy; fail-closed chỉ ở cổng promote, không ở runtime).

2. Lý do cần thêm stamp-based governance

Hướng cũ (module-track + xu hướng "khai sinh gánh toàn bộ") có chuỗi rủi ro đã ghi trong kế hoạch chính §1.9 và đề bài:

Muốn tự động quản lý mọi thứ
→ dồn quá nhiều vào khai sinh
→ khai sinh phải hiểu governance, registry, relation, DOT, collection, promote
→ P0 quá nặng, sửa nhiều vòng vẫn chưa xong

Stamp-based governance cắt chuỗi này bằng cách phân rã governance theo thời gian và theo DOT chuyên trách, thay vì theo không gian (module). Quan trọng: đây không phải lý thuyết mới — nó đã là cách Điều 0-G vận hành:

Khai sinh chỉ ghi căn cước tối thiểu (trigger fn_birth_registry_auto, < 1ms/INSERT, transactional).
Mỗi inspector (PEN/STAMP/GATE) chạy độc lập, theo schedule hoặc event, chỉ UPDATE cột của mình, không inspector nào hiểu toàn hệ.
certified (≈ "đủ dấu") là kết quả phái sinh, auto-tính khi tất cả inspect_* NOT NULL.

Việc cần làm chỉ là tổng quát hóa mô hình này từ "birth inspection 3 dấu" thành "stamp ledger N dấu cho ô ma trận", và nối tập-dấu-bắt-buộc vào cổng promote (vốn chưa có).

2b. Hai substrate lưu stamp: PRE-PROMOTE vs POST-PROMOTE (sửa blocker Codex #1)

Sửa hiểu nhầm: KHÔNG phải "mọi stamp là cột inspect_* trên birth_registry". Object kho tạm CHƯA có dòng birth canonical, nên pre-promote stamp KHÔNG thể nằm trên birth_registry.

Tách rõ hai nơi lưu:

PRE-PROMOTE STAMP STORE  = candidate/workspace staging metadata (staging record)
  • lưu: TEMP_ID_STAMP · CELL_STAMP · IO_STAMP · VALIDATION_STAMP · ROLLBACK_STAMP
  • CHƯA ghi birth_registry canonical
  • sống ở: candidate/workspace staging (Đ41 zones / sandbox-local)

POST-PROMOTE STAMP STORE = canonical substrate / birth_registry / canonical metadata
  • lưu: BIRTH_STAMP · PROMOTE_STAMP · và canonical_required
  • CHỈ ghi SAU khi atomic promote transaction pass (§7b)

Câu chuẩn (thay câu cũ "mọi stamp = cột inspect_*"):

Các post-promote/canonical stamps có thể tận dụng birth_registry/inspect_* hoặc canonical substrate hiện có.
Các pre-promote stamps KHÔNG nằm trong birth_registry; chúng nằm trong candidate/workspace staging metadata hoặc staging record.

Đề xuất tận dụng substrate hiện có (KHÔNG tạo bảng mới ở v0.1): kiểm tra/tận dụng iu_core.iu_staging_record + iu_core.iu_staging_payload cho pre-promote staging nếu lifecycle status của chúng đủ dùng. HOLD FOR SYSTEM CHECK: chưa xác minh schema/lifecycle của iu_staging_record/iu_staging_payload — phải khảo sát thực tế trước khi bind checker vào, không tự đoán.

Rule lưu trữ (anti-bloat):

system_issues CHỈ để log lỗi/cảnh báo — KHÔNG làm stamp ledger chính.
event_outbox / registry_changelog CHỈ làm provenance — KHÔNG làm source chính của pre-promote stamps.
meta_catalog KHÔNG dùng làm per-candidate stamp store.
Không cần stamp ledger mới ở v0.1 nếu staging metadata đủ dùng.

3. Khai sinh tối thiểu là gì

Khai sinh P0 chỉ trả lời 8 câu căn cước — và birth_registry hiện hành đã ghi đúng đủ 8 trường này:

Câu hỏi căn cước	Cột birth_registry hiện có
Tôi là ai?	`entity_code` (PREFIX-NNN), `id` bigserial
Tôi thuộc tầng nào?	`composition_level` (atom/molecule/compound/material/product/building/meta)
Tôi thuộc loài nào?	`species_code` (auto từ `species_collection_map`; null = audit, không chặn)
Tôi nằm ở kho nào?	`collection_name`
Tôi thuộc miền nào?	(chiều Miền/jurisdiction — gắn như thuộc tính, §8)
Workspace/candidate/canonical?	`status` (default `'born'`), `certified` (bool)
Ai tạo tôi?	`dot_origin`
Tạo lúc nào?	`born_at` timestamptz

KHÔNG nhồi vào khai sinh P0 (đúng đề bài, và đúng thiết kế Đ0-G §IV "Component birth chỉ kiểm reuse decision ở mức existence/authority. KHÔNG đánh giá chất lượng kiến trúc sâu tại birth"): full governance · full owner scope · full relation graph · full DOT mapping · full KG · full promotion · full approval/quorum.

Những phần đó = các dấu kiểm soát đóng sau khai sinh.

Điểm khớp với kế hoạch chính §4.4 / §12.3: "vào kho tạm = chưa cần khai sinh canonical; promote = thời điểm khai sinh/ghi sổ". Stamp model làm rõ: BIRTH_STAMP = chính dòng birth_registry được tạo tại thời điểm promote. Trước promote, object sống trong kho tạm (Đ41 zones / sandbox_tac) ở trạng thái stamp-light, mang TEMP_ID_STAMP (workspace_id/candidate_id), không cần dòng birth canonical.

4. Các loại stamp đề xuất

Mỗi post-promote/canonical dấu = một cột inspect_<name> (timestamptz) trên birth_registry, do một DOT inspector đóng — đồng dạng inspect_pen/stamp/gate đã có. Cột đã hiện hữu được đánh dấu ✅. Pre-promote dấu (TEMP_ID/CELL/IO/VALIDATION/ROLLBACK) KHÔNG nằm trên birth_registry — chúng ở candidate/workspace staging metadata (xem §2b).

Stamp	Ý nghĩa	Nền cột/DOT
`TEMP_ID_STAMP`	có căn cước tạm trong kho tạm (workspace_id/candidate_id)	+ candidate/workspace metadata hoặc staging record (Đ41 zones) — KHÔNG dòng birth_registry
`BIRTH_STAMP`	có căn cước canonical (sinh SAU promote)	✅ chính dòng birth_registry + `inspect_pen` (code, origin, species) — đóng tại promote
`SPECIES_STAMP`	map đúng loài/tầng	✅ `species_code` + `composition_level` + `inspect_gate` (đúng chuồng)
`COLLECTION_STAMP`	biết nằm kho/collection nào	✅ `collection_name` + check `collection_registry` (HC-REG)
`GOV_STAMP`	governance nhận diện	✅ `governance_role` (governed/observed/excluded) — route vào One-Roof
`OWNER_STAMP`	có owner/scope tối thiểu	↺ `governance_audit_log` (Đ37 ownership minute) + axis_assignment
`IO_STAMP`	có IO Contract tối thiểu	+ cột mới `inspect_io` (DOT đọc record IO Contract §11 kế hoạch chính)
`RELATION_STAMP`	quan hệ bắt buộc tối thiểu đủ	↺ `universal_edges` (2.199 cạnh) — DOT kiểm cạnh bắt buộc
`VALIDATION_STAMP`	validator pass	↺ bộ FIX7 (validator hardened, bad-input ≥8 lớp, any_fail_open=false)
`ROLLBACK_STAMP`	có cách xóa/rollback	↺ rollback_contract (PROVEN_IN_STAGING) — bắt buộc tại promote
`PROMOTE_STAMP`	đủ điều kiện vào kho chính	+ verdict của checker promote Mức 2 (§10)
`STAMP/GATE` (sẵn)	metadata đủ · hợp lệ business rule	✅ `inspect_stamp`, `inspect_gate`

✅ = cột/nền đã tồn tại · ↺ = tái dùng bảng/hệ cũ (chỉ thêm DOT đọc) · + = thêm tối thiểu (1 cột inspect_*, không bảng mới).

Trần dấu v0.1 (đồng bộ de-bai-cai-tien.md §10–§12 + required-stamps.v0.1.json): bộ dấu lõi v0.1 giữ ở 7 dấu — TEMP_ID_STAMP · BIRTH_STAMP · CELL_STAMP · IO_STAMP · VALIDATION_STAMP · ROLLBACK_STAMP · PROMOTE_STAMP — nằm dưới trần 8–10.

Tách hai dấu căn cước: TEMP_ID_STAMP (kho tạm: workspace_id/candidate_id) và BIRTH_STAMP (canonical, dòng birth_registry sinh sau promote) là hai dấu tách biệt — không dùng chung một dấu cho hai nghĩa.

Precondition vs output (tránh circular): checker promote kiểm promote_preconditions = TEMP_ID_STAMP + CELL + IO + VALIDATION + ROLLBACK; BIRTH_STAMP + PROMOTE_STAMP là promote_outputs, chỉ đóng sau khi pass. Trước canonical birth, stamp nằm trong candidate/workspace metadata hoặc staging record; KHÔNG ghi birth_registry canonical trong kho tạm.

Các inspector mịn hơn trong bảng trên là chi tiết hiện thực gom dưới dấu lõi tương ứng và chỉ bắt buộc ở vùng high-risk: SPECIES_STAMP/COLLECTION_STAMP/RELATION_STAMP xác nhận CELL_STAMP; GOV_STAMP/OWNER_STAMP chỉ vùng canonical/kernel/high-risk. Thêm một dấu bắt buộc mới = thay đổi Mức 3 (Canonical/Kernel).

Trạng thái thiếu dấu (đề bài) ánh xạ vào trạng thái đã có:

Trạng thái đề xuất	Nền hiện hành
`UNSTAMPED` / `MISSING_STAMP`	`certified=false` + `inspect_* IS NULL` (đã có `idx_birth_uncertified`)
`ORPHAN`	orphan/phantom detection Đ0-G §2.5 (đã có truy vấn)
`QUARANTINE`	`entity_audit_queue` / `system_issues` severity (đã có `fn_log_issue`)
`PROMOTE_BLOCKED`	checker promote fail-closed Mức 2 (cần nối — §7)

5. DOT đóng dấu hoạt động thế nào

Tái dùng nguyên mô hình inspector của Đ0-G §2.4 + Điều 35 DOT v5.2 (BAN HÀNH, dot_tools 309 tools, paired-DOT):

DOT khai sinh   → BIRTH_STAMP      (= fn_birth_registry_auto + dot-inspect-pen)
DOT kho         → COLLECTION_STAMP (đọc collection_registry)
DOT loài/tầng   → SPECIES_STAMP    (đọc species_collection_map + entity_species)
DOT governance  → GOV/OWNER_STAMP  (đọc governance_role + governance_audit_log)
DOT IO          → IO_STAMP         (dot-inspect-io: đọc record IO Contract)
DOT relation    → RELATION_STAMP   (đọc universal_edges)
DOT validate    → VALIDATION_STAMP (chạy bộ FIX7 rút gọn)
DOT rollback    → ROLLBACK_STAMP   (kiểm rollback_contract)
DOT promote     → PROMOTE_STAMP    (checker promote Mức 2)

Nguyên tắc (đã ban hành ở Đ0-G):

Mỗi DOT chỉ UPDATE cột của mình; thêm inspector mới = ALTER ADD COLUMN inspect_xxx + 1 DOT tool, DOT cũ chạy không đổi.
DOT inspector chạy độc lập, idempotent, theo event/schedule — query WHERE inspect_x IS NULL AND <tiền điều kiện>. Điều này khớp NT8 + cho phép chạy song song tự nhiên (mỗi DOT một cột, không tranh chấp), gỡ áp lực Đ20 §6.9 ở phạm vi chấm dấu.
Auto-certify = trigger AFTER UPDATE: khi đủ dấu bắt buộc (đọc danh sách từ metadata, KHÔNG hardcode) → certified=true.

6. Scanner / cơ quan liệt kê thiếu dấu hoạt động thế nào

Không tạo cơ quan mới. Ghép 3 nền sẵn có:

Liệt kê thiếu dấu (read-only): 1 câu SQL trên birth_registry (kiểu Đ0-G §2.3) — SELECT collection_name, count(*) WHERE certified=false AND governance_role='governed' GROUP BY 1. Mở rộng theo từng dấu: WHERE inspect_io IS NULL, WHERE inspect_rollback IS NULL…
Phát hiện sai kho / orphan / DOT orphan: orphan/phantom của Đ0-G §2.5 + inverse-check Điều 23 (collection có trong meta_catalog nhưng ngoài scope mọi DOT scan → UNMONITORED; bảng PG ngoài meta_catalog → UNREGISTERED → system_issue HIGH) + dot_tools.coverage_status null (103/309).
Object muốn promote nhưng thiếu dấu: checker promote Mức 2 trả PROMOTE_BLOCKED + lý do (dấu nào thiếu).

Kết quả là bảng cảnh báo, KHÔNG sửa hệ ngay — đúng đề bài và đúng hành vi hiện hành (record certified=false chỉ nằm chờ, không phá gì). Lưu ý: DOT One-Roof dot_governance_coverage_scan… CHƯA tồn tại (kế hoạch chính §4.3) — không được giả định có; dùng Đ23 + truy vấn birth_registry cho v0.1.

7. Promote cần những dấu nào

Tập dấu bắt buộc khai báo trong metadata (không hardcode), checker promote Mức 2 (§10 kế hoạch chính) đọc và fail-closed:

PRECONDITIONS (checker kiểm TRƯỚC promote):
  TEMP_ID_STAMP · CELL_STAMP (COLLECTION+SPECIES) · IO_STAMP
  VALIDATION_STAMP · ROLLBACK_STAMP
OUTPUTS (đóng SAU khi pass — không phải precondition):
  BIRTH_STAMP · PROMOTE_STAMP
BẮT BUỘC nếu vùng cần governance:
  GOV_STAMP / OWNER_STAMP

Nguyên tắc fail-closed (khớp quick-rules 24–26):

Thiếu một dấu bắt buộc → PROMOTE_BLOCKED, không vào kho chính.
Checker chỉ kiểm cục bộ (7 câu §10 Mức 2): đúng ô? đúng input? đúng schema? DOT kiểm pass? relation bắt buộc đủ? rollback có? owner/scope rõ? — nghi ngờ → đẩy lên Mức 3 (probation).
Blast-radius class được TÍNH, không tự khai; khai sai = incident + nâng lane.
BIRTH_STAMP + PROMOTE_STAMP là output, đóng sau khi pass preconditions (thời điểm tạo dòng birth_registry per §3) — KHÔNG phải điều kiện đầu vào; tránh circular requirement. Kho tạm dùng TEMP_ID_STAMP.

7b. Atomic Promote Contract v0.1 (sửa blocker Codex #3)

Tách bạch: checker = verdict-only (§7 spec); atomic promote transaction = mutation. Hai bước riêng, không gộp.

Atomic promote transaction CHỈ được chạy sau khi checker trả PROMOTE_OK. Trong cùng một transaction phải:

1. khóa candidate/staging record (SELECT ... FOR UPDATE / lock tương đương)
2. xác nhận packet chưa expired / chưa consumed / packet_hash còn đúng
3. tạo canonical birth_id/entity_code nếu cần
4. ghi/cập nhật canonical object vào kho chính
5. đóng BIRTH_STAMP   (post-promote store)
6. đóng PROMOTE_STAMP (post-promote store)
7. mark staging record = consumed
8. ghi provenance/audit (event_outbox / registry_changelog / governance_audit_log — register-before-emit)
9. nếu BẤT KỲ bước nào fail → ROLLBACK toàn bộ transaction (all-or-nothing)

Negative states phải bị chặn (không được tồn tại sau transaction):

birth-only                                       (BIRTH_STAMP nhưng thiếu canonical write / PROMOTE_STAMP)
promote-stamp-only                               (PROMOTE_STAMP nhưng thiếu birth)
canonical write thiếu rollback proof             (ghi kho chính khi ROLLBACK_STAMP chưa pass)
staging consumed nhưng canonical write fail      (mark consumed mà kho chính chưa ghi)
canonical write pass nhưng staging chưa consumed (rủi ro double-promote)

Mọi negative state ở trên = transaction phải rollback toàn bộ; không để lại trạng thái nửa vời.

Điều kiện cứng: Chưa có atomic promote transaction + rehearsal proof (staging, kiểu FIX7) thì CHƯA được mở pilot promote thật. (HOLD: transaction thật + rehearsal là việc triển khai, ngoài phạm vi task tài liệu này.)

7c. TTL / cleanup fail-safe cho kho tạm

Workspace/candidate packet phải có TTL (expires_at).
Cleanup CHỈ được xóa candidate ở trạng thái draft / expired / quarantined.
Cleanup KHÔNG được xóa candidate đang checking / promote_ok-chưa-consumed / approved / đang promote.
Cleanup fail-safe: nghi ngờ thì KHÔNG xóa.
Nếu hệ có iu_core.iu_staging_record / iu_staging_payload: ưu tiên kiểm tra/tận dụng lifecycle status sẵn có ở đó thay vì tự định nghĩa vòng đời mới. HOLD FOR SYSTEM CHECK trước khi bind.

8. Cách tận dụng bảng/hệ cũ

Bảng "stamp ledger" và toàn bộ provenance đã có chỗ, không tạo mới:

Nhu cầu stamp	Bảng/hệ cũ tái dùng	Trạng thái
Pre-promote stamp store (TEMP_ID/CELL/IO/VALIDATION/ROLLBACK)	candidate/workspace staging metadata — đề xuất tận dụng `iu_core.iu_staging_record`/`iu_staging_payload`	◷ HOLD FOR SYSTEM CHECK (chưa xác minh schema/lifecycle)
Post-promote stamp ledger per-object	`birth_registry` (cột `inspect_*`, `certified`, `status`, `governance_role`)	✅ enacted v1.0, 162 trigger sống
`object_ref`	`birth_registry.entity_code` (UNIQUE)	✅
`stamp_type`	tên cột `inspect_<type>`	✅ (mở bằng ALTER)
`stamp_status`	`inspect_x IS NULL` / `NOT NULL` + `certified`	✅
`issued_by_dot`	`dot_tools` (Đ35) + (tùy chọn) cột `inspect_x_by`	↺
`ruleset_version`	`governance_ruleset` = hash canonical 140 rows `measurement_registry`	◷ design-only (SB-10/11)
`evidence_ref`	`event_outbox` (182.731 rows, register-before-emit, `event_type_registry` 40 types) · `registry_changelog` · `vps_deploy_log` (Đ41) · `governance_audit_log` (Đ37)	↺ / ◷
`created_at` / `expires_at`	`born_at` / `certified_at` + (stale-after của SB-10)	✅ / ◷
`notes`	`entity_audit_queue` / `system_issues` (`fn_log_issue`)	✅
Candidacy "đủ điều kiện" (group-grain)	`governance_candidate_state` (SB-10) — snapshot+ruleset-keyed, no-checked-forever, stale-after, fail-closed prod gate	◷ design-only, BUILD NO-GO

✅ chạy thật · ↺ enacted, chỉ thêm DOT đọc · ◷ đã thiết kế nhưng BUILD NO-GO (không được giả định đã build).

Quan trọng: governance_candidate_state (SB-10) là group-grain (candidacy theo nhóm, "no per-row explosion"), KHÔNG phải per-object stamp. Nó là lớp PROMOTE_STAMP/candidacy, bổ sung cho per-object stamp của birth_registry, không thay thế. Hai cái compose; không trùng.

9. Nếu cần bảng mới thì đề xuất tối thiểu

Khuyến nghị cho v0.1: KHÔNG tạo bảng mới. Stamp ledger = cột inspect_* của birth_registry; mở rộng bằng ALTER ADD COLUMN (cơ chế đã ban hành). Đây là chuyển đổi tối thiểu nhất có thể.

governance_stamp_ledger chỉ nên cân nhắc nếu (và chỉ nếu) xuất hiện đồng thời 2 nhu cầu mà cột birth_registry không gánh được:

Cần chấm dấu per-object cho object TRONG kho tạm TRƯỚC khi có dòng birth (vì birth = tại promote).
Cần lịch sử nhiều dấu cùng loại theo thời gian (audit trail dạng hàng, không phải 1 timestamp/cột).

Kể cả khi đó, thứ tự ưu tiên: (a) giữ stamp ở sandbox-local (Đ41 zones) cho tới promote → 0 bảng mới; (b) dùng governance_candidate_state (SB-10, đã thiết kế) cho candidacy; (c) chỉ khi (a)(b) đều không đủ mới đề xuất bảng tối thiểu:

governance_stamp_ledger  (CHỈ nếu thật sự cần — không mặc định)
  object_ref      → FK birth_registry.entity_code (KHÔNG shadow SoT — Đ31)
  stamp_type      text
  stamp_status    text   (issued/revoked/expired)
  issued_by_dot   text   → dot_tools.code
  ruleset_version text   → governance_ruleset hash
  evidence_ref    text   → event_outbox / registry_changelog / vps_deploy_log
  created_at      timestamptz
  expires_at      timestamptz
  notes           text

Ràng buộc nếu phải tạo: additive-only, FK tham chiếu SoT (không copy/shadow — Đ31 "no hidden second SoT"), rollback drafted, register-before-emit nếu phát event, đi lane Mức 3.

10. Cách ghép với Matrix 4+3

Giữ nguyên mô hình chính (kế hoạch §3):

Ma trận định vị = Tầng × Loài × Kho × Miền      (4 chiều — KHÔNG đổi)
Trong mỗi ô     = Công thức + DOT + Governance state + IO Contract
Quan hệ         = graph riêng (universal_edges)
Task/request    = overlay
Capability      = thuộc tính lọc

Stamp KHÔNG phải chiều mới. Stamp = nội dung của lớp "Governance state" (§3.2) ở mức object. Ánh xạ:

Xác nhận tọa độ ô: BIRTH/SPECIES/COLLECTION stamp khẳng định object nằm đúng cell_id (tầng, loài, kho, miền). SPECIES_STAMP đọc composition_level (Tầng) + species_code (Loài); COLLECTION_STAMP đọc collection_name (Kho); Miền gắn như thuộc tính (jurisdiction Đ37).
Độ-đầy-đủ khai báo ô (§3.4): IO/RELATION/VALIDATION/ROLLBACK/GOV/OWNER/PROMOTE stamp = từng mục bắt buộc của ô đã đủ hay chưa. Ô "đủ dấu" = ô hợp lệ để promote.
3 mức governance = 3 tập dấu bắt buộc:

Mức (§10 plan)	Tập dấu yêu cầu
Mức 1 — kho tạm	chỉ TEMP_ID_STAMP (tối thiểu); sai thì xóa
Mức 2 — promote	precond: TEMP_ID+CELL(COLLECTION+SPECIES)+IO+VALIDATION+ROLLBACK+(GOV/OWNER) → output: BIRTH+PROMOTE
Mức 3 — canonical/kernel	đủ dấu + packet đầy đủ + rollback PROVEN_IN_STAGING + Đ32

Stamp do đó là cơ chế thực thi của governance 3 mức, không phải tầng song song.

11. Rủi ro và cách giảm rủi ro

Rủi ro (đề bài C.5)	Đánh giá	Giảm thiểu
Stamp biến thành registry mới phức tạp	Rủi ro thật nếu tạo `governance_stamp_ledger` sớm	Mặc định 0 bảng mới; ledger = cột `inspect_*` birth_registry; bảng mới chỉ qua §9 với 3 điều kiện chặt + lane Mức 3
Stamp trùng GCOS	Thấp nếu phân vai đúng	Stamp = per-object grain; GCOS candidate-state = group-grain "no per-row explosion". Hai cái BỔ SUNG; GOV_STAMP route vào One-Roof, KHÔNG dựng governance song song
Stamp mất an toàn	Thấp	Dấu là additive timestamp; không dấu nào ghi đè/xóa dữ liệu entity. Thêm dấu = ALTER ADD COLUMN, DOT cũ bất biến
Object thiếu dấu → cảnh báo / quarantine / vô hiệu hóa?	Quyết định: cảnh báo + liệt kê + chặn promote, KHÔNG vô hiệu hóa	Đúng hành vi Đ0-G hiện hành: `certified=false` chỉ nằm chờ, entity vẫn sống. Vô hiệu hóa entity đang chạy = vỡ hệ → cấm. Quarantine chỉ nghĩa "khỏi promote", không "khỏi tồn tại"
Promote fail-closed thiết kế thế nào	—	Tập dấu bắt buộc trong metadata (không hardcode); checker Mức 2 đọc → thiếu 1 dấu = `PROMOTE_BLOCKED`; nghi ngờ → đẩy Mức 3; class TÍNH không tự khai; "no lane before checker" (quick-rule 32)
Stamp thành ceremony tự mọc (R8)	Trung bình	Trần dấu bắt buộc cố định ở Mức 1–2; thêm dấu bắt buộc = thay đổi Mức 3 (§22 quick-rules)
Drift giữa cột stamp và sổ hiện hành (R4)	Trung bình	Stamp là cột TRÊN birth_registry, không sổ thứ hai; 1 DOT đối soát định kỳ (Đ23 inverse-check)
Giả định DOT scanner One-Roof đã có	Cao nếu bất cẩn	`dot_governance_coverage_scan…` CHƯA tồn tại; v0.1 chỉ dùng Đ23 + truy vấn birth_registry
Kho tạm không có birth → stamp ở đâu	Trung bình	v0.1: stamp pre-promote sống sandbox-local (Đ41); BIRTH_STAMP sinh tại promote. Không ép tạo birth canonical trong kho tạm

12. Kết luận: GO

GO (ADJUST). Đưa stamp-based governance vào kế hoạch chính như cách thực thi lớp "Governance state" của ma trận, với 3 chốt:

Khai sinh tối thiểu = giữ nguyên birth_registry 8 trường căn cước; KHÔNG mở rộng khai sinh P0.
Đóng dấu dần = tổng quát hóa PEN/STAMP/GATE: mỗi dấu là 1 cột inspect_*, 1 DOT inspector độc lập, idempotent, chạy song song được; thêm dấu = ALTER ADD COLUMN (cơ chế đã ban hành).
Promote fail-closed theo tập dấu = checker Mức 2 đọc tập-dấu-bắt-buộc từ metadata; thiếu dấu = chặn, liệt kê, không vỡ hệ.

Vì sao GO chứ không HOLD: mô hình này đơn giản hơn module-track (không module/Integration Bus/federated registry), tận dụng nhiều hơn (birth_registry + Đ35 + Đ23 + system_issues + universal_edges + governance_audit_log + event_outbox — đều đã chạy hoặc enacted), và giảm tải khai sinh P0 đúng mục tiêu đề bài. Nó không phải khái niệm mới mà là triệt để hóa một cơ chế đang sống.

Điều kiện trước khi vượt khỏi giấy + kho tạm (kế thừa §15 kế hoạch chính): (a) Owner chốt; (b) danh mục tập-dấu-bắt-buộc per mức được duyệt; (c) checker promote fail-closed pass selftest; (d) pilot chứng minh "thiếu dấu = chặn promote, không vỡ hệ" trong staging. Mọi enact luật + mọi thứ chạm production vẫn đi lane Canonical/Đ32 hiện hành; addendum này không mở cổng nào.

Phản biện trung thực (theo yêu cầu F): nếu sau khi build thử mà stamp khiến hệ phình (nhiều bảng/lane/ceremony mọc thêm), đường lùi đơn giản hơn là dừng tổng quát hóa, giữ đúng PEN/STAMP/GATE 3 dấu của Đ0-G cho birth + 1 checker promote duy nhất — vì bản thân Đ0-G đã đủ cho phần lớn nhu cầu "căn cước + chứng nhận". Stamp mở rộng chỉ nên thêm theo nhu cầu đo được, từng dấu một, không thêm trước.

Stamp-based Governance Addendum v0.1 | 2026-06-13 | DRAFT not-enacted | "Khai sinh cấp căn cước; DOT đóng dấu dần; thiếu dấu thì liệt kê, không vỡ hệ; promote fail-closed nếu thiếu dấu bắt buộc."