MEASURE 2.5 Validity and reliability: requirements and evidence

What MEASURE 2.5 asks for and why teams struggle with it

A customer, regulator or internal risk owner asks whether the AI system you are about to deploy is valid and reliable. MEASURE 2.5 is the outcome behind that question: the system to be deployed is shown to be valid and reliable, and the limits of its generalizability beyond the conditions under which it was developed are documented. The bar is the system as it will actually run, not a model score from a development notebook. NIST AI 100-1 presents the AI RMF as voluntary, and no certification exists for it, so there is no badge to point to. Your evidence has to show, in plain documents, what the system does, under which conditions, and where those conditions stop applying.

The reason teams struggle is that test sets rarely look like production. Development data is usually cleaner, more balanced and more stable than the inputs the system receives after launch, and the gap is often largest for edge cases the business cares about most. NIST AI 100-1 also notes that accuracy and robustness can pull against each other, so a change that lifts one may weaken the other. It asks that accuracy measurements be paired with realistic test sets that represent expected use, along with enough detail about the test methodology for someone else to repeat it. Confirm with your data owners which production conditions they can reproduce in test, and record the ones they cannot.

Before any sign-off, ask the team to write down the operating conditions and limits the system was validated for, the populations and input types outside that scope, and the reason each boundary was drawn. A reviewer should be able to trace each claim of validity to a test set, a metric and a stated condition. If a claim cannot be traced that way, the requirement is not yet met, whatever the headline accuracy figure says.

Which systems, data and teams fall under MEASURE 2.5 scope

MEASURE 2.5 asks whether the AI system you deploy is valid and reliable, and where that evidence stops applying. Four scoping choices decide how much work that involves: which system is being judged, which parts came from someone else, what kind of output it produces, and who on the team is qualified to judge it. Nothing in the framework makes any of these choices mandatory, so each organization should record its own decisions.

Deployed system versus base model

A base model rarely reaches users unchanged. Prompts, retrieval sources, fine-tuning data, tool access and guardrails all change behavior, so validity claims about the model do not transfer to the deployed system. Define the scope as the complete system in its deployment configuration, and record which layers were tested. Illustrative example: a model that scores well on a public benchmark may still perform poorly once a company's documents are added through retrieval. Confirm the boundary with the system owner before testing starts.

Third-party and pre-trained components

Pre-trained models, vendor APIs, open datasets and embedded libraries each carry validity assumptions made by someone else. Ask suppliers for the conditions under which they tested their components, and whether those conditions match your use. Where the supplier does not disclose test conditions, your own tests become the only evidence for that component. Record each external component in the scope so that a later change in a vendor version triggers a retest.

Generative versus predictive output

Predictive systems are usually judged against labeled outcomes with metrics such as error rates on held-out data. Generative systems produce open-ended text or content that has no single correct answer, so validity testing must cover factual accuracy, citation quality and consistency across prompts. NIST AI 600-1 lists MEASURE 2.5 actions tied to confabulation and information integrity, and warns against extrapolating broad performance from narrow or anecdotal assessments. Choose the test method before you choose the metric.

TEVV staff and domain experts

The Playbook tags MEASURE 2.5 with two AI actor categories: TEVV personnel who design and run tests, and domain experts who judge whether the test conditions reflect real use. Confirm named owners for both roles, and make sure the domain experts can say which operating conditions and failure modes matter in the setting. Testers without domain input tend to build test sets that look realistic but miss the cases that matter. Record who signed off on the validity claim and on its stated limits.

How an assessor tests validity and reliability evidence

This table walks through the review steps an independent assessor would take for MEASURE 2.5, the evidence each step asks for, and the findings that usually come up. Read it as a checklist of what to have ready before an assessment, since the framework itself is voluntary and no assessor issues an AI RMF certificate.

Review step	Evidence the assessor asks for	Common finding
Operating conditions and limits	Written statement of the conditions, input types, users and settings the system is designed for, with stated limits	Limits are missing, or they describe the lab setup rather than expected use
Test set representativeness	Test sets documented against expected production inputs, with the test methodology and rationale for sample choice	Test data is drawn from development conditions only and does not reflect the deployment population
Construct, internal and external validity	Evidence that the metric measures the intended property, that results follow from the test design, and that results hold across settings	Metrics are accepted without showing they measure the risk they are meant to cover
Variance and uncertainty	Confidence intervals, bootstrapping or cross-validation results and an explanation of how variance was estimated	Single point scores are reported with no spread, so small differences look meaningful
Robustness and reliability	Documented robustness measures, standard software testing results (unit, integration, functional and chaos testing) and failure cases	Testing covers the happy path only, with no record of how the system behaves under degraded or unexpected inputs
Generalizability limits	Documented boundary of where performance was shown, with statements on which populations, languages or settings were not tested	Results from narrow or anecdotal tests are extended to general claims about performance
Generative AI pre-deployment checks	Records of MS-2.5-001 and MS-2.5-003 style checks in NIST AI 600-1, including source and citation review of outputs before and during monitoring	No review of sources or citations is recorded, and confabulation is not tested in the pre-deployment set

Implementing MEASURE 2.5 step by step

This sequence moves from defining where the AI system may be used to documenting how far its validity and reliability evidence reaches, so the organization can show the system to be deployed performs as intended and where that evidence stops.

Define operating conditions and limits
The product owner, the system's domain experts and the TEVV lead write down the conditions the system is designed for: user populations, input types, data sources, languages, volumes, and the decisions its output feeds. They also state explicit limits, such as inputs that fall outside the design envelope and tasks the system must not perform. Done means a signed operating envelope exists that every later test is measured against, with out-of-scope conditions listed as well as in-scope ones.
Define the construct and validity checks
The TEVV team and domain experts define what the system is supposed to measure in operational terms, then state how they will check internal validity (whether results follow from the design and data) and external validity (whether results carry over to real use). They also name the metrics that represent the construct. Done means a validity plan records each construct, its metrics, and the reason each metric stands in for the real-world target, with domain experts' sign-off on the mapping.
Select variance and uncertainty methods
The TEVV team chooses how it will assess variance in results, using methods such as confidence intervals, bootstrapping or cross-validation, and records why each fits the data size and model type. Results are reported with their spread, not as single point scores. Done means the analysis plan names each method, its parameters and the criteria for calling a result stable, and a dry run on existing data confirms the methods produce output the team can interpret.
Run deployment-representative test sets
The TEVV team builds or selects test sets that reflect the expected conditions of use, including edge cases from the limits defined earlier, and keeps them separate from development data. The team runs the system against these sets and records inputs, outputs and scores. Done means every test set has documented provenance, a stated link to the operating envelope, and results that show performance inside and at the edges of the envelope.
Document robustness and reliability measures
The TEVV team measures how results change under input perturbations, data shifts and repeated runs, and records the reliability measures it uses. Where accuracy and robustness pull against each other, the document explains the trade-off the organization accepted and why. Done means a robustness report lists each measure, the conditions tested, the observed behavior, and the conditions where the system falls short of its stated limits.
Apply standard software testing
The engineering team runs standard software tests around the model and its surrounding pipeline, including unit, integration, functional and chaos tests, so that failures in data handling, retrieval, or tool calls are separated from model behavior. Results are stored with the build. Done means the test suite runs on each release, failures are tracked to a resolution, and the test records are linked to the validity evidence.
Document the generalizability limits
The TEVV lead and domain experts write a limits statement that states the conditions under which the validity and reliability evidence holds and the conditions it does not cover, including populations, languages, data sources and time periods. The statement is reviewed by the accountable owner before any go or no-go decision. Done means the limits statement is approved, versioned, and linked to the operating envelope and the production monitoring plan.

How validity and reliability tests work in practice

Validity asks whether the system measures what the business thinks it measures, and reliability asks whether it does so consistently. For engineers, *construct validity* is the gap between the target and the proxy: a fraud model scored on chargeback labels measures chargebacks, not fraud. *Internal validity* asks whether the test itself supports the conclusion, meaning the splits, leakage checks and baselines are sound. *External validity* asks whether the result holds outside the test conditions. Reliability is the repeatability side: run the same evaluation on another seed, sample or day and check whether the spread is small enough to act on. The Playbook suggests confidence intervals, bootstrapping or cross-validation to show that variance, and the result should be written down with the method, not just the headline number.

AI 100-1 notes that accuracy and robustness can pull against each other, and that an accuracy figure means little without a test set that resembles expected use and a description of how it was run. Practically, the team should record the test set source and date range, the inclusion rules, the metric definition, the preprocessing, and the operating conditions the system was built for. Then it should define where the system is not expected to work, such as languages, document types, customer segments or input lengths that were absent from testing. Results from one population or one prompt set should not be extrapolated to others. For generative systems, MS-2.5-001 warns against extrapolating performance from narrow or anecdotal assessments, so a handful of impressive demo prompts is not evidence of validity.

For generative AI, MS-2.5-003 asks teams to review sources and citations in outputs during pre-deployment measurement and keep doing so in monitoring. In practice, build a labeled set of prompts with known correct answers or verifiable source documents, score each output for unsupported claims and citations that do not resolve to the cited material, and record the failure rate by prompt category. Keep traces of retrieval results and generated answers so a reviewer can tell whether a hallucinated or unsourced claim came from the model or from a bad retrieval step. Confirm with domain experts which errors matter for the use case, because the Playbook tags this subcategory for them alongside TEVV staff.

Which evidence shows an AI system is valid and reliable

MEASURE 2.5 asks for proof that the system you deploy is valid and reliable, and for a written record of where that proof stops applying. The six artifacts below work together: the conditions define what is being tested, the test sets and variance analyses show the results can be trusted, and the software and output reviews show the system still behaves as tested after it changes.

Documented operating conditions and limits

This is a written statement of the inputs, users, languages, data ranges and deployment settings the system was validated for, plus the conditions it was not validated for. Assessors look for limits that are specific enough to act on, such as a maximum input length or an excluded document type. Review the statement whenever the use case, user population or upstream data source changes, and record who approved each revision.

Test set descriptions and representativeness rationale

Each test set needs a description of its origin, size, labeling method and time period, and a written reason why it represents the conditions of expected use. Accuracy figures without this context are hard to defend, because a test set drawn from last year's tickets may not reflect today's traffic. Refresh the rationale when production inputs drift, and keep the datasets versioned alongside the results they produced.

Variance and confidence analyses

Single headline scores hide how much results move between runs, samples and data splits. Keep confidence intervals, bootstrap estimates or cross-validation results for each reported metric, and state how many repetitions were used. A change in the interval after a retraining job is often a stronger signal than a change in the point estimate, so compare intervals release to release, not only the scores.

Robustness and reliability test results

These results show how performance changes under noisy, shifted or adversarial inputs, and how often the system fails on edge cases defined in the operating limits. Record the perturbations used, the failure rate for each and the threshold that triggers escalation. Rerun the suite after every model, prompt or dependency change, because a robustness result from a previous version does not carry forward.

Software test reports from CI pipelines

Unit, integration and functional test results show that the surrounding code, data pipelines and serving layer behave as designed, which the Playbook also asks organizations to consider. GitLab's protected branches can ensure that only tested changes reach the release branch, and Semgrep can run in the pipeline to flag code issues on each commit. Archive the pipeline reports with the model version they accompany, and confirm which test types your team actually runs before citing them as evidence.

Reviews of citations in generative outputs

For generative systems, NIST AI 600-1 asks organizations to avoid extrapolating performance from narrow or anecdotal assessments and to review sources and citations in outputs during pre-deployment measurement and ongoing monitoring. Sample outputs on a schedule, check each cited source exists and supports the claim, and log the error rate. Langfuse traces can supply the inputs, outputs and retrieval steps that a reviewer needs to trace a citation back to its origin.

What meeting MEASURE 2.5 costs in money and effort

The largest one-time cost for MEASURE 2.5 is engineering time to build the evidence base: representative test sets, the harness that runs them, and the documentation that shows validity and reliability. The NIST AI RMF Playbook suggests defining operating conditions and limits, measuring construct, internal and external validity, and assessing variance. Each of these becomes engineering work, and the organization owns the result even when an outside partner does the build.

Test set construction: Engineers assemble data that reflects expected use conditions, which AI 100-1 Section 3.1 asks for when it pairs accuracy with realistic test sets.
Harness and pipeline code: Scripts or pipelines run the tests repeatedly, including variance methods such as cross-validation or bootstrapping.
Standard software testing: Unit, integration, functional and chaos tests are built into the delivery pipeline.
Documentation: Limits of generalizability and robustness measures are written up for assessors.
Scope decisions: Time spent defining which use conditions are in scope is often underestimated.

Ask the proposal to separate these lines so you can see which work your team keeps and which is delivered.

Open-source tools that produce MEASURE 2.5 evidence

This table maps four open-source tools to the MEASURE 2.5 evidence they can produce, along with their licenses and the human review each output still needs. Read each row as a source of records for an assessor, not as proof that the system is valid or reliable.

Tool	Evidence it produces	License and limits
garak	JSONL report of every probe attempt and evaluation, plus a hit log of attempts that found a vulnerability, useful for documenting robustness testing of language models	Apache-2.0. Probes cover hallucination, data leakage, prompt injection, misinformation, toxicity and jailbreaks, but the probe set does not cover every condition of expected use.
Langfuse	Traces that record inputs, outputs, timing, token usage and metadata for each operation, including LLM calls, retrieval steps and tool executions, supporting reliability and production comparisons	MIT. Traces show what happened, not whether results are valid. Confirm retention and access settings in your own deployment.
GitLab Community Edition	Protected branch settings that restrict who can push or merge changes to test sets, evaluation scripts and configuration, with audit trail of approved changes	MIT. Protected branches control change access only. Confirm that reviewers check that test methodology matches the stated conditions of use.
Semgrep Community Edition	Scan results from CI/CD runs against evaluation and pipeline code, showing that tooling used to compute validity and reliability metrics was checked on each change	LGPL-2.1-only. Code scanning does not test model behavior or statistics. Supported languages include Python, which is common in evaluation code.
Human review of statistics	Documented review of confidence intervals, cross-validation results and test set representativeness, signed off by TEVV staff and domain experts	Not a tool. No open-source product replaces the judgment needed to decide whether results generalize beyond development conditions.

Who owns validity evidence and who can help

Your organization owns the AI system, the conditions it is meant to operate under and the judgment that it is valid and reliable for that use. The AI RMF treats these as organizational decisions, and no outside party can take them over. Your domain experts define what correct performance means in the setting where the system will run, and your accountable leaders decide whether the evidence supports deployment.

Operating conditions and limits: define the populations, data types, volumes and decision contexts the system is meant to serve, and the conditions outside which it must not be used.
Construct and metric choice: decide what the system is supposed to measure and whether the chosen metrics represent that construct in your environment.
Interpretation of results: judge whether accuracy, robustness and variance figures are acceptable for the intended use, including the tension between accuracy and robustness noted in AI 100-1.
Generalizability statements: document where the system has and has not been shown to perform, and what must be rechecked before it is applied elsewhere.
Go or no-go sign-off: record who approved deployment, on what evidence and with which residual risks accepted.

Confirm that these decisions have named owners and dated records before any outside party starts work.

Common gaps that fail a validity and reliability review

Reviewers of MEASURE 2.5 usually find the same weaknesses: evidence drawn from development conditions, limits left unstated, and results without the method behind them. Each gap below is paired with the action that closes it, so the evidence still holds when the system, its data or its users change.

Testing only on development data

A system that scores well on the data it was built and tuned on has shown little about the conditions it will meet after deployment. MEASURE 2.5 asks that the system to be deployed is shown to be valid and reliable, which requires test sets that represent expected use. Check whether any held-out test set was drawn from the same sources, time window or users as training data. Action: build a test set from deployment-representative data and record how it differs from development data.

No documented limits of generalizability

Teams often report that a system works without stating where it stops working. MEASURE 2.5 expects the limits of generalizability beyond development conditions to be documented, including populations, geographies, languages, input types and operating ranges not covered by testing. A reviewer will ask what the system was never tested on. Action: write a limits statement that lists untested conditions and the controls used to keep the system inside its tested range.

Accuracy reported without methodology

A single accuracy figure cannot be reviewed without the test design behind it. NIST AI 100-1 says accuracy measurements should be paired with details of the test methodology, and it notes that accuracy and robustness can pull against each other. Assessors look for the dataset, the split, the metric definitions and the tool versions used. Action: attach the test methodology to every reported metric, and keep it with the TEVV documentation described in MEASURE 2.1.

No variance estimates

A point estimate hides how much a result would move on a different sample. MEASURE 2.5 is served by showing how performance varies, using methods such as confidence intervals, bootstrapping or cross-validation, as the Playbook suggests. Without these, a small gain can look like a reliable improvement. Action: report an interval or spread with every headline metric and state the resampling method used.

Generative outputs not checked for sources

Generative systems can produce confident statements that are unsupported or citations that do not exist. The Generative AI Profile lists suggested actions under MEASURE 2.5 that call for avoiding extrapolation from narrow or anecdotal assessments and for reviewing sources and citations in outputs during pre-deployment measurement and ongoing monitoring. Reviewers ask for a sampled check of citations, not a statement that the model cites well. Action: sample outputs on a fixed schedule, verify each cited source, and log the failure rate with the sample.

Evidence not refreshed after changes

Validity and reliability results describe a specific model, data set and configuration. A new model version, a retrained model, a changed prompt or a shift in input data can make earlier results stale. Reviewers check the date of each result against the date of the last change to the system. Action: tie each validity result to a model and data version, and rerun the affected tests before any change goes live.

Common questions about MEASURE 2.5 cost, effort and outsourcing

Is there a NIST AI RMF certification I can get for MEASURE 2.5?

No. NIST does not certify, accredit or validate organizations against the AI RMF, and it does not endorse any organization's approach to using it. The framework is voluntary, so there is no certificate to earn for MEASURE 2.5. What a customer or regulator can reasonably ask for is evidence: documented operating conditions, validity and reliability measurements, the limits of generalizability, and the test methods behind them. Any firm offering an AI RMF certificate is selling something NIST does not recognize, so ask the vendor which body issued it and what it tests. Your own assessment, or an independent assessor's review if you commission one, produces the evidence without a certification step.

How much effort does MEASURE 2.5 take, and what drives it?

Effort depends mostly on how many AI systems are in scope, how complex each system is, and how much evidence already exists. The work splits into defining operating conditions and limits, measuring construct, internal and external validity, quantifying variance, and documenting robustness and reliability. Generative AI systems add work because NIST AI 600-1 asks you to avoid extrapolating performance from narrow or anecdotal tests and to review sources and citations in outputs. Systems with external dependencies, such as retrieval sources or third-party models, need more testing because their behavior changes outside your control. Ask any provider to estimate effort per system, the number of test sets and the evidence format before agreeing a scope.

How long does MEASURE 2.5 preparation take?

No supplied figure gives a duration, so treat any timeline as unverified until it is tied to a written scope. The schedule usually depends on whether test sets already exist, whether the team has documented operating limits, how many systems need evaluation, and how quickly domain experts can review results. Confirm with your team which test sets, metrics and logs already exist, then ask any provider for milestones tied to specific deliverables, such as a documented test methodology, a validity and reliability report and a list of generalizability limits. Fixed-scope engagements usually state these deliverables in writing before work starts.

Can an in-house team complete MEASURE 2.5 without outside help?

Often yes, if the team has people who can design test sets, run statistical checks and write defensible documentation. The AI RMF Playbook tags MEASURE 2.5 with the TEVV and Domain Experts actor categories, so the work needs both testing skill and subject knowledge. Teams without experienced evaluators, or without domain experts who can judge whether a test set reflects real use, often find the gaps late. Before deciding, check whether you can produce confidence intervals or cross-validation results, reproduce them, and explain why the test conditions match expected use.

What does outsourcing MEASURE 2.5 cover, and what stays with us?

An implementation partner can prepare test environments, build evaluation pipelines, run standard software testing such as unit, integration and functional tests, set up tracing and logging, and organize evidence. DeployOpen works this way: it prepares systems and evidence inside your own infrastructure, but it does not issue audit reports, attestations or certifications. Your organization still owns the AI system, its intended use, its risk tolerance and the decision about whether validity and reliability are acceptable. Ask any partner to state in writing which deliverables they produce and which decisions remain yours.

What does an independent auditor or assessor need from us for MEASURE 2.5?

An independent assessor needs to see the claims you make and the evidence behind them. Expect requests for the defined operating conditions and limits, the test sets and how they represent expected use, the metrics and tools used, the results with their variance measures, and a record of where performance was found to be weaker or narrower than claimed. Assessors also look for a clear link from each result to a decision made by an accountable person. Gather these artifacts before the review starts, and confirm the exact evidence list with the assessor, since no single list is fixed by the framework.

What recurring costs should we expect after MEASURE 2.5 is complete?

Validity and reliability are not one-time results. Model updates, changes in data, new use cases and drift in production all change the conditions under which the system was tested, so the evaluation must be repeated. Recurring costs therefore include re-running test sets, updating documentation, maintaining the tooling and reviewing results with domain experts. Ask any provider whether support is delivered as a retainer or an ad hoc project, what triggers a re-evaluation and who owns the test sets after handover.

How DeployOpen prepares MEASURE 2.5 evidence

DeployOpen plans, implements and prepares the technical side of MEASURE 2.5 inside the client's own infrastructure, but the validity and reliability conclusions remain the organization's decision. Under an agreed written scope, DeployOpen can build the test harnesses that exercise the system against realistic test sets, set up the monitoring that records performance over time, and assemble an evidence pack that shows how each measurement was produced. The organization owns the operating conditions and limits, the acceptance thresholds and the go or no-go decision. DeployOpen does not issue assessments, attestations or certifications, and it does not decide whether a system is valid or reliable. An independent auditor or assessor makes that judgment when one is required.

In practice, the work usually starts with the components the MEASURE 2.5 actions name. The team sets up repeatable runs for accuracy and robustness with a fixed test_set_version and records the test methodology, sampling approach and confidence interval method next to each result. For generative AI, the harness can also capture output samples so that sources and citations are reviewed during pre-deployment testing and monitoring. Where the platform is open source, DeployOpen can use tracing such as Langfuse documentation: Observability overview to link each output to its inputs, retrieval steps and tool calls, and can run a probe suite such as garak to produce a JSONL attempt log and hit log. Every harness, configuration and test set is kept under version control with protected branches, so a reviewer can tell which version produced a given result. The client should confirm which tools are approved for use in its environment before scope is agreed.

MEASURE 2.5 Validity and reliability