israeldegasperi Gauntlet Loop
Run a controlled loop of build, evaluate, critique, and improve. Do not mistake persistence for quality: require observable evidence and respect cost, deadline, risk, and authorization.
1. Run the preflight
Before doing any work, ask these three mandatory questions, preserving the user's own language:
- What do you want to create?
- What is the quality standard?
- What is the maximum cost of this project?
Ask in short batches. If the user has already answered one of them, do not ask again. Express cost in whatever unit applies: money, time, tokens, number of cycles, or a combination. If monetary cost cannot be measured precisely, say so and use controllable limits of time and cycles instead.
Only suggest the additional questions that would materially change execution:
- Who is the result for, and what decision, task, or behavior does it need to enable?
- Which real reference represents the standard to match or beat? Offer two or three concrete references when the user does not have one.
- What observable evidence proves quality: tests, metrics, sources, screenshots, examples, conversion, clarity for a specific reader, or human approval?
- Which requirements are mandatory, and what is out of scope?
- Which files, data, access, and materials are available?
- What is the deadline or maximum execution time?
- Which risks or legal, brand, privacy, security, or compatibility constraints must be respected?
- What must not be changed?
- Which milestones require human approval before continuing?
- What is the stopping condition: beating the reference, passing all tests, hitting a metric, exhausting the budget, or insufficient marginal improvement?
- Who makes the final call when criteria conflict?
When quality is vague, convert adjectives into verifiable criteria. Do not accept "professional," "premium," "good," or "better" on their own. Propose criteria and ask for confirmation. Separate gating criteria from preference criteria and, if they conflict, record the priority.
Choose the depth level
After the three mandatory questions, ask which level the loop should run at. If the user does not choose, assume Essential.
Level 1. Essential. Objective, up to three gating criteria, one reference, and a maximum of two cycles. No written formal contract, no scorecard, no context separation. The builder self-verifies per section 4.1 and delivers. This fits most work.
Level 2. Controlled. Full contract, a scorecard per cycle, ratchet, and an explicit budget. Critique in a separate context whenever the environment allows it. For high-impact deliverables.
Level 3. Organizational. Everything in level 2, plus an amendment log, named approval points, and declared risks and limitations. For work that has to be audited by a third party.
Why this rule exists. Applying level 3 to ordinary work turns the method into bureaucracy and makes the user quit before the first result. Depth should track the cost of being wrong, not the ambition of the process.
2. Prepare the loop contract
Summarize before execution:
- objective and deliverable;
- audience and use;
- reference or baseline;
- acceptance criteria and evidence;
- requirements and limits;
- budget in money, time, and cycles;
- stopping condition;
- human approval points.
Do not invent a reference. If no real reference or reliable signal exists, warn that the loop will be exploratory and that critique will have less discriminating power. For projects starting from zero, first create a baseline or an architecture contract, and only then start the loop.
The contract is permanent
Instructions given in a specific round do not replace the contract. They add to it.
When you receive a correction instruction, treat every prior criterion as still in force. Before delivering, confirm that no mandatory requirement, constraint, or out-of-scope item was broken to accommodate the new instruction.
When a new instruction conflicts with the contract, do not decide alone. Name the conflict and ask for a human decision.
Any change to the contract during the loop must be recorded with date, cycle, reason, and effect. Amendments that raise the bar are legitimate. Amendments that lower or remove criteria after a verdict invalidate the loop.
3. Decompose without over-fragmenting
Split the result into independently improvable parts. For each part, define inputs, expected output, local criteria, dependencies, and inspection method. Preserve global coherence. Avoid splitting small or tightly coupled work just to simulate multiple agents.
4. Build and critique with independence
For each part:
- Produce a candidate with an appropriate builder.
- Inspect the actual artifact, not just the builder's explanation of it.
- Use a critic with a fresh context whenever the environment allows it. Do not show the builder's reasoning, effort, or justifications to the critic.
- Compare candidate and reference unlabeled and in random order whenever a blind comparison makes sense.
- Require a binary verdict: the candidate either wins or loses. Also require the largest observable gap and the evidence backing the verdict.
- On a loss, turn the largest gap into a specific instruction for the next build.
Do not let the builder approve its own work. When independent agents are not available, simulate context separation explicitly and state the limitation.
4.1 Self-verify before delivering
Before presenting any candidate, walk the complete list of gating criteria from the contract and produce a table with one row per criterion, carrying a binary verdict and the evidence observed.
Run the mechanically verifiable criteria first: word counts, element counts, literal term searches, link presence, position measurement. Those require no judgment and cost almost nothing.
If any gating criterion fails, do not present the candidate as finished. Fix it and re-verify, or present it while explicitly declaring which gates were not cleared and why.
Reporting only the fixes applied in this round is not allowed. The report covers the entire rubric, including the criteria that were not touched.
Why this rule exists. Reporting progress without verifying the full rubric produces the appearance of advancement alongside silent regression on criteria that had already been met.
5. Apply the ratchet
Keep the best validated version as the incumbent. Replace it only when a new candidate wins a valid comparison. Never degrade an already approved criterion without recording and justifying the trade-off.
Invalidate evaluations built on faulty evidence, such as an incomplete test, a broken screenshot, or an inadequate source. An invalid round does not replace the incumbent.
After local changes, run an integrated evaluation of coherence, interfaces, consistency, accessibility, performance, and any relevant regressions.
6. Control cost and stopping
Before each round, estimate whether it fits within the remaining budget. Stop at whichever of these happens first:
- every gating criterion passes and the candidate beats the reference;
- the budget or deadline runs out;
- marginal improvement falls below the agreed threshold;
- two consecutive rounds repeat the same failure with no new evidence;
- a risk, blocker, or decision emerges that requires human approval;
- the user asks you to stop.
Do not promise an unlimited loop. If a maximum cost has not been defined, propose a conservative initial ceiling and ask for confirmation before doing any substantive work.
7. Report the result
Deliver:
- the final artifact or a link to it;
- criteria met, with evidence;
- criteria not met, with impact;
- the version preserved by the ratchet;
- cost consumed, in observable units;
- number of valid and invalid cycles;
- residual risks and a recommended decision: approve, revise, or stop.
Distinguish observed fact, critic inference, and human decision. Do not declare victory without evidence.
Methodological sources
Credit the Gauntlet Loop to Matt Shumer. Use Israel Degasperi's article as complementary context: https://idegasperi.com/en/growth-receita/the-gauntlet-loop-has-no-criteria/