LEGO Pilot Slice 0 — Bad-input / Delete-fast / Verification Plan (design-only, 2026-06-18)
LEGO Pilot Slice 0 — Bad-input / Delete-fast / Verification Plan
Date: 2026-06-18 · Workstream: LEGO-PILOT-SLICE-0-R2-B2-PLANNING-BUNDLE-2026-06-18 (Deliverable D of five) · Editorial revision: rev1
Class: design-only / adversarial verification plan · READ-ONLY · NON-ENACTING · NON-AUTHORIZING · NOT remediation · NOT technical design · NOT implementation · NOT a runtime test · NO blocker resolved · NO runtime touched.
Metadata convention. This body uses editorial revision (rev1) only. AgentData storage revision and
content_lengthare authoritative in AgentData metadata at read time; they are deliberately not pinned in this body.
Plan-not-execution lock. This packet defines the adversarial verification plan for the future B2 pilot slice — what would be tested, the expected fail-closed behavior, what would count as fail-open, and the evidence required. It runs no test, executes no bad input, mutates nothing, and claims no runtime result. Every "expected behavior" below is a design obligation the future producer must satisfy, not an observed outcome (B2 is MISSING; INHERITED_EVIDENCE).
0. Status and non-authorization
STATUS: PASS — engineering / design-only. This is a complete design-only adversarial verification plan for the future B2 pilot slice: the Codex-style adversarial method, a bad-input inventory (≥15 cases), expected rejection behavior, fail-open conditions, and the evidence required to prove rejection / delete-fast / rollback / no-production-touch — plus minimal pilot acceptance criteria. It builds nothing, mutates nothing, authorizes nothing, and runs no test.
Engineering PASS ≠ authority PASS. A PASS here means the verification plan is complete and fail-closed on paper. It is not an Owner authorization to build a producer, build staging, run any test, or remediate. Default disposition: HOLD.
Pipeline position (downstream-only). This is Deliverable D of the Pilot-Slice-0 planning bundle, downstream of the accepted R2-B2 TD-prep and paired with the staging IO contract (Deliverable C). It defines the acceptance gate a future B2 pilot must pass; it opens no test and no package.
Non-authorization (explicit). This document does not, and cannot: run any DB write / DDL / DML; run any test against runtime; execute any bad input; restart/reload any service; run any worker/cron/job; trigger DOT/KG/birth/certify/promote; set inspect_*; set certified=true; write canonical_address; flip any gate; assign an owner; install pg_cron; promote any contract; enable any worker; create a current corpus or staging corpus; patch source or any prior report; write technical design; implement; resolve any blocker; claim any runtime verification result; 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; the producer does not exist to test (BAD_INPUT_BEHAVIOR_UNCLEAR). Every expected behavior is a conceptual design obligation. 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 adversarial verification plan for the future B2 pilot slice. The packet answers:
- What bad inputs must be tested later? — §4.
- What is the expected reject behavior? — §5.
- What would count as fail-open? — §6.
- What evidence proves reject? — §7.
- What evidence proves delete-fast? — §8.
- What evidence proves the rollback boundary? — §9.
- What evidence proves no production/canonical touch? — §10.
The one rule, above all detail. A B2 pilot is acceptable only if invalid input never produces a stamp, a certify, a canonical write, or a PASS, the staging surface deletes fast and total, the rollback is one bounded staging run, and production/canonical is provably untouched. Any deviation is fail-open and disqualifying. This is the plan; no test is run here.
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 + Codex) |
§8 bad-input matrix BI-1…12; the fail-closed test; B2-AC rules; the Codex-style adversarial reconstruction |
| Interface / block | registries-pivot-lego-interface-td-prep-2026-06-18.md; r2-b-block-contract-packet-lego-2026-06-18.md (+ Codexes) |
S7 records-not-decides; the 7-point adversarial method; B5/B7 boundaries |
| LEGO map | r1-r2-modular-lego-architecture-scoping-2026-06-18.md (+ Codex) |
fail-closed default; anti-coupling AC-1…12 |
| R2 root cause / readiness | r2a-…-2026-06-18.md (+ Codex); r2-…readiness-scope-2026-06-17.md; phase1b-…-2026-06-17.md |
the fused-INSERT anti-pattern; no live setter; 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 rule-set; birth≠canonical; DOT-100%/no-manual-SQL; scanner=list-only; "Không chắc đúng = sai" / AP-CLOSE |
3. Codex-style adversarial method
Applied as a conceptual contract check — NOT run against runtime. The seven adversarial steps (carried from the accepted packets) frame the plan:
- Do not trust the report; target actual governed surfaces. The plan is written against the real governed identifiers (
birth_registry.inspect_pen/stamp/gate,certified/certified_at,canonical_address/owner/jsonb_profile/status,trg_birth_auto_certify → fn_birth_auto_certify, the Điều 0-G PEN/STAMP/GATE rule-set) read first-hand — not from memory. - Fresh-reconstruct from KB, not local prose. The VPS PostgreSQL
directusDB is the substrate-of-truth; the local repo is substrate-free/stale. All facts are INHERITED; AgentData metadata authoritative. - Use actual readback metadata and exact identifiers. Bad inputs are constructed against the real columns and the real fail-closed rules.
- Create bad-input scenarios outside the happy path. §4 constructs the invalid-input / invalid-state cases a happy-path harness would skip (missing identity, partial/ambiguous stamps, fused shortcut, out-of-order, out-of-scope, leak-to-production, delete-fast residue, authority confusion).
- Check whether each contract rejects bad input fail-closed. §5 states the expected rejection per case.
- Fail-open ⇒ reject. §6: if invalid input would still stamp / certify / canonicalize / leak to production / survive delete-fast / act as approval / produce a PASS, the contract is fail-open and the pilot is rejected.
- Distinguish engineering PASS from authority PASS. A pilot passing these checks is an engineering result, never an Owner authorization to promote staging→production.
No bad-input test was executed; nothing was scanned, stamped, certified, canonicalized, or mutated. The plan is a design obligation, not a runtime result.
4. Bad-input inventory
The future B2 pilot must adversarially test at least these fifteen cases (BAD-1…BAD-15). Each is conceptual; BAD_INPUT_BEHAVIOR_UNCLEAR is marked where the built behavior cannot be determined without the producer.
| ID | Bad input / invalid state | Surface tested |
|---|---|---|
| BAD-1 | Uncertified row missing entity_code |
PEN identity-completeness |
| BAD-2 | Uncertified row missing collection_name |
PEN birth-completeness |
| BAD-3 | Row already certified=true presented for inspection |
scope / idempotency |
| BAD-4 | Row with partial inspect_* of unknown origin |
provenance-of-stamps (BAD_INPUT_BEHAVIOR_UNCLEAR) |
| BAD-5 | Điều 0-G rule-set unresolved (source not recovered) | SOURCE_RECOVERY_REQUIRED fail-closed |
| BAD-6 | Producer asked to set certified=true |
certify firewall (B2-AC-1) |
| BAD-7 | Producer asked to set canonical_address |
canonical firewall (B2-AC-2) |
| BAD-8 | Producer asked to stamp blanket inspect_*=now() without checks |
fused-shortcut anti-pattern (B2-AC-5/6) |
| BAD-9 | Channel not approved / S2 owner missing | Owner-gate precondition |
| BAD-10 | v0.2-hardening offered as authority for FIX7 | tool lock (B2-AC-11) |
| BAD-11 | Producer asked to set inspect_gate/inspect_stamp out of order (earlier stamp NULL) |
PEN→STAMP→GATE ordering (B2-AC-13) |
| BAD-12 | Row with out-of-scope governance_role (excluded/observed) presented for stamping |
inspection scope (BAD_INPUT_BEHAVIOR_UNCLEAR for observed) |
| BAD-13 | An S7/staging audit event used as an approval | S7 records-not-decides (B2-AC-8) |
| BAD-14 | A candidate inspect result accidentally written to a production field | staging↔production separation (Deliverable C §7) |
| BAD-15 | Delete-fast fails to remove a candidate output | staging disposal totality (Deliverable C §9) |
5. Expected rejection behavior
For each case, the future producer/pilot must exhibit the fail-closed behavior below. No runtime test is claimed.
| ID | Expected rejection (fail-closed) |
|---|---|
| BAD-1 | No candidate/production inspect_pen; append failure to the (staging) audit evidence; no downstream stamp possible (ordering). |
| BAD-2 | No candidate/production inspect_pen; append failure to audit evidence. |
| BAD-3 | Skip / no producer write; certified rows are out of scope (no re-inspection, no overwrite). |
| BAD-4 | Mark ambiguous; require Owner-gated review; never continue the chain or certify. (BAD_INPUT_BEHAVIOR_UNCLEAR — conceptual.) |
| BAD-5 | SOURCE_RECOVERY_REQUIRED; fail closed; no stamp; escalate source recovery (S6). ("Không chắc đúng = sai.") |
| BAD-6 | Reject; B2 never certifies (B4's atomic per-row consumer owns certified). |
| BAD-7 | Reject; canonical is output-at-promote (S4/B6), gated on S5+S6; B2 writes inspect_* only. |
| BAD-8 | Reject as the fused-shortcut pattern; each stamp requires a genuine per-stage pass. |
| BAD-9 | No-op / pending Owner; with no Điều 32 authorization and no S2 owner, the producer does not run; no stamps. |
| BAD-10 | Reject until Owner/User promotes v0.2 (after regression); v0.1-stable / FIX7 V3 stays the baseline. |
| BAD-11 | Reject — out-of-order; a later stamp may not be set while an earlier one is NULL; the row waits at its current stage. |
| BAD-12 | Skip / out of scope; PEN scope is governed; out-of-scope rows are not inspected. (BAD_INPUT_BEHAVIOR_UNCLEAR for observed.) |
| BAD-13 | Reject; S7/staging evidence records, it does not approve; approvals live only in S1 / Điều 32. |
| BAD-14 | Reject / impossible by separation; a candidate result must never reach a production field (Deliverable C §7); if observed, the pilot fails. |
| BAD-15 | Reject the staging design; disposal must be total; residual candidates after delete-fast are a disqualifying defect. |
6. Fail-open conditions
A pilot is fail-open (and rejected) if any invalid input still produces a forbidden effect. The disqualifying outcomes:
- F-OPEN-1 — Phantom stamp: invalid input (BAD-1/2/4/5/11/12) still yields a candidate/production
inspect_*. - F-OPEN-2 — Unearned certify: any path sets
certified=truefrom the producer, or a staging run triggers a production certify (BAD-3/6/14). - F-OPEN-3 — Canonical leak: any
canonical_address/owner/jsonb_profile/statuswrite occurs (BAD-7). - F-OPEN-4 — Fused shortcut: all three
inspect_*set without genuine per-stage checks (BAD-8). - F-OPEN-5 — Ungoverned run: the producer runs with no channel/owner/Điều 32 authorization (BAD-9).
- F-OPEN-6 — Authority confusion: v0.2-hardening treated as FIX7 authority (BAD-10), or an audit event treated as approval (BAD-13).
- F-OPEN-7 — Order violation: a later stamp set while an earlier is NULL (BAD-11).
- F-OPEN-8 — Production leak: a staging candidate reaches a production field (BAD-14) — the load-bearing isolation failure.
- F-OPEN-9 — Disposal residue: delete-fast leaves any candidate/evidence behind (BAD-15).
- F-OPEN-10 — Silent PASS: the pilot reports PASS without the evidence in §7–§10 (a PASS-without-evidence is itself fail-open, per "PASS/FAIL không có số liệu" anti-pattern).
The fail-closed test (carried verbatim in sense): if invalid input would still stamp, certify, canonicalize, leak to production, survive delete-fast, act as approval, or produce a PASS, the contract is fail-open and must be rejected.
7. Evidence required for rejection
For each BAD-n, the pilot must produce positive evidence of rejection (AP-CLOSE: counts, ids, paths, hashes). The plan requires:
- No-stamp proof: the target row shows the relevant
inspect_*still unset after the bad input (per-row before/after). - Failure-record proof: a corresponding entry in the staging/audit evidence naming the row (
entity_code), the stage, and the failed check (Điều 0-G "Fail → INSERT audit queue"). - No-certify proof:
certified/certified_atunchanged for the target (and no production certify attributable to a staging run). - Counts: rows scanned / rejected-per-stage / skipped, matching the injected bad-input set.
- Reproducibility: the rule-set version/hash and the staging run id, so the rejection is repeatable.
Records-not-decides constraint. The rejection evidence is observability only; it must never itself act as an approval or a gate-pass (BAD-13). No evidence is generated here — this is the required shape of evidence a future pilot must emit.
8. Evidence required for delete-fast
Delete-fast (Deliverable C §9) must be provable. The plan requires a before/after comparison around disposal:
- Pre-disposal inventory: the staging surface contents (candidate-row count, candidate
inspect_*count, staging-evidence count) and a checksum/identifier of the staging run. - Post-disposal proof: the staging surface is empty/absent — zero candidate rows, zero candidate
inspect_*, zero residual staging evidence belonging to the disposed run. - Totality: all candidate outputs (including bad-input candidates from §4) are removed; none survive (BAD-15 / F-OPEN-9).
- Speed/isolation note: disposal is one unit (no per-row surgery); the disposal touches only the staging surface.
No DELETE/DROP/SQL is written here — only the evidence the delete-fast must yield. The disposal mechanism is FUTURE_TECHNICAL_DESIGN_REQUIRED.
9. Evidence required for rollback boundary
The rollback boundary (Deliverable C §10) — one staging run = one rollback unit — must be provable:
- Unit proof: the disposed unit corresponds to exactly one staging producer run (its run id), not a partial or cross-run set.
- No-downstream proof: because B4 never sees staging candidates, completing all three candidate
inspect_*triggered no production certify — evidenced bycertified/certified_atunchanged for all production rows during the staging run. - Bounded proof: rolling back the staging run removed exactly that run's candidates and evidence; no other staging run (if any) was affected.
- Fail-closed proof: if a clean single-run rollback cannot be shown, the staging design is rejected (Deliverable C §10).
Contrast with production B2 (carried). The production S8 rollback must additionally account for the downstream-certify interaction and HOLD-2 (no atomic birth-certify promote transaction); the staging rollback does not, because staging never certifies. The pilot's rollback evidence proves the staging boundary only.
10. Evidence required for no production/canonical touch
This is the central safety proof (Deliverable C §11). The plan requires a before/after production snapshot bracketing the entire pilot (run + disposal):
- Production
inspect_*unchanged: the count of productionbirth_registryrows with anyinspect_*set is identical before and after (and the specific production rows are unchanged). - Production
certifiedunchanged: the certified count (andcertified_atset) is identical before and after — no production certify attributable to the pilot. - Canonical fields unchanged:
canonical_address/owner/jsonb_profile/statusunchanged on all production rows. - Zero identity mint: no new production
entity_code/S3 identity created by the pilot. - Zero KG write: no
provenance/edge/quarantine write attributable to the pilot. - Containment after delete-fast: the staging surface is gone (or empty) and the production snapshot is byte/count-identical to the pre-pilot snapshot.
Proof posture (carried, CAV-3/CAV-4). Because read-only tooling proves state via catalog reads and DB-captured snapshots, the no-touch proof is a before/after comparison of production counts/checksums plus the staging evidence. No such snapshot or comparison is run here (INHERITED_EVIDENCE); this section defines the required evidence, not a result.
11. Minimal pilot acceptance criteria
A future B2 pilot slice is acceptable (as an engineering result, never an authority result) only if all of the following hold. None is evaluated here.
| # | Acceptance criterion | Proven by |
|---|---|---|
| AC-1 | All fifteen bad inputs (BAD-1…BAD-15) are rejected fail-closed | §5 + §7 evidence |
| AC-2 | No phantom stamp, unearned certify, canonical leak, or fused shortcut occurs (F-OPEN-1…4 absent) | §7 + §10 evidence |
| AC-3 | The producer never runs ungoverned (channel + S2 owner + Điều 32 present) | §7 (BAD-9) |
| AC-4 | No authority confusion: v0.2 not treated as FIX7 authority; no audit event acts as approval | §7 (BAD-10, BAD-13) |
| AC-5 | Candidate results never reach a production field (separation holds) | §10 (BAD-14 / F-OPEN-8) |
| AC-6 | Delete-fast is total and one-unit | §8 (BAD-15 / F-OPEN-9) |
| AC-7 | Rollback boundary = one staging run, with no downstream certify | §9 |
| AC-8 | No production/canonical touch — before/after snapshots identical | §10 |
| AC-9 | The pilot reports PASS only with the §7–§10 evidence attached (no silent PASS) | §6 (F-OPEN-10); AP-CLOSE |
| AC-10 | Engineering PASS is explicitly distinguished from authority PASS; no staging→production promotion follows automatically | §3 step 7; Deliverable C §6 firewall |
Aggregate. Acceptance is all-of; a single fail-open condition (§6) fails the pilot. Even a fully passing pilot is an engineering result that requires a separate Owner gate before any staging→production promotion.
12. 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 B2 producer (so bad inputs can be tested) | Điều 32 + S2 + channel + staging | Yes |
| Build the staging surface to run the plan against | Điều 32 | Yes |
| Execute the BAD-1…BAD-15 tests | Điều 32 + built producer + built staging | Yes |
| Generate the rejection / delete-fast / rollback / no-touch evidence | Điều 32 (within the governed pilot) | Yes |
| Recover the Điều 0-G rule-set source (BAD-5 depends on it) | external S6 — Owner out-of-band | Yes |
| Promote a passing pilot's producer to production | Điều 32 + standing B2 + channel + S2 | Yes |
13. What remains unresolved
- No test is run; the producer is MISSING. Every BAD-n behavior is a conceptual obligation (
BAD_INPUT_BEHAVIOR_UNCLEAR), not a runtime result. - BAD-4 / BAD-12 explicitly
BAD_INPUT_BEHAVIOR_UNCLEAR— ambiguous partial stamps and theobserved-role scope are existing-policy questions, defined conceptually only. - BAD-5 depends on SOURCE_RECOVERY_REQUIRED — the Điều 0-G rule-set is from a working source (broken Constitution ref); authoritative recovery is Owner-controlled, out-of-band (external S6).
- Evidence is a requirement, not a result — §7–§10 define the shape of evidence a future pilot must emit; no snapshot/comparison is run here (CAV-3/CAV-4).
- B5 / B7 remain dependencies only, not opened — the plan tests B2's producer slice; the backlog pass (B5) and GUC policy (B7) are out of scope (SCOPE_CREEP guarded).
- 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 test harness, fixtures, the producer, the staging surface, the delete-fast mechanism, the snapshot/comparison queries, and any command sequence.
14. Ready for GPT/Codex review
Yes — as a design-only verification plan, not a runtime test.
Core rule, kept above all detail: the future B2 pilot is acceptable only if invalid input never stamps, certifies, canonicalizes, leaks to production, survives delete-fast, acts as approval, or produces a silent PASS — proven by rejection evidence, delete-fast evidence, rollback evidence, and a before/after no-production-touch snapshot. Fail-open ⇒ reject. Even a passing pilot is an engineering result requiring a separate Owner gate before any promotion.
Default disposition: HOLD. Engineering PASS = a complete verification plan on paper; it is not an Owner authorization to build, test, or promote. No PASS authorizes writes. All blockers remain OPEN.