How to Make AI Follow Acceptance Criteria
The output reads well and answers the question, so you almost ship it — then you notice it broke a rule you cared about and skipped a section you needed. "Looks good" was never the test. Here's how to give AI the acceptance criteria up front and check the output against them before you rely on it.
Add Success Criteria to Your PromptWhen the output looks done but isn't
You ask the AI to draft a reply to a customer who wants to cancel after renewal. It comes back fluent, calm, and confident — "You can cancel anytime with 30 days' notice, and we'll help with a refund request" — and you're a click from sending it. Then you check it against what your policy actually requires: cancellation needs 30 days' notice *before* the renewal date, not anytime; refunds after renewal are reviewed case by case, not something you promise help with; and there's no next step for the customer to take. The model answered the question. It didn't meet the requirements — and it never could have, because you didn't tell it what they were. "Looks good" is not the same test as "meets the criteria," and the model was running the first one.
That's the gap this guide closes. Handing a model a task without stating what a good result must contain, avoid, and clear leaves the definition of done up to the model — and its idea of done is "a fluent, on-topic answer." The fix is to write the acceptance criteria explicitly, hand them to the model alongside the task, and check the output against them before you trust it. Doing that makes the output reviewable — you can point to exactly which requirement it missed. It does not make the output correct: a passing check isn't a guarantee, and the final call on whether the work is acceptable stays with you.
Why "done" means something different to the AI
You and the model don't share a definition of done, and nothing in a bare task request closes that gap. You mean "meets these specific requirements"; the model, with no requirements in front of it, means "produced something plausible and on-topic." Left to fill in the rest, it optimizes for the answer that looks finished, and that's where the requirements you cared about quietly fall out:
- It fills the obvious shape of the ask. The request implies a rough form, the model matches that form, and the constraints you never wrote down aren't part of the target.
- A rule it never saw can't be followed. "Don't say cancel anytime" only binds the model if it's in the prompt — an unstated must-not is just a phrasing the model is free to reach for.
- The quality bar lives in your head. "Good enough to send" is a standard you can feel but the model can't see, so it settles for good enough to look sent.
- Unnamed edge cases get a confident default. If you don't say what to do when the policy is unclear, the model won't flag it — it'll pick an answer and state it plainly.
- "Looks good" and "meets the criteria" are different checks, and the model only runs the first one on its own.
Step 1: Write the acceptance criteria as a separate, testable list
Pull the criteria out of the task description and write them as their own list — and make every one testable. A testable criterion is a statement you could hold the output against and get a yes or no; an adjective isn't. "Comprehensive" fails that test; "a new hire can finish day one without hitting a question the guide doesn't answer" passes it. If you can't check it, the model can't aim at it.
The Add Success Criteria to a Prompt resource is built around exactly this discipline — turning "make it good" into a definition of done, on the rule that a success criterion is "a sentence you could evaluate the output against." Cover the four kinds that catch real failures: the must-haves (what has to be present), the must-nots (what it can't do or say), the quality bar (what "good enough" concretely means), and the edge cases (what to do when something's missing or unclear). Writing them as "Given [situation], when [the task runs], then [the output does X]" is one reliable way to keep each one checkable, paired with an explicit out-of-scope line so the must-nots are as clear as the must-haves.
Step 2: Hand the model the task and the criteria together
Criteria only help if the model sees them before it starts. Put them in the prompt beside the task so the model works toward them from the first draft, instead of you discovering the misses afterward and correcting them one message at a time. The Agent Task Template resource is one such prompt already assembled: a task with a dedicated success-criteria block ("you are done when these are met"), a separate constraints block for the must-nots, a slot for the required output form, and an instruction for the model to report its result against the criteria when it finishes.
When it's the same kind of task over and over — every support reply, every release note — you don't want to paste the criteria each time. The System Prompt Generator turns them into standing rules: a must-do list and a hard must-not-do list that govern every response in the conversation, so the criteria are always in force. Baking the rules in makes the model far more likely to follow them; it doesn't force compliance or check that a given output actually met them — that's still a step you run, not a guarantee the setup provides.
Step 3: Have the model self-check — but don't mistake it for verification
Before the model hands over the answer, have it walk its own output against the criteria and mark each one met, missed, or needs-revision. It's cheap and it catches the obvious slips — the dropped section, the forbidden phrase that snuck in — without a round-trip to you. So it's worth asking for on every non-trivial task.
But be exact about what it is. A model checking its own work is self-assessment, not verification: it can miss the same thing on the check that it missed while writing, and it has a standing incentive to declare itself done. A self-reported "all criteria met" is evidence you weigh, not a gate you can trust on its own. When the output actually matters, the real check has to come from outside the model that wrote it — you read it against the criteria yourself, a test exercises it, or a fresh reviewer (a person, or a separate model with no stake in the answer) evaluates it cold. The self-check narrows what you have to look at; it doesn't remove the looking.
Step 4: Turn the failures into a revision list, then re-check
A verdict of "needs revision" is only useful if it says which criterion failed and how to fix it. Ask for the review as an itemized list — the criterion, the pass/fail, and the specific change that would flip it — and feed the failures back as a targeted repair instead of regenerating the whole thing, which tends to lose the parts that already passed. The Agent Evaluation Scorecard Prompt is a worked example of that review shape: a verdict per dimension, a pass/fail against a threshold you set, the single most important issue holding the result down, and a re-score after the fix. Its dimensions ship as a generic rubric — you swap them for your own acceptance criteria so it's checking against your definition of done, not a stock one.
Then re-check the revision against the full list, not just the line you fixed. A repair aimed at one criterion can quietly break another that was passing — a tightened word count that drops the next step, a softened tone that loses a required phrase — so a fix isn't done until the whole checklist passes again. That loop, run a couple of times, is usually what turns a first draft that looked finished into one that actually meets the bar.
Step 5: Separate the structural check from the acceptance decision
Some criteria are structural — the required sections are present, the format is valid, the labels come from the allowed set — and those a tool can check deterministically. The AI Output Validator does that in your browser: paste the output and the expected structure and it confirms the shape parses and nothing required is missing, which covers the output-form slice of a definition of done without a model in the loop.
That's also exactly where it stops. It checks structure, not meaning: it can confirm your reply has a "next step" heading, but not that the step is right; it can't tell whether the draft avoided the forbidden phrase, hit the tone, or actually answered what was asked, and it can't tell you a pass/fail judgment is correct. The semantic half of acceptance — does this meet what I actually asked for — is a human read, and the final approval is a human decision. A validator confirms the box exists; whether what's in the box is acceptable is still your call to make.
Common mistakes
A few habits leave "done" undefined and let a not-quite output through:
- Leaving the definition of done to the model. With no criteria in the prompt, "done" means whatever looked finished to the model — which is rarely what you meant.
- Writing criteria as adjectives. "High-quality," "professional," and "thorough" aren't checkable; rewrite each as something you could hold the output against and get a yes or no.
- Only specifying the format. Required sections matter, but outputs usually fail on the must-nots and the quality bar — the parts a format check never sees.
- Leaving the must-nots unsaid. A rule the model never received can't be broken on purpose or kept — name the forbidden moves as plainly as the required ones.
- Taking the self-check as a pass. The model grading its own work can pass its own error; treat its verdict as input to your decision, not the decision.
- Regenerating instead of repairing. A fresh draft can drop what already passed — feed back the specific failures and re-check the whole list.
A worked example: a customer support reply
Say you're drafting a support reply and you write the acceptance criteria first. Here's the task with its definition of done, an output that reads fine but fails the criteria, the self-check that catches it, and the revision that passes.
The same task: an output that looks fine but fails the criteria, checked and revisedTASK:
Reply to a customer asking whether they can cancel after renewal.
ACCEPTANCE CRITERIA (the definition of done):
[must] states 30 days' written notice BEFORE the renewal date
[must-not] says "cancel anytime"
[must] says refunds after renewal are reviewed case by case, not promised
[must] gives the customer a next step
[quality] clear and calm, not legalistic; under 120 words
[edge] if the policy is unclear, say it needs review
FIRST OUTPUT (reads fine, fails the criteria):
"You can cancel anytime with 30 days' notice, and we'll help with a
refund request."
self-check against the criteria:
- notice BEFORE renewal MISS (says "anytime")
- "cancel anytime" FAIL (forbidden phrase used)
- refunds reviewed case by case MISS (implies help / eligibility)
- next step MISS
=> NEEDS REVISION
REVISED OUTPUT (passes):
"To cancel, we need 30 days' written notice before your renewal date —
send that to support@example.com and we'll confirm it. Refunds after
renewal are reviewed case by case, so I can't promise one here, but I've
flagged yours for review." (before renewal, no "anytime", case-by-case,
next step, no guarantee, under 120 words)Where this fits in NewPrompt
No workflow or project on NewPrompt owns acceptance criteria, and that's deliberate — this isn't a build stage you arrive at but a discipline you carry into whatever you hand a model, whether that's a support reply, an SEO brief, or a project plan. So the loop lives in separate parts rather than one page: you write the definition of done, carry it into the prompt beside the task, freeze it into standing rules for the work you repeat, turn the misses into an itemized revision list, and let a tool settle the structural slice a machine can check on its own — the pieces this guide walked through. Tighter, object-specific versions of the same define-then-check loop exist too, for grading an AI agent's behavior or scoping a product's requirements, but the bare version here fits anything. What none of these parts do is close the loop: a self-check is the model marking its own paper, a validator only ever sees shape, and the judgment that the work clears the bar — and that it's cleared to go out — belongs to whoever wrote the criteria.