The Audit Result Is a Local Fact, Not a Deployment Guarantee
The subject of this series is the NIST TEVV-Athlon Framework for Evaluating AI Systems and the question its use raises: when an AI system passes an audit, what has actually been established about its readiness for deployment? The practical answer requires more than a score. It requires tracing the intended use, the property being measured, the evidence-producing method, the data on which the method operates, and the decision the result is meant to support. That is the understanding this series develops: how to treat an audit result as bounded evidence rather than as a permanent badge of trust.
A result has an object, a target, and a boundary
Imagine an organization evaluating a model that helps make decisions affecting customers. The organization may want evidence that the model is accurate, fair, safe, private, or reliable. Those words name different properties, and each one can be narrowed further by the use, the population, the time period, and the conditions in which the system operates. A test that answers one of those questions does not automatically answer the others.
NIST defines test, evaluation, verification, and validation—TEVV—as a framework for assessing whether a system meets its design specifications and requirements and is sufficient for its intended use. That definition contains two different ideas. The first is conformance: did the system meet a stated requirement under the test conditions? The second is adequacy: are those requirements and conditions enough to justify the use for which the system is intended? A pass can be meaningful without settling the second question.
The TEVV-Athlon Framework is NIST’s method for designing a customized assessment around that distinction. It is not itself a universal score or a certificate that means the same thing for every AI system. An organization states what it wants to learn, identifies the system attributes or trustworthiness characteristics that matter, chooses ways to produce evidence, and synthesizes the results for a decision. NIST places the impacts of an AI system at the center of this activity: evaluation is meant to inform risk management across the system’s lifecycle, including decisions about deployment and procurement.
That framing changes how a reader should interpret the word “audit.” At minimum, four claims can be hiding inside the sentence “the model passed.”
- The model behaved acceptably on the specified audit material. This is the most local claim. It may be exactly what the protocol tested, and it may be useful.
- The model tested is the model that will be used. A commitment or an integrity check can strengthen this identity claim by making it harder to switch the model after approval.
- The measurement captured the intended property. A carefully executed test can still use a weak proxy, an unsuitable rubric, contaminated data, or a sample that omits an important part of the problem.
- The property will hold under intended deployment conditions. This is a claim about fresh inputs, users, environments, incentives, and time—not just about the data already placed before the auditor.
These claims reinforce one another, but none should be smuggled in as a consequence of another. A secure way to identify a model does not prove that the test measured fairness well. A high accuracy on a held-out benchmark does not prove useful outcomes in a changing workflow. Evidence from a realistic pilot may reveal problems that a controlled test cannot, but it may also be narrower, noisier, or harder to reproduce. Validation is therefore not a single property attached to a model forever. It is a relationship among a claim, its evidence, and the use that evidence is supposed to justify.
The four claims can come apart in ordinary, non-adversarial circumstances as well. A model may be exactly the version tested and may genuinely perform well on a carefully sampled benchmark, while the benchmark omits rare cases that matter to the organization. A field pilot may involve the right users but use a questionnaire that captures satisfaction rather than harmful outcomes. A statistical test may be precise about the metric it computes while the metric is only a proxy for the decision the organization cares about. Conversely, a troubling result on one narrow sample may identify a problem without establishing that the system fails everywhere. The right response is not to treat every pass as suspect or every failure as conclusive. It is to ask which claim the evidence supports, what assumptions connect it to the intended use, and what new evidence would change the decision.
That discipline matters because the decision is rarely “is this model good?” in the abstract. It is usually closer to “may this system be used for this task, with these people, under these controls, at this stage of its lifecycle?” A procurement team may need evidence about reliability and vendor claims; a developer may need evidence about failure modes before release; an operations team may need evidence about how users respond and how incidents will be detected. The same model can therefore require different assessments for different uses. The object remains identifiable, but the adequacy of the evidence is use-specific.
A proof can preserve identity without expanding scope
Cryptographic model certification makes this distinction unusually clear. In the setting studied by Carter Luck and colleagues, a model provider wants to keep model parameters and training data private, while an auditor wants to assess a property such as accuracy, fairness, or differential privacy. Zero-knowledge proofs can allow the provider to prove a statement about a private model without revealing the model itself. Cryptographic commitments can bind the provider to a particular model, and in some protocols to particular training data. These are valuable protections: they address confidentiality, model switching, and whether a stated computation was performed correctly.
But a proof is a proof of a statement. If the statement says that a committed model satisfies an empirical predicate on a particular audit dataset, cryptographic soundness can establish that fact without establishing a broader one. It does not, by itself, show that the model will satisfy the same property on fresh samples from the underlying distribution. Nor does it show that the audit dataset represented the system’s operational environment or that the predicate was a valid measure of the risk the organization cared about.
The distinction is not merely philosophical. The cryptographic study describes a threat model in which a provider knows the audit data before committing to the model and can control the training data. Under those conditions, the provider may engineer a model that behaves well on the known audit points while behaving differently elsewhere. The resulting proof can be honest: the committed model really can satisfy the tested predicate on the specified data. The problem is that the local statement and the deployment claim are different statements. The attack exploits the gap between them rather than breaking the proof system.
This is why “cryptographically verified” and “validated for deployment” should not be treated as synonyms. The former can describe the integrity and confidentiality of an evidence exchange. The latter asks whether the evidence supports a real use, for a defined population, under defined conditions, with acceptable uncertainty and a way to detect change. Cryptography can secure part of that chain. It cannot choose the right population, define a meaningful construct, or make an artificial test environment become the world in which the system will operate.
The boundary becomes clearer when the roles are made explicit. The auditor can choose or receive a statement and check whether the provider has supplied a proof for it. The provider can keep the model’s internal parameters and proprietary data hidden while demonstrating that the committed object satisfies the relation named in the protocol. If the commitment is binding, the provider has less room to replace that object later. None of this means that the committed training data was independently selected, that the labels represented the real task, or that the audit sample covered the cases that will matter in use. A protocol may faithfully preserve a narrow fact precisely because it does not reveal or test the wider process that produced it.
A deployment decision also has a time dimension. Approval is made at one point, but inputs, users, incentives, and surrounding software can change. A result that was adequate for a limited build-stage question may be inadequate once the system is used at scale, or once people learn how its outputs affect them. This does not make pre-deployment testing pointless. It means the test should be described as evidence for a specified decision and accompanied by a plan for discovering when its assumptions no longer hold.
The diagram’s dotted path is the important warning. A pass at the audit stage may be a legitimate result and still leave the later evidence missing. The missing link is not repaired by repeating the same calculation more securely. It must be addressed by changing the evidence, the sampling relationship, the measurement, or the decision boundary.
Follow the claim before trusting the result
The TEVV-Athlon Framework offers a disciplined way to make those links visible. In its first stage, Articulate & Organize, evaluators state the goal, identify who will use the result, consider resources and challenges, and account for where the system sits in its lifecycle. In Define & Construct, they turn the goal into specific measurement concepts, which NIST calls Metrology Blocks. In Apply & Measure, they select Events—the activities that produce evidence—and the Tools used to elicit, collect, and analyze it. In Synthesize & Interrogate, they ask what the collected evidence means for the original goal and what decision it can inform.
The names matter because they keep different questions apart. A Block is not a benchmark. An Event is not a trustworthiness characteristic. A questionnaire, red-team protocol, annotation schema, or benchmark is not the property itself. Each is part of an evidence path whose usefulness depends on the target and the operating context. NIST’s query-violation example makes this concrete: chatbot helpfulness and violation frequency are different Blocks, and user testing and red teaming provide different evidence about them. One activity cannot silently stand in for the other.
That architecture also prevents a false choice between technical rigor and real-world relevance. Controlled model testing can make comparisons repeatable. User, red-team, and field testing can expose how people, adversaries, and operational settings change behavior. Measurement validation asks whether any of these methods capture the intended concept, whether important cases are missing, whether results generalize, and how much uncertainty should accompany the conclusion. The appropriate combination depends on the risk and the decision.
The central question for the rest of this series is therefore simple but demanding: what does the evidence actually entitle an organization to say? The next step is to follow NIST’s path from an organizational goal to a defined target and a usable body of evidence. Only after that foundation is clear can cryptographic certification be judged fairly—both for the protection it provides and for the deployment claim it cannot create on its own.