Fixed scope needs a definition of done. On ordinary software that definition writes itself: the invoice exports, the permissions hold, the page loads under two seconds. Each one is a sentence somebody can check, and two people checking it reach the same answer.
AI features break that. The equivalent sentence is "the assistant answers correctly," and it is not a criterion at all. It is an invitation to argue in week six, when both sides have already spent the money.
The argument you are buying
Here is how that argument goes, and it goes this way almost every time. The build is done. Someone senior tries the feature, asks it four questions, and two answers are wrong or thin. The verdict arrives as a feeling: this is not ready. The team responds with its own numbers, which are real and were measured honestly, and the numbers do not touch the feeling, because nobody agreed in advance which questions counted.
Both sides are behaving reasonably. There is simply no shared instrument. So the engagement extends, unpaid or badly paid, until the feeling changes or the relationship does.
What goes in the contract instead
Four things, all of them agreed before the first commit, and all of them boring on purpose.
A test set the client wrote. Between eighty and two hundred real inputs, pulled from the client's own tickets, documents, or logs, with the expected outcome recorded next to each. Not questions the build team invented, because a team that writes its own exam passes it. Assembling this is usually the single most valuable day of the engagement, and it regularly surfaces that two departments disagree about what the correct answer is. Better to find that in week one than to encode one department's view in a shipped product.
A threshold with a number in it. Not "high accuracy." Something closer to: 92% of the set answered correctly, no answer citing a document the user cannot access, and 95th-percentile latency under four seconds. The number is a negotiation, and it should be, because it prices the work. What matters is that it exists on paper before anyone is invested in the answer.
A named judge. Someone specific decides whether a given output is correct, and their name is in the document. Where a model grades the output, the grading prompt is part of the deliverable and gets spot-checked against the human on a sample. An unnamed judge means the judge is whoever is most annoyed on demo day.
A stated failure budget. Every AI feature is wrong sometimes. The contract should say what happens then: which errors are acceptable and absorbed by a human review step, and which are severe enough that one instance fails acceptance. Fabricating a policy number and misfiling a low-priority ticket are not the same event and should never share a threshold.
Why this protects the buyer more than the builder
It reads like a studio hedging: agree the exam, then pass it. The opposite is true, and it is why we push for it. Without written criteria the builder holds all the interpretive power, because the builder is the only party who can describe why the system behaved that way. Written criteria hand the buyer a test they own, on their own data, that they can run themselves after handoff, and against a later vendor too.
The harness outlives the engagement. It is the thing that tells you six months later, after a model upgrade or a document migration, whether the feature still works. That is worth more than most of the code around it.
When the threshold cannot be set yet
Sometimes nobody can name a number honestly, because nobody yet knows what the data supports. That is a real state and pretending otherwise produces a fixed-price contract with a guess inside it.
The answer there is not a bigger build contract. It is a week of investigation that ends in the number: assemble the test set, run the current-generation approach against it, and report what is actually achievable. That is what our Diagnostic Sprint produces, and it sometimes concludes that the feature should not be built at all. Either way the build contract that follows has a real threshold in it rather than an adjective.