Review Evaluation Gap

An evaluation gap is the difference between what an evaluation would need to test to support a real-world claim and what the evaluation actually measures.

A score usually covers a slice of behavior under chosen data, metrics, users, and conditions. The evaluation gap is what remains untested when someone stretches that score into a broader claim about usefulness, safety, fairness, or readiness for a particular setting.

A narrow evaluation can create false confidence even when its numbers are accurate. Missing languages, users, failure modes, tool interactions, time pressure, or real consequences can matter more than the measured benchmark once the system is deployed.

A support assistant scores well on factual accuracy for clean English questions. It is then called production-ready even though no evaluation covered multilingual users, prompt injection, tool failures, response latency, or harmful refusals in the actual support workflow.

An evaluation gap is not simply a low score or a lack of many tests. A large benchmark suite can still leave a serious gap if it measures the wrong conditions or values for the claim being made. The gap is between coverage and claim, not between a score and perfection.

The score answers less than the claim.

* [[verification|Verification]] * [[model-card|Model Card]] * [[model-risk-management|Model Risk Management]] * [[capability-provenance|Capability Provenance]] * [[jagged-capabilities|Jagged Capabilities]]

* [Hutchinson et al., “Critical Evaluation Gaps in Machine Learning Practice”](https://research.google/pubs/critical-evaluation-gaps-in-machine-learning-practice/) — documents the gap between the broad concerns needed for responsible system use and the narrow predictive behaviors commonly evaluated. * [NIST AI RMF Playbook, “Manage”](https://airc.nist.gov/airmf-resources/playbook/manage/) — calls for evaluation under deployment-like conditions and continuing post-deployment monitoring as context and risk change.

* Write the deployment claim first, then use [[verification|Verification]] to ask what evidence would actually support it. * Record tested and untested conditions through [[capability-provenance|Capability Provenance]] and a [[model-card|Model Card]].