Evaluate the whole task
A model score is useful when it changes our expectations about what a person can accomplish with the product.
Consider an assistant asked to compare three documents. A test might reward an accurate summary of each one. The user might need something different: identify a disagreement, establish which document is current, and explain what decision follows.
The summaries can all be good while the task remains unfinished. The evaluation boundary determines which version of success becomes visible.
Begin with a decision
Before writing a test, state the decision it is meant to support. Are we choosing a model, deciding whether to release a feature, or identifying the next capability to improve?
For a release decision, an average score may be insufficient. We may need to know how often the system fails on a common workflow, how costly those failures are, and whether the user can detect them. For a research decision, a concentrated pattern of failures may be more informative than a small gain in the average.
Separate the ways a task can fail
A poor outcome can come from several places: incomplete context, a misunderstood request, a wrong tool choice, an execution error, or an answer that is correct but unusable. Putting them in one bucket makes it difficult to choose an intervention.
A helpful evaluation preserves the task outcome while also recording the failure’s location. That lets a team ask whether it needs better training data, better tools, a different interface, or a clearer product boundary.
The distinction matters when comparing models. If a product silently gives one model more useful context or a more forgiving tool interface, the result is a comparison of systems. That can be valuable, provided the conclusion matches what was tested.
Check the checker
A grading system encodes assumptions about success. An exact-state check works well when the desired end state is unambiguous. Open-ended work often admits several valid solutions and needs a more explicit account of what matters.
Neither approach removes the need to inspect disagreements. If a grader accepts a result that a user cannot use, improving the model’s score may push the product in the wrong direction.
Useful checks include human review of borderline cases, alternative valid solutions, and deliberate attempts to satisfy the scoring rule without completing the task. A disagreement is evidence about the evaluation itself.
Preserve a path back to reality
A compact test set is easier to run and interpret. Real workflows are messy. The goal is to preserve the parts of that mess that change the decision: missing information, interruptions, ambiguous instructions, and the need to recover.
A strong evaluation should let us explain both what improved and why that improvement should matter outside the test. When that connection is unclear, the next step is to investigate the gap.