This is a procedure, not an essay. If you have a piece of model output and you want to systematically catch and fix the errors in it, follow the steps below in order. Each step has a specific action and, where useful, the exact prompt to paste. The whole thing takes a few minutes once you know it, and it reliably catches mistakes that a single-pass generation leaves in.
The sequence works because it separates four distinct jobs that people usually try to do at once: generating the output, detecting errors in it, correcting those errors, and verifying the corrections. Collapsing them into one step is why errors slip through. Pulling them apart—asking the model to switch into each mode deliberately—is what makes the process effective.
Follow it as written the first few times. Once the steps are habit, you will compress them naturally and adapt the prompts to your work. For the reasoning behind why each step exists, the Complete Guide to Prompting for Error Detection and Correction covers the mechanism; this article is the hands-on procedure.
Step 1: Generate, Then Stop
Resist the urge to use the first answer immediately.
The action
Produce your initial output as normal. Then deliberately pause before using it. The pause is the whole point of step one—treating the first answer as a draft to be checked rather than a result to be used.
Why this matters
Most errors survive because people skip straight from generation to use. Inserting a stop creates room for the detection step. Mentally label the first output "draft," not "answer." Everything that follows depends on that reframe.
The reframe is harder than it sounds because the first answer usually looks finished. It is well-formatted, confident, and complete, and nothing about its appearance signals which parts are wrong. That polish is exactly what makes the stop necessary—the output gives you no internal cue to doubt it, so the doubt has to come from your process instead. Building the stop into your habit, rather than relying on noticing something looks off, is what makes the rest of the sequence reliable.
Step 2: Run a Targeted Error Hunt
Now switch the model into review mode with a specific prompt.
The action
Send a follow-up that names the error types relevant to your task. Generic works; specific works better.
- General: "Review the output above. List any factual errors, logical gaps, unsupported claims, or contradictions you find."
- Targeted (example for analysis): "Check the output for wrong numbers, unit mismatches, incorrect dates, and internal contradictions. List each problem with its location."
Why targeted beats general
Naming the error types focuses the model's evaluation and catches more than a vague "find mistakes." Match the named types to what your task tends to get wrong—math for quantitative work, contradictions for arguments, unsupported claims for research. This pairs well with asking the model to cite its sources, since unsupported claims are a category of error.
Step 3: Add an Adversarial Pass for High-Stakes Work
For anything consequential, push harder than a cooperative review.
The action
Ask the model to argue against its own output:
- "What is the strongest case that this output is wrong or misleading? Be specific."
Why add this
A cooperative review can be too gentle, accepting the output's framing. Adversarial framing forces the model to look for the failure rather than confirm the success, surfacing weaknesses the standard hunt misses. Skip this step for low-stakes drafts; run it whenever being wrong is costly. It is especially effective on logical and structural work, the way an AI Code Review for Delivery process stress-tests assumptions.
Step 4: Request Corrections With Explanations
Turn the error list into actual fixes.
The action
Prompt the model to fix each identified error and explain it:
- "For each problem you identified, provide the corrected version and briefly explain what was wrong and why the fix is right."
Why require explanations
The explanation forces the model to justify the correction, which both improves the fix and gives you something to evaluate. A correction with a weak or circular explanation is a red flag. Keeping detection and correction as separate prompts—rather than one "find and fix" request—keeps the model from quietly rewriting without surfacing what changed.
Watch specifically for explanations that restate the correction without justifying it ("this is correct because it is the accurate value") versus ones that give a real reason ("the original used the 2019 figure; the provided source lists the 2021 figure"). The second kind you can check; the first kind tells you nothing and should lower your confidence in the fix. Over time, reading explanations becomes a fast filter—a strong justification lets you move on quickly, while a weak one flags exactly which corrections deserve your independent verification in the next step.
Step 5: Verify the Corrections Yourself
This is the step that makes the whole sequence trustworthy.
The action
Check the corrections, with depth matched to stakes:
- Low stakes: read the explanations for plausibility.
- High stakes: independently confirm the corrected facts, recompute the numbers, and check that the fix did not introduce a new error.
Why this is non-negotiable
The model can introduce new errors while correcting old ones, and it can "correct" something that was actually right. Self-correction reduces error rates; it does not eliminate them. Human verification closes the remaining gap. Tier the depth so you do not over-invest on low-stakes work—the same calibration logic in the Beginner's Guide to Error Detection Prompting.
Step 6: Capture What You Learned
Make the process compound over time.
The action
When a particular error type keeps showing up across your work, add it to your standard targeted-hunt prompt. When a correction pattern proves unreliable, note it.
Why capture
The first few runs teach you what your specific tasks get wrong. Folding that into your standard prompts means each run starts smarter than the last. Over time your targeted hunt becomes tuned to your actual failure modes, and the sequence gets faster and more effective. This is how a personal procedure matures into a team standard within a broader prompt practice.
Frequently Asked Questions
Do I have to run all six steps every time?
No. The full sequence is for consequential work. For routine output, run steps one, two, and five—generate, targeted hunt, verify—and skip the adversarial pass and the formal capture step. The calibration is the skill: match the number of steps to what is at stake rather than running the full procedure on everything.
What's the difference between detection and correction prompts?
Detection asks the model to find and list errors; correction asks it to fix them. Keeping them as separate prompts matters—a combined "find and fix" request lets the model rewrite quietly without surfacing what was wrong. Separating them gives you a visible error list you can evaluate before accepting any fixes.
Why require an explanation with each correction?
The explanation forces the model to justify the fix, which improves the correction and gives you a way to judge it. A circular or hand-wavy explanation signals a correction you should not trust. Explanations turn the correction step from a black box into something you can actually evaluate before using.
When is the adversarial pass worth it?
Whenever being wrong is costly—client deliverables, decisions, anything public or contractual. A cooperative review tends to accept the output's framing, while adversarial framing forces the model to hunt for failure. For low-stakes internal drafts it is unnecessary overhead, so reserve it for work where the extra scrutiny pays off.
Can I automate any of these steps?
Generation, the targeted hunt, and the correction request can be chained and partly automated. The verify step on high-stakes claims still needs human judgment, because confirming a correction is actually right—not just plausible—requires knowledge the automation may lack. Automate the prompting; keep humans on consequential verification.
How do I know my error hunt is catching the right things?
Watch which errors slip through to the verify step despite the hunt, then add those types to your targeted prompt. The capture step exists for exactly this. Over a handful of runs, your hunt becomes tuned to your task's real failure modes, and fewer errors survive to verification.
Key Takeaways
- Run the steps in order: generate and stop, targeted error hunt, adversarial pass for high stakes, correction with explanations, verify yourself, capture what you learned.
- Treat the first output as a draft, not an answer—inserting a deliberate stop is what creates room for detection.
- Targeted hunts that name specific error types catch more than vague "find mistakes" prompts; match the named types to your task's failure modes.
- Keep detection and correction as separate prompts and require explanations, so fixes are visible and evaluable rather than quiet rewrites.
- Always verify corrections yourself with depth matched to stakes—self-correction reduces errors but can introduce new ones, so human verification closes the gap.