The line item that decides everything
A buyer running a fixed-price competition for an AI system usually gets three proposals with three different ideas of what actually changes hands at the end. One offers a trained model and a final report. One offers a deployed application. One offers eleven named artifacts with a pass/fail test attached to each. The prices land within ten percent of each other, so the evaluation turns on technical approach and past performance, and nobody spends much time on the deliverables paragraph. The difference shows up eleven months later, when the program office asks what happens if it wants a different vendor to extend the system.
Fixed price is the right instrument for a lot of AI work. FAR 16.202-1 puts cost risk on the contractor and holds the price regardless of what performance ends up costing. FAR 16.202-2 says the type fits when the contracting officer can establish a fair and reasonable price at the outset, which in practice means the scope is definite enough to price. The trap is that AI scopes are easy to write vaguely and hard to write definitely. A vague fixed-price scope moves one particular risk back onto the buyer, in a form nobody priced: the risk that what arrives cannot be operated, verified, or extended by anyone except the firm that built it.
The fix is mechanical, and it belongs in the solicitation rather than in the debrief. Write the deliverable list so every item is a file, a repository, or a running thing someone can open. Then write acceptance so every item passes or fails a test the government can run without the vendor in the room.
Why "a model" is a bad deliverable
A model is a set of weights. Weights are the output of a process and carry almost no information about that process. Handed a checkpoint file and a slide deck, a receiving team cannot answer the questions that matter. What data produced this? Which records were held out, and how were they chosen? What score did it get, on which metric, against what alternative? What preprocessing has to happen at inference time so that a production record looks like what the model saw in training? When the answers live in one engineer's head or in a notebook on a laptop, the buyer has acquired a dependency rather than an asset.
The usual failure mode is not that the model is bad. Often it works fine on the day of the demo. The failure is that its quality is unverifiable and its performance is unreproducible, so the first time production data shifts, the only available move is to re-hire the original firm at whatever price it names. That is what vendor lock-in looks like in AI work. It is also why OMB's 2025 memorandum on AI acquisition (M-25-22) directs agencies to write AI contracts that avoid lock-in and keep government data and the artifacts derived from it under government control.
There is a contractual reason too. A fixed-price deliverable has to be acceptable or rejectable. FAR 52.246-4, the Inspection of Services clause for fixed-price service contracts, gives the government the right to require reperformance at no increase in contract amount when services do not conform to requirements. That right is worth nothing against a deliverable with no conformance definition. "A trained model" cannot fail inspection. "A model scoring at or above 0.82 macro-F1 on the government-held test set, reproduced by government staff from the delivered harness on government hardware" can fail, which is exactly why it is worth writing.
The six artifacts that make up a real deliverable list
A reproducible evaluation harness. One command, run on the buyer's machine, that regenerates every number in the final report. It carries the held-out data (or a pointer plus a hash of it), the metric implementations, the split definitions, the random seeds, and a pinned environment. The test is simple: a government engineer clones the repository, runs the command, and gets the same numbers within a stated tolerance. If the numbers only reproduce on the vendor's laptop, they are a claim rather than a measurement.
The data pipeline, with provenance. The code that turns source records into model inputs, plus a record of where each source came from and what was done to it. Provenance here means record-level lineage: this feature came from that field of that file, pulled on that date, transformed by that function at that commit. Regulated buyers need it because a decision the system makes will eventually be challenged and somebody has to trace it back to source. Everyone else needs it because six months later nobody remembers why the address field gets normalized twice.
A measured baseline. The number the new system has to beat, measured on the same data with the same metric. Sometimes the baseline is the current manual process, timed and scored by sampling real cases. Sometimes it is a deliberately dumb model: logistic regression, a keyword rule, a nearest-neighbor lookup. This is the single most useful line in an AI report and the one most often missing. Without it, "91% accurate" means nothing, because the keyword rule may score 89% and cost nothing to run or maintain.
The model or the system. Weights or a service, delivered with the training code, the exact configuration that produced it, and the version of the data it saw. A model card is the right form for the summary: intended use, training data description, measured performance broken out by the subgroups that matter, known limits, and the conditions under which the thing should not be used. The format traces to Mitchell et al. (2019) and now shows up across federal AI guidance. It takes an afternoon and answers most of what a reviewing official will ask.
Deployment artifacts. A container image referenced by digest rather than by tag, an infrastructure definition, per-environment configuration, health and readiness endpoints, and a demonstrated rollback path. If the target is a government cloud, add what the authorization boundary needs: logging configuration, the STIG or CIS benchmark applied to the base image, and a software bill of materials in SPDX or CycloneDX form. SBOMs stopped being a nice-to-have for federal software after Executive Order 14028; the NTIA minimum elements define the floor. A container handed over without a digest and a bill of materials is a thing that cannot be re-created.
Documentation a successor can use. Not a slide deck. A README that takes a new engineer from a clean machine to a passing test suite. An architecture note saying what each component does and why it exists. A runbook for the three or four failure modes the system actually has. An honest limitations section. The acceptance test for this deliverable is a person rather than a document review: hand it to an engineer who has never seen the project and watch whether they can run the evaluation and deploy to a test environment in an afternoon.
Weight a buyer should place on each artifact when comparing bids
Editorial weighting from public acquisition guidance and engineering practice. Illustrative, not a measured statistic.
The ordering surprises people, so it is worth stating plainly. The model is the artifact a buyer should weigh last, because it is the only one on the list that can be rebuilt from the others. Give a competent team the pipeline, the frozen splits, the harness, and the baseline, and they can produce a model in weeks. Give them a model and nothing else, and they cannot tell you whether it is any good.
Acceptance criteria you can actually run
FAR 37.601(b) requires a performance-based contract to carry a performance work statement, measurable performance standards, and a method of assessing the contractor against those standards. The quality assurance surveillance plan contemplated by FAR Part 46 is where that method lives. For AI work, "measurable" carries a specific meaning that most scopes miss. The measurement has to be executable by the government, on data the vendor did not pick, against a threshold written down before the work starts.
Three properties make an AI acceptance criterion testable. First, it names the data: a sequestered test set, defined at kickoff, held by the government, never shown to the vendor at any point. Second, it names the metric and the threshold, including a per-class or per-subgroup floor. Aggregate accuracy hides the failures that get a system pulled from service, so a criterion reading "macro-F1 at or above 0.82 overall and at or above 0.70 for every class with at least 50 test examples" is far stronger than a single headline number. Third, it names who runs the test and where. A number the vendor reports is a claim. A number the government reproduces is a measurement.
| Deliverable | Language that cannot be enforced | Language that can |
|---|---|---|
| Model performance | "Achieves high accuracy on representative data." | "Macro-F1 ≥ 0.82 on the government-held test set, reproduced by the government from the delivered harness." |
| Latency | "Responds in real time." | "p95 end-to-end latency ≤ 400 ms at 20 requests per second on the specified instance type." |
| Data pipeline | "Includes documented data processing." | "Rebuilds the full feature set from raw sources in one command; output hashes match the delivered manifest." |
| Documentation | "Complete technical documentation." | "A named government engineer, working alone from the README, reaches a passing test suite in under four hours." |
| Deployment | "Deployed to the target environment." | "Container digest matches the delivered SBOM; deploy and rollback both demonstrated in the test environment." |
| Traceability | "Results are traceable." | "For any ten sampled outputs, the system returns source record, transform version, and model version." |
Notice what the right-hand column has in common. Every criterion can be checked by someone who was not in the room while the work happened. That property is what converts a deliverable list from a description of good intentions into something a contracting officer can enforce under FAR Part 46.
Structuring milestones so risk is retired early
The default shape of an AI project runs backwards. Data wrangling in month one, modeling in months two and three, deployment in month four, and the question of whether the thing was ever worth building gets answered last, when the budget is spent. Fixed price makes the incentive worse. A firm that discovers in month three that the available data cannot support the task has every reason to ship something rather than say so.
Invert the order. Each milestone should answer one question that could kill the project, taken in descending order of how likely it is to do the killing.
Milestone order for a 16-week fixed-price build
Two structural points hold this together. The off-ramp at milestone two has to be real, priced, and written into the contract. FAR 39.103 gives buyers modular contracting for information technology precisely so a system can be acquired in increments that are separately useful, and a feasibility increment that ends in an honest no-go is a good outcome at a fraction of the full price. A firm that will not accept an off-ramp is telling you it intends to deliver something regardless of what the data says.
The second point is that money should follow risk retirement rather than the calendar. Tie each payment to acceptance of a named artifact, not to elapsed months, and keep the largest single payment behind the government-run acceptance run at milestone five. Performance-based payment mechanics under FAR Subpart 32.10 exist for this shape of work and are worth the paperwork on anything sizeable.
Data rights get decided in the deliverable list
Under DFARS 252.227-7014, the government's rights in noncommercial computer software follow who paid for the development. Exclusively government funding yields unlimited rights. Mixed funding yields government purpose rights, which convert to unlimited rights after a five-year period under DFARS 227.7203-5(b) unless the parties negotiate otherwise. Development exclusively at private expense yields restricted rights. DFARS 252.227-7017 requires an offeror to assert those restrictions at proposal time, and assertions left out then are difficult to add later.
SBIR-funded work sits under its own regime: the SBIR data protection period runs twenty years from award under the current SBIR/STTR Policy Directive and the corresponding DFARS clause, which is strong protection for the firm and a real planning constraint for the buyer.
The practical consequence is easy to miss. Rights clauses attach to identified artifacts, and the deliverable list is what identifies them. If the evaluation harness never appears as a deliverable, no rights clause has anything to grab. Buyers who want the option of re-competing a follow-on should list the harness, the pipeline, the data manifests, and the documentation as separate line items, each with its own delivery date and acceptance criteria, rather than folding them into "final technical report." In DoD contracts that means separate CDRL entries on DD Form 1423 with the right data item descriptions behind them.
What to strike from a vendor's deliverable list
- Status decks counted as deliverables – weekly reporting is a management obligation, not an artifact anyone will open again.
- "Access to the vendor platform during the period of performance" – an endpoint you lose at contract end is a subscription with a delivery date, not a deliverable.
- A final report as the only technical artifact – the report describes the work; it is not the work.
- Metrics chosen after results are in – if the metric is not fixed at kickoff, the acceptance criterion is whatever the results happened to support.
- Demos that run only on vendor infrastructure – a demonstration running on the vendor's account with the vendor's keys leaves nothing behind.
- Training data described only in prose – a paragraph about data sources is not the same as a manifest with hashes and pull dates.
The cost of doing this, stated honestly
None of it is free. Somebody has to write the harness, cut and freeze the splits, produce the manifests, wire provenance through the pipeline, and write a README a stranger can follow. That is real engineering time, and a firm that includes it will price above a firm that does not. A buyer comparing bids on price alone will systematically pick the proposal that leaves the least behind.
Scale the ask to the size of the buy. Below the simplified acquisition threshold of $250,000 (FAR 2.101), an elaborate CDRL structure is more overhead than the contract can carry; pick the three items that preserve optionality and let the rest go. Those three are the evaluation harness, the data pipeline with its manifests, and the README that gets a successor running. Everything else can be rebuilt if those exist. Above that threshold, and on anything meant to reach production, the full list earns its cost the first time the program needs a second source or a change of scope.
Do the arithmetic before the solicitation goes out. Weigh the incremental cost of the deliverable list against the cost of the follow-on you would have to sole-source without it. The list is usually a modest fraction of the base award. The captive follow-on is usually a multiple of it.
The one-page list to paste into a scope of work
- Evaluation harness that reproduces every reported number on government hardware in one command
- Sequestered test set defined at kickoff and held by the government throughout
- Data pipeline source code plus manifests with source, pull date, and hash for every input
- Record-level provenance from any output back to the source records and transform versions
- Measured baseline: current process and a trivial method, scored on the same data and metric
- Model or service with training code, exact configuration, and a model card
- Container image by digest, infrastructure definition, per-environment config, demonstrated rollback
- SBOM in SPDX or CycloneDX form covering everything shipped
- README, architecture note, runbook, and limitations, validated by a successor test
- Acceptance criteria with named metric, named threshold, named test data, named test executor
Bottom line
Fixed price rewards precise scopes and punishes vague ones, and AI scopes are unusually easy to write vaguely. The deliverable list is where that vagueness either gets resolved or gets deferred to whoever inherits the system. A buyer who writes ten specific artifacts with ten runnable acceptance tests will pay a little more up front, get bids that are genuinely comparable, and keep the option to take the work somewhere else. A buyer who writes "trained model and final report" has written a purchase order for a relationship.
Frequently asked questions
It is, when the scope is definite enough to price, which FAR 16.202-2 makes the governing test. The way to get there is to break the work into increments and put the uncertain part first. A short, separately priced feasibility increment against real data removes most of what makes AI hard to price, and the build increment that follows can be firm-fixed-price with confidence on both sides.
Set the threshold relative to a baseline instead of in absolute terms, and set the baseline in the first milestone. "Beats the current manual process on the same sampled cases by at least X points of macro-F1" is enforceable and does not require knowing the ceiling in advance. Fix the metric and the test data at kickoff even if the numeric threshold is set at milestone two.
It is a slice of the data, cut at the start of the project, held by the buyer, and used once at acceptance. The vendor never sees the records or the labels. This matters because any set a team can measure against repeatedly gets fit to, gradually and usually without anyone intending it. A set used one time is the only kind that gives an honest read at acceptance.
In DoD software work, DFARS 252.227-7014 sets rights by funding source: unlimited for exclusively government-funded development, government purpose rights for mixed funding, restricted for development at private expense. SBIR-developed data carries its own twenty-year protection period. Rights attach to identified artifacts, so anything you want rights in has to appear on the deliverable list by name.
Require that the government reproduce the final numbers itself, from the delivered harness, on its own hardware, as a condition of final acceptance. That one requirement forces the pinned environment, the frozen splits, the manifests, and the documentation into existence, because none of it can be faked at the end. It also tends to separate the bidders quickly.