2.4 Ordering matters: instructions first, data last

The default order that works

1. Role                (who you are)
2. Task                (what to do)
3. Rules / constraints (what NOT to do)
4. Examples            (few-shot demonstrations, if any)
5. Format              (how to shape the output)
6. Data                (the thing to operate on) — LAST

The reasoning: instructions come first because the model needs to know what game it’s playing before it sees the ball. Data comes last because it’s what the model is generating from — its response follows immediately after, so relevant data is freshest.

Why data-last works

Contrast two prompts asking the model to classify a movie review:

Data-first (weaker):

"The film was watchable but the acting was forgettable and I would
not see it again."

Classify the above review as positive, negative, or neutral.

Data-last (stronger):

Classify the movie review below as positive, negative, or neutral.
Return only the label.

Review:
"The film was watchable but the acting was forgettable and I would
not see it again."

In the first, the model reads the review with no task in mind, then only finds out the task at the end — and its response follows immediately, giving little time to re-read the review through the task lens. In the second, the model reads the task first, then reads the review already knowing what it’s looking for.

For short prompts the difference is small. For long ones (a full transcript, a big document), it can be the difference between a right answer and a wrong one.

The one exception: chat continuations

In a chat conversation, the past turns are the data, and the newest user message is both the instruction and the freshest content. That’s fine — chat interfaces put the newest turn last automatically. What you’re controlling with ordering is the structure within a single prompt.

The “lost in the middle” problem

For long prompts, both ends of the context window get more attention than the middle. If a prompt has:

[system]
[task instructions]
[huge block of retrieved documents]
[the specific question at the end]

…the specific question at the very end may work better than the same question buried between the task and the documents. When a prompt gets long, restate the actual ask near the bottom, right before the model has to answer.

The reorder-first debugging move

When a prompt is producing bad output, before you rewrite anything, try just reordering the pieces:

• Move the task to the top.
• Move the data to the bottom.
• If the data is huge, restate the task once more right after the data.

Reordering is free — no new tokens, no rewrites — and it fixes a surprising fraction of “why is the model ignoring my instruction?” bugs.

Check your understanding

Quick check

—

You are extracting fields from a 12-page legal document. Which prompt structure is most likely to give reliable extraction?

1. APaste the 12 pages first, then write the extraction task at the end.
2. BWrite the task and fields at the top, paste the 12 pages, then restate the extraction request at the very bottom.
3. CInterleave the task with each page — one paragraph of instruction per page.
4. DWrap the whole 12 pages in the task sentence and hope for the best.

Check answer→