“It works” is incomplete unless we know what was tried, what counts as success, and what happens when the input changes. A demonstration is useful for exploration, but its selected examples cannot stand in for the range of real use.
Begin with the task
Describe the people, inputs, and outcomes the system is meant to support. Define what a useful result looks like and which errors matter most. Use examples that reflect the task, while protecting personal or confidential information.
Look beyond the happy path
Test ambiguous or incomplete requests, unusual but plausible cases, attempts to exceed the intended scope, and changes in the tools or data the system relies on. Include accessibility and language needs that matter to the intended audience. The evaluation should be proportionate to the system’s impact.
Keep evidence in context
Report what was tested, what was not tested, and the limitations of the evaluation. A result on a fixed or synthetic set does not establish performance in a different environment. Human review can also be inconsistent, so define the review question and record uncertainty where it matters.
Use findings to improve the system, restrict its use, or decide that automation is not appropriate. Evaluation is a continuing practice, not a one-time certificate.