Glossary
Statement of work
The document defining what an outside firm will deliver and by when, which is what a later disagreement gets settled against.
In plain terms
The written answer to what exactly you are paying for. Everything before it is a conversation, and conversations are remembered differently by the two people who had them, which is the entire reason the document exists.
Why it matters
Because AI projects are unusually easy to describe in ways that sound specific and are not. Improving how a team handles enquiries, or making internal knowledge easier to find, are recognisable goals and neither says what will exist at the end, so a document written in that register cannot settle a disagreement about whether the work was completed.
How it works
Deliverables and activities are different things, and confusing them is the commonest fault. A configured system, a written handover and a trained group are things that either exist or do not; workshops held and support provided are descriptions of effort, and effort can be delivered in full while leaving nothing behind.
Acceptance is the clause that decides everything and is the one most often vague. Who decides the work is finished, against what, and how long they have to say so: without those three, completion becomes a matter of opinion at exactly the moment the two parties have started disagreeing.
What the buyer has to provide belongs in it too. Access to systems, decisions within a stated time, people available to be trained: these are the commonest cause of a project running late, and a document silent about them makes the delay look like the supplier's fault when it frequently is not.
AI work has a specific difficulty about the standard being met. Quality is a judgement rather than a threshold, so the useful version defines the evaluation rather than the outcome: this set of cases, judged by these people, against this description of a good answer, agreed before the work starts rather than argued after it.
Change is normal in this category and the document should expect it. A project that learns something in its first fortnight ought to change, and a statement of work with no path for that either blocks the improvement or gets quietly ignored, which leaves the organisation with a signed document describing a project nobody is running.
Two ways to write the same line
Seen in the wild
Defining an assistant rollout as a configured deployment and a trained group rather than as workshops delivered.
ChatGPTAgreeing the evaluation set for a search deployment before the work starts rather than after.
GleanNaming which systems the buyer must give access to, and by when, for an automation build.
Make
Common misconceptions
People assume
A detailed scope is the important part.
In fact
Acceptance is. A long scope with no statement of who decides the work is complete, against what, and within what period leaves the only contested question unanswered, and that question only arises once both sides have stopped agreeing.
People assume
It is the supplier's document.
In fact
It binds both sides, and the buyer's obligations are the half most often left out. Access, decisions and people are what projects actually wait on, and a document that omits them turns a shared delay into an apparent supplier failure.
Questions
- What is the single most valuable clause?
- Acceptance. Naming who signs off, what they are judging against and how long they have converts completion from an opinion into a process, and it is worth more than any amount of additional detail in the scope section above it.
- How do you write one for work whose quality is a judgement?
- By defining the judgement rather than the outcome. Agreeing the cases to be tested, who evaluates them and what a good answer looks like, all before the work begins, turns an argument about quality into a procedure both sides already accepted.
- Should it allow for the project changing?
- It should assume it will. Work in this category routinely learns something early that makes the original plan wrong, and a document with no route for that either prevents the improvement or gets ignored, which leaves a signed description of a project nobody is actually running.
Key takeaways
- Deliverables exist or do not; activities can be completed leaving nothing behind.
- Acceptance is the clause that settles the only contested question.
- The buyer's obligations belong in it, because projects wait on them.
- Where quality is a judgement, define the judgement before starting.
Last checked August 2026