What You Need to Know
A system prompt holds what applies to every request: role, audience, standing policy and output contract. It is a contract, not a greeting. User turns carry each request's own data. A template is a prompt with named variable slots. A guardrail limits what the model receives or returns.
A funeral director's online assistant answers families from its price list. Its standing rules sit in the system prompt; each family's question is a user turn.
The System Prompt as an Architectural Contract
System-prompt policy has stable authority: the model treats it as policy, not one more conversational message. Setting a role there focuses Claude's behaviour and tone, says Anthropic. Prompt caching (objective 2.5) can reuse a stable system-level prefix. Policy restated differently in every user turn drifts per developer, behaves less consistently and pays full input price on each request.
Anthropic's context engineering guidance adds an altitude rule. Effective system prompts sit between two failure modes: hardcoded brittle logic and vague high-level guidance. They are "specific enough to guide behavior effectively, yet flexible enough to provide the model with strong heuristics".
Explicit Instructions and the Escape Hatch
Claude follows clear, direct, specific instructions literally, and obeys vague ones with confident variance. Anthropic's golden rule: if a colleague with minimal context would be confused by the prompt, Claude will be too. State precisely:
- the role
- the audience
- the rules
- what to do when rules conflict
- the output format
Giving the motivation ("this will be read aloud by a text-to-speech engine, so never use ellipses") helps the model generalise correctly.
An escape hatch defines what to do when a task cannot be done honestly. Return null when the document lacks the field. Answer "I don't have enough information" when the sources do not cover the question. Without one, the output contract forces invention. For an unlisted service, the assistant returns the not-enough-information answer.
Anthropic's hallucination guidance says permission to admit uncertainty "can drastically reduce false information", and pairs it with grounding:
- extract word-for-word quotes before analysing long documents
- cite sources for claims
- restrict answers to the provided context
Precision, not a bigger model, fixes confident variance.
Templates as Engineering Artefacts
Named slots make a template testable and versionable: it can be diffed, code-reviewed, evaluated before deploy and rolled back when it regresses. Give each content type (instructions, context, examples, per-request input) its own consistently named XML tag. Anthropic documents XML tags as the way to help Claude parse complex prompts unambiguously, especially where instructions mix with variable and untrusted input. The price list and each family's question get separate tags.
One reviewed template beats ten drifting hand-copies. Prompts in production are code: version-controlled, owned and covered by evals (Domain 4 wires those up).
Guardrails in Layers
The prompt is one layer of defence, never the whole defence:
- Instruction-level: scope ("answer only from the provided policy text"), refusal rules, tone constraints, and the escape hatch.
- Input-side: validate and sanitise before the model. Screen size, format, and sensitive data, and delimit untrusted content (retrieved documents, user uploads) inside tags so it arrives as data, not instructions. Content that arrives as instructions can act as instructions. Treating that content as untrusted by default is Domain 2's share of prompt-injection defence; defence in depth belongs to Domain 5.
- Output-side: parse and validate the model's output against the schema and business rules before anything downstream consumes it. Model output is untrusted input to the next system. At the funeral director, quoted prices are checked against the price list.
Give every refusal a route. A guardrail that blocks with no fallback (no human-review queue, no structured error the caller can handle) converts a safety control into an outage. The funeral director sends blocked questions to staff.
Instructions Cannot Guarantee Behaviour
Instructions shape behaviour probabilistically. Only programmatic validation can guarantee it.
In the exam
The Professional exam tests deliberate contract design, and knowing instructions alone are never the whole defence. When a stem describes a system-prompt-only defence and asks what is missing, the answer is code-level validation around the model, not more emphatic instructions.
Exam Traps
Restating standing policy (differently) in each request's user turn instead of the system prompt
Buried policy loses stable authority, drifts per developer, and destroys the cacheable prefix. The same rules then cost full input price on every request while behaving less consistently.
Responding to an invented-fact incident with a larger model or a lower temperature
Hallucination under a vague contract is a prompt design failure. The keyed answer is scope restriction plus an escape hatch — answer only from provided text, with explicit permission to admit uncertainty. A larger model obeys the same vague contract more fluently.
Relying on system prompt instructions as the sole guardrail around a sensitive workflow
Instructions cannot guarantee behaviour. The missing piece in these stems is programmatic input and output validation wrapped around the model — parsing, schema checks, business rules — before anything downstream consumes the answer.
A schema that demands a value for every field with no honest way out
When the source lacks the field, the model must either break the schema or invent the value. An explicit null path plus permission to say the information is missing removes the incentive to hallucinate.
Practice Scenario
A financial-services chatbot must answer strictly from an internal policy library. Its launch system prompt reads: 'You are a helpful assistant. Answer questions about company policy.' In week one it answers a question about a competitor's products, invents a policy clause, and returns inconsistently formatted answers. Which single redesign most reduces the invented-clause risk?
Build Exercise
Redesign a One-Paragraph Prompt into a Layered Contract
What you'll learn
- How to write an explicit role, scope, and rule-conflict contract
- How to design an output contract with a genuine escape hatch
- How to structure a template with XML tags separating static and per-request content
- How to place input-side and output-side guardrails around the model
- How to pair every refusal rule with a fallback route
- Take a real assistant with a thin system prompt and rewrite it: explicit role, audience, scope limits, and rule-conflict behaviour
Why: Vague prompts produce confident variance. The rewrite is where the contract becomes specific enough to guide behaviour.
You should see: A system prompt where every sentence either sets scope, sets policy, or sets format — nothing decorative.
- Define the output contract: format, schema, length, and the escape hatch for unanswerable input, with the null path spelled out
Why: An output contract without an escape hatch forces invention. The null path is the anti-hallucination control.
You should see: A schema plus one explicit rule for what the model returns when the source does not contain the answer.
- Restructure the template with XML tags separating instructions, policy content, examples, and per-request input; mark which sections are static and which vary
Why: Tags make the prompt parseable and the static/dynamic split is what makes the prefix cacheable later.
You should see: A template with four or five named tag sections and a static/dynamic annotation on each.
- Add the input-side layer: what is validated or sanitised before the model, and how untrusted content is delimited
Why: Content that arrives as instructions can act as instructions. Delimiting untrusted input as data is the Domain 2 share of injection defence.
You should see: A short list of pre-model checks plus the tag that wraps retrieved or user-supplied content.
- Add the output-side layer: the parser and business-rule checks that run before anything downstream consumes the answer, and the fallback route when validation fails
Why: Model output is untrusted input to the next system, and a refusal path that strands the user is an outage.
You should see: A validation list plus one named fallback per failure mode: retry, human review, or structured error.
Sources
- Prompting best practices — Anthropic
- Reduce hallucinations — Anthropic
- Mitigate jailbreaks and prompt injections — Anthropic
- Prompt engineering overview — Anthropic
- Effective context engineering for AI agents — Anthropic
- Claude Certified Architect Professional Exam Guide (v1.0) — Domain 2 — Anthropic