Underspecification Diagnostic

Layer 1 · Principles

• Generic output is the correct answer to an underspecified question. A generative model returns what minimises expected error across the distribution it was trained on. An unconstrained request has nothing narrowing that distribution, so the lowest-error answer is its centre. The model is not failing to try; it is succeeding at the question actually asked. Treating this as a defect sends you looking for a better tool, which is the one move that cannot help.
• The variable is what you withheld, not which model you picked. Two operators with the same tool produce wildly different output. If capability were the binding constraint, the spread between users would be small. It is not.
• Almost always one of three things is missing: your standard, your context, your reasoning. Standards are applied by reflex and so never written down. Context is invisible to you because it is ambient and invisible to the model because it was never in the data. Reasoning is rarest, because most people can state what they decided and very few can state how.
• Convergence ratchets, so the centre gets tighter over time. Generated output is published, re-enters training data, and pulls the middle of the distribution harder toward itself. The cost of not specifying rises rather than falls.
• Some questions cannot be specified into range, and that is not a prompting failure. Specification narrows toward an answer the distribution can reach. If the thing you want exists and is specifically yours, the model has never seen it and no prompt closes that gap. If it cannot be captured at all, generation is the best available route rather than a compromise, because nothing real is competing with it.

Layer 2 · Systematic Approach

Gate on whether specification is the right move, recover the three missing inputs in writing, then prove the file earns its place by comparison rather than by belief.

1. Gate: does the thing you want exist to be captured?. Three cases, three routes. Exists and looks like everyone else's: generate, and specification finishes the job. Exists and is specifically yours: capture it instead, because no prompt closes a gap in what the model was never shown. Cannot be captured at all: generation is the only route and the best case available. Only the first and third cases continue.
2. Pick the repeated task, not the interesting one. Choose a task you have run enough times to be right about. A task done twice yields a preference, not a standard.
3. Write the standard. What makes an output right or wrong, written so a competent stranger could apply it without asking you a question. The test is portability. 'Make it professional' fails, because two strangers would apply it differently. 'Every claim about the client's business traces to something they said on the intake call, and anything I inferred is marked as an inference' passes, because it can be checked.
4. Write the context. What is permanently true about your customer, constraint and market that the model has no route to. The three objections you always get. The regulator, the season, the price ceiling. Permanence is the filter.
5. Write the reasoning. Not what you decide, how you decide. The order you weigh things in, the tiebreaker, the condition under which you would do the opposite. Most people skip this layer, and it is what separates a style guide from a decision procedure.
6. Run the task twice and set the outputs side by side. Once cold, once with the file in front of the model. Do not judge the constrained run alone: an output read in isolation is judged against your memory of what you wanted, which is the thing you failed to write down.
7. Read the comparison as a diagnostic, not a result. Better means the file is real. Not better means the file describes something you have not actually decided, and that is the finding. Do not fix it by adding words; return to step 2.
8. Put reading the file into the run order. A specification nobody is required to consult reproduces the problem it was built to solve, quietly, because the file still exists and still looks like a control. The artifact is not the control; the requirement to read it is.

Layer 3 · Force Multipliers

• The file outlives the run A prompt improves one output and dies with it. A specification improves every future run without being rebuilt, so payback scales with how often the task recurs rather than with how well any single run went.
• It separates expensive thinking from cheap execution Once standard, context and reasoning exist as text, a cheaper engine can execute against them at comparable quality, because the judgment now lives in the artifact rather than in the engine.
• It is portable to people, not just models The same file that constrains a model onboards a contractor and settles an argument about what good looks like. Nothing about it is AI-specific, which is why it survives a change of tool.
• A bounded self-contained spec retrieves well It is about one thing and states its own conditions of use, so it comes back as a complete procedure rather than as paragraphs that happen to mention the topic.

Layer 4 · Success Metrics

Leading indicators

• The constrained run is visibly better than the cold run on first comparison, without argument about which is better.
• You can state the standard in a sentence a stranger could apply, with no adjectives doing load-bearing work.
• The reasoning layer contains at least one tiebreaker and one condition for doing the opposite.
• The file fits on roughly one page and you did not have to invent anything to fill it.

Lagging indicators

• The file is reused on the next run without being rebuilt or argued with.
• Someone other than the author produces an acceptable output from it unaided.
• Output quality stops depending on which model or which day.
• The file gets edited when the work changes, rather than every time it runs.

Failure modes

• Adjective standard
• Document creep
• Different but not better
• Silent drift
• The unread control

Layer 5 · Implementation

Required to start

• A generative output missed, and the task is one you repeat.
• You can run the same task twice in one sitting to produce the comparison.

Works best with

• You are about to switch models to fix a quality problem.
• You are about to hand a repeated task to another person or to an agent.

You are done when

• The file exists, the comparison favours it, and reading it is a step in the run order.
• A competent stranger produced an acceptable output from the file without asking a question.
• Or the comparison did not favour it, and you have correctly concluded the decision is not yet made.