Contract Structures for AI Deployments
A milestone-based contract releases a fraction of the total fee each time an agreed milestone is hit, so payment follows verified progress.
When Should the Money Change Hands?
Imagine you hire a team to build an AI system that will eventually run inside your company. The team will not deliver everything on the first day, and you will not know how well the system works until several stages are complete. So a practical question comes up before any work starts: when should money change hands? One answer is to tie each payment to a stage of progress that both sides can check. That is the logic behind a milestone-based contract, the first of the contract structures covered in this chapter.
As you read, keep one question in mind: what does each side of the agreement gain and lose when payments are attached to checkpoints rather than to time spent or to a single final delivery?
What do you think happens?
The vendor says stage two is finished, but the customer cannot confirm that the checkpoint was actually reached. Is the stage-two payment settled?
Reveal answer
No, payment depends on whether both sides can agree the checkpoint was reached
The source states that if the two sides cannot agree on whether a checkpoint was reached, the payment that depends on it cannot be settled cleanly. Payment is tied to verified progress, not to a claim of progress.
Dividing a Total Fee Across Checkpoints
A milestone-based contract releases a fraction of the total fee each time an agreed milestone is hit, so payment follows verified progress.
The key idea is that the total fee is not paid as one lump at the start or the end. Instead it is divided into portions, and each portion is attached to one checkpoint in the engagement. The checkpoints are agreed in advance. When the work reaches a checkpoint and that checkpoint is confirmed, the portion attached to it is released. Until then, that portion stays unpaid.
Tracing the money through one engagement
A customer agrees to a total fee of 300,000 units split across three checkpoints of 50,000, 100,000, and 150,000 units. Trace how much has been released after each checkpoint is verified.
- 1Before any checkpoint
No checkpoint has been hit, so nothing has been released. The full 300,000 units remain unpaid.
- 2After checkpoint 1 is verified
The validation checkpoint clears its agreed threshold. The 50,000-unit portion is released, leaving 250,000 units for the later checkpoints.
- 3After checkpoint 2 is verified
The production deployment completes without failure. The 100,000-unit portion is released, bringing the cumulative total paid to 150,000 units and leaving 150,000 units.
- 4After checkpoint 3 is verified
The agreed business metric moves in the specified direction over the specified window. The final 150,000-unit portion is released, and the cumulative total paid equals the full 300,000 units.
Payment follows verified progress. At each step the released amount equals the fee attached to the checkpoint that was confirmed, and the unreleased amount is whatever remains for later checkpoints.
What Makes a Milestone Verifiable
The word that carries the most weight in this structure is verifiable. A milestone is not a vague stage such as making good progress. It has to describe an outcome that someone can observe and confirm, so that both the customer and the vendor can agree on whether it has happened. If the two sides cannot agree on whether a checkpoint was reached, the payment that depends on it cannot be settled cleanly.
The source gives three kinds of outcome that work as milestones. Each one is a different way of making a checkpoint observable.
How Each Side's Exposure Is Bounded
The structure works by limiting how much each party can lose at any moment, and the two limits come from different places. The customer's downside is set by the fee attached to the milestone currently in progress. The customer is not asked to pay the entire engagement in advance, so the most they can lose on an unfinished stage is that stage's fee.
The vendor's downside is set by a different quantity: the cost of the work performed between the last paid milestone and the next one. Money is only received on hit milestones, so the vendor absorbs the cost of everything done in between. A longer gap between checkpoints means a larger amount of unpaid work for the vendor to carry.
Advantage and Limitation for a New Engagement
The source describes milestone-based contracts as the simplest structure and the one most familiar to enterprise procurement teams. That familiarity is a practical benefit: the terms are easy to explain to internal approvers, and the logic of paying when a checkpoint is met matches how many organizations already think about purchases. For this reason, the source recommends it for a first engagement with a new customer.
The source also calls the structure honest. Each payment corresponds to a visible result, and neither side is paying for a promise that cannot be checked. That honesty is part of why both parties can trust it at the start of a relationship.
The same feature that makes the structure honest also limits it. Payments are tied to predefined checkpoints, so if the engagement produces far more value than either side expected, the fixed milestone fees do not automatically grow to reflect that. The source states plainly that the structure captures very little of the upside when results are dramatically better than anticipated.
Mistakes When Writing Milestones
Common mistake Writing a milestone as a stage of effort
What it looks likeCheckpoint 1: good progress on the model
Why it failsA milestone must be an outcome someone can observe and confirm. Progress is a vague judgment, so the two sides may never agree that it was reached.
Do this insteadDescribe an observable result, such as a validation measurement reaching an agreed level.
Common mistake Leaving the metric or window undefined
What it looks likeCheckpoint 3: the business metric improves
Why it failsThe source's business-metric milestone requires an agreed metric moving over an agreed period. Without both, the checkpoint cannot be verified cleanly.
Do this insteadName the metric, the direction of change, and the time window in the contract.
Common mistake Assuming payment follows the vendor's claim
What it looks likeThe vendor reports completion, so the stage fee is released
Why it failsPayment is tied to verified progress. An unconfirmed checkpoint leaves the dependent payment unsettled.
Do this insteadRequire the agreed verification before releasing the portion attached to that checkpoint.
Common mistake Stretching the gap between checkpoints far apart without noticing that the vendor's unpaid work grows
Designing a Milestone Plan
A new AI engagement has a total fee of 200,000 units. Propose three checkpoints, one for each of the three kinds of outcome in the source. For each one, state the observable result, the portion of the fee attached to it, and how the two sides would confirm it was reached. Then say which checkpoint would leave the vendor carrying the most unpaid work and why.
Hints
- Use a validation threshold, a successful production deployment, and a business metric over a window, one each.
- The portions must add up to 200,000 units, and the last checkpoint usually depends on the most time passing.
- The vendor's exposure is the cost of work since the last paid checkpoint, so think about which gap is longest.
Key Takeaways
- A milestone-based contract divides the total fee into portions, and each portion is released when an agreed checkpoint is hit, so payment follows verified progress.
- A suitable milestone describes an observable outcome, such as a validation threshold, a successful production deployment, or an agreed business metric moving over an agreed period.
- The customer's maximum loss is the fee of the milestone in progress, while the vendor's exposure is the cost of work performed since the last paid milestone.
- The structure is simple, familiar to procurement teams, and honest, which is why it is often recommended for a first engagement, but it captures little of the upside when results greatly exceed expectations.