LEGO Pilot Slice 0 — Staging / Kho-tạm IO Contract

Date: 2026-06-18 · Workstream: LEGO-PILOT-SLICE-0-R2-B2-PLANNING-BUNDLE-2026-06-18 (Deliverable C of five) · Editorial revision: rev1 Class: design-only / IO-contract boundary / staging-discipline · READ-ONLY · NON-ENACTING · NON-AUTHORIZING · NOT remediation · NOT technical design · NOT implementation · NO schema · NO SQL · NO table · NO corpus · NO live data extraction · NO blocker resolved · NO runtime touched.

Metadata convention. This body uses editorial revision (rev1) only. AgentData storage revision and content_length are authoritative in AgentData metadata at read time; they are deliberately not pinned in this body.

IO-contract-only lock. This packet defines the staging/kho-tạm surface at the IO-contract / boundary level only. It writes no schema, no table/column definition, no SQL, no DDL/DML, no staging corpus, and no live-data-extraction plan. It defines what crosses the staging boundary, what must never cross it, and how the surface is deleted fast — nothing about how staging is implemented. Any drift toward schema/DDL is STAGING_TD_DRIFT and must be rejected (return HOLD).

0. Status and non-authorization

STATUS: PASS — engineering / design-only. This is a complete design-only IO-contract boundary for a disposable staging/kho-tạm surface in which the B2 inspect producer can be developed and tested without touching canonical/production: the staging objective, the input/output contracts, the forbidden outputs, the candidate-result separation, the evidence contract, the delete-fast boundary, the rollback boundary, the no-production-touch proof requirement, IO compatibility with B2/B3/B4, bad-input handling, and the Owner-gated future-work list. It builds nothing, mutates nothing, authorizes nothing, and creates no staging surface, schema, or corpus.

Engineering PASS ≠ authority PASS. A PASS here means the staging IO contract is complete and fail-closed on paper. It is not an Owner authorization to build a staging surface, to extract live data, to run a producer, or to promote anything from staging to production. Default disposition: HOLD.

Pipeline position (downstream-only). This is Deliverable C of the Pilot-Slice-0 planning bundle, downstream of the accepted R2-B2 TD-prep. It prepares the disposable workshop the B2 readiness packet (Deliverable B, §11) names as a precondition for B2 TD. It opens no next package and builds no surface.

Non-authorization (explicit). This document does not, and cannot: run any DB write / DDL / DML; create any table/schema/index; extract live birth_registry rows; create a staging corpus or staging schema; restart/reload any service; run any worker/cron/job; set inspect_*; set certified=true; write canonical_address; trigger DOT/KG/birth/certify/promote; promote anything from staging to production; assign a governance owner; patch source or any prior report; create a current corpus; write technical design; implement; resolve any blocker; overwrite the v0.1-stable / FIX7 V3 baseline; promote or use Tool-Kiem-Thu v0.2-hardening as authority.

Evidence basis — INHERITED_EVIDENCE. No runtime was queried in this run; runtime facts (the birth_registry column shape, the Điều 0-G rule-set, the no-live-setter gap) are inherited from accepted read-only reports. AgentData metadata authoritative at read time. CAV-3/CAV-4/CAV-5 carried.

Reading discipline (Codex caveat, honored). All sources read directly from AgentData KB, in bounded, sequential, single-document batch_read (full) calls, by the main process — no parallel/background reader-agents, no sub-agents, no local-prose inference.

1. Purpose

Define the kho-tạm/staging contract that lets B2 be developed in a disposable surface without touching canonical/production. The packet answers:

What is the staging input? — §4.
What is the staging output? — §5.
What must never be written in staging? — §6.
How are candidate inspect results separated from production inspect_*? — §7.
What evidence must staging emit? — §8.
What is the delete-fast boundary? — §9.
How does staging prove "nháp thoải mái" without touching canonical? — §9, §10, §11.

The one rule, above all detail. Staging is a disposable workshop, not a second production path. Everything that enters it is a copy/sample; everything it produces is a candidate on a disposable surface; nothing it does ever writes production birth_registry, certifies, canonicalizes, mints identity, or touches the KG. If the staging design is wrong, the entire staging surface is deleted in one move and rebuilt — with production provably untouched.

2. Sources read

All sources read first-hand, directly from AgentData KB, via batch_read (single path, full: true), one document per call, sequentially, by the main process — no parallel/background reader-agents, no sub-agents, no local-prose inference. None SOURCE_NOT_READ. (Same 19-source set as Deliverable A §2; AgentData storage revision/content_length authoritative in metadata at read time.)

Cluster	Sources	Used for
Accepted B2 chain	`r2-b2-inspect-producer-td-prep-lego-2026-06-18.md` (+ exec report + Codex)	B2 contract; the "tested in isolation on a controlled fixture" requirement (PO-9); B2-AC rules
Interface	`registries-pivot-lego-interface-td-prep-2026-06-18.md` (+ Codex)	S3/S4/S7/S8; "interface not brain"; no-production-touch isolation
Block contract	`r2-b-block-contract-packet-lego-2026-06-18.md` (+ Codex)	B2 "tested alone (feed sample rows, read `inspect_*`)"; B5 "deletable after run"; B3 stud
LEGO map	`r1-r2-modular-lego-architecture-scoping-2026-06-18.md` (+ Codex)	"tested alone / deleted-rebuilt alone"; Assembly First; no second SSOT
R2 root cause / readiness	`r2a-…root-cause-2026-06-18.md` (+ Codex); `r2-…readiness-scope-2026-06-17.md`; `phase1b-…-2026-06-17.md`	`birth_registry` column shape (the fields the inspectors read); fused-INSERT anti-pattern; blockers OPEN
Anchors	`architecture/birth-registry-law.md` (Đ0-G); `notes/dieu4-…`; `notes/dieu32-…`; `laws/dieu32-approval-law.md`; `notes/dieu35-…`; `ssot/operating-rules.md`	the PEN/STAMP/GATE rule-set staging must mirror; birth≠canonical; DOT-100%/no-manual-SQL; fail-closed; Assembly First

3. Staging objective

The kho-tạm objective (verbatim sense from the Owner direction). Provide a safe, disposable staging slice where future B2 work can be developed quickly, tested quickly, rejected quickly, deleted quickly, and never touch canonical/production except through explicit Owner gates.

What staging is. A bounded, isolated, disposable surface that mirrors the shape of B2's production IO contract — the same B3 inspect_* contract shape and the same Điều 0-G fail-closed rules — so a candidate B2 producer can be exercised end-to-end against a copy without any production effect.

What staging is NOT.

Not a parallel SSOT or a second registry (Assembly First / Điều 39 NT11) — it is a disposable mirror, never a competing source of truth.
Not a production path — nothing in staging ever flips production certified, sets production inspect_*, materializes canonical, mints identity, or writes the KG.
Not a place to certify — staging never runs B4; it proves only the producer half (PEN/STAMP/GATE writes) against a copy of the B3 contract.
Not the channel decision (R2-D2) — staging is channel-agnostic; whichever channel is later chosen can be exercised against staging.

Why staging matters for LEGO. It operationalizes "tested alone" and "deleted/rebuilt alone": a B2 design that is wrong can be thrown away by deleting the whole staging surface, with zero cascade into B1/B3/B4 or any shared surface — exactly the LEGO ideal, made safe to iterate on.

4. Staging input contract

The staging input is a disposable, isolated projection of the shape of B2's production input — never a live mutation of production, and never co-located with production.

Shape (carried from the live birth_registry schema, R2 readiness §3): the fields the Điều 0-G inspectors read — entity_code, collection_name, species_code, dot_origin, governance_role, born_at, and the metadata fields the STAMP stage checks (name, description, status). Plus the three inspect_* slots (initially unset) so the PEN→STAMP→GATE ordering can be exercised.
Provenance: input rows are a bounded, disposable sample that mirror uncertified production rows (certified=false, governance_role='governed' for the PEN scope). They are candidate fixtures, not the production rows themselves.
Isolation: the staging input lives on the disposable staging surface only. Reading production to populate staging is not designed here — how a sample is obtained is FUTURE_TECHNICAL_DESIGN_REQUIRED and Owner-gated (no live-data-extraction plan is written; this packet defines only the contract that input must satisfy).
Fail-closed input rule: if a candidate input row is malformed (missing entity_code/collection_name, ambiguous partial inspect_*, out-of-scope governance_role), staging must reject it exactly as production would (§13) — never fabricate a passing row.

No live data extraction. This packet does not specify, plan, or authorize extracting live birth_registry rows into staging. The input contract describes the shape and isolation the staging input must have; population is a separate, Owner-gated, future design decision.

5. Staging output contract

The only outputs staging may produce are candidate inspect_pen / inspect_stamp / inspect_gate results, written to the disposable staging surface only.

Genuine per-stage: each candidate stamp is set only on a genuine per-stage pass (PEN = identity-completeness; STAMP = metadata-completeness; GATE = species-fit/business-rules) — never a blanket =now().
One column per inspector: each inspector writes only its own candidate column ("mỗi DOT chỉ UPDATE cột của mình").
PEN → STAMP → GATE order: a later candidate stamp is never set while an earlier one is unset.
Idempotent: only an unset candidate column is set; an already-stamped candidate column is left untouched.
On failure: no candidate stamp for that row/stage; a failure record is appended to the staging evidence (§8) — a no-op on the row plus an evidence append, never a fabricated pass.

Critical separation. These candidate outputs are written only to the disposable staging surface and are explicitly not production birth_registry.inspect_* (§7). A B2 producer exercised in staging proves it can produce genuine PEN/STAMP/GATE results in the B3 shape — without any production write.

6. Forbidden staging outputs

Staging is fail-closed against every production-affecting write. All are MUST-NOT.

Forbidden in staging	Why
Writing any production `birth_registry` column (incl. production `inspect_*`)	Staging must never touch production; candidate outputs live only on the disposable surface (§7)
`certified` / `certified_at`	Staging never certifies (that is B4, not exercised in staging); B2-AC-1
`canonical_address` / `owner` / `jsonb_profile` / production `status`	Canonical is output-at-promote (S4/B6), gated on S5+S6; B2-AC-2; birth≠canonical
`entity_code` or any identity field as a mint	Identity is B1/S3; staging reads identity shape, never mints it; B2-AC-3
KG `provenance` / edge writes	The birth lane is independent of the KG lane; B2-AC-4
All three `inspect_*` at once without genuine per-stage checks	The 2026-03-21 fused-shortcut anti-pattern; B2-AC-5/AC-6
Net-new stamp columns / a parallel staging SSOT treated as truth	Assembly First / Điều 39 NT11; staging is a disposable mirror, not a second registry; B2-AC-12
Promoting a staging candidate result into production `inspect_*`	Promotion staging→production is a separate Owner gate (Điều 32), never an implicit staging side-effect
Manual SQL / SSH+`docker exec` writes against production from staging	Điều 32 §2.1 (no manual SQL / no curl bypass)

The promotion firewall. Nothing flows from staging to production automatically. A validated B2 producer is evidence that the producer is contract-correct; turning that into a production write is a distinct, separately-authorized act behind the full Owner gate. Staging proves; it never promotes.

7. Candidate inspect result separation

Candidate inspect results MUST be physically and namespacedly separated from production inspect_* — at the boundary level (no schema here).

Separate disposable surface: candidate inspect_pen/stamp/gate results live on the staging surface, never on production birth_registry. They are a disposable copy's columns, not the production columns.
Distinct identity / tagging: candidate results carry a clear STAGING marker (e.g. a staging run id and a "candidate" designation) so they can never be confused with, queried as, or read into the production certification path. The exact naming/tagging mechanism is FUTURE_TECHNICAL_DESIGN_REQUIRED — not a schema written here.
One-directional: production birth_registry.inspect_* is never read from staging as authority, and staging candidates are never read into production. The only legitimate bridge is an explicit Owner-gated promotion (§6 firewall), which is out of scope here.
Consumer isolation: B4 (fn_birth_auto_certify) reads only production inspect_*; it must never see staging candidates. Staging therefore cannot trigger any production certify — by construction.

Why this is the load-bearing separation. If candidate results could land in (or be read as) production inspect_*, a staging experiment could starve-or-trigger B4 and certify uninspected rows — exactly the failure staging exists to prevent. The separation is what makes "nháp thoải mái" safe.

8. Evidence contract

Staging emits its own S7-shaped evidence, on a disposable, append-only, records-never-decides basis, clearly distinguished from production S7.

What staging evidence records: per-run counts (candidate rows scanned / passed-PEN/STAMP/GATE / failed-per-stage / skipped); run identity (staging run id, the rule-set version/hash exercised, start/end timestamps); per-failure records (which candidate row, which stage, which check failed); paths/hashes for reproducibility (AP-CLOSE).
Records, never decides. Staging evidence may never act as an approval, a certify signal, or a gate-pass — it is observability only. Approvals live only in S1 / Điều 32.
Distinct from production S7. Staging evidence is tagged STAGING so it is never mistaken for production audit/approval evidence and never read into a production decision.
Disposable with the surface. Staging evidence is part of the staging disposal unit (§9) — deleting staging deletes its evidence too. (If an experiment's findings are worth keeping, that is a separate, deliberate export, not a production write.)

Why staging needs its own evidence. "Tested quickly, rejected quickly" requires that each staging run leaves a clear, disposable record of what passed/failed — enough to judge a candidate B2 producer, and enough to prove (Deliverable D) that production was untouched.

9. Delete-fast boundary

The delete-fast boundary = the entire staging surface as ONE disposal unit. This is what makes "deleted quickly / nháp thoải mái" real.

One disposal unit: the staging input projection + the candidate inspect_* outputs + the staging evidence form a single bounded unit that can be deleted in one move.
Fast: rejecting a B2 design is "delete the staging surface" — no surgical unwind, no per-row repair, no production cleanup.
Total: delete-fast removes all candidate outputs (including bad-input candidates) and all staging evidence; nothing survives outside the unit.
Isolated: because the disposal unit contains no production rows, deleting it cannot cascade into B1/B3/B4 or any shared surface.
Verifiable: after delete-fast, the proof obligation (§11, Deliverable D) is that production birth_registry (incl. inspect_*, certified, canonical_address) is byte-for-byte unchanged and the staging surface is empty/absent.

"Nháp thoải mái" defined. An operator can iterate freely on a candidate B2 in staging precisely because (a) nothing they do writes production, and (b) the whole experiment can be thrown away in one delete-fast with production provably untouched. The freedom comes from the disposability + isolation, not from relaxed rules — the fail-closed Điều 0-G rules still apply inside staging (§13).

The delete-fast mechanism (how the unit is deleted) is FUTURE_TECHNICAL_DESIGN_REQUIRED — no DELETE/DROP/SQL/command sequence is written here.

10. Rollback boundary

One staging run = one rollback unit; in staging, deletion is the rollback.

Rollback unit: a single staging producer run (one scan-and-candidate-stamp pass over the staging input) is the unit that can be undone — by disposing of its candidate outputs and evidence.
Disposable-by-construction: because staging never wrote production, there is no production rollback to perform. The rollback boundary lives entirely inside the staging surface. This is strictly simpler than B2's production S8 rollback (which must contend with the downstream-certify interaction and HOLD-2).
No downstream-certify in staging: since B4 never sees staging candidates (§7), completing all three candidate inspect_* in staging does not trigger any certify — so the staging rollback unit has no downstream effect to unwind (unlike the production case, where the downstream-certify subtlety is FUTURE_TECHNICAL_DESIGN_REQUIRED).
Fail-closed rollback rule: if a staging run cannot be cleanly disposed (its candidate outputs cannot be fully removed), the staging design is itself defective and must be rejected (Deliverable D bad-input case BAD-15: "delete-fast fails to remove candidate output").

No rollback script / command sequence is written here (B2-AC-9 / RP-AC-8).

11. No-production-touch proof requirement

Staging's central safety claim — "never touched canonical/production" — must be provable, not asserted. This packet states the proof requirement; the proof evidence plan is Deliverable D.

The staging contract is acceptable only if, for any staging run, it can be shown that:

Zero production writes — no production birth_registry row changed (no production inspect_*, no certified/certified_at, no canonical_address/owner/jsonb_profile/status).
Zero identity mint — no production entity_code/S3 identity created.
Zero KG write — no provenance/edge/quarantine write.
Zero certify trigger — B4 never fired off a staging candidate (no production certify attributable to staging).
Containment after delete-fast — after disposal, the staging surface is gone and production is unchanged.

Proof posture (carried). Because the available read-only tooling proves state via DB-captured snapshots and catalog reads (CAV-3/CAV-4), the no-production-touch proof must be expressible as a before/after comparison of production counts/checksums plus the staging evidence — the evidence design is Deliverable D; no such check is run here (INHERITED_EVIDENCE).

12. IO contract compatibility with B2/B3/B4

Staging is useful only if a producer validated in it is contract-compatible with the real lane. The compatibility is deliberately one-directional and producer-only.

Block	Staging relationship	Compatibility rule
B2 (inspect producer)	Staging is B2's disposable workshop	A candidate B2 exercised in staging uses the same logic it would in production; only the surface differs (disposable vs production). Validating in staging satisfies the PO-9 "tested in isolation on a controlled fixture" obligation.
*B3 (`inspect_` contract)**	Staging mirrors the B3 shape	The candidate `inspect_` columns in staging have the same meaning and PEN→STAMP→GATE order as the production B3 stud. This is what makes a staging-validated producer promotable later (separate Owner gate). Staging must not redefine* B3 — only mirror it.
B4 (certify consumer)	NOT run in staging	B4 is never exercised against staging candidates; staging proves only the producer half. A staging run therefore certifies nothing and triggers no production certify.
B5 (backlog)	Dependency only — not opened	B5's one-time historical pass could also be rehearsed in staging in a future, separately-authorized package, but B5 is not designed here (SCOPE_CREEP guarded).
B7 (GUC/gate policy)	Dependency only — not opened	Staging is gate-agnostic; B7's warn→block decision is a separate block, not designed here.

One-directional promotion. Contract compatibility means a staging-validated B2 could be promoted to production through an explicit Owner gate (Điều 32) — it does not mean any automatic flow exists. The promotion firewall (§6) holds.

13. Bad-input handling in staging

Staging applies the same fail-closed Điều 0-G rejections as production — on the disposable surface. Staging is not a place where the rules relax; it is a place where breaking the rules is safe to observe and throw away. (Conceptual contract only — no runtime test claimed; B2 is MISSING.)

Bad input in staging	Expected staging behavior (fail-closed)
Candidate row missing `entity_code` / `collection_name`	No candidate `inspect_pen`; append failure to staging evidence
Candidate already marked "certified-like"	Skip / no candidate write (staging never certifies anyway)
Ambiguous partial candidate `inspect_*`	Mark ambiguous in staging evidence; no candidate continuation; never certify
Điều 0-G rule-set unresolved	`SOURCE_RECOVERY_REQUIRED`; no candidate stamp
Asked to write production `inspect_*` / `certified` / `canonical_address`	Reject — staging writes candidates only, never production (§6)
Blanket candidate `inspect_*=now()`	Reject as the fused-shortcut pattern
Out-of-order candidate STAMP/GATE	Reject — later candidate stamp may not precede the earlier
Out-of-scope `governance_role`	Skip / out of scope
Candidate result written to a production field by mistake	Reject / must be impossible by separation (§7) — this is the load-bearing isolation failure Deliverable D tests
Delete-fast leaves a candidate behind	Reject the staging design — disposal must be total (Deliverable D BAD-15)

The two staging-specific failures to never allow: (a) a candidate result leaking into a production field (§7 separation must make this impossible), and (b) delete-fast failing to remove a candidate (the disposal unit must be total). Both are tested adversarially in Deliverable D.

14. Owner-gated future work

Every action below is forbidden now (OWNER_GATE_REQUIRED). Listing is scoping, not authorization.

Future work	Gate required	Forbidden now?
Build the staging/kho-tạm surface (schema, tables, isolation)	Điều 32 (staging build is future TD)	Yes
Populate staging with a sample (any live-data extraction)	Điều 32 + read-only extraction design	Yes
Run a candidate B2 producer against staging	Điều 32 + a built staging surface	Yes
Define the candidate-result tagging/naming scheme	Điều 32 (part of staging TD)	Yes
Build the staging evidence sink	Điều 32	Yes
Define/execute the delete-fast mechanism	Điều 32 (part of staging TD)	Yes
Promote a staging-validated candidate into production `inspect_*`	Điều 32 + standing B2 + channel decision + S2 owner	Yes
Recover the Điều 0-G rule-set source (so staging rules are authoritative)	external S6 — Owner out-of-band	Yes

15. What remains unresolved

STAGING_TD_DRIFT guarded — staging is IO contract only. No schema, table, SQL, corpus, or extraction is written here; building staging is FUTURE_TECHNICAL_DESIGN_REQUIRED.
No live data extraction designed. How a disposable sample is obtained from production is deliberately not specified (Owner-gated, future).
SOURCE_RECOVERY_REQUIRED — Điều 0-G. The rule-set staging mirrors is from a working source (architecture/birth-registry-law.md; broken Constitution ref); authoritative recovery is Owner-controlled, out-of-band (external S6).
No-production-touch proof is a requirement, not a result. The proof evidence plan is Deliverable D; nothing is verified at runtime here (INHERITED_EVIDENCE; CAV-3/CAV-4).
B5 / B7 remain dependencies only, not opened. Backlog rehearsal and GUC policy are out of scope (SCOPE_CREEP guarded).
Promotion firewall holds. Nothing flows staging→production automatically; promotion is a separate Owner gate.
Blockers — all OPEN, none resolved: CONS-002, CONS-003, CELL-003/004/007, HOLD-1, HOLD-2, RISK-BYPASS, GOV-016/017, GOV-REUSE-001, Điều 39 runtime-EMPTY, Điều 35 production-readiness FAIL.
FUTURE_TECHNICAL_DESIGN_REQUIRED (NOT written here): any staging schema/DDL, table/column definition, tagging scheme, extraction plan, delete-fast mechanism, promotion mechanism, or SQL.

16. Ready for GPT/Codex review

Yes — as a design-only IO-contract boundary, not a staging implementation.

Core rule, kept above all detail: staging/kho-tạm is a disposable workshop that mirrors the B3 inspect_* shape and the Điều 0-G rules so B2 can be developed and tested fast — producing only candidate results on a disposable surface, separated from production inspect_*, deletable in one delete-fast unit, with production provably untouched. It never certifies, never canonicalizes, never mints identity, never writes the KG, and never promotes to production without an explicit Owner gate.

Default disposition: HOLD. Engineering PASS = a complete staging IO contract on paper; it is not an Owner authorization to build staging, extract data, or promote anything. No PASS authorizes writes. All blockers remain OPEN.