Change Control in Vendor Contracts

An engagement agreement is the document that governs a piece of work done by one organization for another. In AI engineering, this often means a vendor building an evaluation pipeline, a model integration, or a production system for a customer. The agreement settles questions that are easy to argue about later: what is being built, when money changes hands, what happens if the plan changes, and who keeps what was created.

This article follows one agreement from the scope clause through the milestones, the change control rules, the termination path, and the ownership split. As you read, keep one habit from the source outline in mind: for every clause, ask what it obliges someone to do, and what value would need to be filled in to make it concrete. Many clauses in a real outline contain bracketed placeholders such as a date, a dollar amount, or a number of days. Those brackets mark values the two parties must fill in before the agreement is valid.

The engagement scope answers the question of what is inside the job. The scope clause is a reference rather than a full description. It names an external scoping document, attached as Schedule A, and records that both parties signed that document on a specific date. The scope therefore lives in Schedule A, and the agreement makes that document binding by having both sides sign.

Why does the signature matter so much? Because the scope is read through Schedule A rather than through the clause text alone. When someone later asks whether a task was part of the job, the answer is found by reading the signed attachment. The clause text tells you where to look and confirms that both sides agreed to what they find there.

The deliverables and milestones clause splits the engagement into four stages. Each stage has a deliverable, which is the concrete thing the vendor must produce, and a payment, which the outline shows as a placeholder amount. Each payment is tied to a trigger event rather than a calendar date. The four milestones are read in order, because each one builds on the one before it.

Trace the chain from left to right. The first milestone is scoping, and its deliverable is the signed scoping document. The second is validation, where the deliverable is eval-set results that clear the agreed threshold. The third is delivery, where the production system must be live and a runbook must be handed over. The fourth is outcome, where the deliverable is a customer-confirmed movement of the success metric across the agreed measurement window. The last milestone depends on something that happens in the customer's business over time, not only on the vendor's output.

The ongoing consumption clause covers money that flows after the milestones. It is marked optional in the outline, so the parties may or may not include it. When it applies, the customer pays a per-unit rate for ongoing system operation, billed monthly, with a minimum monthly fee. The minimum means that even a month of low use is charged at least that floor, so the customer's ongoing cost has a variable part and a fixed lower bound.

Engagements rarely stay exactly as first scoped, so the change control clause governs how scope can move. The rule for material changes is strict: they require a written amendment, and that amendment must be signed by both the vendor lead and the customer sponsor. A change agreed to in a meeting does not take effect merely because someone said yes. It takes effect when the written amendment carries both signatures.

Read the diagram as a sequence of questions. First, is the change material? If so, a written amendment is needed. Second, does that amendment carry both signatures? If one is missing, the change is not in effect. Third, does the budget band exempt the amendment from legal re-approval? The clause includes a budget band: amendments do not need legal re-approval if they fit within a plus or minus N percent window around the original budget, where N is a placeholder the parties must fix. The outline's source does not spell out the path for changes that are not material, so this path covers only the material case the clause describes.

The early termination clause sets the conditions under which the agreement can end before its natural completion. Either party may terminate, but only on a stated number of days of written notice, and the trigger is that the validation threshold was not cleared within the validation window. The notice requirement is written, so an informal end to the work does not satisfy it.

The financial consequences are specified in the same clause. If early termination occurs, the customer pays only for milestones that were already achieved. The clause also states that neither party owes penalties for early termination under this clause. The termination path is therefore a sequence: the validation threshold fails, written notice is given, the notice period runs, and the customer's obligation shrinks to the milestones already reached.

The IP and code ownership clause divides the results of the work into categories, and each category has a different owner. Customer-specific code belongs to the customer. Generalized patterns, eval frameworks, and infrastructure contributions belong to the vendor. The split reflects a practical distinction: code written for one customer's particular needs is separated from the reusable machinery the vendor brings to many engagements.

Two further terms sit alongside ownership, and they are separate questions. The vendor keeps the right to use lessons learned from the engagement to improve its own product. At the same time, the customer's data may not be used for any purpose beyond this engagement unless the parties sign a separate written agreement. Owning code and being permitted to use data are different things, and the clause answers both.