How do you know a definition actually landed? Grade it with a second model.
You can measure whether a definition landed instead of trusting that it read well. Point a second model at the spec and grade what comes back. Here are four checks I used while grounding a vocabulary for an AI assistant. Each costs minutes. Each caught something a re-read would have missed.
Grade the definition with a fresh model
The core check is blind. I had written down what each term means. The real question was different: does that meaning reach a reader?
So I ran two fresh contexts. The first model reads only the spec, none of my intent. It defines each term, including what the term does not mean. The second scores that definition against the register, also blind. Neither carries my intent into the judgment.
The output is a number, not a feeling. In my last run, 43 of 44 definitions landed — a 98 percent baseline. The one miss told me exactly which term to rework. “Looks clear to me” would have told me nothing.
The blindness is the point. I wrote the definitions, so I read them the way I meant them. A grader who has seen my intent grades the intent, not the text. Strip the intent and you test the words on the page. That gap between what I meant and what the page says is where meaning goes missing.
Let an adversarial pass check your own reasoning
The second habit is adversarial. After drafting the design, I ran a deliberately critical honesty pass over my own claims.
It caught a confirmation bias I had written in. An early draft credited the fix to the wrong rule. I claimed the win came from a “scope never shrinks” rule. The rule that actually worked was different: deferring the rest of the work is the user’s decision, not the model’s default. I had pattern-matched to the tidier story.
The pass caught this before it hardened into normative text. A wrong reason in a spec teaches the wrong lesson to every future reader.
A deterministic task list is also a collision detector
The third habit looked like bookkeeping and turned out to be a safety net. Before writing any spec text, I listed every file the change would touch.
That list overlapped with a second rebuild running in parallel. The collision was visible on paper before a single line was written. Without the list, the two efforts would have written over each other. A vague plan hides that. A concrete file list surfaces it.
Audit against the original words, not the plan
The last check compares the result to the first instruction, not to a summary of it.
An audit against my original request caught a real error: the whole build had been authored in the wrong container. Every intermediate summary had passed, each describing the plan faithfully. None noticed the plan itself had drifted from what I first asked for. Only the original words caught it. Left alone, the next sync would have deleted the work.
The math is simple
Each of these checks costs minutes. The first uses two throwaway model runs. The second is one critical read. The third is a list you were half-writing anyway. The fourth is a diff against your own first message.
Rework costs days. A wrong definition ships, teaches the wrong thing, and gets copied. A collision overwrites finished work. A build in the wrong place gets silently deleted later.
Verification is cheaper than rework. That is truer with LLM work than almost anywhere else, because “sounds right” and “is right” come apart so easily. Pick one of the four checks and run it on your next spec change. The blind grade is the one I would start with.