Module 02 · Reasoning Patterns
Self-Critique Loops: Making the Model Check Its Own Work
Open lesson + course map
On this lesson
Course outline
Module 1 · Structural Prompt Frameworks
Module 2 · Reasoning Patterns
Module 3 · Few-Shot and Example-Driven Prompting
Module 4 · Reusable Instruction Systems
A self-critique loop is a three-turn workflow: generate a draft, inspect it against a fixed rubric, then revise only the defects the inspection identified. It makes review visible and repeatable instead of hoping that “make it better” will improve the right things.
By the end, you will have a reusable loop for reviewing client-update emails. You can adapt the same pattern to reports, product copy, proposals, or study notes, while keeping factual verification with a human.
// concept
Build a Fixed Generate-Critique-Revise Loop
The three turns have different jobs. Turn 1 creates. Turn 2 diagnoses without rewriting. Turn 3 repairs only named defects. Separating them prevents a critique from replacing the draft and introducing new errors.
| Turn | Model’s job | Saved output |
|---|---|---|
| Generate | Draft from supplied facts and constraints | Draft v1 |
| Critique | Test v1 against the same five criteria | Defect list with quoted evidence |
| Revise | Fix accepted defect IDs and preserve everything else | Draft v2 plus change log |
A weak instruction hides the target:
BAD prompt: Make this email much better and double-check everything.
“Better” could mean shorter, warmer, more formal, or more persuasive. “Double-check everything” also implies access to evidence the model may not have.
Use this bounded GOOD prompt instead. It is Turn 1 of the reusable loop:
You are drafting a client project-update email.
Use only the facts inside <facts>. Do not add dates, causes, commitments,
prices, or completed work. If an essential fact is missing, insert [NEEDS INPUT].
Audience: a UK-based client who prefers direct, professional English.
Required content:
1. current status;
2. blocker and its effect;
3. next action and owner;
4. one clear client decision, if needed.
Constraints: 120-170 words; descriptive subject line; no blame; no hype;
no claim that an unconfirmed date is final.
<facts>
Project: product-catalog cleanup
Completed: 42 sample product records reviewed
Finding: 9 records lack an approved category
Next action: Sana will send the 9 record IDs
Client input needed: approve a category or mark each record out of scope
Date mentioned in notes: 18 August, not independently confirmed
</facts>
Return only: Subject, then email body.Redact unnecessary private client data before pasting. Ask for an inspectable table of criteria, excerpts, defects, and repairs—not hidden internal reasoning.
// concept
Make the Critique Cite the Defect
A critique is actionable when it names the rule, quotes the failed text, and proposes a narrow repair. Use one rubric for every version:
| Criterion | Pass condition | Hard gate? |
|---|---|---|
| Evidence fidelity | Every factual statement appears in <facts> or is marked [NEEDS INPUT] | Yes |
| Task coverage | Status, blocker, next action, and decision are present | Yes |
| Audience and tone | Direct professional English; no blame or inflated certainty | No |
| Actionability | Owner and requested decision are unambiguous | Yes |
| Format | Subject plus 120–170-word body | No |
This is Turn 2. It asks for observable defects, not a private thought process:
Act as a strict reviewer, not a rewriter. Evaluate <draft> only against
the fixed rubric below.
RUBRIC
1. Evidence fidelity: every factual statement is supplied in <facts> or
marked [NEEDS INPUT].
2. Task coverage: status, blocker, next action, and client decision appear.
3. Audience and tone: direct professional English, no blame, no hype,
no false certainty.
4. Actionability: every requested action has a clear owner.
5. Format: subject line plus a 120-170-word body.
For each failed criterion, return one row with:
DEFECT ID | CRITERION | EXACT QUOTE | WHY IT FAILS | MINIMAL REPAIR
Rules:
- Do not rewrite the draft.
- Do not infer missing facts.
- Do not claim that a date, policy, price, or external fact is true merely
because it appears in the supplied material.
- If no defect is visible, return NO VISIBLE DEFECTS.
<facts>
[paste the identical facts used in Turn 1]
</facts>
<draft>
[paste Draft v1 unchanged]
</draft>The exact quote matters: “tone could improve” is vague; quoting “We guarantee completion on 18 August” identifies the unsupported certainty.
// concept
Revise Named Defects, Then Stop
Turn 3 receives the original facts, Draft v1, and only the defects you accept. It must not start another unlimited review.
Revise <draft> by applying only the accepted defects in <defects>.
Preserve all other meaning. Use only <facts>; do not add new facts.
After the revised email, return a CHANGE LOG with one line per defect ID:
ID -> exact change made.
Stop after one revised version. Do not continue critiquing or revising.
<facts>
[paste the identical facts used in Turn 1]
</facts>
<draft>
[paste Draft v1 unchanged]
</draft>
<defects>
[paste accepted defect rows from Turn 2]
</defects>Stop when all hard gates pass, remaining comments are preferences, and v2 has no new unsupported claim. Cap repairs at two rounds; then a human decides whether the rubric, inputs, or draft need manual work. Never loop until the model announces perfection.
// worked_example
Worked Example
Subject: Catalog cleanup on track for 18 August
We reviewed 42 sample product records and found 9 without an approved category. Sana will send those record IDs. Please approve a category or confirm which records are out of scope. We guarantee completion on 18 August once we receive your reply.
The critique returns two useful rows:
| Defect ID | Criterion | Exact quote | Why it fails | Minimal repair |
|---|---|---|---|---|
| D1 | Evidence fidelity | “on track for 18 August” | The notes contain the date, but it is not confirmed | Say the date is awaiting confirmation |
| D2 | Audience and tone | “We guarantee completion” | The facts do not support a guarantee | Remove the guarantee and state the dependency |
Turn 3 produces this repaired excerpt:
Subject: Decision needed on 9 catalog categories
We reviewed 42 sample product records and found 9 without an approved category. Sana will send the 9 record IDs. Please approve a category for each record or confirm which records are out of scope. The 18 August date in our notes remains unconfirmed; we will confirm timing after receiving your decision.
The loop caught the unsupported guarantee. It did not prove that “42 records,” “9 records,” or “18 August” are correct; it checked only consistency with supplied facts. A typo could survive every turn. A human must compare the counts with the project sheet and confirm the date before sending.
// failure_cases
Failure Cases to Diagnose
6 cases to diagnose
The rubric changes after seeing v1.
A reviewer invents new preferences to justify endless edits. Freeze the criteria before generation; revise the rubric only as a recorded new test version.
The critique says “looks good” without evidence.
Require exact quotes for failures and
NO VISIBLE DEFECTSwhen none are found.The critic rewrites the entire email.
Diagnosis and repair become impossible to audit. Add “reviewer, not rewriter” and reject any response without defect rows.
The revision fixes uncited issues.
Compare v1 and v2; revert changes that do not map to an accepted defect ID.
The model validates its own source pack.
Consistency is mistaken for truth. Check counts, dates, policies, quotations, and prices against the original human-controlled source.
The loop never stops.
New wording triggers new stylistic complaints. Use hard gates, a two-round cap, and a human decision.
// pakistan_angle
Pakistan Angle
Pakistani freelancers often send client updates through WhatsApp first and email second. Build one English rubric, but test the real destination: a long paragraph that works in email may be unreadable on WhatsApp. For a local client, add a criterion for agreed English/Roman-Urdu register, but do not let the model silently change commercial terms such as PKR price, advance amount, delivery date, or revision count.
Load-shedding and unstable mobile data can interrupt a chat session. Save the facts, rubric, v1, defect table, and v2 in one local Markdown file so the review survives a dropped connection. Remove CNIC numbers, personal phone numbers, bank details, and unneeded client records before using a hosted AI service; placeholders such as [CLIENT_PHONE] preserve structure without exposing the data.
// hands_on
Hands-On Exercise
7 steps
Build a reusable three-turn critique loop for one real, low-risk client-update email:
Copy the five-criterion rubric and adjust only its pass conditions for your email type.
Create a redacted
<facts>block containing status, blocker, next action, owner, and any uncertainty.Run Turn 1 and save the response as
client-update-v1.md.Run Turn 2 in a new message. Accept or reject each defect row yourself.
Run Turn 3 with accepted defects, then compare v1 and v2 line by line.
Verify every count, date, commitment, and commercial term against your source outside the model.
Record whether the hard gates passed and stop after no more than two repair rounds. Done means your file contains the three complete prompts, one sample input, v1, the cited defect table, v2, a change log, and a human fact-check note.
// completion_rubric
Completion Rubric
5 checks — tick as you verify
// sources
Sources
3 official sources — check every claim yourself
// check_yourself
Check yourself
4 questions · answers and options are taken word-for-word from this course
1 / 4 · diagnose
Your work shows this failure mode: “The rubric changes after seeing v1.” The lesson describes it like this: “A reviewer invents new preferences to justify endless edits.” What does the lesson tell you to do about it?