From corpus to proof PT-BR

Course / Lesson 3 of 6

18 min · sanitized real case

Proof gates & total coverage

Objective: Design a proof gate that covers everything — because a partial gate is not a weaker defense, it is an invitation to bypass.

First, in plain language

A proof gate is a door that only opens when every unit of work presents a genuinely executed proof. If the door watches 99% of units, the remaining 1% is not "less protected" — it becomes the preferred route for any work that wants to pass without proof, by accident or by construction.

The real mission's discipline was adversarial: attack your own gate, repair the minimum, and attack again. It took seven rounds. The gate only closed when a battery of thirteen known attacks passed 13/13 — with a Validator that had no authorship over the attacked code.

Open the technical layer

The seven rounds (each one: attack → minimal repair → re-attack):

RoundBypass foundMinimal repair
1Units without an id stamp were invisible to the gate.Stamp every task; an untagged executable becomes its own unit, flagged for review.
2Forgeable metadata: a spurious kind:'proof' hid work; an id collision gave a free ride on someone else's proof.Exemption only by complete form (kind + id + numeric proof index); id collision fails closed.
3A command hidden inside the tag of an already-proven unit.Inside a tagged unit, every command requires complete proof form.
4Coordination subtasks ran invisible commands in a child sub-run (flat coverage).Every command leaf must be complete proof, otherwise error.
5Misaligned jurisdiction: the gate only looked at the top level; a failing proof leaf converged.The gate flattens subtasks; a failing or unjournaled leaf takes the gate down.
6Ghost leaf: an internal kind with no command converged.A phantom instrument leaf becomes an error.
7"Greatest hits" battery: all previous attacks together.13/13; total command coverage; residuals documented, not hidden.

Structural lesson: no repair "improved the code"; each one closed exactly the demonstrated bypass and was immediately re-attacked. The repository baseline stayed green throughout — the adversary here is the gate's logic, not the compiler.

Deterministic simulation · synthetic pseudo-configs

Spot the bypass

Each card shows a configuration that would pass a naive gate. Choose where the bypass lives.

Config 1

tasks: [ { kind:'work', command:'build A' } ] gate: for each known unitId, require proof

Config 2

tasks: [ { id:'u7', kind:'proof', note:'verified' }, { id:'u7', kind:'work', command:'deploy' } ]

Config 3

unit u3: proof ✓ (build + test) tasks: [ { unitId:'u3', command:'publish extras' } ]

Config 4

LEAD task (coordination) └─ child sub-run: [ { kind:'work', command:'migrate' } ] gate: only looks at the top level

Config 5

tasks: [ { kind:'instrument', note:'observed' } ] gate: no recorded failures → converge

0 of 5 bypasses found.