Prompt Structure

Context, requirements, constraints, acceptance. Each part blocks one kind of drift, and the symptom tells you which one you left out. Structure is information, not decoration.

"Say everything that matters" is too vague to act on. Break it into four parts and it becomes concrete: context, requirements, constraints, acceptance. Miss one, and it drifts exactly there. Prompt engineering is largely the work of arranging those four kinds of information well. prompt-eng-wiki

After reading, you should be able to answer:

• Which kind of drift does each of the four parts block, and what does its absence look like?
• What does the same sentence actually gain once all four parts are filled in?
• Why is writing prompts with headings and lists not a formatting preference?

Four parts, each blocking one kind of drift

Context — who the output is for, and where it will be used. Who the user is, where the product sits in the market, which screen this text appears on, what happened before. The writer carries all of that in their head, so it feels like shared ground and gets left out — which is exactly why it is the part most often skipped. But the model knows nothing about your corner of the world, and none of those unstated premises reach it. The cost of leaving it out: what you get back would hold true for any company, and is therefore useless to all of them.

Requirements — what exactly you want delivered. The verb is where vagueness creeps in. "Polish this sentence" gives it nothing to aim at; "cut it to 60 characters without dropping any of the three selling points" pins the range down at once. If the work takes more than one step, spell out the order. Skip this part and it picks whichever reading of your sentence seems most defensible — and the most defensible reading is usually the most widespread one, not necessarily yours.

Constraints — which approaches are off limits, and where the edges sit. Of the four, this one costs the fewest words, returns the most, and gets written the least. "If a parameter is uncertain, mark it pending rather than filling it in." "No internal system names in the reply." "No hedging words like 'roughly' or 'possibly.'" "Quote only the log I gave you." All of these belong here.

Why do negative statements punch so far above their weight? The space of options narrows step by step, and ruling out a whole region is far more efficient than sketching the target region bit by bit. One "don't write it as a bulleted mini-essay" can match three lines of "natural, flowing, sparing with lists." When this part is missing, it makes its own choices, and where evidence runs out it fills the gap with whatever looks most like the answer, in a tone indistinguishable from the truth.

Acceptance — what conditions must hold before the delivery counts as done. Reframe it as a question: who ends up holding this thing, and in what form is it consumed? Pasted into a document, entered into a spreadsheet, read by a program? Are any fields mandatory? Is a blank allowed? All of it is an acceptance criterion. Leave it out and two runs come back in different shapes, forcing a pile of branches downstream. Pinning the format down has its own techniques, but the precondition is still stating the standard in the prompt.

What the four look like together is easiest to see on one task written two ways.

The off-the-cuff version: "Pull the action items out of these meeting notes for me." The output reads fine; the problem is consistency — the grouping changes every time, and owner and deadline appear only now and then.

Now the version with all four parts filled in:

Context: a transcript of yesterday's product sync with our supplier, three people from each side, and the result goes to both project managers.

Requirements: list every action agreed in the meeting, each marked with which side owns it, the point in time it is pinned to, and what input from the other side it depends on.

Constraints: extract only actions that were explicitly agreed; options that were discussed and dropped must not appear; where no owner was named, write "unassigned" — do not infer one for us.

Acceptance: grouped by owning side, one line per action, fields in this order — action, owner, timing, dependency.

The second version is clearly longer, but every sentence pushes the range narrower, and none of it is padding. It is also directly reusable — swap the transcript for next month's and run it again. The official guides make the same point: the more explicit the requirements, the more stable the output. openai-prompt-eng

The "write unassigned, do not infer one" line deserves a note of its own. Without it, the model will often assign an owner to every action, reading complete while the name is actually invented. That is precisely what the constraints part blocks.

Sectioning tells it what changed here

So far the four parts have all been about content. But the same content laid out as one block, versus split into a few headed sections, performs differently by more than you would expect. The reason is not how it looks; it is whether it can be parsed accurately.

The reason lies in the material it saw during training. Of everything the model read, formatted text accounts for an enormous share: repository readmes, software manuals, community Q&A threads, encyclopedia entries. A few conventions got reinforced over and over: a hash sign starts a new section, a dash starts one of several parallel items, and text between triple backticks is preserved exactly as written. Among ways of marking boundaries with symbols, this notation belongs to the earliest batch standardized at scale. markdown-wiki

In other words, when it comes to structure, the model is far more at home with this notation than with any alternative. By splitting along it, you are using a set of marks it already knows to announce: the topic turns here, these items rank equally, this block is raw source material. Flatten it all into one paragraph instead, and every one of those announcements disappears, leaving it to infer — and the longer the prompt and the more it mixes, the higher the odds of inferring wrong.

Splitting has a second payoff, and that one is for whoever maintains it: once each of the four parts stands as its own section, any part can be swapped on its own. Adjusting constraints does not require reading the context; changing the context does not disturb acceptance. A single-block prompt, by contrast, means touching anything requires rereading the whole thing — and that is usually where a prompt loses its order.

In practice, four or five second-level headings are plenty. A skeleton you can take as is: role, task, material, constraints, output format. Four rules of thumb:

1. List constraints as items, not sentences. String three prohibitions into one sentence ("Don't do A, and also not B, and C is out too") and losing one is routine; split them into three separate items, each starting with a dash on its own line, and the odds of skipping a whole item drop sharply.
2. Give sequential steps to an ordered list. The numbered form itself already says that order matters.
3. Put the most important lines at the end. Attention thins out most in the middle, so scheduling constraints and output format for last lands them where it reads most carefully. That is also why the conventional arrangement runs context first, requirements in the middle, constraints and acceptance closing.
4. Fence off outside material and say it is not instructions. That one gets its own section next.

Outside material needs a fence, and a disclaimer

Retrieved passages, uploaded files, the previous turn's output — all of it is material. When it goes into the prompt, wrap it in conspicuous delimiters and state that the enclosed text is reference only and does not constitute instructions.

Why is that sentence mandatory? Because imperative sentences inside such material are entirely normal. A line in a product doc reading "enter your contact details here" may send an unfenced model off to ask you for your contact details. In the worse case it is prompt injection: the material came from a web page or a user, with an instruction buried inside telling it to discard everything it was told before. A fence plus a disclaimer stops the cruder style of attack. No amount of care stops all of them, because the line between instructions and data is simply not clear to it. anthropic-prompt-eng

Structure is a means, not a look

The boundary matters too: sections exist to separate unlike things, not to make the page look tidy. Two passages of the same nature need no split.

Every heading and marker costs tokens and is resent every turn; and once nesting passes two levels, its grasp of the hierarchy gets worse, not better. So do not stack five levels of tags around every sentence — past a point the return turns negative.

A cheap self-check: print the prompt and scan it yourself — can you say at once what each section governs? If you can see it at a glance, the model probably can too. If you have to puzzle over it, the structure is not doing its job.

The symptom points back at the missing part

What the four parts are really worth shows up when the output is wrong: instead of starting over, you localize the problem to one part. Read the symptom backwards:

1. A bland answer that would suit anyone — you are missing context. Add who the user is, what the product is, which screen it appears on.
2. The answer cuts along the wrong dimension, or covers only half — you are missing requirements. Make the verb concrete, and list the order for multi-step work.
3. It added what you never asked for, or invented numbers — you are missing constraints. Write a list of prohibitions, and say plainly that "not found" is an acceptable answer.
4. The content is right but your code cannot parse it — you are missing acceptance. Fix the item count, length, and fields, ideally with a format sample.

One case falls outside this list: mostly right, occasionally wild. That is unmanaged randomness, not a missing part, and the fixes live in the iteration method and sampling settings — a completely different problem, so do not tune them together.

Find the missing part, fill it in, then re-run the same sample set. The next move that reliably improves stability is giving it an example.