Incomex AI Portal
KB-5DAE

F4 — Stamp Lifecycle + Checker / Promote / Rollback — Reuse Survey Packet

35 min read Revision 1
laws-newf4reuse-survey-packetstamp-lifecyclecheckerpromoterollbackread-onlynon-authorizing2026-06-16

F4 — Stamp Lifecycle + Checker / Promote / Rollback — Reuse Survey Packet

Ngày: 2026-06-16 · Soạn: Claude Code CLI (read-only AgentData KB) · Track: knowledge/dev/laws-new/ Control basis: technical-slice-framework.md rev56 (§6c F4 = D8 + D9 + canonical-output of D10; D8 Stamp Lifecycle / D9 Checker·Promote·Rollback·Atomic Boundary / D10 Birth·Identity·Canonical Root; build-order note "canonical birth là OUTPUT tại promote, không front-load"; §19 schema-change STOP; §20 self-check). Concept basis: de-bai-cai-tien.md rev33 (§IV.4 stamp = dấu xác nhận not approval workflow; §IV.6 / §V.11 / §VI.7 anti-bloat; §V.4 PROMOTE_BLOCKED verdict vs state; §V.5/§V.7 stamp output ≠ precondition; §V.13 "No checker, no lane" verdict-only; §V.16 production keeps heavy governance; §V.18 pilot must prove "sai thì xóa được"; §VI.4 delete-fast / TTL / no-shadow-prod). Spec basis (documentary candidates): required-stamps.v0.1.json rev6 (DRAFT — not enacted) · promote-checker-v0.1-spec.md rev11 (DRAFT — KHÔNG PHẢI BAN HÀNH) · matrix-stamp-governance-addendum.md rev14 (DRAFT — KHÔNG PHẢI BAN HÀNH). Catalog basis: cau-hoi-khi-tai-cau-truc.md rev82 (DOT-006 promote checker; STG-012/015; STG-REUSE-001/003; DOT-CAP-001/004/006/010; Nhóm R RISK-*; CONS-002/003; CELL-003/004/007). Evidence/gate basis: F3 owner decision record rev1 (F3 gate CLOSED) + F3 execution report rev6 (PARTIAL) + F3 packet rev1 + F2/F1/F0 decision records + constitution v4.6.3 (NT9/NT14/NT15/Đ20/Đ32) + OR v7.58. Layer: F4 = one layer above F3 in the §6c build order; sits below F5 (Scanner / Observability + Runtime / Operational Safety = D11 + D12), and is the layer where canonical birth is the output at the promote boundary (D10).

1. Status / non-authorization banner

STATUS: PREPARATION PACKET — NON-AUTHORIZING. This is a read-only program package that prepares the F4 layer. It is not an F4 execution authorization on its own (the F4 read-only execution in this Program Macro runs only if the internal safety gate in §10 passes), not a Phase-1 survey, not an implementation authorization. It performs no live DB / runtime query, mutates nothing, creates no schema/table/registry/DOT/checker/scanner, runs no checker and no promote, and writes no canonical birth / BIRTH_STAMP / PROMOTE_STAMP / PROMOTE_BLOCKED state. It is structured around the same 3 reuse-first Owner questions as F0/F1/F2/F3 and is intended for GPT → Codex → Owner review.

Boundary invariants (carried from rev56 §6c + F3 decision record):

  • F4 = D8 + D9 + canonical-output of D10. Stamp Lifecycle + verdict-only Checker + Promote / Rollback + canonical birth CHỈ tại promote (framework §6c). Canonical birth is the OUTPUT here, not front-loaded and never earlier than promote.
  • Stamps are documentary vocabulary, not proven runtime delivery. required-stamps.v0.1.json is DRAFT — not enacted, a static config a checker is meant to READ. Framework D8 states "stamp config runtime delivery unknown". F4 must keep runtime delivery UNKNOWN — it may NOT be inferred from the JSON's existence.
  • Checker is verdict-only and not built. promote-checker-v0.1-spec.md is DRAFT — KHÔNG PHẢI BAN HÀNH, never written/selftested. PROMOTE_OK is a verdict, not a mutation; the checker does not sign birth, does not write canonical, does not close BIRTH_STAMP/PROMOTE_STAMP. Rule: "No checker, no lane. A paper lane is no lane." (de-bai §V.13).
  • Promote = Atomic Promote Contract, HOLD-2 / BLOCKED. The all-or-nothing transaction (create canonical birth + close BIRTH_STAMP/PROMOTE_STAMP + consume staging) has no real transaction + no rehearsal proof; "CHƯA được mở pilot promote thật". F4 surveys it documentary-only.
  • PROMOTE_BLOCKED is a verdict/state, not a stamp. It is the checker's verdict and a candidate packet status value — it is absent from the stamp vocabulary and is never a canonical stamp (de-bai §V.4; spec §4; required-stamps.v0.1.json contains no PROMOTE_BLOCKED stamp).
  • BIRTH_STAMP / PROMOTE_STAMP are post-promote OUTPUTS only. They are closed by atomic promote after PROMOTE_OK; they are not preconditions and are not written by F4 (de-bai §IV.4/§V.5/§V.7; framework D10).
  • No cell_id / dot_role materialization · no canonical birth · no schema. CONS-003 + CELL-003/004/007 stay unresolved; CELL_STAMP stays pending. birth_registry / fn_birth_register / fn_birth_gate are documentary candidates, not live proof (framework §4 downgrades reported-LIVE; F1 lineage).
  • Documentary ≠ live proof · Prior-session ≠ current proof · Engineering PASS ≠ Authority PASS · Reuse-now ≠ live-proven · Codex PASS ≠ Owner phase-authorization.

2. Owner View — 3 câu hỏi reuse-first

Đọc riêng mục này là đủ để Owner/GPT thấy F4 định khảo sát cái gì để dùng lại — chưa làm gì chạm hệ thống. Chi tiết kỹ thuật ở §4–§12. Mục này không ủy quyền bất cứ điều gì.

Q1 — Cái gì đang có và (giả thuyết) dùng lại được ngay? (reuse-now — documentary candidates)

Tất cả mục dưới là ứng viên documentary (DRAFT specs + framework rev56 §6c D8/D9/D10 = DOCUMENTARY_ONLY / BLOCKED / UNKNOWN), chưa live-proven. F4 execution phải pin bằng chứng cho từng dòng; nếu bằng chứng yếu thì rớt xuống Q2.

  • required-stamps.v0.1.json as documentary core stamp vocabulary — core_stamps = TEMP_ID_STAMP · BIRTH_STAMP · CELL_STAMP · IO_STAMP · VALIDATION_STAMP · ROLLBACK_STAMP · PROMOTE_STAMP (7, under the 8–10 ceiling) + high_risk_extra = GOV_STAMP · OWNER_STAMP; lifecycle workspace_required / promote_preconditions / promote_outputs / canonical_required. Reuse-now as vocabulary + lifecycle ordering, NOT proven runtime enforcement.
  • F1 / F2 / F3 accepted boundaries — F1 birth boundary (TEMP_ID only; canonical birth = F4); F2 Smart Brick boundary (brick = subject / temp-store = place); F3 IO Contract 5-field + Formula/Assembly/DOT documentary. Reuse-now as the design lineage F4 sits on top of.
  • Candidate packet as view/projection — matrix_candidate_packet.v0.1 = view/binding logic on staging metadata (candidate_id + packet_hash), read by the verdict-only checker; không store/registry mới (de-bai §V.13; spec §2.1). Documentary only.
  • Pre-promote stamp path — TEMP_ID_STAMP (workspace) · CELL_STAMP · IO_STAMP · VALIDATION_STAMP · ROLLBACK_STAMP = the promote_preconditions the checker reads (required-stamps lifecycle; addendum §7; de-bai §V.7). Documentary candidate path.
  • Post-promote stamp path — BIRTH_STAMP · PROMOTE_STAMP = the promote_outputs closed by atomic promote after PROMOTE_OK (required-stamps lifecycle; de-bai §V.5). Documentary candidate path; OUTPUT only.
  • PROMOTE_BLOCKED as verdict/state, not a canonical stamp — the checker verdict + candidate packet status; stored only as a temporary state in candidate/staging metadata if at all (de-bai §V.4; spec §4). Documentary boundary.
  • promote-checker-v0.1-spec as documentary checker spec candidate — verdict-only; fail-closed binding (§2.2); one packet only; emits PROMOTE_OK / PROMOTE_BLOCKED / ESCALATE_L3. Reuse-now as spec, not as a running checker.
  • birth_registry / fn_birth_register / fn_birth_gate as documentary candidates — the post-promote stamp ledger + birth functions (addendum names the analog fn_birth_registry_auto; "162 birth triggers / enacted v1.0" is a documentary claim). Reuse-now as documentary substrate candidates, NOT live proof.
  • Rollback / delete-fast boundary from F2 / F3 — ROLLBACK_STAMP precondition + delete-fast principle ("sai thì xóa"); fn_iu_staging_create / fn_iu_staging_cleanup documentary support (de-bai §VI.4; framework §6.2). Documentary boundary the lifecycle must satisfy.

Q2 — Cái gì đang có nhưng cần sửa / kiểm chứng mới dùng lại được? (repair / verify-before-reuse)

  • required-stamps runtime delivery is UNKNOWN — the JSON is DRAFT/static; framework D8 explicitly says "stamp config runtime delivery unknown" and D12 lists "required-stamps KB→runtime delivery" as UNKNOWN. Must be verified at Phase-1; not inferable from the file existing.
  • Checker spec not implemented / not selftested — promote-checker-v0.1-spec rev11 is DRAFT; "No checker, no lane" — a paper lane is no lane. The mandatory selftest (tamper/empty → fail-closed, no PROMOTE_OK token leak) has not been shown to run. = F4 documentary, implementation is later + Owner-gated.
  • Checker must be verdict-only and fail-closed — the §2.2 binding rules (candidate_id mismatch / wrong packet_hash / stale / missing artifact / cell_id UNKNOWN/PENDING / missing rollback proof → PROMOTE_BLOCKED or quarantined) are a spec, not verified behavior. Verify-before-reuse.
  • Candidate-packet binding depends on STG-015 packet_hash — whether packet_hash covers cell_id + stamps is undefined (catalog STG-015 PARTIAL/BLOCKER); tamper-binding unproven.
  • Staging / pre-promote metadata depends on HOLD-1 — iu_core.iu_staging_record / iu_staging_payload (the proposed pre-promote stamp store) = "HOLD FOR SYSTEM CHECK", UNKNOWN→likely-LIVE; Phase-1-gated.
  • Atomic promote is HOLD-2 / BLOCKED — no real transaction + no rehearsal proof; the all-or-nothing transaction (lock → verify packet → create canonical birth → write canonical → close BIRTH_STAMP+PROMOTE_STAMP → consume staging → audit) is design-only (addendum §7b; de-bai §V.5/§V.7).
  • birth_registry / fn_birth_register / fn_birth_gate are documentary only — reported triggers/columns are documentary; framework §4 downgrades reported-LIVE to DOCUMENTARY_ONLY; exact function names come from F1 lineage, not re-proven this pass.
  • Birth gate warning + bypass = RISK-BYPASS — framework D10: "birth_gate chưa block (warning); bypass kill-switch = BYPASS surface". Blocks trusting the gate at promote. Phase-1 + controlled+audited pilot.
  • Rollback / delete-fast depends on STG-012 + RISK-GC / RISK-CAP — who calls fn_iu_staging_cleanup (no pg_cron); blob_ref orphan; CASCADE / 10 MiB cap — all unverified.
  • CELL_STAMP depends on CONS-003 / CELL-003/004/007 — cell_id dimensions unresolved; CELL_STAMP (COLLECTION + SPECIES) cannot be treated as solved.
  • IO_STAMP depends on CONS-002 / IO examples GAP — which source wins for the IO Contract fields is a BLOCKER; real IO examples are a GAP (carried from F3).
  • DOT-CAP blockers affect DOT-based validation — the addendum §5 maps each stamp to a DOT_* inspector (DOT validate → VALIDATION_STAMP, DOT rollback → ROLLBACK_STAMP, DOT promote → PROMOTE_STAMP, etc.); DOT-CAP-001/004/006/010 (capability contract / no-mutation flag / ≥8 bad-input tests / read-vs-mutate) are BLOCKERs before any DOT inspector is trusted.
  • Runtime / checkout sync not proven (CONS-005 caveat) — baseline covers KB only; runtime state not inferable.

Q3 — Cái gì thật sự phải làm thêm (chỉ khi reuse không đủ)? (add-later — future Owner-gated)

Nothing here is authorized. Each is future Owner-gated, and only if the reuse survey proves reuse is insufficient. Default for all = NO.

  • F4 read-only execution report — produced in this macro only if the internal gate (§10) passes.
  • Checker implementation — only after design + Owner gate; never asserted as built/selftested by this survey (de-bai §V.13; framework §19 STOP).
  • Atomic promote design — only after the evidence decision; HOLD-2 not designed or run by this survey (framework D9; addendum §7b).
  • Runtime stamp-delivery check — only Owner-gated / Phase-1; F4 keeps runtime delivery UNKNOWN (framework D8/D12).
  • Schema / materialization (incl. cell_id / dot_role, stamp columns, candidate-packet store) — only after reuse-insufficiency proof + Owner-gated detailed design (framework §19 STOP; de-bai §V.11 "new mandatory stamp = Mức 3").
  • Canonical birth write / promote — only in future implementation, never in this survey (framework D10; de-bai §V.16 "KHÔNG dùng Matrix/Stamp để né production/kernel gate").
  • Scanner / observability — belongs to F5 (D11 + D12), not F4 (framework §6c; de-bai §17 list-only).

3. F4 scope and non-scope

In-scope (read-only, when the §10 gate passes)

  • Read and classify documentary-only the F4 assets (§2 lists) into Q1/Q2/Q3 from KB evidence pins: required-stamps.v0.1.json; the 8 named stamps + PROMOTE_BLOCKED; candidate packet / packet_hash; the checker / verdict-only boundary; promote-checker-v0.1-spec; the Atomic Promote Contract; the canonical birth boundary; birth_registry / fn_birth_register / fn_birth_gate; the rollback / delete-fast path; staging / pre-promote metadata; post-promote canonical output.
  • Analyse the stamp lifecycle (pre-promote vs post-promote; precondition ≠ output; the 7-core / 8–10 ceiling).
  • Analyse the checker / verdict-only boundary (fail-closed; one packet; no canonical write).
  • Analyse the promote / Atomic Promote Contract boundary (HOLD-2; all-or-nothing; no transaction yet).
  • Analyse the rollback / delete-fast boundary (STG-012; RISK-GC/CAP).
  • Analyse the canonical birth boundary (output at promote only; D10).
  • Carry CONS-002 / CONS-003 / CELL-003/004/007 / HOLD-1 / HOLD-2 / STG-012/015 / STG-REUSE-001/003 / DOT-CAP / RISK-GC/CAP/BYPASS as obligations.
  • Answer the 3 reuse-first Owner questions and emit the execution report.

Non-scope (forbidden at F4 by default)

  • Phase-1; any live DB / Postgres / Directus / runtime / production query or mutation.
  • Touching iu_staging_*, dot_tools, or birth_registry live; calling fn_birth_register / fn_birth_gate / fn_birth_registry_auto live.
  • Writing code / migration / DDL / DML / schema / table / registry / index / source-manifest.
  • Materializing cell_id / dot_role.
  • Creating / registering / running any DOT; running any formula; building any assembly machine.
  • Creating or running a checker; creating or running a scanner.
  • Running promote; writing canonical birth; closing BIRTH_STAMP; writing PROMOTE_STAMP; writing a PROMOTE_BLOCKED state.
  • Resolving CONS-002 / CONS-003 / CELL-003/004/007.
  • Treating documentary row counts / trigger counts as live proof.
  • Treating the Codex PASS as Owner authorization for any future phase.
  • Turning the F4 report into technical design.

4. Reuse-now inventory template (Q1 detail)

F4 execution fills Reuse verdict + Evidence pin (this-pass). Until then every row is a documentary candidate, not a reuse decision. Status quotes framework rev56 §6c D8/D9/D10 + the DRAFT specs + catalog rev82.

Asset Documentary status Documentary detail Reuse-now hypothesis Catalog / spec ref Reuse verdict (fills) Evidence pin (fills)
required-stamps.v0.1.json DOCUMENTARY_ONLY (DRAFT — not enacted; D8) 7 core + 2 high-risk; lifecycle workspace/precond/output/canonical vocabulary + lifecycle ordering required-stamps rev6 / D8 TODO TODO
TEMP_ID_STAMP DOCUMENTARY_ONLY (D8/D10) workspace_required + promote_preconditions; workspace_id/candidate_id pre-promote workspace stamp required-stamps lifecycle TODO TODO
CELL_STAMP DOCUMENTARY_ONLY / BLOCKED-dep (D8) precondition + canonical_required; = COLLECTION+SPECIES pre-promote stamp (cell pending) CONS-003 / CELL-003/004/007 TODO TODO
IO_STAMP DOCUMENTARY_ONLY / BLOCKED-dep (D8) precondition + canonical_required pre-promote stamp (IO source unresolved) CONS-002 TODO TODO
VALIDATION_STAMP DOCUMENTARY_ONLY (D8) precondition + canonical_required; "DOT validate → FIX7 rút gọn" pre-promote stamp addendum §5 TODO TODO
ROLLBACK_STAMP DOCUMENTARY_ONLY (D8) precondition + canonical_required pre-promote stamp (rollback proof) STG-012 / RISK-GC/CAP TODO TODO
BIRTH_STAMP DOCUMENTARY_ONLY (D10) promote_outputs + canonical_required; OUTPUT after promote post-promote OUTPUT only de-bai §IV.4/§V.5 TODO TODO
PROMOTE_STAMP DOCUMENTARY_ONLY (D9) promote_outputs + canonical_required; OUTPUT after promote post-promote OUTPUT only de-bai §V.7 TODO TODO
PROMOTE_BLOCKED DOCUMENTARY (verdict/state) checker verdict + packet status; absent from stamp set verdict/state, NOT a stamp de-bai §V.4 / spec §4 TODO TODO
candidate packet / packet_hash DOCUMENTARY_ONLY (D9) view/binding on staging; sha256; one packet view/projection, no new store STG-015 / spec §2.1 TODO TODO
checker / verdict-only DOCUMENTARY_ONLY (D9; spec rev11) verdict-only; fail-closed; no canonical write spec candidate (not built) DOT-006 / de-bai §V.13 TODO TODO
promote-checker-v0.1-spec DOCUMENTARY_ONLY (DRAFT) PROMOTE_OK/PROMOTE_BLOCKED/ESCALATE_L3 documentary checker spec spec rev11 TODO TODO
Atomic Promote Contract BLOCKED / HOLD-2 (D9) all-or-nothing transaction; no real txn/rehearsal documentary boundary only addendum §7b TODO TODO
birth_registry DOCUMENTARY_ONLY (D10; §4 downgrade) reported inspect_* cols + "162 triggers / enacted v1.0" documentary substrate candidate addendum §1.2/§8 TODO TODO
fn_birth_register / fn_birth_gate DOCUMENTARY_ONLY (F1 lineage) addendum analog = fn_birth_registry_auto; not re-proven documentary candidates, not live F1 reports / framework D10 TODO TODO
rollback / delete-fast DOCUMENTARY_ONLY (§6.2) "sai thì xóa"; TTL; fn_iu_staging_cleanup documentary boundary de-bai §VI.4 / STG-012 TODO TODO
staging / pre-promote metadata DOCUMENTARY / HOLD-1 pre-promote stamp store; iu_staging_* "HOLD FOR SYSTEM CHECK" documentary store candidate HOLD-1 / addendum §2b TODO TODO
post-promote canonical output DOCUMENTARY_ONLY (D10) canonical birth + stamps written only at promote OUTPUT boundary only framework §6c D10 TODO TODO
F1/F2/F3 accepted baselines ACCEPTED (decision lineage) source/evidence/boundary decisions authority/evidence basis F0/F1/F2/F3 records TODO TODO

Reuse-first gate (catalog §2c) — recorded, not executed: before proposing anything new, F4 must answer Decision Rule 1→7 and prove all 5 no-new-creation conditions: (1) existing stamp vocabulary (required-stamps.v0.1.json) insufficient · (2) existing checker spec / candidate-packet view insufficient · (3) existing staging/canonical metadata stores insufficient · (4) existing rollback/delete-fast + birth substrate insufficient · (5) reuse slower than new. Material priority order (de-bai §IV.5): metadata/jsonb hiện có → staging payload → DOT nhẹ/wrapper → stamp xác nhận → (chỉ khi bất khả kháng) sửa core / tạo registry mới. No new-creation proposed by this packet.

5. Repair / verify-before-reuse inventory template (Q2 detail)

Item Why not reuse-now Verification needed (Owner-gated; NOT done at F4) Conflict/HOLD/risk ref
required-stamps runtime delivery JSON is DRAFT/static; "checker READS this file" prove KB→runtime delivery + enforcement at Phase-1 framework D8/D12 UNKNOWN
Checker implementation/selftest spec rev11 DRAFT; never written/selftested build + run selftest (tamper/empty fail-closed, no token leak) — later DOT-006; de-bai §V.13
Checker verdict-only / fail-closed behavior §2.2 binding rules are a spec, not verified behavior verify behavior once a checker exists spec §2.2/§5
Candidate-packet binding packet_hash coverage of cell_id+stamps undefined resolve what packet_hash covers STG-015 BLOCKER
Staging / pre-promote stamp store iu_staging_* "HOLD FOR SYSTEM CHECK" scoped read-only substrate survey HOLD-1 Phase-1
Atomic Promote Contract no real transaction + no rehearsal proof design + staging rehearsal (FIX7-style) — later HOLD-2 BLOCKED
birth_registry / birth functions reported LIVE = documentary; names from F1 lineage confirm live schema/triggers/functions at Phase-1 framework §4 downgrade
Birth gate trust at promote gate warns, does not block; bypass kill-switch surface controlled+audited pilot gate RISK-BYPASS
Rollback / delete-fast who calls cleanup unknown; orphan/cap unverified verify scheduler + blob lifecycle + cap STG-012 / RISK-GC / RISK-CAP
CELL_STAMP cell dimensions unresolved resolve composition levels + cell_id sources CONS-003 / CELL-003/004/007
IO_STAMP which IO source wins; examples GAP resolve IO source precedence + identify examples CONS-002
DOT-based validation (inspector→stamp) DOT capability contract / no-mutation / tests missing resolve DOT capability + ≥8 bad-input tests DOT-CAP-001/004/006/010
Runtime / checkout sync baseline = KB only runtime not inferable CONS-005 caveat

6. Add-later-only-if-needed template (Q3 detail)

Nothing here is authorized. Each is future Owner-gated, and only if the reuse survey proves reuse is insufficient. Default for all = NO.

Possible future item Precondition to even propose Default
F4 read-only execution report This packet passes the §10 internal gate produced in-macro only if gate passes
Checker implementation design reviewed + Owner gate; reuse-insufficiency proven NO
Atomic promote design evidence decision + Owner gate; HOLD-2 lifted by Owner NO
Runtime stamp-delivery check Owner-gated / Phase-1 NO
Schema / materialization (cell_id/dot_role/stamp cols/packet store) reuse-insufficiency proof + Owner-gated detailed design (§19 STOP); new mandatory stamp = Mức 3 NO
Canonical birth write / promote future implementation only; never in survey NO
Scanner / observability belongs to F5 (D11+D12), not F4 NO

7. F4 evidence obligations

The F4 execution report must, for every classified row:

  • Pin the current-pass KB evidence (doc + rev + section) for each Q1/Q2/Q3 classification, and label each as documentary vs (where claimed) live.
  • Keep required-stamps runtime delivery = UNKNOWN unless a Phase-1 proof is presented (it will not be — Phase-1 is forbidden here).
  • Keep promote-checker-v0.1-spec as DOCUMENTARY_ONLY (not executable/implemented).
  • Keep the Atomic Promote Contract = HOLD-2 / BLOCKED (no transaction proof).
  • Keep birth_registry / fn_birth_register / fn_birth_gate as documentary candidates (not live proof); note the addendum analog fn_birth_registry_auto.
  • Keep BIRTH_STAMP / PROMOTE_STAMP as post-promote OUTPUTS only; keep PROMOTE_BLOCKED as a verdict/state, not a stamp.
  • Carry CONS-002 / CONS-003 / CELL-003/004/007 / HOLD-1 / HOLD-2 / STG-012/015 / STG-REUSE-001/003 / DOT-CAP-001/004/006/010 / RISK-GC/CAP/BYPASS honestly, without resolving them.
  • Distinguish current-pass vs prior-session / carried-pinned provenance for every authority/source claim.

8. Known risks / stop conditions

  • Stamp-as-runtime risk — inferring that stamps are delivered/enforced just because required-stamps.v0.1.json exists. STOP: keep UNKNOWN.
  • Paper-lane risk — describing the checker/promote lane as if it exists. STOP: "No checker, no lane"; keep DOCUMENTARY_ONLY.
  • Atomic-promote temptation — designing or "rehearsing" the transaction. STOP: HOLD-2 / BLOCKED, survey-only.
  • Canonical-birth temptation — writing a birth row / closing BIRTH_STAMP / writing PROMOTE_STAMP. STOP: output at promote (F4 implementation), never the survey.
  • PROMOTE_BLOCKED-as-stamp risk — listing it among stamps. STOP: it is a verdict/state.
  • Live-proof inflation — treating birth_registry "162 triggers / enacted v1.0" or dot_tools ~309 as live proof. STOP: documentary.
  • Conflict-resolution drift — quietly picking 6 vs 7 tầng, an IO source, or a cell dimension. STOP: carry CONS-002/003 + CELL-*.
  • Schema drift — proposing cell_id/dot_role/stamp columns/a packet store as if approved. STOP: §19 STOP; new mandatory stamp = Mức 3 (de-bai §V.11).
  • Authority inflation — treating Codex PASS as Owner phase-authorization. STOP: Owner/GPT only.

If F4 cannot classify a critical item safely → mark BLOCKED or PARTIAL and do not execute beyond what is safe. If an item requires live DB/runtime proof → classify Q2/Q3, carry as a Phase-1 obligation, do not query.

9. Bad-input / adversarial checks

The F4 execution report must run an adversarial pass that rejects (at minimum) these bad assumptions:

  1. "required-stamps.v0.1.json existing means the stamps are delivered/enforced at runtime." → Reject (UNKNOWN; DRAFT/static).
  2. "The promote checker is implemented because a spec exists." → Reject (DRAFT; never selftested).
  3. "PROMOTE_OK is a mutation / the checker writes canonical." → Reject (verdict-only).
  4. "PROMOTE_BLOCKED is a canonical stamp." → Reject (verdict/state; absent from stamp set).
  5. "BIRTH_STAMP / PROMOTE_STAMP are preconditions." → Reject (post-promote outputs).
  6. "Atomic promote exists because the contract is written." → Reject (HOLD-2; no transaction/rehearsal).
  7. "birth_registry / fn_birth_register / fn_birth_gate are live-proven." → Reject (documentary; F1 lineage; analog fn_birth_registry_auto).
  8. "The birth gate blocks today." → Reject (warning + bypass surface = RISK-BYPASS).
  9. "CELL_STAMP can be closed because we know the cell." → Reject (CONS-003 / CELL-* unresolved).
  10. "The IO source for IO_STAMP is settled." → Reject (CONS-002 BLOCKER).
  11. "Rollback/delete-fast is trustworthy." → Reject (STG-012 / RISK-GC / RISK-CAP open).
  12. "Candidate-packet binding is tamper-proof." → Reject (STG-015 packet_hash coverage undefined).
  13. "We can reuse iu_staging_* as the pre-promote store now." → Reject (HOLD-1 / "HOLD FOR SYSTEM CHECK").
  14. "Closing F3 / Codex PASS authorizes building the checker or promoting." → Reject (Owner/GPT only; F4 = survey).

Pass condition: no bad assumption leads to a PASS-to-act or a forbidden action → F4 execution is not fail-open.

10. Internal gate — when to proceed from packet to F4 execution

This Program Macro authorizes the read-only F4 execution report (Document 3) only if every gate item below is GREEN. If any item is RED, the macro STOPS at PARTIAL/BLOCKED and Document 3 is not created.

# Gate item Pass condition
G1 Mandatory sources readable F4-critical sources read this pass: F3 report rev6, F3 packet rev1, F3 decision rev1, F2/F1/F0 records, framework rev56 (§6c D8/D9/D10 + §19 + §20), de-bai rev33 (§IV/§V/§VI stamp/promote/rollback), catalog rev82 (DOT-006, STG-, DOT-CAP, RISK-, CONS-002/003, CELL-*), required-stamps.v0.1.json rev6, promote-checker-v0.1-spec.md rev11, matrix-stamp-governance-addendum.md rev14, constitution v4.6.3, OR v7.58
G2 F3 gate closed first reports/f3/f3-owner-decision-record-2026-06-16.md exists and accepts F3 (rev1)
G3 Every F4 asset classifiable honestly each Q1/Q2/Q3 row maps to a KB evidence pin without inventing live proof; runtime delivery kept UNKNOWN; checker kept DOCUMENTARY_ONLY
G4 No live DB/runtime/Phase-1 needed classification is documentary-only; iu_staging_* / dot_tools / birth_registry untouched; no fn_birth_* call
G5 No conflict resolution needed CONS-002 / CONS-003 / CELL-003/004/007 carried, not resolved
G6 No schema/design/implementation needed no cell_id/dot_role/stamp-column materialization; no checker/scanner build; no promote/canonical-birth write; no atomic-promote design/run
G7 Boundary held stamps = documentary vocabulary (runtime delivery UNKNOWN); checker = verdict-only spec only; atomic promote = HOLD-2/BLOCKED; PROMOTE_BLOCKED = verdict/state; BIRTH_STAMP/PROMOTE_STAMP = post-promote outputs only; no canonical birth
G8 3 Owner questions preserved Q1/Q2/Q3 present in the execution report

If all GREEN → run the read-only F4 survey from KB/documentary evidence only and emit Document 3 (STATUS honest — PARTIAL is acceptable and expected where every candidate is documentary-only / DRAFT / BLOCKED / UNKNOWN / Owner-gated).

11. Expected F4 execution report format

When the §10 gate passes, the F4 execution report should mirror the F0/F1/F2/F3 report shape:

  • §0 STATUS (one line): PASS / PARTIAL / BLOCKED, honest.
  • §1 Status / boundary confirmation (incl. internal gate result).
  • §2 Owner View — the 3 reuse-first questions (Q1/Q2/Q3) answered at the control surface.
  • §3 F4 asset classification table — Q1/Q2/Q3 with verdict + evidence pin + documentary/live label per row.
  • §4 Stamp lifecycle analysis (7 core + 2 high-risk; pre-promote vs post-promote; precondition ≠ output; runtime delivery UNKNOWN; 8–10 ceiling).
  • §5 Checker / verdict-only analysis (spec DRAFT; fail-closed; one packet; no canonical write; "No checker, no lane").
  • §6 Promote / atomic promote analysis (Atomic Promote Contract; HOLD-2; all-or-nothing; no transaction yet).
  • §7 Rollback / delete-fast analysis (ROLLBACK_STAMP precondition; STG-012; RISK-GC/CAP; "sai thì xóa").
  • §8 Candidate packet / staging / metadata handling (view/projection; packet_hash / STG-015; HOLD-1 pre-promote store).
  • §9 Canonical birth boundary analysis (output at promote only; D10; birth_registry/fn_birth_* documentary; RISK-BYPASS).
  • §10 Evidence currency table (sources/evidence/authority/conflict/runtime/provenance/safety-lock; documentary vs live).
  • §11 Conflict / HOLD log — CONS-002, CONS-003, CELL-003/004/007, HOLD-1, HOLD-2, STG-012/015, STG-REUSE-001/003, DOT-CAP-001/004/006/010, RISK-GC/CAP/BYPASS carried.
  • §12 Adversarial check result — §9 bad-input results (all rejected).
  • §13 Non-authorization confirmation + self-check.
  • §14 F5 handoff / next-gate recommendation.

PARTIAL is acceptable and honest where evidence is documentary-only / DRAFT / BLOCKED / UNKNOWN or a verification is Owner-gated. Engineering PASS ≠ Authority PASS.

12. How F4 feeds F5

F5 in the §6c order = Scanner / Observability + Runtime / Operational Safety (= D11 + D12): read-only observation (missing-stamp scan, orphan scan, heartbeat/freshness) + runtime/config/operational safety wrapping the running system — "chỉ quan sát / safety, không tạo build mới". F4 hands F5:

  • the stamp lifecycle vocabulary (required-stamps.v0.1.json; 7 core stamps; pre-promote vs post-promote) as the contract a missing-stamp scanner (D11) would read — without implementing the scanner;
  • the checker / verdict-only / Atomic Promote Contract boundary (verdict-only; HOLD-2) as the lane F5 observes — F4 only marks it documentary, never implements;
  • the canonical birth boundary (birth_registry documentary; canonical birth output at promote) as the substrate an orphan / freshness scan would observe;
  • the runtime-delivery UNKNOWN for required-stamps (D12 config-delivery) as an explicit open obligation F5 must verify, not assume;
  • the carried conflicts (CONS-002, CONS-003, CELL-003/004/007) and risks (HOLD-1, HOLD-2, STG-012/015, STG-REUSE-001/003, DOT-CAP-001/004/006/010, RISK-GC/CAP/BYPASS) as obligations F5 must respect, not inherit as solved.

F4 preparation and execution must again preserve the 3 reuse-first Owner questions and remain non-authorizing until its own GPT → Codex → Owner gate. The Program Macro bundling (packet + internal-gated execution in one task) is an Owner choice already exercised for this F4 run; it does not open F5, Phase-1, or any design/implementation. Owner may instead decide that Phase-1 / CONS-002 / CONS-003 / CELL- / HOLD-1 / HOLD-2* must be resolved before F5.

13. Self-check (packet discipline)

  1. Preserved the 3 reuse-first Owner questions (Q1/Q2/Q3)? Yes (§2).
  2. Kept F4 = Stamp Lifecycle + Checker / Promote / Rollback only (D8+D9+canonical-output D10)? Yes (§1/§3).
  3. Avoided Phase-1 / DB / runtime in scope? Yes (§3 non-scope).
  4. Avoided checker execution / promote execution / canonical birth? Yes (§3/§6/§8).
  5. Kept BIRTH_STAMP / PROMOTE_STAMP as future promote OUTPUTS only? Yes (§1/§2 Q1).
  6. Kept PROMOTE_BLOCKED as verdict/state, not a canonical stamp? Yes (§1/§2/§9-checks).
  7. Kept required-stamps runtime delivery UNKNOWN? Yes (§1/§2 Q2/§7).
  8. Avoided cell_id / dot_role materialization? Yes (§1/§3 non-scope).
  9. Carried CONS-002 / CONS-003 / CELL-* honestly? Yes (§2 Q2/§5/§8 risk).
  10. Avoided checker/scanner implementation; kept scanner = F5? Yes (§2 Q3/§12).
  11. Distinguished documentary vs live proof? Yes (§1/§4/§7).
  12. Kept Owner/GPT as the only phase authority (Codex = control verdict only)? Yes (§1/§8/§9-check 14).
  13. Defined an internal §10 gate (G1–G8, all-GREEN rule) gating Document 3? Yes (§10).

F4 Reuse Survey Packet | 2026-06-16 | STATUS: PREPARATION PACKET — NON-AUTHORIZING. F4 = D8 + D9 + canonical-output of D10 (Stamp Lifecycle + verdict-only Checker + Promote / Rollback; canonical birth = OUTPUT at promote only). Stamps = documentary vocabulary; runtime delivery UNKNOWN. Checker = verdict-only spec (DRAFT, not built). Atomic promote = HOLD-2 / BLOCKED. PROMOTE_BLOCKED = verdict/state ≠ stamp. BIRTH_STAMP/PROMOTE_STAMP = post-promote outputs only. No Phase-1 · no DB/runtime · no checker/promote/canonical-birth · no schema/cell_id/dot_role. CONS-002 / CONS-003 / CELL-003/004/007 carried (BLOCKER). HOLD-1 Phase-1-gated. HOLD-2 = F4 subject. STG-012/015 / STG-REUSE-001/003 / DOT-CAP-001/004/006/010 / RISK-GC/CAP/BYPASS open. Documentary ≠ live proof. Engineering PASS ≠ Authority PASS. Codex PASS ≠ Owner phase-authorization. Feeds F5 (Scanner / Observability + Runtime / Operational Safety = D11 + D12).