The customer says it in a program review, almost as an aside. Someone on their staff saw a demonstration, or read a memo, or watched a peer office publish something, and now they want to know why the system your program runs does not do that. The contract was competed and awarded before any of this was written into a requirement. There is no line item for it, no CDRL that names it, and no funded task order that covers it. The question that reaches the program manager is not technical. It is whether this can be done inside the contract that exists, or whether it becomes a new acquisition that takes eighteen months and invites competitors into an account the program has held for years.
The answer is usually that it can be done inside the contract, and that the way it is scoped in the first two weeks decides whether it stays there. This is written for the program manager and the chief engineer who own that decision, from the side of the table where the schedule, the burn rate and the customer relationship all sit.
Why this is a scope question before it is an engineering question
Every path forward runs through the same gate: is the new work within the scope of the contract the government already awarded. Contracting officers answer that question by asking whether the modification is of a nature that potential offerors would reasonably have anticipated under the original competition. If a reasonable offeror reading the original solicitation would have expected work of this kind to fall inside the effort, a modification is defensible. If the change alters the nature of what was bought, it is a new procurement, and issuing it as a modification exposes the award to a protest on sole-source grounds.
That framing is more favorable to program teams than it first appears, because most federal systems contracts are written around a mission outcome and a system, not around a technology list. A contract to sustain and improve a case management system, to operate a logistics data environment, or to modernize an inspection workflow describes the work in terms of what the system does for the mission. Adding a classification model that routes cases, or a forecasting component that ranks parts for replenishment, is a change in method rather than a change in purpose. The statement of work usually already carries language about analysis, decision support, workflow automation or system enhancement that reaches it.
Where teams get into trouble is by describing the work as the technology rather than as the outcome. "Deploy a large language model" reads like a new capability that nobody competed. "Reduce the manual review queue by automating first-pass triage against the existing business rules, with the same audit trail and the same appeal path" reads like the system enhancement the contract was written to buy. The second description is also more honest about what the customer wants, which is why it survives review by a contracting officer who has seen a hundred of these.
Conditions that keep new AI work inside an existing contract
Editorial weighting, illustrative rather than measured. The last row is deliberately low: a genuinely new system is a new acquisition, and pretending otherwise invites a protest.
Four paths, and what each one costs in calendar
There are four workable routes and they are not alternatives so much as a sequence. Programs that handle this well often use two of them in order: something small under existing labor to establish that the thing works, then a funded modification that makes it part of the baseline.
A pilot under existing labor. The fastest path and the one with the least paperwork. Existing hours on the contract are redirected to build a narrow, measured demonstration against real program data inside the program's own environment. No new money, no new scope, no contracting action. What it buys is evidence: a measured number the customer can act on, and an architecture that has already met the environment's constraints. What it cannot buy is production. A pilot funded from slack in the labor mix ends when the slack ends, so it has to be scoped to produce a decision, not a system.
An engineering change proposal. The formal route on programs that carry configuration control. The change is written against the system baseline, priced, reviewed by the configuration control board, and incorporated. It is slower than a task order modification but it produces something the others do not: the change becomes part of the documented baseline, which means the next option year sustains it rather than treating it as an unfunded add.
A task order modification. On an IDIQ or a multiple-award vehicle where the program runs as a task order, the cleanest instrument is usually a modification to the existing order, or a new order under the same contract. The in-scope test applies to the order and to the parent contract. A new order under an existing IDIQ is a competition among the holders unless an exception applies, which is a real event but a short one compared with a new full-and-open acquisition.
An other transaction as a companion. Where the work is genuinely prototype in nature and the program office has access to an other transaction authority, an OT prototype project can run alongside the production contract. It moves faster, admits nontraditional partners easily, and, when the prototype is completed successfully and the original solicitation said so, can support a follow-on production award without further competition. The cost is that it lives outside the program contract, so integration and sustainment have to be planned deliberately rather than inherited.
| Path | Typical time to start work | What it produces | Main risk |
|---|---|---|---|
| Pilot under existing labor | Days to two weeks | A measured result and a working reference architecture | Ends when the labor slack ends; no path to sustainment on its own |
| Engineering change proposal | Weeks to a few months | A change incorporated into the system baseline | Board cycle time; the change competes with other baseline changes |
| Task order modification | Weeks | Funded scope inside the existing order | In-scope determination; ceiling and funding availability |
| New order under the same vehicle | One to three months | Clean scope with its own CDRLs and funding | Fair opportunity competition among vehicle holders |
| Other transaction prototype | Weeks to months | A prototype with a defined follow-on production path | Sits outside the program contract; integration must be planned |
How to scope it so it stays in scope
The scoping work is a writing exercise with an engineering spine. Four decisions carry most of the weight.
Anchor the description to the existing performance work statement. Read the statement of work and find the paragraphs the new work sits under. There are almost always two or three: a system enhancement clause, a data management clause, a decision support or analysis clause. Write the change so that it cites them by paragraph and explains, in one sentence each, why the work is of the kind those paragraphs describe. A contracting officer who has to construct that argument on their own will hedge. One who is handed it, and who agrees with it, will sign.
Keep the outputs inside the existing deliverable structure. If the program already delivers a monthly technical status report, a software version description and a test report, the new work should produce content inside those, not a new CDRL. New deliverable items are the loudest signal that the nature of the effort has changed. Existing CDRLs with new content in them are the quietest.
Do not move the accreditation boundary. A component that runs inside the boundary the system already holds is a configuration change. A component that requires an external service, a new network path, or a new data store outside the boundary is a security event, and security events reopen questions the program has already answered. The architecture choice and the contracting choice are the same choice here.
Keep the data where it already is. The contract gives the program rights to handle certain data for certain purposes. Training a model on that data for the purpose of improving the system the contract covers is usually inside those rights. Sending it to a service that retains it, or using it to build something the program does not deliver, is not. Write the data handling down in the change itself so nobody has to ask.
The engineering, specifically
The reason so many of these additions stall is not the contracting. It is that the component is designed as a demonstration and then cannot be made into part of a system that already has uptime commitments, an accreditation, an audit trail and a user base that will not tolerate surprises. The architecture that survives is recognizably boring, and it looks like this.
The model sits behind the existing service layer, not beside it. The application already has an API tier, an authentication path and an audit log. The inference component becomes another internal service that the existing tier calls, with the same identity, the same logging and the same failure handling as any other dependency. It never becomes a second front door. This one decision is what keeps the security boundary intact and what makes the component removable if it underperforms.
Every inference is written to the same record the human decision writes to. A prediction that lives only in a model server's log is unusable for audit, for accuracy measurement, and for the eventual question of whether the component helped. The record needs the input identifier, the model version, the output, the confidence or score, the timestamp, and, critically, what the human did afterward. That last field is the whole measurement program. Without it there is no way to compute agreement, no way to detect drift against a real label, and no way to answer the customer when they ask whether the thing works.
The component fails to the old behavior, not to an error page. When the model service is down, slow, or returns a low-confidence result, the workflow routes to the manual path that existed before. Users experience a queue that is a little longer, not a system that is broken. This is what makes the addition safe to turn on incrementally, and it is what makes the phased rollout believable to the customer.
Model provenance is a build artifact, not a memory. The version of the model, the data snapshot it was trained on, the code that produced it, the evaluation results, and the person or pipeline that approved it are recorded together and shipped with the release. When a reviewer asks in month nine why a decision came out the way it did, the answer is retrievable. Where this is missing, the first hard question from an assessor becomes a re-engineering project.
Measurement is designed before the model is. The program picks the metric that matches the mission decision, not the one the model naturally produces. For a triage component, the useful metric is usually not overall accuracy; it is the rate of missed items in the class that matters, at a review volume the staff can actually absorb. Deciding that first sets the threshold, the human review policy, and the acceptance criterion in the contract change, all at once.
What decides whether the component survives its first year
Editorial weighting, illustrative rather than measured. The last row is deliberately low: enthusiasm without a number creates pressure without justification.
Failure modes that turn an in-scope change into a new acquisition
Four patterns account for most of the cases where a program loses control of this work.
The demonstration is built somewhere it can never be deployed. A prototype on a commercial account with a copy of program data is a prototype that cannot be moved, and once the customer has seen it they expect it in production on the schedule of the demonstration rather than the schedule of an accreditation. Build in the environment the system lives in, on the first day, even if that costs three weeks at the start.
The scope is written as a technology purchase. A change request that names a model family, a vendor product and a token budget invites the reviewer to ask why this was not competed. A change request that names a workflow, an accuracy floor and a queue reduction is an engineering change to a system the government already bought.
The pilot produces enthusiasm instead of a number. A demonstration that impresses the customer without measuring anything creates pressure without justification. When the modification is priced, there is nothing to point at except a good meeting. A pilot should end with a written finding: what was measured, on what data, against what baseline, and what it would take to run it in production.
Sustainment is nobody's line item. A model is not a feature that ships and stops changing. It needs monitoring, periodic re-evaluation against fresh labels, and a retraining path. If the change does not carry those hours into the option year, the component decays quietly and becomes the customer's example of why the program overpromises.
How a specialist partner works inside the prime's contract
Precision Federal builds AI, data platforms and production software inside federal agencies, and on programs like this we work as a subcontractor under the prime's contract, under the prime's direction, inside the prime's boundary. The shape of that arrangement is straightforward and we prefer to state it plainly before anyone signs anything.
What the first weeks produce. Two weeks in the program's own environment, on the program's own data, with a written finding at the end. That finding names the measurable baseline the current process achieves, the metric that matters for the customer's decision, what the component would have to reach to be worth deploying, where it sits in the existing architecture, and what changes in the accreditation package. It is written so the prime can hand it to the contracting officer and to the customer without rewriting it. Where the answer is that the work is not worth doing yet, the finding says that, which is cheaper for everyone than discovering it in month five.
What the prime keeps. The code, the models, the data pipelines, the documentation and the deployment automation, delivered under the prime's data rights posture as required by the government contract, with a present written assignment rather than a work-for-hire recital. The customer relationship stays entirely with the prime. Our engineers speak to the government through the channel the prime designates, with the rules written down before the first meeting, and we are comfortable being named as a subcontractor with a defined scope or working entirely behind the prime's brand, whichever fits the program.
How it is priced in shape. Either fixed-price milestones tied to written acceptance criteria, so the prime carries no schedule risk on our side, or a committed team at agreed labor categories that maps cleanly into the prime's own cost structure and the contract's rate schedule. On a change that has to be priced for a modification, the milestone shape is usually easier to defend, because the government sees a result rather than a level of effort.
How to start. One email with a one-page brief. The system the component must live inside, named by product and version. The data, where it sits, and who can grant access. The security destination and the accreditation the program holds. The contract instrument and the date that matters. We return a scoped, priced statement of work written so it can be attached to a modification request.
Turning the pilot into next year's baseline
The step teams most often miss is the last one. A component that works, that the customer likes, and that lives on redirected labor is not yet part of the program. It becomes part of the program when three things happen.
- It enters the system baseline through the configuration process the program already runs. Architecture description, interface documentation, version description and test artifacts, treated exactly like any other subsystem. Once it is in the baseline, sustaining it is not a new decision each year.
- Its sustainment hours are in the option-year estimate. Monitoring, evaluation against fresh labels, retraining cadence, and the engineering time to respond when the data shifts. Naming these as ordinary sustainment, in the same table as database administration and patching, is what keeps them funded.
- Its performance is reported in the same status report as everything else. One line in the monthly report showing the metric that matters, the volume processed and the human override rate. A customer who sees that number every month does not need to be persuaded at option exercise, and a program that reports it is very hard to displace.
That last effect is the one worth planning for deliberately. A capability the customer uses daily, that is documented in the baseline, that reports its own performance, and that the incumbent team maintains, is a strong position at the next competition. It is also, for the same reasons, the kind of thing that quietly grows the program's scope rather than opening it.
The conversation with the customer
How this is presented matters nearly as much as how it is built. Program offices are cautious about this class of work for reasons that have nothing to do with any particular contractor: they have watched demonstrations that did not survive contact with real data, and they have read enough guidance about oversight and accountability to know that an unexplainable decision in a mission workflow is their problem, not the vendor's.
So the presentation that works is the conservative one. Here is the narrow decision we propose to assist. Here is the measured baseline of how that decision is made today. Here is what the component achieves on your data, measured this way. Here is the human review policy: what the component does on its own, what it routes to a person, and what it never touches. Here is what is logged, and how you would answer an inspector general or an oversight question about a specific case. Here is what happens when it is wrong, and here is how you turn it off.
That framing is not a sales tactic. It is the actual engineering, described honestly, and it is far more persuasive to a career program office than a demonstration is. It also happens to be exactly the content a contracting officer needs to see in order to be comfortable that this is a change to a system the government already bought.
Bottom line
Adding AI to a running program is usually an in-scope change, and whether it stays that way is decided by how the work is described and where the component is placed. Describe it as an enhancement to the mission outcome the contract already covers, cite the paragraphs it sits under, keep the outputs inside the existing deliverable structure, and put the component inside the accreditation boundary the program already holds. Start with a short measured pilot on real data in the real environment so the modification is priced against evidence. Then put the result into the baseline and the sustainment estimate, and report its performance monthly. Programs that do this hold the account and grow the scope. Programs that build an impressive demonstration outside the boundary hand the work to a new acquisition.
Frequently asked questions
Often yes. The test a contracting officer applies is whether the change is of a nature that offerors would reasonably have anticipated under the original competition. Most systems contracts are written around a mission outcome rather than a technology list, so automating a step in a workflow the contract already covers is a change in method rather than in purpose. It stays in scope when the description is anchored to existing statement-of-work paragraphs, the outputs fit inside existing deliverables, and the component runs inside the boundary the program already holds.
A short pilot funded from existing labor, built in the program's own environment against real program data. It requires no contracting action and produces the two things the next step needs: a measured result the customer can act on, and an architecture that has already met the environment's constraints. Scope it to produce a written finding rather than a system, then use that finding to price an engineering change or a task order modification that carries the work into production and into the sustainment estimate.
Usually not. New deliverable items are the clearest signal that the nature of the effort has changed, and they attract scope review. If the program already delivers a technical status report, a software version description and test artifacts, the new work should produce content inside those. Add the architecture description, the model provenance record and the evaluation results as sections of documents that already exist rather than as new items on the contract data requirements list.
Under the prime's direction, inside the prime's environment and security boundary, with deliverables that flow to the government through the prime. The prime keeps the code, the models, the pipelines, the documentation and the customer relationship, with a present written assignment of intellectual property rather than a work-for-hire recital. Pricing is either fixed-price milestones tied to written acceptance criteria or a committed team at agreed labor categories that maps into the prime's cost structure and the contract's rate schedule.
Placement and provenance. A component that sits behind the existing service layer, using the system's identity, logging and audit path, is a configuration change to an accredited system. One that requires an external service, a new network path or a new data store outside the boundary is a security event that reopens settled questions. Alongside placement, record model version, training data snapshot, producing code, evaluation results and approval as build artifacts shipped with the release, so an assessor's questions have retrievable answers.