Most error-detection prompting fails not because of bad wording but because of missing structure. Teams treat finding and fixing errors as one fuzzy request when it is actually a sequence of distinct stages, each with its own job and its own failure mode. When you collapse the sequence into a single prompt, you lose the ability to see where things went wrong.
This article introduces a named, reusable model we call the DETECT loop. It is not a product or a piece of software. It is a way of decomposing the task into stages you can run, inspect, and improve independently. The name is a mnemonic for the six stages: Define, Examine, Triage, Edit, Confirm, and Track. Run them in order and you convert a fragile one-shot prompt into an engineered process.
The value of a named model is that it gives a team shared language. Instead of debating whether a prompt is good, you can ask which stage failed. That precision is what turns prompting from a craft practiced by individuals into a process a whole team can run consistently.
Define: Establish What Counts as an Error
The loop opens by fixing the standard before any analysis happens.
What this stage owns
Define is responsible for the error taxonomy and the source of truth. You state which categories count as errors, you supply the reference the output is judged against, and you name what is intentional and off-limits.
When to apply it
Always. Skipping Define is the root of false positives and fabricated corrections, the failures cataloged in Seven Ways Error-Detection Prompts Quietly Fail You. There is no stage you can less afford to skip.
Examine: Detect Without Editing
Examine is the pure detection pass.
What this stage owns
The model lists every error it finds, with location and reason, and changes nothing. The output is a diagnosis, not a treatment. For long inputs, Examine runs per chunk.
Why it is separate
Separating examination from editing preserves the audit trail and prevents the model from silently rewriting. You can inspect and challenge the reasoning before any text moves.
Triage: Sort by Confidence and Stakes
Triage decides which flagged items deserve which level of scrutiny.
What this stage owns
Each item gets a confidence rating and a verification flag. High-confidence, low-stakes items can flow to automated correction; low-confidence or high-stakes items route to a human.
Why it matters
Without Triage, you treat a confident guess and a verified fact identically. Triage is where the confidence signal becomes an actual routing decision, feeding the metrics in The Numbers That Tell You an Error-Detection Prompt Works.
Edit: Correct With a Minimal Diff
Edit is the correction pass, deliberately constrained.
What this stage owns
For each triaged item cleared for automated correction, the model proposes the smallest change that fixes it and preserves everything else verbatim. Each edit maps to a specific flagged error.
The constraint that matters
The smallest-viable-change rule is what prevents overcorrection from erasing intent. You review the diff, not the rewrite, so any creep is immediately visible.
Confirm: Verify the Correction
Confirm treats the corrected output as a draft that itself needs checking.
What this stage owns
A verification pass checks that each flagged error is resolved and that no new error was introduced. For code and data, Confirm is the test suite or source revalidation.
Why it is non-negotiable for shipped work
Correction can introduce errors. Confirm is the only stage that catches a defect the Edit stage created, which is exactly how clean-reading bad corrections reach clients.
Track: Measure and Improve the Loop
Track closes the loop by feeding outcomes back into the process.
What this stage owns
You record catch rate, false positives, and escaped errors, and you maintain a known-bad calibration set the prompts are tuned against. Track is what lets the loop get better over time rather than silently degrade.
How it connects
The calibration discipline here is the same one that powers Hard-Won Rules for Error-Checking Prompts That Hold Up. A loop you measure is a loop you can trust.
Running the Loop on a Real Task
Seeing the stages flow on a concrete task makes the model less abstract.
A worked pass
Imagine checking a client-facing product comparison for accuracy. Define sets the standard: the spec sheet is the source of truth, factual mismatches are errors, and tone is off-limits. Examine produces a list of every claim that disagrees with the spec sheet, each with a location and reason, and nothing is edited yet. Triage rates each flag, sending the high-confidence factual mismatches to automated correction and routing two ambiguous claims to a human. Edit proposes the minimal fix for each cleared item, changing only the disputed figures. Confirm re-checks the corrected comparison against the spec sheet and finds that one fix accidentally broke a sentence's grammar, which it flags. Track records the catch, the one introduced error, and adds the ambiguous claims to the known-bad set.
What the walkthrough reveals
Every stage caught something a single prompt would have missed: Examine kept the diagnosis auditable, Triage protected the ambiguous claims from automated overreach, and Confirm caught the introduced error. The same arc appears in the worked scenarios in Five Error-Detection Prompts, Walked Through End to End.
Where the Loop Tends to Break
Knowing the failure points of the model helps you reinforce them.
The weak joints
- Skipping Define and letting the model infer the standard, which produces drifting false positives run to run.
- Collapsing Examine into Edit, which destroys the audit trail and invites silent rewrites.
- Treating Triage as optional, so confident guesses and verified facts get corrected identically.
- Dropping Confirm because the output read cleanly, which is exactly how an introduced error ships.
How to reinforce them
Make each stage produce a distinct artifact: a standard document, a flagged list, a triaged queue, a diff, a verification report, and a metrics entry. When every stage has a visible output, a skipped stage becomes obvious instead of invisible. These weak joints map directly onto the failure modes in Seven Ways Error-Detection Prompts Quietly Fail You.
Frequently Asked Questions
Do I have to run all six stages every time?
For high-stakes work, yes. For a quick personal draft you might collapse Triage and skip Confirm. The value of naming all six is that you are then making a deliberate choice to skip a stage rather than forgetting it exists.
Why give the loop a name at all?
A name gives a team shared language. Instead of arguing about whether a prompt is good, you can pinpoint which stage failed, which makes the process diagnosable and improvable rather than a black box.
Which stage is most often skipped?
Define and Confirm. Teams jump straight to asking for fixes without setting a standard, and they trust the first correction without verifying it. Those two omissions cause the majority of escaped errors.
How does the loop handle long documents?
Examine and Confirm run per chunk, with an added cross-chunk consistency check in Confirm. Define and Track operate at the document level. Chunking is what keeps detection thorough across long inputs.
Can the loop run partly automated?
Yes. Define is human-authored once per task type. Examine, Edit, and parts of Confirm can be automated, while Triage routes uncertain items to people. Track is where humans review aggregate outcomes.
How is this different from just following a checklist?
A checklist tells you what to verify; the loop tells you how the task decomposes into stages with distinct owners. The two are complementary, and a working checklist version appears in A Working Pre-Flight List for Error-Detection Prompts in 2026.
Adapting the Loop to Your Domain
The six stages are constant, but how you fill them depends on what you check.
How the stages flex
- For prose, Define is an editorial standard and Confirm leans on human review and self-critique.
- For code, Define is the spec and Confirm is the test suite, the strongest verification available.
- For data, Define is the schema and source figures, and Confirm is automated validation against them.
- For legal copy, Triage is weighted heavily toward human review because the stakes of a missed contradiction are high.
Why the loop still holds
The stages do not change; only their contents do. That stability is the point of a named model: you carry the same six-stage skeleton into a new domain and simply re-fill Define and Confirm with domain-appropriate standards and checks. The domain-specific flex mirrors the verifiability axis in Single-Pass or Multi-Pass: Deciding How to Hunt AI Errors, where what can be checked deterministically reshapes the workflow.
Key Takeaways
- The DETECT loop decomposes error-detection prompting into six inspectable stages.
- Define fixes the error taxonomy and source of truth before any analysis.
- Examine detects without editing to preserve an auditable diagnosis.
- Triage routes items by confidence and stakes; Edit corrects with a minimal diff.
- Confirm verifies the correction and is non-negotiable for shipped work.
- Track measures outcomes and tunes prompts against a known-bad calibration set.