"Walk away clean" is a slogan until it is a paragraph in a signed contract. This post is the paragraph.
Why a clause, not a promise
Most AI services contracts treat the artifacts of the engagement — code, prompts, evaluation sets, model weights, runbooks, dashboards — as ambient outputs that are "of course yours." In practice, the moment the engagement ends those artifacts split into three buckets: things the client actually owns, things the client uses but cannot move, and things that were never written down at all. The first bucket is small. The second is the lock-in. The third is where the institutional knowledge evaporates the day the vendor's last engineer logs out.
A handshake does not survive that split. A clause does. The exit-ready artifact clause is the paragraph that fixes the three buckets before any work starts, while there is still negotiating power to fix it (Class E — "ownership is whatever you wrote down" is the consistent finding of every honest IT outsourcing post-mortem).
The clause, in plain English
Here is the version SWU writes into the master services agreement. It is short on purpose.
Exit-Ready Artifacts. On the effective date and continuously throughout the engagement, all artifacts produced for the Client are delivered into a Client-controlled repository the Client can read, fork, and revoke vendor access to at any time, with no waiting period. Artifacts include source code, prompts and prompt templates, evaluation datasets and held-out test sets, model configuration and any fine-tuning artifacts the Client paid for, infrastructure-as-code, runbooks, the operations ledger, and the dashboards used to verify acceptance. The Vendor warrants that on the day the engagement ends, a competent third party can read those artifacts and operate the system without further assistance from the Vendor. The Vendor will, on request, sit for one paid handover session with that third party. After the handover, the Vendor has no continuing rights of access.
Four sentences. They do most of the work.
What each sentence is actually fixing
Sentence one — repository on day one, not day ninety. The artifacts live in the client's environment from the first commit. Not the vendor's GitHub organization with a promised "we'll transfer it at the end." The client controls the substrate; the vendor is a contributor with revocable access (Class C — observable in every SWU engagement we run). If the vendor cannot agree to this, the engagement has not started.
Sentence two — the list. The list is long because the lock-in lives in the items people forget. Code is usually fine; everyone remembers code. The evaluation set is what makes the system testable by a successor. Prompt templates are where months of tuning live. The operations ledger is the only honest record of why the system behaves the way it does on a Tuesday morning. If the list is short, the clause is decorative.
Sentence three — the competent-third-party test. This is the falsifier. The vendor is not warranting "the artifacts exist." The vendor is warranting that a stranger of reasonable skill could pick them up and run the system. That is a much higher bar, and it forces documentation to be written for an outside reader rather than as an aide-memoire for the team that wrote it.
Sentence four — the paid handover and the hard stop. One session, paid, after which the relationship ends. No on-call retainer the client did not ask for. No "we still hold the keys to the AWS account." The relationship ends cleanly because the clause says it ends cleanly.
What this rules out
Writing this clause on day one rules out a family of vendor behaviors visible in most AI services proposals we have reviewed in the last twelve months (Class C). It rules out hosting the production system in the vendor's cloud account, prompt templates kept in a private vendor wiki, evaluation datasets the vendor describes as "proprietary methodology," and runbooks that exist only as Loom recordings on the vendor's drive. Every one of those is a lock-in mechanism, and every one is solved by a single paragraph in the contract.
It also rules out something quieter: the slow erosion of the client's ability to understand their own system. If the artifacts live in the client's repository from day one, the client's engineers read them as they land. By month six they know the system as well as we do. That is the point.
What this asks of us
The clause cuts both ways. To honor it, we write documentation as if a stranger is reading it, keep the evaluation set version-controlled in the open, and push to the client's repository with their review instead of reconciling later. More friction — and the friction that makes the handover work.
What to do with this
If you are evaluating any AI services engagement — ours or someone else's — ask for the exit-ready artifact clause in writing before you sign. If the vendor hedges on any of the four sentences, that is the answer to whether they intend to be transferable.