The rule is simple: at any point in our engagement, if you fire us tomorrow, you have a working thing you own. Not a promise of a thing. A thing.
What "exit-ready at every point in time" means
Most contracts treat the handover as an event at the end. Ours treats it as a property of every week. On any Friday, if the engagement ended, the client has a runnable artifact that does some useful subset of the agreed work, plus receipts that prove what it does and what it does not (Class C — observable in the artifact list and the ledger).
We ship small, complete increments rather than building one large invisible thing and revealing it at the end. The first increment may be tiny — a script, a single prompt with its evaluation, a one-page runbook. But it is yours, it runs, and you understand it.
The artifact list — what you own, in writing
By default, every SWU engagement produces and transfers the following, listed in the contract as deliverables you own outright (Class C):
- The code. Source, in a repository you control, under a license you control. We do not retain a privileged copy. If a private dependency from another engagement is in scope, we either rewrite it for yours or disclose and price it — never silently bundle.
- The prompts and prompt history. Every prompt that ships, plus the iteration log showing the versions we tried and why we picked the one we shipped.
- The evaluation set. The actual inputs and expected behaviors we use to decide whether a change is an improvement. Without it, future maintainers cannot tell whether an edit broke anything.
- The dependency manifest. Every external service, API key holder, model version, and library the system relies on, with current monthly cost and a substitution note for each. Clients have a right to know how their thing will die.
- The runbook. A plain-language document that walks an operator through deploying, running, observing, and rolling back the artifact. Written for someone who has never met us.
- The ledger. Every claim, decision, falsifier, and cost from the engagement, evidence-classed (A/B/C/E/F/U), in the document we have been jointly editing since week one.
If any item is missing on handover day, we have not delivered.
The runbook test — how we know it is real
The runbook test is the falsifier we apply before sign-off. Someone outside the engagement — a person who was not in any of our working sessions — receives the runbook and the artifact, and deploys the system, runs it against the evaluation set, and produces the expected outputs. Every question they have to email us is a bug in the runbook, which we fix before sign-off.
This is uncomfortable, and we keep doing it. We have failed the runbook test more than once (Class C — failures are in the ledger with the specific gap that fired). Without this test, "documentation" tends to mean "documentation that makes sense to the people who already know the system."
What the handover meeting looks like
When an engagement ends — at planned conclusion, because the falsifier fired, or because the client took it in-house — the handover is one meeting:
- The repository is transferred and access on our side is revoked. We confirm we no longer have admin.
- The dependency manifest is walked end-to-end. Anything that lived on our infrastructure is migrated or replaced before the meeting; we do not leave a bridge.
- The runbook is opened and the operator performs one full deploy-and-rollback cycle live, with us watching but not touching.
- The ledger is exported to a format the client controls, and the final entries are signed by both sides.
- We tell the client, in writing, what we think the next three risks for the system are. This is not a sales hook; it is the last thing the partnership clause requires of us.
After that meeting, the engagement is closed and we are no longer involved unless re-hired under a new scope.
What this rules out
Being exit-ready at every point rules out a few common practices (Class C): we do not build inside platforms whose export format is deliberately useless; we do not bundle internal tooling as an undisclosed dependency; we do not hold prompts or eval sets "for safekeeping" after handover; we do not write retainer clauses for "ongoing optimization" the client cannot inspect and cancel any month. Those practices are common, they are extractive, and we wrote them out of the contract (Class E — vendor lock-in via opaque deliverables is well documented across the AI services market; our response is to make the deliverable inspectable by design).
The standing offer
If you are evaluating any AI services engagement, the runbook test is a fair question to put to the vendor in writing: Can someone outside the engagement deploy the artifact from your runbook, and what happens to my ownership of the code, prompts, and eval set on the day I end the contract? The answer separates a partnership from a hostage situation.