TL;DR
LLMs are bad at correcting themselves: the standard "check and improve" request either breaks the correct parts of an answer or ignores the real errors altogether. DISC solves this with a fundamentally different structure. Instead of a single "find and fix" request, the method runs a loop with three roles: a verifier asks targeted questions about specific claims, a judge issues a strict verdict based on evidence, and a corrector rewrites only what is explicitly flagged as an error.
The main pain point of LLM self-checking is that the model fixes things that are already correct. Ask Claude to "double-check your answer" and it starts rephrasing true statements, adding caveats, changing the structure. The answer changes, but the quality drops. That happens because the model has no "brake": it never asks itself "does anything actually need changing?"
DISC adds that brake, a "judgment gate": before anything is fixed, the judge has to find concrete evidence of an error. No evidence, no fix, and the loop stops. Evidence found, and the loop repeats up to 3 times, each time "peeling off" one layer of errors, like cleaning up a noisy signal.
Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.
Method Blueprint
ORIGINAL ANSWER (already written)
↓
ROUND 1 (of at most 3):
VERIFIER → asks 3-10 targeted questions about specific
claims in the answer → answers them independently
↓
JUDGE → compares the evidence (the verifier's answers)
with the original answer → issues a verdict:
NO_ERROR? → stop immediately, the answer is left untouched
ERROR? → points to the exact spot and the evidence
↓
CORRECTOR → rewrites ONLY the flagged spot,
leaves everything else alone
↓
ROUND 2 (if the verdict was ERROR) → repeat the loop
↓
ROUND 3 (if ERROR again) → final repeat
↓
FINAL ANSWER
All steps run in a single prompt: the model plays the verifier, judge and corrector roles in sequence.
Example in Practice
The task: You asked Claude to draft a sales proposal for a client, a small coffee shop in Chicago, to supply espresso machines. What matters: financing terms, warranty periods, competitor comparisons all have to be accurate, not made up.
Prompt:
Check the following sales proposal text. Follow the roles strictly.
ORIGINAL TASK: a sales proposal for a coffee shop to supply espresso machines
TEXT TO CHECK:
"""
We offer professional La Marzocco GB5 espresso machines for $18,500.
Warranty: 2 years. Delivery within Chicago: 3 business days.
12-month financing at 0% interest. Free barista training (2 hours).
"""
ROLE 1 — VERIFIER:
Write 4-5 targeted questions about specific claims above.
Then answer each question on your own, as if you had never seen the text above.
Format:
Q1: [question]
A1: [answer]
(and so on)
ROLE 2 — JUDGE:
Compare each A with the corresponding claim in the text.
Is there a concrete contradiction between the evidence and the text?
Issue one of two verdicts:
NO_ERROR — return the text unchanged and briefly explain why
ERROR — point to the exact spot of the error and the evidence that confirms it
ROLE 3 — CORRECTOR (only if the verdict is ERROR):
Fix ONLY the flagged spot. Leave the rest of the text word for word.
Output the final text.
Result:
The model will output three blocks in order: the verifier's questions with independent answers, the judge's verdict pointing to a specific contradiction (or a stop with an explanation), and, if an error was found, a corrected version changed only at the flagged spot. If the first round found an error, you can ask it to "run the loop again on the new text," for up to three rounds.
Why It Works
The LLM weakness: the model generates text by continuation patterns, not by the logic of "what's definitely true here." When asked to "check yourself," it slips back into "continue the text" mode and starts rewriting, because rewriting itself looks like the expected continuation of the request.
The LLM strength: the model handles specific questions well. "What's the standard warranty on a La Marzocco?" is a different mode from "say something about the warranty in this text." Independent, targeted questions force the model to answer "on the merits," not "in context."
How the method exploits this: DISC breaks the vicious circle because the verifier answers questions independently of the original text. Then the judge compares two independent sources. If they match, nothing changes. If they diverge, there's concrete evidence and the corrector works with precision. It's not "evaluate and improve," it's "compare two sources and decide whether there's a contradiction."
Control knobs: - Number of questions (3–10) — fewer for short texts, more for complex multi-step calculations - Judge strictness — add "require a direct quote of the evidence" for maximum precision; drop it for a gentler check - Number of rounds (1–3) — one round for simple tasks, three for chains of reasoning - Verifier persona — ask it to "ask questions like a skeptical competitor" for a sharper check
Prompt Template
Check the following {text_type}. Follow the roles strictly — don't skip any.
ORIGINAL TASK: {task}
TEXT TO CHECK:
"""
{text}
"""
ROLE 1 — VERIFIER:
Write {number_of_questions} targeted questions about specific claims above.
Answer each question on your own, as if you had never seen the text above.
Output format:
Q1: [question]
A1: [answer]
...
ROLE 2 — JUDGE:
Compare each answer (A1-A{number_of_questions}) with the corresponding claim in the text.
A direct contradiction is required, not a subjective quality judgment.
Issue one of two verdicts:
NO_ERROR — return the text unchanged and explain the conclusion in one sentence
ERROR — quote the exact spot of the error + state which evidence confirms it
ROLE 3 — CORRECTOR (only if the verdict is ERROR):
Fix ONLY the quoted spot.
Copy the rest of the text word for word, unchanged.
Output the final text.
Placeholders:
- {text_type} — "sales proposal," "legal wording," "financial calculation," "technical plan"
- {task} — the original brief the text was answering
- {text} — the text to check
- {number_of_questions} — 3 for short texts, 5-7 for complex ones
🚀 Quick start — paste into the chat:
Here is the DISC template for checking texts. Adapt it to my task: [describe your task].
Ask me questions to fill in the fields.
[paste the template above]
The LLM will ask about the text type, the task and how many questions to ask, because without context the judge doesn't know what counts as an error. It will take the role structure from the template and plug in your details.
Limitations
⚠️ A weak judge blocks everything: If the model isn't strong enough, the judge will return NO_ERROR even when contradictions are obvious. The verifier finds the error, the judge ignores it, and the correction never runs. This is the "competence floor": below it, the method doesn't work.
⚠️ Facts vs. logic: The method is excellent at catching factual errors: wrong numbers, contradictory claims, missing conditions. It's worse at fixing logical errors in chains of reasoning, especially when the error is in the premise rather than the conclusion.
⚠️ Subjective tasks: Not suited to judging style, tone or "on-brand-ness": the judge can't issue an objective verdict where there's no clear-cut evidence.
⚠️ More tokens: One DISC round costs roughly 5x more than a plain "check and improve" request. For short texts with obvious errors, that's overkill.
How They Tested It
The Thomson Reuters Labs team built the system to measure the architectural contribution of each element, not just "better or worse." They took three fundamentally different task sets: BIG-Bench Mistake (ready-made reasoning chains with deliberate errors, starting accuracy ~15%), HotpotQA (7,405 questions requiring search across two Wikipedia articles), and GPQA Diamond (198 graduate-exam-level questions in physics, chemistry and biology).
The most interesting experiment was five configurations on GPQA, where the verifier, judge, generator and corrector roles were split between a weak model (gpt-4.1-nano) and a strong one (gpt-5.2). The result was surprising: a strong verifier without a strong judge gave +0 improvement (the judge said NO_ERROR 100% of the time). A strong judge without a strong verifier gave +3. Both together gave +34. The effect doesn't add up, it multiplies. In other words, in a "checker + evaluator" pair, the weaker link determines the result of the whole chain.
Another clean experiment was disabling the "gate": same prompts, same model, but the judge always returned ERROR and always triggered a fix. The result: the number of degradations (breaking what was right) rose 2-3x. That proves it's the brake, not the prompts themselves, that stops overcorrection.
Adaptations and Extrapolations
1. Simulating cross-model checking in one chat
The study showed that the main problem with self-checking is self-confirmation bias. The model checks the answer with the same "eyes" it wrote it with. In the actual research this is solved by swapping in a different model. In a chat, you can simulate a change of perspective:
🔧 Technique: change the verifier's persona → a sharper check
Replace the start of ROLE 1 in the template with:
ROLE 1 — VERIFIER: You are a skeptical editor seeing this text for the first time who doesn't trust a single number. You never wrote this text. Write your questions like someone trying to catch the author in an inaccuracy.This isn't programming, it's a change of angle. The model starts generating questions in a different pattern: not as a continuation of the original text but as an outside audit.
2. DISC for checking prompts before you send them
The principle of verification through independent questions works not only for final answers but for the prompts themselves.
Check the following prompt before I put it to work.
PROMPT TO CHECK:
"""
{my_prompt}
"""
ROLE 1 — VERIFIER:
Ask 4 questions about specific instructions in the prompt:
- What result is expected?
- What counts as success?
- Are there contradictory instructions?
- What will the model do if it runs into ambiguity?
Answer each question on your own.
ROLE 2 — JUDGE:
Is there a concrete contradiction between the expected result
and the prompt's wording?
NO_ERROR — the prompt is clear, send it
ERROR — point to the specific ambiguity
ROLE 3 — EDITOR (only if ERROR):
Fix only the flagged spot.
Resources
Paper title: Denoising Iterative Self-Correction: Structured Verification Loops for Reliable LLM Reasoning
Authors: Shen Yin, David Ken, Joel Stremmel — Thomson Reuters Labs
Related work from the paper: - Chain-of-Verification (CoVe) — Dhuliawala et al., 2023 - Self-Refine — Madaan et al., 2023 - GPQA Diamond benchmark — Rein et al., 2023 - Critiques of self-correction — Huang et al., 2024; Kamoi et al., 2024