Build a test set from real work
Start with 30 to 100 examples from the work you actually need Claude to do. Include ordinary tasks, messy tasks, ambiguous tasks, tasks with missing evidence, tasks that should trigger a refusal, and tasks that should not trigger a refusal. Label what a good answer must contain and what it must avoid.
Do not score only vibes. Score factuality, citation support, instruction following, refusal calibration, recovery path, latency, cost, and human edit distance. If the task uses tools, score tool calls separately from prose quality.
Separate source truth from model fluency
For factual workflows, prepare a source bundle and a claim checklist. Claude should cite which source supports each claim. Then a reviewer should check the original source, not just the citation label. This catches the common failure where a cited page exists but does not support the sentence Claude wrote.
For current facts, record the retrieval date. The model overview and system prompt docs show that model behavior, system prompts, and cutoffs change. A test result without model ID and date is hard to interpret later.
Include expected failures
Expected failures are not gotchas. They are the only way to know how the system behaves at its boundary. If your evaluation never triggers a refusal or a truncation, it cannot tell you how production will behave under pressure.
- A benign request that uses words associated with a prohibited domain.
- A prohibited request that should be refused.
- A task that exceeds normal output length.
- A long-context task with old conflicting instructions.
- A webpage or file that contains hostile instructions.
- A prompt that asks for a fake quote or unverified source.
Make a deployment decision
At the end, decide whether Claude is allowed to draft, recommend, execute, or decide. Those are different authority levels. Many workflows are safe when Claude drafts and a human approves, but unsafe when Claude executes or decides alone.
A honest result can be "use Claude, but only with these sources, these tools, these refusal handlers, these logs, and this human review step." That is not a lesser deployment. It is a real system design.
FAQ
How many test prompts do I need?
For a serious workflow, use enough examples to cover normal cases, edge cases, expected refusals, source errors, tool failures, and long-context pressure. Thirty to one hundred examples is a practical starting range.
Should refusals count as failures?
Only if they are miscalibrated. A correct refusal is a pass. An overrefusal or missing safe alternative is a failure.
Primary sources
- Model system cards Anthropic - Accessed July 6, 2026
Lists public Claude system cards and frames them as documents about capabilities, safety evaluations, and deployment decisions.
- Models overview Claude Platform Docs - Accessed July 6, 2026
Provides current model IDs, context windows, output limits, knowledge cutoffs, and availability notes.
- Claude is providing incorrect or misleading responses. What's going on? Claude Help Center - March 16, 2026
Plainly states that Claude can hallucinate, produce misleading output, and should not be treated as a single source of truth.
- Stop reasons and fallback Claude Platform Docs - Accessed July 6, 2026
Documents API stop reasons including refusals, truncation, tool use, and context-window overflow.
- Context windows Claude Platform Docs - Accessed July 6, 2026
Explains what counts toward context, current context sizes, and why long conversations still need token management.