Incomex AI Portal
KB-635C

F4 Owner Decision Record — Stamp Lifecycle + Checker / Promote / Rollback gate closed — 2026-06-16

16 min read Revision 1
laws-newmatrix-assemblystamp-governancef4owner-decision-recorddecision-gatestamp-lifecyclecheckerpromoterollbackatomic-promotehold-2non-authorizing2026-06-16

F4 Owner Decision Record — Stamp Lifecycle + Checker / Promote / Rollback gate closed — 2026-06-16

Ngày: 2026-06-16 · Soạn: Claude Code CLI (recorder, read-only AgentData KB) · Track: knowledge/dev/laws-new/ Records: decisions taken by GPT/Owner on the F4 read-only execution. Claude Code is the recorder, not the decider. Records (artifacts): reports/f3/f3-owner-decision-record-2026-06-16.md rev1 (F3 gate closed) · f4-stamp-checker-promote-rollback-reuse-survey-packet.md rev1 · reports/f4/f4-stamp-checker-promote-rollback-execution-report-2026-06-16.md rev1 (STATUS=PARTIAL). Evidence basis: F4 execution report rev1 (PARTIAL) + F4 reuse-survey packet rev1 + Codex review STATUS: PASS + carried-pinned F0/F1/F2/F3 decision records + constitution v4.6.3 (NT9/NT14/NT15/Đ20/Đ32) + OR v7.58 (reused as authority basis under CONS-004, not re-opened). Layer: F4 = framework rev56 §6c D8 (Stamp Lifecycle) + D9 (Checker · Promote · Rollback · Atomic Boundary) + canonical-output of D10 (Birth · Identity · Canonical Root). Next layer F5 = D11 (Scanner / Observability / Heartbeat) + D12 (Runtime / Config / Operational Safety).

0. STATUS (one line at top)

F4 DECISION GATE CLOSED. The F4 bundle (decision-prep packet rev1 + execution report rev1 PARTIAL) is accepted as the evidence basis; Codex PASS is accepted as a control verdict only; the F4 boundary is accepted; all carried conflicts/risks remain unresolved; this unlocks the F5 Program Macro only. READ-ONLY, NON-AUTHORIZING. Documentary ≠ live proof · Prior-session ≠ current proof · Engineering PASS ≠ Authority PASS · Reuse-now ≠ live-proven · Codex PASS ≠ Owner phase-authorization.

1. Owner View — 3 câu hỏi (control surface, simple)

Mục này KHÔNG ủy quyền vận hành. It records, in plain terms, what the F4 survey established so the Owner can decide the next gate.

Q1 — Cái gì đang có và dùng lại được? The stamp lifecycle vocabulary is documented and reusable as a contract on paper: 7 core stamps (TEMP_ID_STAMP · BIRTH_STAMP · CELL_STAMP · IO_STAMP · VALIDATION_STAMP · ROLLBACK_STAMP · PROMOTE_STAMP) + 2 high-risk (GOV_STAMP · OWNER_STAMP), with a pre-promote vs post-promote ordering and the load-bearing rule precondition ≠ output. Also reusable as documentary boundaries: the verdict-only checker spec, the Atomic Promote Contract shape, PROMOTE_BLOCKED as a verdict/state (not a stamp), and the F0/F1/F2/F3 accepted lineage. All of this is documentary — none is proven running.

Q2 — Cái gì đang có nhưng cần sửa/kiểm chứng mới dùng lại được? The runtime delivery of required-stamps is UNKNOWN; the checker is a DRAFT spec, never built or selftested; the Atomic Promote Contract is HOLD-2 / BLOCKED (no transaction, no rehearsal); the pre-promote staging home (iu_staging_*) is HOLD-1; birth_registry / fn_birth_* are documentary only; CELL_STAMP and IO_STAMP are blocked by CONS-003/CELL-* and CONS-002; DOT-based validation is constrained by DOT-CAP; and the cleanup/orphan/bypass risks (STG-012/015, RISK-GC/CAP/BYPASS) are open. Each needs Owner decision and/or a Phase-1 read-only survey before it can be trusted.

Q3 — Cái gì thật sự phải làm thêm? Building the checker, designing/rehearsing the atomic promote transaction, proving KB→runtime stamp delivery, materializing any cell_id/dot_role/stamp columns or a new store, writing canonical birth / closing BIRTH_STAMP / writing PROMOTE_STAMP — all are future, Owner-gated, default-NO work, none authorized by closing F4. Scanner/observability/runtime-safety belongs to the next layer (F5 = D11 + D12), which this gate unlocks as a survey macro only.

2. What was decided (decision table)

# Decision item Decision
D1 F4 bundle accepted as evidence basis. Accepted. The F4 execution report rev1 (PARTIAL) + F4 reuse-survey packet rev1 are the evidence basis for closing F4 and unlocking F5. No Claude patch required.
D2 Codex PASS accepted. Accepted as a control verdict only, not Owner phase-authorization (constitution NT-discipline; OR §8). Codex reviewed the F3 decision record + F4 packet + F4 report together and returned STATUS: PASS.
D3 PARTIAL accepted as honest and non-blocking. Accepted. PARTIAL (not PASS) is correct because every F4 asset is DOCUMENTARY_ONLY / DRAFT / BLOCKED / UNKNOWN and the gating conflicts/risks are carried, not resolved. Engineering PASS ≠ Authority PASS.
D4 F4 boundary accepted (see §3). Accepted and not re-opened.
D5 CONS-002 / CONS-003 / CELL-003/004/007 remain unresolved. Carried as obligations to Owner / Phase-1 (see §4). Not decided here.
D6 HOLD-1 remains Phase-1-gated. Carried. The live home of the pre-promote staging store (iu_staging_*) is verified only under a separate Owner-gated Phase-1 read-only survey (see §5).
D7 HOLD-2 remains F4-implementation-only, not resolved. Carried. The Atomic Promote Contract is BLOCKED; the real transaction + rehearsal proof are implementation work behind a separate Owner gate — surveyed documentary-only at F4, not designed or run (see §5).
D8 STG-012 / STG-015 / STG-REUSE-001/003 / DOT-CAP-001/004/006/010 / RISK-GC/CAP/BYPASS remain open. Carried as Phase-1 / Owner / spec obligations (see §4).
D9 What this unlocks. The F5 Program Macro only (see §7). Nothing operational.

3. F4 boundary (ACCEPTED — not re-opened)

The following F4 boundary, held throughout the F4 execution report rev1, is accepted and is not re-opened at F5:

  • Stamps are documentary vocabulary, not proven runtime delivery. required-stamps.v0.1.json (rev6) is DRAFT — not enacted: a static config a checker is meant to READ. Its existence does not imply stamps are enforced at runtime.
  • Runtime delivery of required-stamps = UNKNOWN. Framework D8 states "stamp config runtime delivery unknown"; D12 lists "required-stamps KB→runtime delivery" as UNKNOWN. Delivery may NOT be inferred from the JSON's existence. This is an explicit open obligation, not a solved fact.
  • Checker is a DRAFT spec and not built. promote-checker-v0.1-spec.md (rev11) is DRAFT — KHÔNG PHẢI BAN HÀNH, never written/selftested. Hard rule: "No checker, no lane. A paper lane is no lane." Until the checker runs for real (fail-closed, passes selftest) there is no promote lane.
  • Checker is verdict-only. It checks exactly one candidate packet; it does not scan the system, does not sign birth, does not write canonical, and does not close BIRTH_STAMP / PROMOTE_STAMP. PROMOTE_OK is a verdict, not a mutation.
  • 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 and no rehearsal proof: "Chưa có atomic promote transaction + rehearsal proof … thì CHƯA được mở pilot promote thật." Checker (verdict) and atomic promote (mutation) are two separate steps, not merged.
  • 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.
  • BIRTH_STAMP / PROMOTE_STAMP are post-promote OUTPUTS only. They are closed by the atomic promote transaction after PROMOTE_OK; they are not preconditions and were not written by F4. Precondition ≠ output is the load-bearing invariant.
  • Canonical birth = output at promote only. Per framework §6c D10 and the build-order note, canonical birth is the OUTPUT at the promote boundary (F4) — never front-loaded, never earlier than promote. F4 wrote no canonical birth, closed no BIRTH_STAMP, wrote no PROMOTE_STAMP, and called no fn_birth_* live.
  • No cell_id / dot_role materialization · no canonical birth · no schema. birth_registry / fn_birth_register / fn_birth_gate remain documentary candidates, not live proof (framework §4 downgrades reported-LIVE; F1 lineage).

The adversarial check in the report (§12, 14 numbered bad-assumptions, all Rejected) confirms F4 execution was not fail-open.

4. Carried blockers — remain unresolved (NOT decided here)

These conflicts/risks are carried forward to F5 and Phase-1 as obligations, not resolved at this gate:

  • CONS-002 — which source wins for the IO Contract fields (5-field thin vs DOT/evidence/owner). Status: TODO / BLOCKER. Owner decision; keep the 5 fields meanwhile. Blocks IO_STAMP.
  • CONS-003 — 6 tầng vs 7 Lớp/dimensions (constitution Đ0-B/Đ29 vs drafts NT6/Đ5). Status: CONFLICT / BLOCKER. Owner decision (not adjudicated). Blocks cell placement, cell_id, CELL_STAMP.
  • CELL-003 (layer source) PARTIAL/BLOCKER · CELL-004 (species, 2 namespaces) CONFLICT/BLOCKER · CELL-007 (tier catalog / composition_level not enacted) PARTIAL/BLOCKER. Owner + Phase-1. All block CELL_STAMP.
  • STG-012 — cleanup scheduler unknown (no pg_cron; who calls fn_iu_staging_cleanup). TODO / BLOCKER. Phase-1.
  • STG-015 — candidate-packet tamper-binding (packet_hash coverage of cell_id + stamps). PARTIAL / BLOCKER. Owner/spec + Phase-1.
  • STG-REUSE-001 — iu_staging_* as shared kho tạm sufficiency. TODO / BLOCKER. Phase-1.
  • STG-REUSE-003 — any new packet store/registry. BLOCKER-if-proposed; default NO.
  • DOT-CAP-001 / 004 / 006 / 010 — DOT capability contract / no-mutation flag / ≥8 bad-input tests / read-vs-mutate classification. BLOCKERs. Owner/spec + Phase-1. Constrain trusting DOT-based validation/observability.
  • RISK-GC (blob_ref lifecycle + delete-fast) OPEN · RISK-CAP (payload under CASCADE / 10 MiB cap) OPEN · RISK-BYPASS (birth gate warning + bypass surface, inherited F1; framework D10) OPEN. Phase-1 (RISK-BYPASS also a controlled+audited pilot gate).
  • required-stamps runtime delivery UNKNOWN — Phase-1 (D12). promote-checker implementation DOCUMENTARY_ONLY (DRAFT) — F4 implementation behind a separate Owner gate.

No blocker above is resolved by this record. Resolving any of them is future Owner work, not implied by closing F4.

(Reused, not re-opened: CONS-004 authority order and CONS-005 freeze baseline, both decided at F0; CONS-005 carries the "no runtime/checkout sync proof" caveat.)

5. HOLD-1 (Phase-1-gated) and HOLD-2 (F4 implementation) — carried

  • HOLD-1 — the live home for the pre-promote stamp store (iu_staging_record / iu_staging_payload) is "HOLD FOR SYSTEM CHECK". Status: UNKNOWN → likely-LIVE / CONFLICT. Resolution: a separate Owner-gated Phase-1 read-only survey — not opened here.
  • HOLD-2 — the Atomic Promote Contract has no real transaction and no rehearsal proof. Status: BLOCKED. HOLD-2 is the reason canonical birth stays at the promote boundary. It is F4-implementation work behind a separate Owner gate — surveyed documentary-only, not resolved, not designed, not run at this gate. Closing F4 does not lift HOLD-2.

6. What is still NOT authorized (boundary)

Closing F4 authorizes none of: Phase-1; any live DB / runtime / production query; touching iu_staging_* / dot_tools / birth_registry live; calling any birth/checker/promote/scanner function live; creating any source manifest / schema / table / registry / index; materializing cell_id / dot_role / stamp columns; creating or running a DOT / formula / assembly machine / checker / 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; or any technical design / implementation. Default = HOLD.

7. What this unlocks — F5 Program Macro only

This gate unlocks exactly one thing: running the F5 Program Macro for the next §6c layer —

F5 — Scanner / Observability / Heartbeat (D11) + Runtime / Config / Operational Safety (D12) — the operational "roof" (mái), built last; cross-cut by FX (Governance One Roof). A read-only survey of scanner / missing-stamp / orphan / heartbeat / freshness / observability concepts and runtime / config-delivery / operational-safety gates — observation and safety only, no new build.

The unlocked F5 macro is itself non-authorizing: it produces an F5 reuse-survey packet, an internal safety gate, and (only if that gate passes) a read-only documentary execution report — and it remains subject to its own GPT → Codex → Owner gate before anything further. It does not authorize Phase-1, DB/runtime access, a real scanner/heartbeat, a checker/promote lane, or canonical birth.

8. Self-check (recorder discipline)

  1. Did I record the F4 bundle as the evidence basis (not as authorization)? Yes.
  2. Did I record Codex PASS as a control verdict only? Yes.
  3. Did I record PARTIAL as honest and non-blocking? Yes.
  4. Did I record the full F4 boundary (stamps documentary / runtime UNKNOWN / checker DRAFT verdict-only / atomic promote HOLD-2 / PROMOTE_BLOCKED verdict-not-stamp / BIRTH_STAMP·PROMOTE_STAMP post-promote outputs / canonical birth at promote only)? Yes.
  5. Did I carry CONS-002 / CONS-003 / CELL-003/004/007 unresolved? Yes.
  6. Did I carry HOLD-1 (Phase-1-gated) and HOLD-2 (F4 implementation, not lifted)? Yes.
  7. Did I carry STG-012/015, STG-REUSE-001/003, DOT-CAP-001/004/006/010, RISK-GC/CAP/BYPASS open? Yes.
  8. Did I keep the 3 Owner questions at the control surface? Yes.
  9. Did I limit the unlock to the F5 Program Macro only (non-authorizing)? Yes.
  10. Resolved any conflict / wrote any schema / touched any live system / authorized any implementation? No.

9. Next action

  1. Owner reads this record.
  2. Run the F5 Program Macro (packet → internal safety gate → read-only execution report only if the gate passes), per the same discipline used for F0–F4.
  3. Route the F4 decision record + F5 packet + F5 execution report + the cross-F evidence/readiness matrix together to Codex for an independent control review (Codex = control verdict only).
  4. After Codex, Owner decides the post-survey route: A. a Phase-1 read-only substrate/runtime survey; B. blocker decision notes (CONS-002/003, CELL-, HOLD-1, HOLD-2, STG-, DOT-CAP, RISK-*); C. technical-design preparation; D. implementation planning later. Given every F4 candidate is documentary-only / DRAFT / BLOCKED / UNKNOWN, the conservative default is to resolve the checker-implementation / atomic-promote (HOLD-2) and staging (HOLD-1) obligations before building observability (F5) on top of an unproven lane.
  5. Default = HOLD. Codex PASS ≠ Owner phase-authorization.

F4 Owner Decision Record | 2026-06-16 | STATUS: F4 DECISION GATE CLOSED. Unlocks the F5 Program Macro only. READ-ONLY, NON-AUTHORIZING. F4 boundary accepted: stamps = documentary vocabulary; runtime delivery UNKNOWN; checker = DRAFT verdict-only spec, not built ("No checker, no lane"); Atomic Promote Contract = HOLD-2 / BLOCKED; PROMOTE_BLOCKED = verdict/state, not a stamp; BIRTH_STAMP/PROMOTE_STAMP = post-promote outputs only; canonical birth = output at promote only. CONS-002/003 + CELL-003/004/007 unresolved; HOLD-1 Phase-1-gated; HOLD-2 not lifted; 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.