Anthropic's evaluation guidance opens with three design principles, and the first is: "Be task-specific: Design evals that mirror your real-world task distribution. Don't forget to factor in edge cases!" The docs then enumerate the edge cases worth factoring in. They fall into four categories, and each one maps to a distinct failure mode you will eventually see in production — whether you call Claude through the first-party API, Amazon Bedrock, Vertex AI, or Microsoft Foundry.
1. Irrelevant or nonexistent input data
What happens when the document a prompt refers to is empty, missing, or about something else entirely? Retrieval pipelines misfire, upstream jobs write blank files, and users paste the wrong thing. A summarization prompt fed an empty string, or a contract-analysis prompt fed a lunch menu, should degrade gracefully — ideally by saying the input does not support the task — rather than confidently inventing an answer. Your eval set needs rows that exercise exactly this: empty variables, wrong-domain documents, and inputs that contradict the premise of the instruction.
2. Overly long input
Long inputs stress a model differently than typical ones: key facts get buried in the middle, and in the worst case the request approaches the context window. Include test cases at realistic extremes for your workload — the longest documents your users actually upload, multi-document bundles, transcripts that run for hours. This category also earns its keep during model migrations, because tokenizer changes shift how much text fits in the same window (see tokenizer drift).
3. Poor, harmful, or irrelevant user input
This category is specific to chat-style applications: users who type gibberish, go off-topic, attempt prompt injection, or ask for something your policy prohibits. Anthropic's docs phrase it as "poor, harmful, or irrelevant user input." The eval question is not just "does the model refuse the harmful request?" but "does it stay in character, stay on task, and follow your escalation policy?" Treat these rows as defensive tests of your guardrails, and keep them in the suite permanently — every prompt change is a chance for a guardrail to silently loosen.
4. Ambiguous cases where humans disagree
The subtlest category: "Ambiguous test cases where even humans would find it hard to reach an assessment consensus." Is a sarcastic product review positive or negative? Is a borderline support ticket urgent? If two of your own reviewers would split, the model's answer is not simply right or wrong — but you still need to know what it does. These rows tell you whether behavior on genuinely hard inputs is at least consistent and reasonable, and they calibrate expectations for what your grader should count as a pass.
| Category | Real-world trigger | What a pass looks like |
|---|---|---|
| Irrelevant / nonexistent input | Retrieval miss, empty upstream file | Acknowledges the gap instead of inventing content |
| Overly long input | Max-size documents, long transcripts | Task quality holds; key mid-document facts used |
| Poor / harmful / irrelevant user input | Chat abuse, injection, off-topic turns | Guardrails hold; stays on task and in character |
| Ambiguous cases | Inputs where humans split | Consistent, defensible handling |
Generating examples without hand-writing hundreds
You do not need to author these by hand. Anthropic's docs are explicit: "Writing hundreds of test cases can be hard to do by hand! Get Claude to help you generate more from a baseline set of example test cases." A practical recipe: write five to ten seed examples per category yourself — enough to define what "irrelevant input" means for your task — then ask Claude to generate variations, and human-review the output before it enters the suite. The Console's Evaluation tool bakes this in with its 'Generate Test Case' button, whose generation logic you can edit for precision. The same docs also recommend automated grading wherever the question structure allows it, which is what makes a four-category suite affordable at volume (see volume over quality).
One caution for category four: automated graders inherit the ambiguity of the inputs. For rows where humans disagree, either grade for consistency rather than correctness, or route that slice to periodic human review.
Where to go next
Pair this taxonomy with measurable success criteria and a grading strategy from code-based grading or LLM-judge rubrics. Adversarial inputs deserve their own program — see adversarial prompt testing.