Every traditional application validates its inputs before processing them. LLM applications need the same discipline, but much of the validation logic lives in the prompt rather than in code — because "is this a real invoice or a lunch menu?" is a judgment call, not a regex. This article covers the prompt-side patterns for catching malformed and out-of-scope inputs before Claude produces a confident answer to the wrong question. Everything here is plain Messages API prompting, so it behaves the same on Amazon Bedrock, Google Vertex AI, Microsoft Foundry, and Claude Platform on AWS.
Split the work: code validates form, the prompt validates meaning
A useful dividing line: anything a deterministic check can catch should be caught in code before you spend tokens — empty input, inputs over your length budget, missing required fields, wrong file types. Reserve the model for the judgments code can't make: is this document the kind of document the workflow expects, is the request within the assistant's scope, is the text coherent enough to act on. Paying for an API call to discover an empty string is a design smell.
Define valid input explicitly in the system prompt
Claude can only enforce a boundary you have described. Anthropic's prompting guidance frames this as the golden rule of clear prompting: if a colleague with minimal context would be confused by your instructions, Claude will be too. So spell out the input contract the way you would for a new employee:
You process expense reports submitted as free text.
A valid submission includes: an amount, a currency, a date,
and a business purpose.
Before answering, check the submission:
- If any required element is missing, do not process it. List the
missing elements and ask the user to resubmit.
- If the text is not an expense report at all, reply: "I can only
help with expense reports." Do not attempt a partial answer.
- If the text appears truncated or garbled, say so and ask for a
clean copy rather than guessing at the content.Note the shape: a positive definition of validity, then explicit branches for each failure mode, each with a scripted response. The guidance to explain why an instruction matters applies here too — "do not attempt a partial answer, because downstream systems treat your output as approved data" teaches Claude how to handle the malformed cases you didn't list.
Separate untrusted input from instructions
User input should never sit in the same undifferentiated text blob as your instructions. Anthropic's best practices recommend structuring prompts with XML tags — wrap the user's submission in something like <user_input>…</user_input> and state that everything inside it is data to be evaluated, not instructions to be followed. This markedly improves parsing on complex prompts, and it is also your first, defensive line against prompt injection: input that says "ignore previous instructions" is easier for the model to treat as content when your prompt has already declared that region as content. Treat this as a mitigation, not a guarantee — see prompt injection basics for the fuller defensive picture.
Show the failure cases, not just the happy path
Few-shot examples are the strongest lever for consistent validation behavior. Anthropic recommends 3–5 relevant, diverse examples wrapped in <example> tags — and for validation, diversity means including the rejections: one clean input handled normally, one missing-field input triggering the resubmit message, one off-topic input triggering the scope refusal. Models imitate what they are shown; a prompt whose examples are all successes will drift toward always succeeding.
Make the verdict machine-readable
If a validation decision gates downstream code, don't parse it out of prose. Ask for a structured verdict — a status field like valid, invalid_missing_fields, or out_of_scope alongside the response — using the prompt-only JSON patterns covered in extraction to JSON via prompt-only techniques, or the API's structured outputs feature (output_config with a JSON schema) when you want the shape guaranteed. Structured outputs are generally available on the Claude API, Claude Platform on AWS, Bedrock, and Vertex AI, and in beta on Foundry.
Where to go next
Validation branches are a special case of conditional branching in prompts. For what happens after a rejection — refusing gracefully or routing to a human — see prompting for graceful escalation.