What happens after the contract ends

The contract ends on a date. The system does not.

Every engagement has a last day written into it before the first line of code exists. A Phase I ends at six or twelve months. A task order runs its base year. A state platform build wraps at go-live. The software, though, keeps running long after the invoices stop, and somebody who never met the original team ends up responsible for it. That person is the real customer of the work. Most delivery failures we get called in to fix are not failures of the model or the architecture. They are failures of the last two weeks.

The pattern is familiar to anyone who has inherited a system. The repository is there. The README says run setup.sh. The setup script fails on line 40 because it references an internal package registry the vendor took down. There is a training pipeline, but the data it trained on lived in a bucket in the vendor's account. There is a model artifact, and no record of what produced it. The government or the prime paid for a working system and received a working system that only worked in one place, on one machine, in the hands of one person who is now on a different program.

We treat that outcome as a defect in the engagement, not a fact of life. The handoff is designed at kickoff, tested in the middle, and rehearsed before the end. Our engineers write the exit before they write the code, and the customer sees the exit plan in the first two weeks, not the last two.

Documentation a successor engineer can actually use

Most delivered documentation is written for the wrong reader. It describes the system to a program manager who wants to know that it exists. The person who needs it is an engineer, six months later, at 4pm on a Thursday, with a production alert and no context. That reader needs different documents.

The decision log. A dated, numbered list of the choices that shaped the system and the reasoning behind each one. Why Postgres and not a document store. Why the retrieval index is chunked at 800 tokens. Why the classifier threshold sits at 0.62 instead of 0.5. A successor who knows the reasoning can change the decision safely. A successor who finds only the result treats every constant as load-bearing and touches nothing, which is how systems ossify.

The data dictionary and lineage map. Every field, its source system, its refresh cadence, its known defects, and the transformation that produced it. When a downstream number looks wrong, this document is the difference between a two-hour investigation and a two-week one. For any model, this extends to the training set: what it contained, how it was labeled, who labeled it, what was excluded and why.

The operations runbook. One page per failure mode. What the alert looks like, what it usually means, the first three commands to run, and the escalation path. Written from real incidents observed during development, not from imagination. If nothing ever broke during the build, the system was not exercised hard enough.

The evaluation record. The metrics that were measured, the exact procedure used to measure them, and the held-out data the numbers came from. This matters most for AI and ML work, where a claim like "94% accuracy" is meaningless without the denominator. A successor should be able to re-run the evaluation and get the same number to the same decimal place. If they cannot, the number was never real.

The reproducible environment

Documentation describes. The environment proves. Our standing test is blunt: take a machine that has never seen the project, give it the repository and the written instructions, and see whether it reaches a passing test suite without anyone from our team in the room. Everything else in a handoff is commentary on that one result.

Getting there means fixing the things that quietly bind a system to its authors. Dependencies get pinned with lockfiles and hashes, not floating version ranges that resolve differently next quarter. Container images are referenced by digest, because a tag moves and a digest does not. Infrastructure is expressed as code with pinned provider and module versions, and the state file lives in the customer's account. Secrets are read from a named store, never from a developer's shell history. Test fixtures ship with the code and are small enough to run offline.

Model artifacts get the same treatment. Weights are stored with a checksum, the training configuration that produced them, the dataset snapshot identifier, and the commit hash of the training code. A model without that chain is an object of unknown provenance, and in a federal setting an unexplainable artifact is a finding waiting to happen. Our engineers also ship the training run as a script the customer can execute, even when nobody expects to retrain, because the ability to retrain is the ability to own.

One more piece is easy to skip and expensive to omit: the build must work in the customer's network, not only in ours. Restricted egress, proxy inspection, mirrored package registries, and government cloud regions all break assumptions that hold on a commercial laptop. We do that build inside the target environment while the contract is still open and there is still someone to ask.

Knowledge transfer that actually transfers

A knowledge transfer session where the vendor talks and the customer watches is a presentation. It transfers almost nothing. Retention from a two-hour walkthrough is close to zero four weeks later, and everyone in the room knows it while it is happening.

The version that works inverts the roles. The successor drives. Our engineer sits alongside and says nothing unless asked. The session has a task list, and the tasks are real: stand the system up from scratch, push a small change through the pipeline, break something on purpose and recover it, run the evaluation and reproduce the reported number. Whatever the successor cannot do without help is a documentation defect, logged and fixed that week. Three sessions of ninety minutes, spaced a week apart, outperform a single all-day session by a wide margin.

Recording the sessions helps the person who joins later, and the recordings belong in the same repository as the code so they cannot drift apart from it. Sanitize them first if the work touches controlled unclassified information; a screen share full of CUI in an unmanaged video file is a spill, and DFARS 252.204-7012 obliges a contractor to report a covered incident within 72 hours of discovery.

The paperwork of leaving

Handoff has a contractual half that engineers tend to ignore and that decides who is allowed to do what with the delivered work. It should be settled at award, not discovered at closeout.

Instrument	What it governs	When it bites
DFARS 252.227-7013 / -7014	Rights in noncommercial technical data and computer software. Government purpose rights normally run five years from award, then convert to unlimited rights.	When a follow-on competitor asks for the source you delivered.
DFARS 252.227-7018	SBIR data rights. Under the current SBIR/STTR Policy Directive the protection period runs 20 years from award.	When Phase II or a Phase III sole-source depends on who controls the code.
FAR 52.227-14	Rights in Data, General. The civilian-agency baseline, with limited-rights and restricted-software assertions handled through the alternates.	On NIH, DOE, NSF, USDA and state work modeled on federal terms.
CDRL / DD Form 1423	The deliverable list, each item tied to a Data Item Description with a format and a due date.	At final acceptance, when "documentation" turns out to have a specification.
FAR 52.245-1	Government property, including furnished data and equipment. Inventory disposal schedules are due within 120 days of completion of performance.	When nobody can say who holds the loaned hardware.
FAR 4.703 and 4.804-1	Record retention of three years after final payment; closeout targets of six months for firm-fixed-price and 36 months where indirect rates must be settled.	Two years later, during an audit, when the files must still exist.

The practical lesson is that markings are the mechanism. Software and data delivered without the correct restrictive legend can lose the protection the clause would otherwise give it, and the fix is unglamorous: mark the files correctly during development, list the asserted restrictions before award, and keep the assertion list current as the code grows. Our teams maintain that list as a living file in the repository so the closeout version is never a reconstruction from memory.

Why the partner who plans their own exit is the one to hire

There is an old incentive problem in technical services. A vendor whose next contract depends on being irreplaceable has a quiet reason to stay irreplaceable. Nobody writes that down. It shows up as documentation that never quite gets finished, an environment only one person can stand up, and a renewal conversation where the alternative to renewing looks frightening.

A firm that engineers its own replaceability is making a different bet. It is betting that the customer will come back because the work was good, and that being easy to leave is the strongest evidence the work was good. That posture is visible early. Ask for the exit plan at kickoff and watch what happens. A partner who already has one hands it over. A partner who does not starts explaining why it is premature.

Our engagements are structured on the first assumption. We are an SBIR and STTR shop that builds production AI, ML, data and cloud systems, and we bring a standing bench of named engineers, licensed professional engineers and domain specialists into the work. Our team is led by a former professor in technology who ranks in the Kaggle Top 200 of more than 200,000 competitors and holds seven cloud certifications, with twenty years of production federal delivery across five consulting firms, three of them federal. The handoff standard on this page is the one we apply to our own deliveries, on federal, state and commercial work alike, as prime or as subcontractor.

Ask any vendor what handoff includes

Put the question before the award, in writing, and read the answer closely. Vague answers here predict expensive ones later. This is the list we would want asked of us.

• Who is the named successor, and when do they start participating?
• Will the final build run on a clean machine inside our network, with our people driving?
• Which documents ship, and against what specification or Data Item Description?
• How many hands-on transfer sessions, and who holds the keyboard?
• What data rights assertions will you make, and are they listed before award?
• Where do credentials, repositories, container registries and cloud accounts end up?
• Can we reproduce every reported metric ourselves, from the shipped code?
• Who answers questions for the 90 days after final acceptance, and by name?

Write the answers into the statement of work. A handoff that lives only in good intentions competes with the next program for attention in the final month and loses. A handoff that is a numbered deliverable with an acceptance criterion gets done.

Bottom line

Software outlives the contract that bought it, and the value of the work is set by what happens in the year after the vendor leaves. Documentation written for engineers, an environment anyone can rebuild, transfer sessions where the successor does the work, and clean rights and property paperwork are the whole of it. None of it is difficult. It is simply work that has to be scheduled, and a firm that plans its own exit from the first week is the one whose delivery still runs when the paperwork is closed.

Frequently asked questions