Waving the Contract

The agreements crossing my desk this quarter are for a different kind of work than the ones I read two years ago. A retrieval-augmented copilot over a bank's own policy and product estate. An advisory assistant on a payments operation's dispute library. A carefully scoped pilot whose deliverable is an evaluation set and a decision rather than a running system. The scopes are new. The commercial paperwork underneath them is not: the same milestone table, the same acceptance language, the same schedule of remedies for a late one.

The earliest of these agreements are now old enough to slip, and I am getting the call that follows a slip. The question is usually some version of whether it is time to put the supplier on notice.

I want to argue against the reflex, and the argument is not about goodwill. It comes from a review whose working notes carry the shortest and least ambiguous finding I have read on the subject.

One line in the project-management notes

Nearly a decade ago I led an independent review of a failed offshore software build for a European retail and private banking group. The build was a customer-facing advisory application for the group's own clients. By the time the review started, the work had been brought back in house and the sourcing arrangement was over. My job was to establish what had happened across the delivery approach, the project management and the software itself.

The project-management workstream captured its raw observations before they were written up, three positives against six things that should have been done differently. The positives were real: strong governance, escalation called early, and a client that in the reviewer's own capitals really tried to make it work. Among the six remedial observations sits a single line saying that invoking the contract was not helpful in building the relationship.

That line never grew into a chapter. It should have, because two other findings in the review describe the mechanism behind it.

Correct, and expensive

The finding does not say the escalation was wrong. It says early and rightly so. The reviewer holds two things at once: this was the right act under the agreed governance, and it changed the quality of what came back afterwards.

The mechanism is not mysterious. Once a client raises the temperature, the supplier's cheapest available response is not to deliver faster. It is to stop volunteering. Nothing rewards a delivery lead for saying out loud, on a call now being minuted with an eye to the file, that the framework is unfamiliar and the team will not make the date. The moment a slip acquires a commercial consequence it stops being a shared engineering problem and becomes a claim to be contested, and the buyer's information supply, already thin, gets thinner exactly when it is needed most.

What makes this engagement worth studying is that the client's process discipline was not the weak point. The review's own words are close to an exoneration: it is hard to fault the client's project management on this assignment, because every piece of documentation was in place and every meeting was minuted and the emails were logged. Testing plans were in place and, on the review's own careful wording, apparently agreed and approved by both parties, though the same finding adds that they were not necessarily followed to the standard that was expected. The governance ran.

It ran, and two defect classes the review's summary says should not have existed at the point of handover still reached it: caching of customer data, and an absence of error handling. Complete paperwork and a well-run escalation route stopped neither.

What the escalation actually deployed

The most instructive line in those working notes is not about the contract at all. It is the observation that the architect should have been sent to sit with the delivery team when the project escalated.

Read that against the review's evidence register, where the monthly bills for supplier headcount were obtained and the one comment recorded against them is that no architect was being billed. Two independent sources, the client's remedy list and the supplier's invoices, agree that the missing input was architectural capability applied to the build.

The escalation route was not built to deliver that. It was built to carry information upward to people who could apply pressure. So it did, and pressure was what the programme already had too much of.

That is the structural point, and it survives intact into every delivery model since. An escalation path is a communication design: it moves a problem to a higher altitude, where the tools available are commercial rather than technical. If the failing component needs an engineer, altitude is the wrong direction of travel. Ask what an escalation on your programme actually deploys, another review meeting or someone who can change the thing that is broken.

3 positives

Against six remedial observations in the project-management working notes

5 of 8

Recommendations asking the buyer, not the supplier, to change

4 weeks

Upfront training on the unfamiliar framework, proposed by the supplier itself

2

Defect classes the summary says should not have existed at handover, cached customer data and absent error handling

The only quantified remedy came from the party being blamed

Count the recommendations and the ratio tells its own story. Eight against seven findings. Five require the client to act: build experience of the delivery model through cultural awareness training and time spent with the supplier's team; put its own people on site alongside the developers; drop penalty-clause language from deadline management; gauge supplier capability through practical tests rather than initial interviews; and make sure the supplier understands the end-to-end deliverable so it is not producing its part in isolation. One is joint: agree what pass and fail mean, and what each status colour means, before work starts rather than during the argument. Two are for the supplier: be upfront about concerns and decline work you cannot deliver, and set aside four weeks of upfront training on unfamiliar technology.

That last one is the only recommendation in the document carrying a number, and the supplier wrote it. The review carries it in the supplier's own feedback column and again in the reviewer's working notes, credited both times to the supplier, before it reaches the recommendations as an instruction back to them. Every other remedy is directional: be more collaborative, build the relationship, judge capability better.

The party closest to the work held the only estimate anyone could act on, and it arrived in a post-mortem, after the arrangement had ended, in a setting where saying it cost nothing. During delivery, under an escalation and a schedule of remedies, saying it would have cost something. So it was not said.

Reaching for the contract converts a delivery problem into a legal posture, and a posture is much harder to climb down from than a plan. The clause was always going to be there. What it costs is the sentence the supplier would otherwise have said out loud.

The copilot contract on your desk

A copilot pilot that slips rarely slips for the reason the milestone table assumes. It slips because the documents the retrieval layer was pointed at contradict each other, because the lineage that would settle which version of a policy is current does not exist, or because the evaluation set was written after the demonstration rather than before it. Those are data readiness problems, and they belong to the buyer at least as much as to the supplier. Serving notice for the state of your own document estate produces a defensible file and no working copilot.

Three of the review's client-side recommendations transfer directly, and they are cheaper than the clause.

Gauge capability through practical tests rather than interviews, and keep testing after signature. For this class of work that means writing your evaluation set on your own documents and your own questions before the supplier demonstrates anything, then running it every release. It converts the question of whether the supplier is delivering from an argument into a measurement that neither party authors alone. That measurement layer is where a RealAI Platform engagement starts, ahead of the model and ahead of the vector store, because most of what stops a copilot being useful sits upstream of both.

Make sure the supplier has understood the end-to-end deliverable. On a retrieval build that means shared access to how the answer will be used, by whom, and what a wrong one costs. A supplier tuning a similarity score in isolation will hit the score and miss the job.

Manage the deadline without the clause in the room. Not because the clause is unfair, but because the estimate you need most is the one the supplier is least willing to give once it is expensive to give.

There is a governance argument in the same direction. The European AI Act is agreed, and its obligations will arrive in stages rather than all at once. When they do, someone will have to describe how these systems were built, what they were evaluated against and where their inputs came from. A supplier relationship that has already taught the other side to volunteer nothing is a poor place from which to assemble a truthful account of training data, lineage and evaluation coverage. The MLOps discipline that makes that account possible is the same discipline that makes a slip visible early.

None of this argues for a weak contract. Write the acceptance criteria hard, and write them as checks something can run rather than as prose two parties will read differently. The point is narrower, and it is what the review found: the contract is a settlement instrument, and using it as a management instrument degrades it as a settlement instrument while buying you nothing operationally. Escalation is a real tool with a real price, and the price is paid in the honesty of everything reported to you afterwards.

Before the notice goes out, work out what the delivery problem actually is and who would have to move to fix it. That diagnosis is quick. Reversing a legal posture is not, and on this programme it never happened at all.

Drawn from an independent review I led of a failed offshore software build for a European retail and private banking group: its project-management working notes, its findings and recommendations set, and its evidence register. That review produced findings and recommendations after the engagement had ended, not delivered results. Reading its contract finding as a lesson for AI supplier agreements is mine.