Tell the model how to know it succeeded

Modern models check their own work. Before answering, they weigh what they have produced against what was asked — and if it falls short, they revise.

That self-check is only as good as the bar you gave them. With no bar, there is nothing to check against, and the review step quietly does nothing.

Write a 600-word blog post in markdown for beginners about database indexing. Include an example of a slow query.

This prompt tells the model what to make. It never tells it what would make the result wrong. So the model will produce something plausible, look at it, find nothing to compare it against, and hand it over.

Criteria are not the same as instructions

An instruction says what to do. A criterion says how to tell whether it worked. They are not interchangeable, and most prompts contain only the first.

• Instruction: "Write a blog post about indexing."
• Criterion: "A reader who has never created an index should be able to create one after reading this."

The second one changes the output, because it is checkable. The model can hold the draft up against it and notice that it never actually shows the CREATE INDEX statement.

The most useful criteria are usually about what to leave out — because that is the decision models get wrong most often, and it is the decision you are least likely to have stated.

Write a launch post announcing Acme Sync.

### Audience
Frontend developers at small startups who have lost work to version mismatches.

### Context
Acme Sync keeps Figma files and production code in step. Nobody in the audience has heard of it.

### Requirements
- Length: About 600 words.
- Output format: Markdown, with a heading per section.
- Avoid: marketing superlatives.

### Example of the wanted output
## Title
Opening line naming the specific pain.

"Avoid: marketing superlatives" is doing more work than it looks. It is not a stylistic preference — it is a test. The model can scan its own draft for superlatives and remove them. "Make it sound authentic" cannot be tested, which is why it does nothing.

What to write

Pick from these; two or three is plenty.

What must be present. "Every claim must cite a line number from the log." "The answer must include the exact command to run."

What must be absent. "No preamble." "Do not mention competitors." "No superlatives." This is the highest-yield category.

What would make it wrong. "If the transcript does not say, write 'not stated' rather than inferring." This one is enormously valuable and almost nobody writes it — it is the instruction that prevents confident fabrication.

Where the line is. "Report anything that could cause incorrect behaviour; omit pure style preferences."

The failure this prevents

Without criteria, you get output that is defensible rather than right. Nothing in it is wrong. It just is not what you needed, and you cannot point to the instruction it violated — because there wasn't one.

Then you regenerate, with a slightly different phrasing, and get a slightly different defensible answer. Three rounds later you have spent more time than it would have taken to write down what "good" meant in the first place.

The shortcut

Ask yourself one question before you send the prompt: if this comes back and I am unhappy with it, what will the complaint be?

Whatever you just imagined yourself saying — "it's too long", "it's too salesy", "it made things up", "it buried the answer" — write it into the prompt as a constraint. You have just converted a future complaint into a present instruction, and that is the whole of the technique.

Every check in this article ran live in your browser. The same nine run on any prompt you paste in, for free.