What a prompt is

The four parts

A prompt is usually described as “what you type”. That framing hides the structure that makes one reliable and another a lottery. Every prompt that works has four parts: an instruction saying what to do, context the model needs, the input to act on, and a contract describing what the answer should look like.

When an answer disappoints, one of those four is usually missing. The model guessed the format, or invented context, or answered a slightly different question because the instruction was a topic rather than a task.

Mechanically, the model receives one string and produces one continuation. Every dimension you leave open — length, register, format, what counts as relevant — is filled from the distribution of text it was trained on. That is not randomness; it is an average, and the average is usually longer and more cautious than a product needs. The four parts work because each one closes a dimension before generation starts.

Instruction is a verb

“Refunds” is a topic. “Summarise the refund policy in three sentences for a customer” is an instruction. The difference is a verb, an object and a constraint — the three things a model needs before it can do anything specific.

A useful test: could a new colleague follow the instruction without asking a question? If not, the model is guessing too, and it will guess differently on Tuesday.

The four parts, labelled

PROMPT = """You are a support assistant.          # role
Summarise the policy in three sentences. # instruction
Use only the text between the markers.    # constraint

<policy>
{policy}
</policy>

Return plain text. No headings, no bullets. # output contract
"""

One request, four blocks

Take a request that arrives as “the customer wants to know about refunds”. The instruction is “answer the customer’s question about refunds”. The context is the refund policy and the customer’s plan. The input is the question itself. The contract is “at most three sentences, plain text, cite the policy section”. Written as one sentence, the same request leaves the model to decide whether it is writing a policy summary, an email, or an internal note — and it will pick one silently.

The symptom of a missing block is easy to recognise once you look for it: the answer is plausible but shaped for someone else. A reply that reads like documentation when you wanted a customer email usually means the audience was never stated. A reply that runs to five paragraphs when you asked for a summary usually means the length was never stated. Fix the missing block, not the wording of the instruction.

The contract is not decoration

The output contract is what makes a reply usable by code. “Answer in JSON with keys sentiment and confidence” is a contract; “reply in JSON” is a hope. If a parser runs afterwards, the contract and the parser are the same requirement written twice.

Contracts should be checkable. A length limit, a set of allowed labels, a required citation — each can be verified mechanically, which is what turns a prompt into something testable.

Write the contract in the same words the parser uses. If the parser expects a key called sentiment, the prompt should name that key rather than “a sentiment field”; if the parser rejects a trailing sentence, the prompt should say “return the object and nothing else”. When the two drift, the failure looks like a model problem but is a specification problem, and the fix belongs in the prompt.

Context is not the same as input

The input is what the task is about — the sentence to classify, the question to answer. Context is what the model needs to do it correctly: a policy, a schema, a previous turn. Mixing them is how a document ends up being summarised instead of used as reference.

Keep context in its own delimited block and say what it is for. That single habit removes a large share of “the model ignored my instructions” reports, because the instructions are no longer buried inside a wall of text.