If we cannot write the sentence that ends the engagement before we start it, we are not ready to start it. That sentence lives at the top of every SWU scoping document.
What "exit condition" means here
An exit condition is the falsifiable, testable statement that — when true — ends the engagement on good terms. Not a milestone. Not a status. A line a stranger can read and check. Most contracts describe what the vendor will do; the exit condition describes the state of your business when we stop doing it (Class C — observable in every SWU scoping document we publish).
We write it before any code, any prompt, any architecture sketch. If the sentence is hard to write, the work is not yet scoped. That is useful information, and it usually saves a client a five-figure mistake.
The four-line template
Every SWU scoping doc opens with these four lines, filled in, before anything else is agreed:
- Exit condition. One sentence. Present tense. Describes the operating state of the client's system, not our activity. Testable by someone who was not in the room.
- How we know it is true. The artifact, dashboard, or measurement an outside operator can inspect to verify the exit condition holds.
- Who signs that it is true. A named person on the client side. Not a role, not a committee. The person who, when they say "this is done," it is done.
- What is explicitly out of scope. The two or three adjacent things the exit condition might be confused with, written as negations so no one can re-read this later and claim we agreed to them.
Four lines. They live at the top of the document until handover. We refer to them in every working session.
A worked example
For an intake-triage build, the four lines might look like this:
- Exit condition. Inbound support tickets are auto-classified into three queues with a published accuracy and a logged override rate; the override rate is reviewed weekly by support ops.
- How we know it is true. A dashboard showing accuracy on a held-out evaluation set, an override-rate timeseries from production, and a runbook the on-call engineer uses to retrain.
- Who signs. Head of Support Operations, named.
- Out of scope. Sentiment scoring. Auto-replies to customers. Cross-language routing.
A stranger can read those four lines and tell you whether the engagement is done. That is the whole point.
Why we do this before anything else
Three reasons, all uncomfortable in different ways.
First, it forces the client to decide what "done" means while they still have the negotiating power to say no. Once code is in flight, "done" tends to drift toward whatever the vendor has built (Class E — scope drift is one of the best-documented failure modes in services work; the canonical pattern is in The Mythical Man-Month and every honest delivery retrospective since). Writing the exit condition up front fixes the target before momentum bends it.
Second, it changes who carries the risk of vague success criteria. Without an exit condition, every disagreement at the end of the engagement is a he-said-she-said. With one, there is a sentence to point at and a named signer who has the authority to evaluate it. The vendor cannot quietly redefine completion at sign-off.
Third, and most importantly, the exit condition is the falsifier for the engagement itself. If we cannot reach it, the engagement failed, and we say so on the ledger (Class C). That is what "transparency architecture" means in practice — the project's success has a public, pre-committed test, not a retroactive narrative.
What this rules out
Writing the exit condition first rules out a particular kind of comfortable vagueness (Class C): kickoff decks that list "objectives" instead of an end state, scopes whose acceptance criteria are "client satisfaction," and time-and-materials engagements with no written notion of when they should stop. We do not work that way, and the four lines are how we make sure.
If a prospective client cannot agree on those four lines after one or two scoping sessions, the right answer is to not start the engagement yet. We will say so, and we will refund the scoping fee. That is also in the contract.
What to do with this
If you are evaluating any AI services engagement — ours or someone else's — ask the vendor to write the exit condition, the verifier, the signer, and the out-of-scope list before you sign. If they cannot or will not, that is the answer to whether the work is scoped.