Start with a falsifiable claim
“Our system is accurate” is not a test specification. Translate it into a task, population, input distribution, metric, operating condition, and decision threshold. Specify whether the claim concerns the model alone or the complete workflow. Record the exact system version, data cutoff, prompts, tools, and operator instructions. A claim register should include the original wording, source, proposed test, acceptance rule, and the person responsible for supplying evidence. Preserve claims that cannot yet be tested as unresolved rather than treating silence as support.
Choose the baseline before viewing the results
Use a meaningful comparator: the current process, a simpler model, or a conventional software rule. Give each option comparable data and tuning opportunity. Include the human effort already present in the incumbent workflow. Predefine the primary metric and the cost of different errors. Report the denominator and coverage: a high success rate on a narrow subset can conceal a low completion rate. Averages should be accompanied by relevant subgroups and failure examples. A baseline is a control for the decision, not a weak opponent selected to make the new system look good.
Protect the held-out test
Split by the unit that creates dependency. For repeated documents, split by source; for longitudinal data, consider time; for imaging, consider subject or site. Deduplicate before evaluation and inspect whether training or retrieval includes test answers. Freeze the held-out set and keep it separate from debugging. When contamination cannot be excluded, document that uncertainty and collect a genuinely new test set where possible. Test-set secrecy alone does not guarantee independence if the underlying sources overlap.
Measure the human and the entire system
Track manual corrections, escalations, rejected outputs, retries, tool failures, and the time spent by reviewers. Evaluate the output that reaches the user rather than only the first model response. For an assisted workflow, define the human’s permissible actions and record them. Compare quality at a fixed review budget, and cost at a fixed quality threshold. An “automated” result requiring extensive hidden intervention is a different operating proposition from the one buyers may infer.
Make the result reproducible and decision-relevant
Retain dataset identifiers, versioned configurations, dependency versions, run timestamps, seeds where meaningful, raw traces, and scoring instructions. Repeat stochastic runs and show variability. If a judge model scores outputs, calibrate it with a blinded human sample and report disagreements. Avoid optimizing to the judge. The final decision brief separates supported, conditional, unsupported, and untested claims. State which limitations would change the recommendation. Reproduction access may be constrained by licences or privacy; the report should name those constraints rather than imply unrestricted reproducibility.
Connect evaluation to deployment
Passing a scoped evaluation does not establish universal reliability. Define rollout monitoring, regression thresholds, incident escalation, and reevaluation triggers for model, data, or workflow changes. Tie each threshold to the decision owner and failure consequences. NIST’s AI Risk Management Framework provides broader risk-management context; this testing protocol is not a certification against that framework. The useful outcome is a traceable decision, with enough evidence to revisit it when the operating conditions change.
Sources and further reading
References provide background. The proposed methods and decision framing above are Tensor State Group’s technical synthesis; no external publication endorses this service.
Put the method to work
Explore the related service and deliverables · Inspect a reproducible synthetic cost demonstration · Discuss your system or decision