The decision this supports
Agree what acceptable work looks like, test representative and consequential failures separately, and make the release decision traceable to evidence.
For engineering leads, domain reviewers, and release owners
01 / Engineering guide
Define an observable outcome
Start with the result the operating team will accept. For an onboarding assistant, “a well-written summary” is too loose. A useful criterion might require a complete source-linked review package, an explicit list of missing documents, and no change to the client record before approval. Separate content quality, permitted behavior, and recorded system state.
Write a test case with its inputs, starting state, expected outcome, disallowed actions, and grading method. Define when asking a person for help is the correct result. Otherwise, a workflow that safely stops on missing evidence may appear worse than one that confidently guesses.
Anthropic’s guide to agent evaluations distinguishes the execution transcript from the final state and explains why repeated trials matter. Apply that distinction to your workflow: an action described in a response still needs evidence from the system where the action should have occurred.
02 / Engineering guide
Build a case set with deliberate coverage
Use appropriately authorized examples of real work, with sensitive information handled under your organization’s rules. Add designed cases for rare but consequential conditions. Keep a held-out set that is not used to tune prompts, and record which source and policy versions each expected answer assumes.
Scroll across the table to read all columns.
| Case | Expected behavior | Evidence to inspect |
|---|---|---|
| Complete submission | Prepare a source-linked package for review. | Required fields agree with the supplied records. |
| Missing document | Identify the gap and request review or clarification. | No invented details or false completion. |
| Conflicting records | Show the disagreement without silently choosing. | Both sources and the unresolved field remain visible. |
| Restricted source | Respect the requester’s access boundary. | Neither the answer nor its citations reveal restricted content. |
| Interrupted update | Establish the recorded outcome before retrying. | No duplicate action; uncertainty remains explicit. |
Add adversarial content where retrieved documents or tool results could contain instructions. Test that such content cannot redefine the task, expand permissions, or cause an unapproved action. A few clean demonstrations do not exercise these boundaries.
03 / Engineering guide
Use the right judge for each question
Use deterministic checks for properties such as required fields, allowed tool calls, record identifiers, and calculated totals. Use domain reviewers for nuanced judgments such as whether an explanation gives the next operator enough information to act. Give reviewers a written rubric and examples of borderline cases.
A model-based grader can help triage large volumes of qualitative output, but check its judgments against human review before treating its scores as decision evidence. Inspect disagreements. Keep the grader version and rubric with the results so a score change is not automatically attributed to the workflow itself.
Repeat variable tasks and report the spread of outcomes. Keep results separate by case type and severity. A high overall pass rate can obscure a permission violation or a recurring failure on the small group of cases that creates the most operational work.
04 / Engineering guide
Make release criteria specific to the consequence
Agree release gates before looking at the result. Identify conditions that block release, acceptable review effort, expected completion quality, and how unresolved cases will be routed. There is no universal pass percentage suitable for every workflow. The accountable business and technical owners need to accept the criteria for the actual consequences.
Review both false confidence and unnecessary escalation. A workflow that routes everything to a person may avoid some errors but provide little benefit. Compare the new process with the existing baseline using the same definitions of completed work, correction effort, and elapsed time.
Start with a bounded rollout and named reviewers. Confirm that monitoring, pause controls, and a manual path work before widening access. Evaluation evidence supports a scoped release decision; it does not establish that failures are impossible.
05 / Engineering guide
Keep evaluation connected to operations
Save the configuration, model identifier, retrieval settings, tool versions, rubric, and case results for each evaluated release. Re-run affected cases after a model, source, permission, integration, or process change. Include old failure cases so a local improvement does not silently reintroduce a known problem.
Use operational feedback to extend the case set. Investigate source gaps, tool failures, and reviewer corrections separately: each may require a different remedy. Report cost per accepted outcome alongside model consumption, latency, review effort, and unresolved cases.
The evaluation case template provides a repeatable record for inputs, expected behavior, observations, grading, and the release owner’s decision.