Working is not a property a model has
A deliverable is done when it conforms to the specification. That rule holds for a report, a schema, an API, or a dashboard, and it comes apart the moment the deliverable is a model. A classifier does not conform or fail to conform. It is right a certain fraction of the time, on a certain population, at a certain decision threshold, and all three of those qualifiers have to be written down before anybody can say whether the thing works. Buyers who skip the step land in one of two places: an acceptance clause nobody can satisfy, or an acceptance clause the vendor satisfies on a test set of its own choosing.
The gap is not a legal one. Acceptance law is settled and short. The gap is that a probabilistic system needs a different kind of specification than deterministic software, and most buyers write the second kind out of habit. A statement of work saying the system "shall correctly classify submitted documents" is unenforceable in both directions: the vendor cannot prove it and the buyer cannot disprove it. Saying it "shall achieve 95% accuracy" is worse, because it sounds precise and is not. Accuracy on which data, drawn how, labeled by whom, at what threshold, across how many items.
What follows is the structure that makes those questions answerable, and the language that turns each answer into something enforceable.
What the contract already says about acceptance
On a federal award the machinery sits in FAR Part 46, and it is brief. FAR 46.501 states that "acceptance constitutes acknowledgment that the supplies or services conform with applicable contract quality and quantity requirements," and that acceptance may occur before, at, or after delivery. FAR 46.502 makes acceptance the contracting officer's responsibility. FAR 46.401 adds the piece most buyers forget: "Quality assurance surveillance plans should be prepared in conjunction with the preparation of the statement of work," specifying all work requiring surveillance and the method of surveillance.
The clauses carry the teeth. FAR 52.246-2, Inspection of Supplies—Fixed-Price (Aug 1996), says at paragraph (k) that "acceptance shall be conclusive, except for latent defects, fraud, gross mistakes amounting to fraud, or as otherwise provided in the contract." FAR 52.246-4, Inspection of Services—Fixed-Price (Aug 1996), requires the contractor to maintain an inspection system acceptable to the Government and lets the Government require re-performance at no additional cost or "reduce the contract price to reflect the reduced value of the services performed." For commercial buys, FAR 12.402 flips the default: "the Government will rely on the contractor's assurances that the commercial product or commercial service tendered for acceptance conforms to the contract requirements," while preserving the right to refuse nonconforming items and noting that complex or critical applications may need different acceptance procedures.
One word carries all the weight above: conform. Every clause defers to the specification and says nothing about what conformance means for a system whose outputs are distributions. That is the buyer's job, and citing more regulation does not do it. One caution for 2026: the FAR overhaul launched in 2025 is reissuing large sections through agency deviations and proposed rules, so confirm the deviation text your contracting activity is using. The substance above has not moved.
You are accepting three things, not one
The artifact. Weights or a trained pipeline, the code that produced them, the container that runs them, the documentation, and the rights attached to all of it. This part behaves like ordinary software acceptance: it either exists at the named commit or it does not.
The measured behavior. Numbers produced by running the artifact against a specific body of data under a specific procedure. This is the part needing new language, because the number is an estimate and estimates have error bars.
The operability. Whether somebody other than the vendor can rerun the evaluation, deploy the artifact, watch it in production, and retrain it when the world moves. A model that scores well and cannot be reproduced by the buyer is a demo, not a deliverable.
Most acceptance disputes look like arguments about the second item and are failures in the first or third. The vendor hits the number, the buyer cannot reproduce it, and neither party wrote down what reproducing it would take.
Where acceptance language has to change
Each row below is a place where language copied from a software acceptance clause produces an unusable criterion.
| Dimension | Deterministic software deliverable | Machine learning deliverable |
|---|---|---|
| What conformance means | Every specified behavior occurs on every run | A measured rate clears a floor, on a named population, at a named threshold |
| What the test is | A test suite the vendor can run and the buyer can rerun | An evaluation against held-out data the vendor did not train on and ideally has never seen |
| What a failure looks like | A reproducible defect with a stack trace | A rate below the floor, or a slice below its floor while the average passes |
| Who owns the test data | Rarely contested; fixtures ship with the code | The central question. Whoever holds the test set controls the verdict |
| Re-performance | Fix the defect, rerun the suite, done | Retrain or retune, then re-measure on a set that has not been burned by the first attempt |
| What survives acceptance | Warranty on defects | Warranty on defects plus a drift obligation, because inputs change after signature |
The instrument comes before the number
Before arguing about whether the floor is 88% or 92%, settle who builds the ruler. A held-out evaluation set is an instrument, and its properties decide what any number measured on it means. Four questions settle it.
Who assembles it. Strongest is buyer-assembled, drawn from the buyer's operational records and sampled the way real work arrives rather than the way a clean dataset arrives. Second best is jointly assembled under a written sampling rule. Weakest is vendor-supplied, which measures the vendor's skill at picking a test.
Who holds it. If the vendor has the answers, the number drifts upward through ordinary human iteration, with nobody intending anything. Federal buyers now have policy language behind them here. OMB Memorandum M-25-22, Driving Efficient Acquisition of Artificial Intelligence in Government (April 3, 2025), states that agencies "must use data they have defined (e.g., agency validation and testing datasets) when conducting any independent evaluations," that the data used "should not be accessible to the vendor, and should be as similar as possible to the data used when the system is deployed," and that vendors "must provide the access and time necessary for agencies to complete independent evaluation." The same section says contracts "must detail the examination, testing, and validation procedures of the vendor and must not prohibit agencies from internally disclosing how the vendor conducts testing or the results of testing." A commercial buyer has no memo to cite and can write the identical terms into a master services agreement.
When it freezes. Name a date. After it the set is sealed, the labels are final, and any change is a bilateral modification with a written reason. An unfrozen test set is not an instrument.
How many attempts it allows. A held-out set burns a little every time somebody sees the result and adjusts. Two formal attempts is a reasonable allowance; a third should be scored against a reserve partition sealed at the same time and never opened until needed.
A threshold with no sample size behind it is a wish
This is where most acceptance criteria quietly fail, and it is arithmetic rather than opinion. Suppose the criterion is 90% and the vendor delivers exactly 90% on the acceptance run. What that establishes depends entirely on how many items were in the set. The bars below show the lower end of the 95% confidence interval around that measured 90%. The bar is not a score. It is the worst true rate still consistent with what was observed.
Lower 95% bound on a measured 90% pass rate, by size of the held-out set
Wilson score interval, 95%, computed for an observed 90% pass rate at each sample size. Arithmetic, not an estimate or an editorial weighting.
Read the bottom row again. A vendor demoing 27 correct answers out of 30 is showing a system whose true rate could be 74%. The full intervals say the same thing from the other side: 90% on 100 items spans 82.6% to 94.5%; on 500 items, 87.1% to 92.3%; on 2,000 items, 88.6% to 91.2%. Precision costs data, and there is no clever way around it.
Two more numbers are worth carrying into a negotiation. First, the rule of three: if a test produces zero failures in n trials, the 95% upper bound on the failure rate is roughly 3/n. Zero failures in 100 items only bounds the failure rate below 3%; getting to 0.1% takes about 3,000 clean items. A vendor reporting a perfect run on a small set has demonstrated far less than the report implies. Second, comparison is much more expensive than measurement. Distinguishing a system that is truly 90% from one that is truly 85%, at 95% confidence with 80% power, takes on the order of 690 items per arm. Separating 90% from 88% takes roughly 3,800 per arm. If the acceptance criterion is "better than the incumbent process," the evaluation set has to be sized for a comparison, not for a point estimate, and almost none of them are.
One number is the wrong shape for a criterion
Whatever single metric goes in the contract becomes the thing that gets optimized, sometimes in ways that damage the workflow the system serves. A criterion naming only accuracy on an imbalanced task is satisfied by a model that always predicts the majority class. A criterion naming only recall is satisfied by a model that flags everything. Write a family of floors and ceilings instead, all measured at one stated operating point.
The operating point. The decision threshold, named as a number, fixed before the acceptance run. Metrics quoted without one are not comparable across runs.
A precision floor and a recall floor together. Both, at that threshold. One without the other is trivially satisfiable.
An abstention or escalation ceiling. A system that can decline to answer will trade coverage for accuracy if the criterion allows it. Cap the share of items it may push to a human, or the accuracy floor means nothing.
Latency and cost per item. A p95 latency ceiling and a cost-per-thousand-items ceiling, measured under the concurrency the workflow will see. Accuracy bought with unbounded compute is not deliverable.
A slice floor. Covered in the next section, and the one most often missing.
For federal buyers this is the shape FAR 37.601 already asks for on performance-based work: measurable performance standards addressing quality, timeliness, and quantity, with a method of assessing performance against them. FAR 37.602 requires the work be described "in terms of the required results rather than either how the work is to be accomplished," which is exactly right for a model. M-25-22 recommends the same tools, naming statements of objectives, performance work statements, and quality assurance surveillance plans.
Slice floors keep the average from hiding the failure
An aggregate number is a weighted average over whatever the test set happened to contain. A system at 92% overall can sit at 61% on the document type that makes up 6% of volume and carries most of the risk. The aggregate criterion passes. The deployment fails in week three, on exactly those items, in front of exactly the people who were skeptical.
The fix is to name the slices in the criterion and give each its own floor, usually lower than the aggregate floor and never absent. Slices worth naming: input format or channel, source system, region, time period including the most recent months, document or case type, size bucket, and any class protected under nondiscrimination law where the application touches individuals. Each slice needs enough items to support a real measurement, which is why slice floors force the evaluation set to grow.
This is not a novel demand. The GAO Artificial Intelligence Accountability Framework (GAO-21-519SP, June 30, 2021) organizes federal AI oversight around four principles: governance, data, performance, and monitoring. OMB Memorandum M-25-21 (April 3, 2025) requires an AI impact assessment before deploying a high-impact use case, documenting "the quality and appropriateness of the relevant data and model capability," including, where applicable, "information included in the data about classes protected by Federal nondiscrimination laws." A vendor asked for slice results at acceptance is being asked for something the buyer will need anyway.
Write the test procedure, not just the target
The number is half the criterion. The other half is the procedure that produces it, and it belongs in the contract as its own attached document, the way a quality assurance surveillance plan attaches to a performance work statement. FAR 37.604 lets the Government either write that plan or require offerors to propose one. Either way the acceptance test procedure names:
- The exact artifact under test — container image digest, model version, commit hash. Not a branch name.
- The input manifest — a file listing every item in the acceptance set with a checksum, so both parties can prove they ran the same thing.
- The environment — hardware class, driver and runtime versions, batch size, concurrency, and any external service the pipeline calls.
- Determinism settings and tolerance — seeds fixed where possible, plus a stated tolerance band for the residual nondeterminism floating-point and GPU kernel scheduling introduce. Demanding bit-identical outputs across hardware starts a fight nobody wins.
- Who runs it and who observes — buyer-run on buyer infrastructure is cleanest; vendor-run with the buyer present and per-item outputs retained is the workable compromise.
- The scoring code — delivered, readable, rerunnable. Metric definitions differ across libraries, and averaging choices alone can move a reported number several points.
- Per-item output retention — the predictions, not just the summary. Without them no dispute is adjudicable and no slice is recomputable.
- Time-boxing — how long the run may take and what counts as a timeout failure.
- The disposition rule — what happens on a pass, on a near miss, and on a clear miss, written before anyone knows which one occurred.
The sequence that makes acceptance survivable
Acceptance goes badly when the first time both parties look at a number together is the day money depends on it. Every step below is cheap compared with a disputed delivery.
Acceptance sequence for a model deliverable
Step 3 is the one buyers cut and should not. A dry run on data nobody cares about proves the harness works, the container starts, the outputs parse, and both parties' scoring code agrees. Finding a metric-definition disagreement on the day of the formal run turns a technical difference into a commercial one.
Provisional acceptance and the latent-defect problem
FAR 52.246-2(k) makes acceptance conclusive except for latent defects, fraud, and gross mistakes amounting to fraud. For deterministic software the doctrine works, because a latent defect is a real thing with a discoverable cause. For a model it fits poorly. When a system that measured 91% at acceptance falls to 74% in month four because the input population shifted, calling that a latent defect is a stretch, and litigating the point is worse than writing around it.
Write around it. Split acceptance into provisional and final, with a defined operating window between them. Provisional acceptance releases most of the payment and starts the clock. During the window the system runs in shadow mode or on limited live volume, the same metric family is computed on real traffic, and the criterion is that live performance stays within a stated band of the acceptance-run performance. Final acceptance and the retention release happen at the end.
Give the near miss its own path. FAR 46.407 lets a contracting officer accept nonconforming work, but not for free: where the nonconformance is critical or major, the contracting officer must modify the contract for "an equitable price reduction or other consideration," document the basis for amounts withheld, and obtain concurrence from the activity responsible for the technical requirements. The framework works in commercial agreements too. A system landing at 87% against an 88% floor may still be worth taking, and the right response is a priced acceptance with a remediation schedule rather than a binary rejection that helps nobody.
The monitoring window is part of the criterion
A model degrades even when nothing about it changes, because the inputs change. Criteria that end at signature leave the buyer holding that risk alone.
M-25-21 requires agencies to "conduct testing and periodic human review of AI use cases," with monitoring "designed to detect unforeseen circumstances, changes to an AI system after deployment, or changes to the context of use or associated data." M-25-22 pushes the obligation into the contract itself: contractual terms "must provide the contracting agency the ability to regularly monitor and evaluate (e.g., on a quarterly or biannual basis, based on the needs of the program) performance, risks, and effectiveness of an AI system or service." It goes on to encourage agencies to "require vendors to meet performance standards before deploying a new version of an AI system or service or to roll-back to a previous version if a new version fails to meet performance standards."
Commercial buyers should copy that last clause in spirit. Version upgrades are the most common source of silent regression in a deployed model, particularly when a hosted third-party model sits inside the pipeline and the provider changes it. Three terms cover it: re-measurement on any version change, evidence before the new version carries production traffic, and a rollback right if it misses the same floors. Then define the drift trigger in numbers — metric, threshold, measurement window, who computes it — and state the remedy that fires when it trips.
Criteria that will not hold up
A number with no denominator. "95% accuracy" with no evaluation set defined and no size stated. The most common defect, and the arithmetic above prices it out.
Comparative language with no baseline measurement. "Better than the current manual process" is enforceable only if the current process was measured first, on the same items, by the same rules. Measuring the baseline is often the most valuable week of the engagement, and it has to happen before the model exists.
A vendor-supplied test set. Whoever assembles the instrument sets the answer. That is not an accusation of bad faith; it is how iterative development works.
Satisfaction language. "To the satisfaction of the buyer" and "industry-standard performance" import a dispute rather than settle one. There is no industry standard accuracy for a task defined by one organization's documents.
Accuracy on a task with a lopsided base rate. If 96% of records are clean, a model that flags nothing scores 96%. Name precision and recall on the minority class, or the criterion measures the base rate rather than the model.
Acceptance that ignores the human workflow. The model is a component. If a reviewer checks every output anyway, model accuracy is the wrong measurement; measure handling time, escalation rate, and end-to-end error after review. Buyers who write the workflow metric get systems that help. Buyers who write the model metric get systems that score.
Bottom line
Defining done for a probabilistic system is four decisions and one attachment. Decide who assembles and holds the evaluation set and when it seals. Decide the metric family, the operating point, and the slice floors, sized so the numbers mean something. Decide the test procedure in enough detail that either party can run it and get the same answer. Decide what the window after signature obligates and what happens when the numbers move. Then attach the procedure instead of burying a sentence in a statement of work. The regulation, the clause selection, and the payment milestones all follow from those four in an afternoon. Buyers who make the decisions before award get a system they can hold to a standard. Buyers who leave them to delivery week are negotiating without an instrument, and the vendor brings the only one in the room.
Frequently asked questions
It should name the evaluation set and its size, the decision threshold the metrics are measured at, a floor for precision and a floor for recall rather than one accuracy number, a ceiling on abstention or escalation, latency and cost ceilings under realistic load, and a floor for each named slice. It should also reference an attached test procedure describing how those numbers get produced and by whom.
The buyer, wherever the data and the security posture allow it. OMB Memorandum M-25-22 (April 3, 2025) directs agencies to use data they have defined for independent evaluation, states that the evaluation data should not be accessible to the vendor, and requires vendors to provide the access and time needed to complete it. Commercial buyers can write the same terms into a master services agreement.
Enough that the confidence interval is narrower than the decision being made. A measured 90% on 100 items has a 95% Wilson interval of roughly 82.6% to 94.5%; on 500 items it tightens to about 87.1% to 92.3%. A comparative criterion costs far more: separating a true 90% from a true 85% at conventional confidence and power takes on the order of 690 items per arm. Slice floors raise the requirement again, since each named slice needs its own usable sample.
Decide before the run, not after. On a federal fixed-price services award, FAR 52.246-4 lets the Government require re-performance at no additional cost or reduce the contract price to reflect the reduced value of the services performed, and FAR 46.407 allows acceptance of nonconforming work with an equitable price reduction or other consideration, with technical concurrence and a documented basis. A near miss usually deserves a priced acceptance with a remediation schedule; a clear miss deserves a re-performance attempt against the reserve partition.
Not if the agreement is written well. FAR 52.246-2(k) makes acceptance conclusive except for latent defects, fraud, or gross mistakes amounting to fraud, a poor fit for performance loss caused by shifting inputs. The practical answer is a provisional acceptance period of 30 to 90 days with live measurement, a numeric drift trigger with a named remedy, and a re-measurement and rollback obligation on any version change. M-25-22 directs federal contracts to include ongoing monitoring rights and encourages rollback terms.