Mega Gate — Staging Build Readiness (IO contract, no schema/corpus)
Mega Gate — Staging Build Readiness
Date: 2026-06-18 · Workstream: LEGO-PILOT-SLICE-0-B2-MEGA-GATE-BUNDLE-2026-06-18 (Deliverable 11 of 20) · Editorial revision: rev1
Class: design-only / build-readiness / IO-contract boundary · READ-ONLY · NON-ENACTING · NON-AUTHORIZING · NOT remediation · NOT technical design · NOT implementation · NO schema · NO SQL · NO corpus · NO live data extraction · NO blocker resolved · NO runtime touched.
Metadata convention. Editorial revision (rev1) only. AgentData storage revision and
content_lengthare authoritative in AgentData metadata at read time; not pinned in this body.
Build-readiness-not-build lock. This packet defines what must be true before a disposable staging surface is built — readiness, not the build. It writes no staging schema, no table/column definition, no SQL/DDL/DML, no staging corpus, and no live-data-extraction plan. It defines the readiness criteria and the IO-contract boundary only. Any drift toward schema/corpus/extraction is
STAGING_SCHEMA_OR_CORPUS_DRIFT→ HOLD.
0. Status and non-authorization
STATUS: PASS — engineering / design-only. This is a complete design-only staging build-readiness packet: the readiness criteria a future staging build must meet, the carried IO-contract boundary (input/output/forbidden/separation/delete-fast), the candidate-vs-production separation, the no-schema/no-corpus constraint, and the Owner-gated future work.
Engineering PASS ≠ authority PASS. A PASS means the build readiness is fully specified on paper. It is not an Owner authorization to build staging, extract data, or run a producer. Default disposition: HOLD.
Pipeline position (downstream-only). Deliverable 11 of the Mega Gate Bundle; it is Option C / GATE-6 deepened into a readiness-to-build checklist, sitting on top of the accepted staging IO contract (Deliverable C of the planning bundle). It builds no surface.
Non-authorization (explicit). As Deliverable 1 §0, and specifically: it creates no staging schema/table/corpus; extracts no live birth_registry rows; runs no producer; promotes nothing staging→production. v0.1/FIX7 V3 not overwritten; v0.2 not authority.
Evidence basis — INHERITED_EVIDENCE. No runtime queried. Staging facts inherited from the accepted staging IO contract + B2 contract. 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, bounded/sequential, by the main process — no parallel/background reader-agents, no sub-agents, no local-prose inference. /tmp = decode-scratch only, never SSOT.
1. Purpose
Answer the macro's fourth question: what staging build readiness must exist before actual staging TD/build? The packet answers:
- What is the staging readiness, and what does "ready to build" mean? — §5.
- What is the carried IO-contract boundary the build must honor? — §3 / §5.
- How are candidate results kept separate from production? — §5 separation.
- Why is this readiness, not a build (no schema/corpus)? — §0 lock + §4.
The one rule, above all detail. Staging is a disposable workshop, an IO contract — never a second production path and never a schema written here. Build-readiness means the criteria for a future, separately-authorized staging build are specified; the build itself is FUTURE_TECHNICAL_DESIGN_REQUIRED.
2. Sources read
All 25 required sources read first-hand from AgentData KB, by the main process, sequentially; none SOURCE_NOT_READ (full list in Deliverable 20 §2). Used principally: the accepted staging IO contract (Deliverable C — objective, input/output/forbidden/separation/evidence/delete-fast/rollback/no-touch); the B2 contract (the B3 shape staging mirrors); the R2 readiness scope §3 (the birth_registry column shape); the interface packet (no parallel SSOT; Assembly First); operating-rules (anti-pattern: no second SSOT).
3. Accepted baseline (carried, not re-derived)
The staging IO contract (carried from Deliverable C; the boundary the build must honor):
- Objective: a safe, disposable staging slice where B2 can be developed/tested/rejected/deleted fast and never touch canonical/production except through explicit Owner gates.
- Input: a bounded, disposable projection of the shape of B2's production input (the fields the Đ0-G inspectors read + the three
inspect_*slots), never a live mutation of production, never co-located with production. How a sample is obtained isFUTURE_TECHNICAL_DESIGN_REQUIRED(no extraction plan here). - Output: candidate
inspect_*results on the disposable surface only — genuine per-stage, one column each, PEN→STAMP→GATE order, idempotent; on failure no candidate stamp + a staging-evidence append. - Forbidden: any production
birth_registrywrite (incl. productioninspect_*);certified/certified_at; canonical/owner/jsonb_profile/status; identity mint; KG provenance; fusedinspect_*=now(); net-new stamp columns / a parallel staging SSOT; promoting a candidate into production; manual SQL against production. - Separation: candidate results physically/namespacedly separated from production
inspect_*; B4 reads production only, never staging candidates → staging triggers no production certify by construction. - Delete-fast: the staging surface + candidate outputs + staging evidence form one disposal unit (Deliverable 13).
- No-production-touch proof: required, not asserted (Deliverable 12).
Blockers — all OPEN. Tool/packet lock carried.
4. Analysis — readiness vs. build
"Build readiness" is the set of conditions that must hold before a future staging build is authorized; the build is a separate Điều 32 gate. The distinction matters because staging is exactly where STAGING_SCHEMA_OR_CORPUS_DRIFT is tempting — a readiness packet that "just sketches the table" has already built staging on paper. This packet therefore states only criteria (what the build must satisfy) and the carried IO boundary (what crosses / never crosses), and writes no schema, table, SQL, corpus, or extraction. The readiness is channel-agnostic (staging is gate/channel-agnostic per Deliverable C), so it does not depend on the channel decision.
5. Staging build readiness
Build-readiness criteria (each must hold before a future staging build is authorized; none is met by building anything here):
| # | Readiness criterion | What it requires (criterion, not a build) | Met by this packet? |
|---|---|---|---|
| SR-1 | A staging IO contract exists | the accepted Deliverable C contract (input/output/forbidden/separation/evidence/delete-fast/rollback/no-touch) | Yes (carried) — the contract exists; the surface does not |
| SR-2 | Candidate-vs-production separation specified | candidate inspect_* on a disposable surface, physically/namespacedly separate; B4 never sees candidates |
Yes (carried §3 separation) — the tagging mechanism is FUTURE_TD, not written |
| SR-3 | Delete-fast as one disposal unit | input projection + candidate outputs + staging evidence disposable in one move (Deliverable 13) | Yes (criterion stated) — the delete mechanism is FUTURE_TD |
| SR-4 | No-production-touch proof requirement | a before/after production snapshot proof obligation (Deliverable 12) | Yes (requirement stated) — no snapshot run |
| SR-5 | Contract compatibility with B3 | staging mirrors the B3 inspect_* shape + the Đ0-G fail-closed rules, so a staging-validated producer is contract-compatible (promotion still a separate gate) |
Yes (carried) — staging mirrors, never redefines, B3 |
| SR-6 | No schema / corpus / extraction in readiness | the readiness step writes no DDL/table/SQL/corpus and no live-data-extraction plan | Yes — none written; STAGING_SCHEMA_OR_CORPUS_DRIFT guarded |
| SR-7 | Promotion firewall | nothing flows staging→production automatically; promotion is a separate Owner gate (Điều 32) | Yes (carried §6 firewall) |
| SR-8 | Đ0-G rules authoritative for staging | staging applies the same fail-closed Đ0-G rules; their authority is the GATE-3 / Deliverable 10 gap | Partial — staging mirrors the rules; their authority is owed (GATE-3) |
Build-readiness verdict: the staging IO contract and separation/delete-fast/no-touch criteria are READY (carried); the staging surface is not built (GATE-6 No-Go). A future staging build is authorized only behind a separate Điều 32 gate and must honor SR-1…SR-8. No schema, table, SQL, corpus, or extraction is written here.
Candidate-vs-production separation (restated, load-bearing). Candidate inspect_* results live only on the disposable staging surface, carry a STAGING marker, and are never read into the production certification path; production birth_registry.inspect_* is never written from staging, and B4 never sees staging candidates. This is what makes "nháp thoải mái" safe — and what Deliverable 12's no-production-touch proof must demonstrate. The exact marker/tagging is FUTURE_TECHNICAL_DESIGN_REQUIRED, not a schema written here.
6. Owner-gated future work
| 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 |
| Define the candidate-result tagging/naming scheme | Điều 32 (part of staging TD) | Yes |
| Build the staging evidence sink | Điều 32 | Yes |
| Run a candidate B2 producer against staging | Điều 32 + a built staging surface | Yes |
Promote a staging-validated candidate into production inspect_* |
Điều 32 + standing B2 + channel + S2 owner | Yes |
7. What remains unresolved
- GATE-6 No-Go — the staging surface is not built. The IO contract and readiness criteria are carried/stated; the build is a separate Điều 32 gate.
- No schema/corpus/extraction designed —
STAGING_SCHEMA_OR_CORPUS_DRIFTguarded; the tagging scheme, sink, and extraction are all FUTURE_TD. - SR-8 partial — staging mirrors the Đ0-G rules; their authority is the GATE-3 / Deliverable 10 source-recovery gap.
- No-production-touch is a requirement, not a result (Deliverable 12); delete-fast is one disposal unit (Deliverable 13).
- 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): the staging schema/DDL, tagging scheme, extraction plan, delete-fast mechanism, promotion mechanism, any SQL.
8. Ready for GPT/Codex review
Yes — as a design-only build-readiness / IO-contract packet, not a build.
Core rule, kept above all detail: staging is a disposable workshop / IO contract; build-readiness means criteria SR-1…SR-8 are specified (the contract, separation, delete-fast, no-touch, B3-compatibility, promotion-firewall) while the surface is not built and no schema/corpus/extraction is written. The build is a separate Điều 32 gate.
Default disposition: HOLD. Engineering PASS = a complete build-readiness on paper; it is not an Owner authorization to build staging, extract data, or promote anything. No PASS authorizes writes. All blockers remain OPEN.