Software sustainment has a shape everyone knows. Defects get fixed, dependencies get patched, the operating system moves and the application follows, and once a year the accreditation package is refreshed. The system does not get worse on its own. An AI component does. Its performance is a function of how much the world it sees still resembles the world it was trained on, and that resemblance decays from the day of fielding whether or not anyone touches the code. A sustainment contract written for the first kind of system, applied to the second, produces a program that pays to keep a model running while it quietly stops being right.
This is written for the sustainment program manager at a prime who has inherited, or is about to inherit, a fielded model. The question is what the sustainment scope should actually contain, how to price it, and what belongs in the option years so the program is not renegotiating in month four of a five-year period of performance.
What actually degrades, and how fast
"Drift" is used loosely enough to be unhelpful. Four distinct things happen after fielding, they have different causes and different fixes, and a sustainment plan should name them separately.
The inputs change. A sensor is recalibrated or replaced with a different model. A new platform variant enters service. A document format changes upstream. An interface starts sending a field it used to omit. These are step changes, not gradual slides, and they are detectable without any labels at all by comparing what the model sees now against what it saw during test. This is the most common cause of a sudden performance drop and the easiest to catch.
The world changes. The mix of what the system encounters shifts: new classes appear, old ones become rare, seasonal patterns move, an adversary changes behavior. This is gradual and it is the case people mean by drift. It needs labeled data to measure, which is why it is usually detected late.
The relationship changes. The mapping from input to correct answer moves, because a policy changed, a definition was revised, or a threshold in the operational concept was adjusted. The model is now correctly computing an answer to a question nobody is asking anymore. No amount of input monitoring finds this; only a person who knows the mission does, which is why the sustainment process needs a channel to the operational community and not just a dashboard.
Everything around the model changes. Library versions, hardware refresh, the runtime, the operating system baseline, the security control set. These do not change the model's mathematics but they can change its numbers, and a program that cannot rebuild its model from source at all is one dependency deprecation away from a system it can no longer produce.
What belongs in an AI sustainment scope, ranked by what it prevents
Editorial weighting, illustrative rather than measured. The last row is deliberately low: an alarm nobody is authorized to act on produces a meeting.
The governed data pool is the asset
The most valuable thing a fielded AI system produces is not its outputs. It is the record of what it saw and what happened next, and a sustainment program that does not capture it is throwing away the only reason the system can improve.
What a governed pool contains, and why each part is there. Sampled inputs, collected by rule rather than by convenience: a random sample for unbiased reference, plus targeted sampling of high-uncertainty cases, cases near the decision threshold, cases flagged outside the operating envelope, and any case an operator overrode. The system's output and the model version that produced it, so any record can be traced to an exact artifact. Operator actions, particularly overrides with a reason code, which are the cheapest labels a fielded system generates and the ones most often discarded. Outcomes where the mission produces them, when the eventual truth becomes known later. And provenance and handling metadata on every record: where it came from, what classification and handling rules apply, what consent or authority covers its use, and whether it may be used for training as distinct from evaluation.
That last field is the one that most often blocks a retraining eighteen months in. Data collected for one purpose is not automatically available for another, and the question of whether fielded data may be used to train is a policy and legal question with a real answer that should be obtained once, early, in writing, rather than discovered as a blocker later. Ask it in the first month of sustainment, not the first month of the retraining.
Governance also means the pool is versioned. A retraining that cannot be reproduced is not a sustainment activity; it is an experiment. Every training set is a named, hashed, immutable snapshot, and every fielded model records which snapshot produced it. That single discipline is what lets a program answer, three years later, why the model does what it does.
A retraining cycle the program office will trust
The reason program offices are cautious about model updates is not superstition. It is that a model update is a change to system behavior with no source-code diff to review, and the normal configuration control instincts have nothing to grip. The fix is to give the change board something to review that is at least as informative as a diff.
The cycle we run has six steps, and each produces an artifact.
Trigger. Retraining starts for a stated reason from the trigger table: a monitoring indicator crossed its threshold, the scheduled cadence arrived, a known input change occurred, or the operational community reported a policy change. The trigger is recorded. A retraining with no stated trigger is how programs drift into continuous unreviewed change.
Data assembly. A new immutable snapshot is cut from the governed pool with the selection rule written down, including how the class balance was handled and what was excluded. Held-out portions follow the same split rule used at original test, and the sealed evaluation set stays sealed.
Training and conversion. Run from source through the recorded pipeline, producing an artifact with its full provenance chain: data snapshot, code version, dependency versions, conversion and quantization steps, hashes throughout.
Evaluation. The same evaluation used at the original milestone, per operating condition, with confidence intervals, plus a direct comparison against the currently fielded model on the same data. This comparison is the artifact the change board actually wants, because the question is never "is the new model good" but "is it better, and where is it worse".
Regression review of the assurance argument. Which branches of the fielded system's assurance case does this change touch, and what evidence has been regenerated. With a case that includes a change-impact map, this is a short document. Without one, it is a re-argument.
Staged fielding. Shadow first where the architecture permits, then a limited population, then general, with the previous artifact retained and a rollback that has been rehearsed rather than assumed.
Note what is missing from that list: any step where the model is updated automatically without review. Continuous training into a fielded defense system is a design most program offices will not accept, and for good reason. What is achievable, and worth negotiating for, is a pre-approved envelope: agreement in advance that a model change which passes the defined evaluation and stays inside stated bounds is handled through an expedited path rather than a full re-authorization. Negotiating that envelope during the original fielding, when goodwill is high and nothing has gone wrong, is far easier than after.
Two ways to shape the sustainment scope
The contract shape determines what the program can actually do, and it should follow how much change is expected rather than what is administratively convenient.
| Dimension | Care and feeding scope | Continuous capability scope |
|---|---|---|
| What is bought | Monitoring, defect response, dependency and platform currency | The above plus a funded retraining and re-evaluation cadence |
| Pricing shape | Fixed monthly amount with a defined response commitment | Committed team at a fixed monthly rate, or fixed-price cycles |
| Labeling effort | Not funded, so no defensible post-fielding number exists | Funded per cycle, with the volume stated in the scope |
| What the option years hold | Continuation, and a growing gap between model and mission | Cadence, data growth, and a planned technology refresh |
| Best fit | Stable task and stable inputs, short remaining life | Live mission data, evolving conditions, multi-year fielding |
| Failure mode | Degradation found by a user complaint, fixed by an urgent modification | Cadence becomes ritual if triggers and thresholds are not enforced |
Most programs that field a model on live mission data need the second shape and buy the first, because the first is what the sustainment cost model knows how to price. The argument that wins the funding is not about model quality. It is that the alternative to a funded cadence is an unfunded urgent modification at an unpredictable time, and the program office generally prefers the version it can plan.
What the option years should contain
Option years are where AI sustainment is either set up to succeed or set up to be renegotiated. Five things belong in them explicitly.
A stated evaluation cadence with labeling volume attached. Not "periodic evaluation" but a number of cycles per year and a number of records labeled per cycle. Without the labeling hours in the scope, the evaluation does not happen, because labeling is the part nobody has spare capacity for.
A retraining allowance with a defined trigger set. A stated number of retraining cycles per period that may be drawn on when a trigger fires, so that responding to a real change is an execution decision rather than a contract action.
Technology refresh. Model tooling and runtimes move faster than platform baselines. Scope the periodic work of moving to a supported dependency set before the current one is deprecated, because doing it under duress is far more expensive.
Data pool growth and its handling. Storage, curation and labeling of the growing pool, with the handling rules revisited as the pool grows and its aggregate sensitivity changes.
A defined transition-out package. Whatever happens at the end of the period, the next party needs the pool, the pipelines, the evaluation code, the provenance records and the runbooks. Making that a priced deliverable rather than an assumption is the difference between a clean recompete and a capability that dies with the contract.
Sustainment failures we see most often on fielded models
Editorial weighting, illustrative rather than measured. The last row is deliberately low: a fielded model rarely fails because it is not the newest design.
Dividing the work between the prime and a specialist partner
Sustainment is where a specialist scope has to be drawn carefully, because the prime's team owns the system and will own it long after any subcontract ends. The division that works splits by artifact, not by activity.
The prime's team holds the fielded system, the operations, the user relationship, the change board interface, the security posture and the accreditation. They run the monitoring in production because they run production. The specialist scope is the model-specific engineering: maintaining the evaluation pipeline and the data pool tooling, running each retraining cycle end to end, producing the comparison and assurance-impact artifacts the change board reviews, and doing the technology refresh work on the model side.
That division has a property worth naming: it is designed to become unnecessary. From the first month, the goal is that the prime's sustainment engineers can run a retraining cycle themselves. The pipelines are theirs, in their repositories, and the cycle is documented as a procedure rather than as expertise. A specialist partner whose value depends on being the only party who can run the pipeline is a risk to the program, and a program manager is right to test for it. Ask, in the first review, what it would take for the prime's own team to run the next cycle unaided, and treat a vague answer as a finding.
How we work inside a prime's program
Precision Federal builds AI, data platforms and software and delivers them into production inside federal agencies. On a sustainment program we come in as the specialist subcontractor on the model, the data pool and the evaluation cycle.
The first four weeks. We inventory what exists: whether each fielded model can be rebuilt from recorded source, what monitoring is running and what it would catch, what data is being retained and under what authority, what the evaluation code can still reproduce, and what the change process with the program office actually is. The output is a written sustainment assessment with a gap list, each gap costed, plus a draft trigger table and a proposed cadence. Programs regularly find that the highest-value item on that list is the cheapest one: turning on operator override capture.
The first year. The data pool and its governance, the evaluation pipeline made reproducible and running on a schedule, the first full retraining cycle executed end to end with the change board artifacts, and the procedure documentation that lets the prime's own engineers run the next one. Everything in the prime's environment, repositories and pipeline, written to the program's standards and CDRL formats.
What the prime keeps. All of it. The data pool and its tooling, the pipelines, the evaluation code, the models and their provenance records, the documentation, the procedures and the customer relationship. Intellectual property in the delivered work is assigned by a present written assignment; any pre-existing tooling we bring is named, carved out and licensed back perpetually so the sustainment team is never blocked. The exit package is a condition of final payment: repositories, pipelines, infrastructure as code, configuration, credential rotation and runbooks, with a handover rehearsal in which the receiving team runs a full cycle while our engineers watch. Where the prime wants us named on a bid, we are content with a defined technical scope and committed key personnel, which on a scored proposal generally reads better to an evaluator than an unnamed pool.
How it is priced. The sustainment assessment works as a firm-fixed-price first milestone. The ongoing work fits either shape: a committed team at a fixed monthly rate across the base and option years, which suits a program with live mission data and an active cadence, or fixed-price evaluation and retraining cycles with written acceptance criteria, which suits a program that wants the cost tied to countable events. Both are compatible with a small fixed-price first increment, which is how we prefer a new teaming relationship to begin.
Bottom line
A fielded model is not a delivered artifact. It is a system whose fit to the mission decays, and sustaining it means funding the loop that measures the decay and corrects it. That loop has four parts: a governed, versioned data pool that grows from fielded operations with handling and training authority settled in writing; monitoring with a trigger table naming the response and the decision authority; a retraining cycle whose artifacts give a change board more to review than a model file, including the direct comparison against the fielded model and the assurance-impact map; and an expedited change path negotiated with the program office before it is needed. Put the cadence, the labeling volume, the retraining allowance, the technology refresh and the transition-out package in the option years, and the program can keep the capability current for the life of the system. The first step is one email with a one-page brief describing the fielded system and the current sustainment scope, and we return a scoped, priced statement of work.
Frequently asked questions
By trigger, with a scheduled floor. The triggers are a monitoring indicator crossing a threshold, a known change to the inputs such as a sensor or format change, or a reported change in policy or operational definitions. The scheduled floor exists because gradual change in the world is not always visible until it is measured. Fund a stated number of evaluation cycles per year with a stated labeling volume, and a retraining allowance that can be drawn on when a trigger fires.
Monitoring with a written trigger table naming the response and the decision authority. A governed, versioned data pool with capture rules, provenance and handling metadata. Periodic truthed evaluation with the labeling hours actually funded. A retraining cycle producing the artifacts a change board needs. Technology refresh on the model tooling and runtimes. And a priced transition-out package so the pool, pipelines and provenance records survive the end of the contract.
Sometimes, and the answer has to be obtained in writing early rather than assumed. Data collected for one purpose is not automatically available for another, and classification, handling rules and the authority under which the data was collected all bear on it. Record the answer as a field on every record in the pool, distinguishing permission to use for evaluation from permission to use for training. Asking in the first month of sustainment is cheap. Discovering it during a retraining is not.
Give the change board something better than a model file to review: the stated trigger, the data snapshot and its selection rule, the full provenance chain, the evaluation per operating condition with confidence intervals, a direct comparison against the currently fielded model showing where it is better and where it is worse, and a map of which assurance-case branches the change touches. Then negotiate an expedited path for changes that pass the defined evaluation and stay inside agreed bounds, before it is needed.
A stated evaluation cadence with a per-cycle labeling volume, not the phrase "periodic evaluation". A retraining allowance with a defined trigger set, so responding to a real change is an execution decision rather than a contract action. Technology refresh for model tooling and runtimes before the current set is deprecated. Storage, curation and labeling for the growing data pool with handling rules revisited as it grows. And a defined, priced transition-out package.