A mockup of a generated surface is one sample from a distribution, presented as if it were the decision. Useful for aligning a room. Useless as a specification, because the thing that ships is a thousand states and the mockup covered the one where retrieval worked and the account had data in it.
What you write instead is three columns.
Best case is the target. What a great output looks like when everything is available and clean.
Worst acceptable is the floor. Below it, do not ship. This column does more work than the other two combined, because it is the only thing that turns good enough into a decision instead of a mood. Without it, good enough is whatever the most senior person felt about the last five examples they saw.
Refuses to is a hard line. The product declines rather than degrades.
A worked example, a support-reply drafter inside an agent console. Best case: the draft answers the customer's actual question in three sentences, cites the policy article it drew from, matches the tone of the last five replies this agent sent, and needs no edit before sending. Worst acceptable: factually correct, cites its source, reads generic, needs light editing, sent after under thirty seconds of work. Refuses to: draft anything containing a commitment about refunds, dates, legal outcomes, or account access, which return an empty draft and a pointer to the human process.
That refusal column is not a claim that the model is bad at refunds. It is a judgment that a confident wrong answer about a refund is expensive enough that shipping nothing is better.
Then the sentence that makes the whole thing worth writing.
Everything between the second and third columns is allowed and does not need your review. A specified range is permission. It tells the team how far they can go without asking, which is the only way work moves at generation speed rather than at the speed of one person's calendar.
Four rules for the cells. Write the worst acceptable column first. Write what the user sees, not what the system does, so "retrieval returns three documents" is not a cell and "an answer with two cited sources, both opened from the answer in one click" is. Make refusal a category rather than a topic. And keep probabilities out: correct ninety percent of the time is a model target and says nothing about the other ten percent.
Four states almost every first draft is missing. Nothing to work with, meaning empty account or first run, where the right call is sometimes that the feature should not appear yet. Partial input, meaning half the fields or a truncated document. Conflicting sources, where two documents disagree and the product has to pick, present both, or decline, and where products most often invent a confident synthesis nobody asked for. And the long tail language or format nobody tested, where the choice is refuse, degrade, or attempt.
The test that tells you whether the range is specified or merely written is the sorting test. Pull ten real outputs, from a prototype or from production, not ones you composed to make a point. Have two people independently sort them into four piles: best case, acceptable, below the floor, should have been refused. Compare.
Agreement on eight or more means the range is doing its job. Below that, the disagreement will not be spread evenly. It clusters at exactly one boundary, and that boundary is the column to rewrite before sorting again. Run it before launch and once a quarter after, because the boundaries move as the model and the product change.
One thing to do this week: fill in the refusal column only, for the feature you are working on right now, and send it to your PM and engineering lead. If anyone is surprised by a line on it, that is the most important conversation of your week, and it was going to happen eventually with a customer instead.
The three-column template with the sorting test, the four forgotten states, and the worked example is The Range Spec. The full argument is You Cannot Mock a Distribution.