Making it check its answer against the rules

Composing under constraint is harder than checking

You know from earlier that a list of eight requirements gets partly satisfied and quietly trimmed. The fix is not a firmer instruction. It is a second pass, because checking is a much easier task than composing.

When a model writes a product description while holding eight rules in mind, every token is a compromise between fluency and compliance. When it reads a finished description and asks “does this contain the SKU?”, that is a simple lookup with a yes or no answer.

So split the two.

The pattern

Step 1. Write the description.
Step 2. Then output a checklist: for each of the eight rules,
        state PASS or FAIL and quote the words that decide it.
Step 3. If any rule is FAIL, output a corrected version.

Three things make this work rather than being ceremony.

Quote the deciding words. Without that, you get a column of PASS that means nothing, since a model asked whether it complied is being asked a leading question. With a quote, you can check the check.

Rules must be mechanically decidable. “Under 120 words”, “contains the SKU”, “does not use the word quality”, “ends with a question”. Not “engaging”, not “on brand”. A rule the model cannot apply reliably produces a confident PASS and teaches you to distrust the whole checklist.

Correction is a separate step. Asking it to fix and re-check in one breath tends to produce a claim of correction rather than a correction.

Where this is worth the tokens

Anything with hard requirements: legal wording that must appear, a character limit, a required disclaimer, an accessibility rule, a format another system will parse.

Anything going out at volume. A hundred product descriptions where two break a rule is a real problem, and reading a hundred descriptions is not going to happen. Reading a hundred checklists filtered to FAIL rows takes two minutes.

Anything where the requirements came from somebody else. A client brief, a regulator, a house style guide. The checklist becomes the evidence you complied.

The self-check’s blind spot

It catches violations of rules you wrote down. It does not catch anything you did not think to write down, and it does not catch a factual error, because a factual error is not visible from inside the text.

That is worth stating plainly, because a green checklist is persuasive out of proportion to what it establishes. Eight PASS rows tell you eight things were checked. They tell you nothing about the ninth thing you never listed, and nothing about whether the figures are right.

Independent checking is stronger

The strongest version does not tell the checker what was intended:

Below is a product description. Check it against the rules that follow. Do not assume it was written to satisfy them.

Better still, run the check in a fresh conversation. In the same conversation the draft is in the context, along with the effort that produced it, and there is a documented pull towards consistency with what has already been said. A clean context has no such attachment.

For anything consequential, this is the version to use: draft in one place, check in another, with only the artefact and the rules crossing between them.

The everyday version

Most of the time you do not need the full apparatus. One line at the end of a prompt does most of the work:

After the answer, list any of my instructions you did not fully satisfy, and why.

Models will often tell you, honestly, that they dropped the word limit or could not find a figure. It is not reliable, and it is free, and the answer is frequently more useful than the output it accompanies.

Writing rules that can be checked

Since the whole technique depends on decidable rules, it is worth knowing how to convert the undecidable ones. Take each vague requirement and ask what you would look at to settle it.

• Professional tone → no exclamation marks, no contractions, no first names in the opening line.
• On brand → uses the product name in full at first mention, never abbreviates it afterwards, does not compare us to a named competitor.
• Accessible → no sentence over 25 words, every acronym expanded at first use, no colour-only references.

None of those is the whole of what you meant. Each is a testable proxy for part of it, and three testable proxies enforce more than one unenforceable adjective.