An evaluation set shows what an assistant should do before a team depends on it. Build the set around observed questions, expected behavior, and known ways an answer or action can go wrong. Keep the checks reproducible as sources and configuration change.
Specify observable behavior
For each example, record the input, expected outcome, and evidence a reviewer should check. If several answers are acceptable, describe the conditions they share. Evaluate support from source material and correct handling of uncertainty alongside usefulness. Keep the test examples within the agreed data boundary.
Include more than common cases
Sample incomplete inputs, conflicting instructions, requests beyond scope, and questions about restricted sources. If the assistant can propose an action, check the review and cancellation path. Use separate users or permissions when access is part of the task. Record why an answer was wrong or why the assistant should have abstained.
Track regressions with a stable baseline
Run the same cases after meaningful changes to the sources, prompts, permissions, or workflow. Note the tested version and the reviewer. Prioritize failures that expose restricted content, lead to the wrong action, or make errors difficult to detect. Decide which cases block the next rollout and how they will be retested.
Example
Use a synthetic dataset with answerable, unanswerable, and restricted questions.
What to do next
Use a representative set and explicit failure cases to make the decision to release reviewable.