A Philosophy of Verifiable Work
GAVEL is a contract-first discipline for running verifiable agent loops: the contract is the law, the maker is the party doing the work, and the verifier is a judge that rules from disk — deterministically, in isolation, against checks proven to fail first.
Write the failing check, freeze it, let a separate judge rule.
Never rewrite the law to win.
A loop without a verifier is an agent talking to itself.
It produces work, evaluates the work, decides the work is good, and moves on. The evaluation step is invisible. There's no record of what "good" meant, no proof the criterion was meaningful before the work was done, no guarantee the same judge run tomorrow returns the same verdict.
This is a discipline problem, not a technology problem. It existed before AI: in code review, in manual QA, in any process where the person doing the work also declares it done. The solution existed before AI too. TDD found it: commit to the check before you see the output.
But TDD failed in practice for a specific reason. Engineers wrote tests after the code — not because they were lazy, but because writing tests against a void is hard. There's nothing to assert against. The I/O contract doesn't exist yet. So the pendulum swung back to code-first, and the tests followed, describing behavior that existed rather than behavior that was intended.
GAVEL fixes this without pretending the void problem doesn't exist.
The TDD implementation pendulum can't swing meaningfully until the foundation is built. Ground zero is three things, in order:
What components exist, what each is responsible for, and what deliverable each checkpoint must produce. Not an implementation plan: a boundaries map. You cannot write a contract for a unit you haven't named.
The concrete list of files to create or modify, each tagged to the checkpoint that owns it. This is the entry-state definition. When you RED-proof checkpoint N, "prerequisites present" means files owned by checkpoints 1 through N−1 are on disk and satisfy their done condition. Without this map, RED is a guess — you're failing the contract because nothing exists, not because this checkpoint's work is missing.
Per unit: input shape, output shape, transformation rules, and at least two representative I/O cases. Not implementation — just the I/O surface. This is where contracts get their teeth. A verifier asserting a single I/O pair can be fooled by a maker that returns a hardcoded value. Two cases, especially with a boundary or edge case, cannot both be satisfied by the same stub.
Only after ground zero can you write contracts that mean something. Only then can a RED proof fail for the right reason. TDD was missing this piece: you don't need the implementation before you write tests, but you do need the architecture, the file map, and the I/O contracts.
A verified loop is a courtroom, not a pipeline.
A pipeline moves work forward. Each stage hands off to the next. Success is throughput. The pipeline is satisfied when the work exits the end.
A courtroom adjudicates claims. A party presents work. A judge who did not do the work rules on whether it meets the law. The law was set before the party entered. A verdict is not the same as the work: it's a statement about the work, made by someone with no interest in the work succeeding.
| Role | In GAVEL |
|---|---|
| The law | The contract — written before the work began, shown to fail against the starting state, then locked. It does not change because the work is hard. |
| The party | The maker — its job is to satisfy the contract. It does not set the standard, does not interpret it charitably, and does not grade the output. |
| The judge | The verifier — it did not do the work. It reads only what's on disk, never context memory, never the maker's explanation of intent. PASS or FAIL, with evidence. Nothing in between. |
A verdict is a claim until the evidence is reproduced. If you can't re-run the verifier against the same disk state and get the same verdict, it wasn't a verdict. It was an opinion. Opinions are not admissible.
Deterministic is the word that separates a real verifier from a dressed-up second opinion. A judge who rules based on how the argument is framed is a participant in the argument. A verifier that can be convinced by a well-written summary of what was done is a maker in disguise: same priors, same patterns recognized as correct, same blind spots.
Deterministic means: same inputs on disk, same verdict. That's only possible when the verifier is a tool — a script or test suite — not another model reading the maker's report and deciding whether it sounds right.
Model-judged verdicts are permitted where no deterministic check can exist. But they carry a burden: a rubric specific enough that a third party following it grades identically. A rubric that requires judgment isn't a rubric — it delegates back to the problem determinism was supposed to solve. For critical-path work — anything where a wrong verdict means data loss, security breach, or irreversible action — there is no model-judged path. The verifier is a tool, or the checkpoint isn't complete.
A goal that can't be machine-verified can't be looped. A goal that can be verified but has no architecture, no file map, and no I/O contracts is a checkable void: the pendulum has nowhere to land. Both conditions must hold before the loop starts. The goal is real only when it's checkable and there's a foundation to build from.
Writing a contract is not enough. Prove it fails against the starting state — not theoretically, actually. Run it. Confirm it exits non-zero. Confirm the failure is for the right reason: the work is missing, not the environment. Then run it against an adversarial fixture — a plausible-but-wrong output the maker might produce. The verifier must reject it.
Only then do you lock the contract. The lock is a hash. The contract can't change after the lock without a human decision and a written justification: "the spec was wrong because X." Implementation difficulty is not a justification — that's the party rewriting the law to win the case.
The maker never sees the verifier's code. The verifier never reads the maker's reasoning. It reads only what's on disk. The separation is epistemic, not just technical: a judge who heard the defense's private argument before reading the evidence is not impartial. The separation must be structural — different context, different tools, no shared memory.
A checkpoint that passes is a claim until it's reproduced. "The verifier said done" is not proof. Proof is another verifier, in a fresh context, reading the same disk, returning the same verdict.
An unattended loop is a loop making mistakes without observation. The bounds are the conditions under which the loop is permitted to run unattended — not suggestions. When iteration count or token budget trips, the loop stops, writes a handoff report, and waits. When the same failure signature appears twice in a row, the loop is spinning: retrying the identical action after the identical failure is waste, not learning. When the maker touches files outside the checkpoint's declared scope, the loop has drifted. A green result with undeclared side effects is not a clean green.
Convergence is not completion. When all checkpoints pass in sequence, the chain must hold all at once — individually passing checkpoints can mask interference between them. Then harden: checkpoints that took more than three iterations are telling you the contract was wrong or the scope too large. Verifiers that never failed may not be able to fail — mutation-test them before you trust them. Remove tools the loop never used. Extract a template. Make the next run cheaper.
Every checkpoint is four filesystem pieces working as one gate. Shape alone is not a checkpoint — it's a pre-filter.
.loop-cycle/contracts/ <checkpoint>.schema.json ← Layer 1: shape <checkpoint>.verify.* ← Layer 2: semantic (the real gate) <checkpoint>.artifacts.md ← Layer 3: what must exist on disk <checkpoint>.fixtures/ ← adversarial: wrong work it must reject
Schema — shape. A JSON Schema validating the state object at this boundary. Fields exist, types match. Runs first because it's fast and cheap. A well-shaped state object that says the wrong thing still fails Layer 2.
Semantic verifier — the RED/GREEN signal. A deterministic script or test that exits non-zero on failure and asserts at least two I/O cases from the pseudocode, so a stubbed single return value cannot pass.
Artifacts on disk — reproducibility substrate. Everything the verifier needs to re-run cold, in a fresh context, with no conversation memory. This is what makes "done" a proof rather than a claim.
Adversarial proof. At least one plausible-but-wrong input the verifier must reject — proving the contract fails on wrong work, not just absent work, before it is ever frozen.
A checkpoint that passes all four can be re-verified by anyone, at any time, from disk alone. That's the standard.
No. 1
The RED proof fails because nothing exists, not because this work is missing. The first iteration produces something; the loose contract accepts the first approximation. The checkpoint is green but wrong.
No. 2
The maker evaluates its own output and reports done. Its definition of "done" drifts toward what it can produce, not what the goal requires. Not a failure of intelligence — a failure of structure. Even excellent work needs an external judge.
No. 3
A maker told to satisfy one exit condition will find the minimum: a stub, a hardcoded return. Two cases — especially with an edge case — close this escape. The maker has to implement the real thing to pass both.
No. 4
A verifier that reads the maker's reasoning and forms an opinion is a second maker with a different perspective. Its verdict is interpretation, not measurement. Interpretation drifts. Measurement doesn't.
No. 5
The loop can't satisfy a contract, so the contract is relaxed, and the loop passes. Nothing was proven — the work that passed satisfied the weakened version, not the original. The law was rewritten to let the party win. Every instance must be logged, justified, and audited.
GAVEL is not TDD. It borrows TDD's core insight — commit to the check before you see the output — and extends it to loops, agents, and the specific failure modes that arise when the maker and verifier can share training data.
| TDD | GAVEL |
|---|---|
| Failing test (RED) | Checkpoint contract that fails before the loop runs |
| Passing test (GREEN) | Verifier approves the state object at a checkpoint |
| Deterministic test runner | Deterministic verifier — a script or test that exits non-zero, mandated |
| Refactor | Harden: tighten contracts, prune tools, reduce cost |
| Test suite | Checkpoint chain — typed state object at every boundary |
| Triangulation (≥2 tests) | ≥2 I/O cases per contract — a stub can't pass both |
| "Never modify a test to make it pass" | "Never weaken a contract to make the loop converge" |
| A human writes the tests | Agents draft scaffolding; a human authors every semantic exit condition |
| A fixed codebase to test against | Ground zero first: architecture, file map, pseudocode |
Same discipline. Different domain. Higher rigor required — because the consequences of a soft verifier are invisible until they compound.
A contract-first discipline for running verifiable agent loops, adapting TDD's red-green-refactor to autonomous agents. The letters: Goal made checkable and buildable; Arm the contracts (prove they fail, then freeze); Verify in isolation; Enforce the bounds; Lock in and harden.
A loop without one is an agent talking to itself — it produces work, grades its own work, and declares it done, and its definition of "done" drifts toward what it can produce. GAVEL runs the verifier in a separate context, reading only artifacts on disk, emitting PASS or FAIL with reproduced evidence.
Before the loop runs, every contract is executed against the entry state and must FAIL for the right reason — the checkpoint's work is missing, not an environment error — and must REJECT an adversarial fixture. Only then is the contract hash-frozen. A check that has never failed proves nothing.
A script or test suite that exits non-zero on failure: same inputs on disk, same verdict, every time. Model-judged verdicts are a last resort requiring an explicit flag plus a deterministic backstop — and are forbidden outright on critical-path checkpoints (data loss, security, irreversible actions).
It keeps TDD's core move — commit to the check before you see the output — and adds what loops need: ground zero before any contract, hash-frozen contracts, a structurally separate judge, at least two I/O cases per contract so a stub can't pass, and human-authored exit conditions.
Hard bounds. An iteration cap and token budget halt the loop regardless of progress; spin detection halts it when the same failure signature appears twice in a row; drift detection halts it when the maker touches files outside its checkpoint's declared surface.