Incomex AI Portal
KB-722F

F2 Owner Decision Record — Information Unit / Smart Brick + Temp Store / Candidate gate

15 min read Revision 1
laws-newf2owner-decisionsmart-bricktemp-storedecision-gate2026-06-16

F2 Owner Decision Record — Information Unit / Smart Brick + Temp Store / Candidate gate

Ngày: 2026-06-16 · Soạn (scribe): Claude Code CLI · Track: knowledge/dev/laws-new/ Records decisions taken by GPT/Owner on the F2 read-only execution. Claude Code is the recorder, not the decider. Evidence basis (F2 bundle): reports/f2/f2-information-unit-temp-store-execution-report-2026-06-16.md rev1 (STATUS=PARTIAL) + f2-information-unit-temp-store-reuse-survey-packet.md rev1. Control basis: technical-slice-framework.md rev56 (§6c D4/D5). Concept basis: de-bai-cai-tien.md rev33. Catalog basis: cau-hoi-khi-tai-cau-truc.md rev82. Prior gate: reports/f1/f1-owner-decision-record-2026-06-16.md rev1 (F1 gate CLOSED) + reports/f0/f0-owner-decision-record-2026-06-16.md rev1 (CONS-004 / CONS-005 / OBL-R2 decided). Codex verdict on the F2 bundle: PASS (relayed by GPT/Owner, accepted).

0. STATUS (one line at top)

STATUS: F2 DECISION GATE CLOSED. GPT/Owner accept the F2 bundle (execution report rev1 + reuse-survey packet rev1) as the evidence basis, accept the Codex PASS, and accept the PARTIAL status as honest and non-blocking. The Smart Brick boundary (brick = subject / temp-store = place; TEMP_ID inherited; no canonical birth; no BIRTH_STAMP) is accepted. iu_staging_* remains documentary / HOLD-1. CONS-003 and CELL-003/004/007 remain unresolved BLOCKERs; STG-012 / STG-015 / STG-REUSE-001/003 remain unresolved; RISK-GC / RISK-CAP / RISK-BYPASS remain open; HOLD-2 (atomic promote) remains an F4 matter. This record unlocks the F3 Program Macro only — no Phase-1, no DB/runtime, no implementation, no schema/registry, no canonical birth, no cell_id materialization. Documentary ≠ live proof · Prior-session ≠ current proof · Engineering PASS ≠ Authority PASS · Reuse-now ≠ live-proven.

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

Đọc riêng mục này là đủ để biết F2 đã được chốt thế nào. Chi tiết ở §3 trở xuống. Cùng cấu trúc 3 câu hỏi reuse-first xuyên suốt F0→FX. Mục này KHÔNG ủy quyền vận hành.

Câu hỏi Owner Trả lời tại gate này
Q1 — Cái gì đang có và đã được chấp nhận để dùng tiếp? F2 execution report rev1 (PARTIAL, honest) + F2 packet rev1 + Codex PASS + the F2 Q1/Q2/Q3 classification + the Smart Brick / "Miếng thông tin" concept (subject) + the TEMP_ID / candidate identity inherited from F1 + the temp-store / candidate reuse map (iu_staging_record / iu_staging_payload + metadata/jsonb + candidate-packet-as-view) + the IO Contract 5-field boundary (nhận·trả·schema_min·fail·rollback) → accepted as the F2 basis for preparing F3. Every F2 substrate candidate stays documentary; acceptance is of the classification quality, not of any live proof.
Q2 — Cái gì đang có nhưng còn điều kiện / chưa chứng minh? iu_staging_* live schema / lifecycle / TTL / candidate_id / blob_ref = DOCUMENTARY_ONLY / UNKNOWN→likely-LIVE CONFLICT → needs a separately-authorized Phase-1 = HOLD-1. Cleanup scheduler (STG-012), packet_hash coverage (STG-015), shared-store sufficiency (STG-REUSE-001) unproven. blob_ref orphan/cap (RISK-GC / RISK-CAP). cell_id dimension sources unresolved (CELL-003/004/007), gated upstream by CONS-003 (6-vs-7 tầng). IO Contract examples = GAP. Checkout/runtime sync still unproven (CONS-005 caveat). RISK-BYPASS carried from F1.
Q3 — Cái gì thật sự còn phải làm thêm? The F3 Program Macro (preparation packet + internal-gated read-only execution) for the next §6c layer — F3 = IO Contract + Formula + Assembly Machine / DOT. Everything touching runtime/DB/schema/canonical-birth/cell_id materialization / new store stays Owner-gated and closed. Resolving CONS-003 / CELL-003/004/007 and authorizing a Phase-1 substrate survey (HOLD-1) remain Owner decisions that F2 surfaced but did not make.

2. What was decided (decision table)

Decision item Recorded? Decision
F2 bundle accepted as evidence basis ✅ Yes The F2 execution report rev1 + F2 reuse-survey packet rev1 are accepted as the authoritative F2 evidence record for this chain. No Claude patch required.
Codex PASS accepted ✅ Yes Codex verdict PASS on the F2 bundle (relayed by GPT/Owner) is accepted as a control verdict only.
PARTIAL status accepted ✅ Yes PARTIAL is accepted as honest and non-blocking. The PARTIAL reasons (every F2 substrate candidate is documentary-only; iu_staging_* = HOLD-1; conflicts/risks carried) do not block the next Owner gate.
Smart Brick boundary accepted ✅ Yes brick = subject; temp-store = place; TEMP_ID inherited; no canonical birth; no BIRTH_STAMP. See §3.
iu_staging_* remains documentary / HOLD-1 ✅ Yes Classified as a documentary candidate only; never treated as proven live. See §5.
CONS-003 remains a BLOCKER ✅ Yes Not resolved at F2. See §4.
CELL-003 / CELL-004 / CELL-007 remain BLOCKERs ✅ Yes Not resolved at F2. See §4.
STG-012 / STG-015 / STG-REUSE-001 / STG-REUSE-003 remain unresolved ✅ Yes Cleanup scheduler, packet_hash coverage, shared-store sufficiency, no-new-store gate all open. See §4.
RISK-GC / RISK-CAP / RISK-BYPASS remain open ✅ Yes blob_ref orphan/cleanup, CASCADE/10 MiB cap, birth-gate bypass — all OPEN. See §4.
HOLD-2 (atomic promote) remains an F4 matter ✅ Yes The reason canonical birth stays at F4. See §5.
What is still NOT authorized ✅ Yes See §6.
What this unlocks ✅ Yes F3 Program Macro only — see §7.

3. Smart Brick boundary (ACCEPTED — not re-opened)

The F2 report (§4–§6) held, and GPT/Owner accept, the boundary exactly as drawn:

  • The brick is the subject; the temp-store is only the place. The Information Unit / Smart Brick / "Miếng thông tin" (framework D4; de-bai §II.1/§VI) is the central subject spanning the lifecycle. The temp store / candidate (D5) is only where the brick stands — the brick is không chôn trong temp-store (must not be buried). F3 must not collapse the subject into its storage.
  • TEMP_ID / candidate identity = inherited from F1 — a minimal identity root only (TEMP_ID_STAMP / candidate_id / workspace_id at kho tạm), sufficient to operate (edit/check/delete/rollback) the brick (de-bai §V.10). The brick stands on it before lifecycle.
  • No canonical birth at F2. BIRTH_STAMP + canonical birth are the OUTPUT at the promote boundary = F4 (framework §6c D10; de-bai §V.5/§V.10). Pre-promote stamps live in candidate/workspace metadata or the staging record — never written to birth_registry in kho tạm.
  • No BIRTH_STAMP written. F2 wrote no TEMP_ID_STAMP, no BIRTH_STAMP, no canonical record — it only classified the inherited identity concept. "KHÔNG dùng cùng một dấu cho hai nghĩa" (de-bai §V.10) is upheld: TEMP_ID_STAMP (kho tạm) ≠ BIRTH_STAMP (canonical, after promote).
  • No new Information Unit registry / temp-store table / packet store (framework D4/D5 Forbidden; de-bai §V.13; catalog STG-REUSE-003). The candidate packet = view/projection on existing staging metadata (candidate_id + packet_hash), read by a verdict-only checker — not a new store.

This boundary is the explicit thing F2 hands forward. It is not an authorization to write any stamp or canonical record; it is the rule F3 (and F4) must respect.

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

The F2 report carried these as gating conflicts/risks. GPT/Owner record that they remain open and are not resolved by accepting F2:

  • CONS-003 (6-vs-7 tầng) — CONFLICT / BLOCKER (TODO). Confirmed against constitution.md rev44: Đ0-B "7 Lớp Cấu tạo (33 species)" and Đ29 "33 species, 7 dimensions" vs the drafts' 6-tầng model. Blocks any cell placement and cell_id dimension resolution. Owner decision required.
  • CELL-003 (layer source: composition_level vs meta_catalog.layer) — PARTIAL / BLOCKER.
  • CELL-004 (species source: 2 namespaces) — CONFLICT / BLOCKER.
  • CELL-007 (chuẩn 6-tầng; composition_level chưa enacted) — PARTIAL / BLOCKER.
  • STG-012 (cleanup scheduler) — TODO / BLOCKER. Who calls fn_iu_staging_cleanup (no pg_cron); TTL fail-safe unproven until then.
  • STG-015 (packet_hash coverage) — PARTIAL / BLOCKER. Whether it covers cell_id + stamps; affects candidate-packet tamper-binding.
  • STG-REUSE-001 (shared-store sufficiency) — BLOCKER. Whether iu_staging_* is sufficient as the shared kho tạm for all tiers v0.1.
  • STG-REUSE-003 (no new packet store) — BLOCKER-if-proposed. Default NO (de-bai §V.13).
  • RISK-GC (blob_ref orphan/cleanup) — OPEN. Payload blob lifecycle unverified.
  • RISK-CAP (CASCADE / 10 MiB cap) — OPEN. Payload behavior under load unverified.
  • RISK-BYPASS (fn_birth_gate warning + app.bypass_birth_gate) — OPEN (inherited F1). Verify + control + audit before trusting the gate at the promote boundary.

Decision: these are carried, not resolved. F3 must respect them as obligations and may not inherit cell_id placement, the candidate-packet binding, or the staging substrate as solved. CONS-004 and CONS-005 remain decided at F0 (working precedence + accepted KB-only freeze-candidate baseline) and are reused, not re-opened.

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

  • HOLD-1 (iu_staging_record / iu_staging_payload) — UNKNOWN→likely-LIVE / CONFLICT ("HOLD FOR SYSTEM CHECK"). This is the TEMP_ID live home, the F2 temp-store / candidate candidate, and the natural live home for the candidate packet. Decision: it remains a Phase-1 read-only obligation — verifying its live schema / lifecycle / TTL / candidate_id / blob_ref + the STG-012 cleanup scheduler + STG-015 packet_hash + STG-REUSE-001 shared-store sufficiency + RISK-GC / RISK-CAP is a separate Owner gate, not part of the F3 Program Macro. F3 may classify it as a documentary / HOLD-1 candidate only, never as live-proven.
  • HOLD-2 (atomic promote) — BLOCKED (no real transaction yet). Decision: it remains an F4 matter — it is the reason canonical birth stays at F4, not F2/F3.

6. What is still NOT authorized (boundary)

This decision record authorizes nothing operational. Still forbidden / Owner-gated:

  • ❌ Phase-1 substrate survey (read-only DB survey), including any read of iu_staging_* (HOLD-1).
  • ❌ Any live DB / runtime / Directus / PG / production query or mutation.
  • ❌ Touching birth_registry, iu_staging_*, dot_tools, or any production data.
  • ❌ Canonical birth write / BIRTH_STAMP close (remains an output at the promote boundary = F4).
  • ❌ Creating schema / table / registry / index / DOT / checker / scanner / source-manifest / packet store.
  • ❌ Materializing cell_id / dot_role as a column; adding columns to dot_tools / meta_catalog / collection_registry.
  • ❌ Registering or running a DOT; building an assembly machine; running a formula; creating an IO library / Module Contract First system.
  • ❌ Resolving CONS-003 / CELL-003/004/007 (still BLOCKER, Owner-gated).
  • ❌ Selecting a pilot slice or writing detailed F2/F3 design / implementation.
  • ❌ Treating documentary substrate (row counts, reported-LIVE labels) as live proof.

CONS-004 / CONS-005 / OBL-R2 stay decided only to the extent written at F0. No other conflict is resolved by this record. Codex PASS is a control verdict, not an Owner authorization for any future phase.

7. What this unlocks — F3 Program Macro only

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

F3 — IO Contract + Formula + Assembly Machine / DOT (framework rev56 §6c, = domains D6 + D7). F3 = the IO Contract 5-field boundary (nhận·trả·schema_min·fail·rollback) between bricks (D6), the Formula concept (how a brick is assembled from direct inputs — documentary pattern, not an engine), and the Assembly Machine / DOT / wrapper that runs/checks (D7), reusing the Smart Brick shape + TEMP_ID inherited from F1/F2. NOT canonical birth (F4). No Module Contract First, no formula registry, no DOT-per-layer / DOT-capability system, no schema change to dot_tools (dot_role / cell_id), no cell_id materialization by default.

The F3 Program Macro comprises: (a) this F2 decision record; (b) an F3 reuse-survey packet (f3-io-formula-assembly-dot-reuse-survey-packet.md); (c) an internal safety gate; and (d) — only if the gate passes — a read-only F3 execution report from KB / documentary evidence only. All of it preserves the same Owner-facing 3-question structure (reuse-now / repair-verify / add-later) and remains non-authorizing until its own GPT → Codex → Owner gate.

8. Self-check (recorder discipline)

  1. Recorded Owner/GPT decisions; did not invent or expand them — ✅
  2. Used the F2 bundle (report rev1 + packet rev1) evidence; did not contradict it — ✅
  3. Kept Owner/GPT as the only phase authority; Codex PASS treated as a control verdict only — ✅
  4. No live DB/runtime touched; no schema/registry created; no Phase-1 — ✅
  5. No canonical birth write; no BIRTH_STAMP; brick = subject ≠ temp-store = place upheld — ✅
  6. Carried CONS-003 / CELL-003/004/007 / STG-012/015 / STG-REUSE-001/003 / RISK-GC/CAP/BYPASS / HOLD-1 / HOLD-2 as unresolved, honestly — ✅
  7. Distinguished documentary vs live proof throughout — ✅
  8. This record unlocks the F3 Program Macro only — ✅

9. Next action

  1. GPT/Owner read this F2 decision record alongside the F3 reuse-survey packet and (if produced under the internal gate) the F3 execution report.
  2. Codex reviews the F2 decision + F3 packet + F3 report together (same 3-question Owner structure; deep layer covers sources · evidence · authority · conflict · runtime · provenance · safety lock).
  3. Only after Codex review + Owner/GPT authorization is the next phase decided: whether F4 (Stamp Lifecycle + Checker / Promote / Rollback, incl. canonical birth at promote) may proceed, or whether a separate Phase-1 read-only survey (HOLD-1 iu_staging_*) and resolution of CONS-003 / CELL-003/004/007 are needed first. Default HOLD for everything touching canonical / production / runtime / schema.

F2 Owner Decision Record | 2026-06-16 | STATUS: F2 DECISION GATE CLOSED. Unlocks the F3 Program Macro only. READ-ONLY, NON-AUTHORIZING. Brick = subject ≠ temp-store = place. TEMP_ID inherited ≠ BIRTH_STAMP ≠ canonical birth (F4). iu_staging_* documentary / HOLD-1. CONS-003 / CELL-003/004/007 carried (BLOCKER). STG-012/015 / STG-REUSE-001/003 / RISK-GC/CAP/BYPASS open. HOLD-2 = F4. Documentary ≠ live proof. Engineering PASS ≠ Authority PASS.