Engagement Scope and Schedule Documents

An engagement agreement governs a piece of work that one organization does for another. In AI engineering this often means a vendor building an evaluation pipeline, a model integration, or a production system for a customer. Such agreements settle the 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. The scope and schedule documents are the part of the agreement that answers the first and most basic of these questions.

The engagement scope answers the question of what is inside the job. Read literally, the scope clause is only a pointer. The authoritative description of the work is the signed scoping document attached as Schedule A. This means you cannot understand the scope by reading the clause alone; you read the clause, follow it to Schedule A, and then rely on the document that both sides have signed.

The diagram shows the chain of authority. The agreement contains a scope clause. The clause references Schedule A. Schedule A is the signed scoping document that defines the work. The signatures are what make the reference binding: the agreement makes Schedule A binding by having both sides sign it, rather than by restating its contents in the clause.

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 to a calendar date. The four milestones build on one another in order, so they should be read in sequence.

Read the diagram as a dependency chain. Each payment hangs off the milestone whose trigger it is tied to. The validation milestone is also the one that connects to the termination path, because failing to clear the validation threshold is the trigger for early termination. The chain is not a list of unrelated tasks; each stage depends on the one before it.

The outline does not spell out a remedy for a late or rejected deliverable. What it does establish is that payments are tied to trigger events rather than calendar dates. A payment therefore follows the achievement of its milestone, not the passing of a date. A deliverable that has not been produced or accepted at its milestone has not triggered the payment attached to it.

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

The clause also contains 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 that the parties must fix. The diagram reads as a sequence of questions. First, is the change material? If it is, is the amendment signed by both parties? Only then does the budget band decide whether legal re-approval is needed.

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

The financial consequence is what makes this path concrete. If termination occurs, the customer pays only for milestones that were already achieved. A milestone that was not reached is not paid for under this clause. The clause also states that no penalties are owed under it. Together these two points mean the customer's exposure is limited to completed milestones.

The source material does not say explicitly which other obligations, such as deliverable ownership, survive the termination date. It is therefore safest to treat only the stated points as settled: written notice, the failed validation trigger, payment limited to achieved milestones, and no penalties under this clause. Anything beyond those points should be checked against the full signed agreement rather than assumed.

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, evaluation 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 reusable machinery the vendor brings to many engagements.

The table shows that ownership and permission are not the same thing. Lessons learned are not owned by the customer in the same way as customer-specific code; the vendor keeps the right to use them to improve its own product. Customer data is governed by a different rule: it may not be used for any purpose beyond this engagement unless the parties sign a separate written agreement. Reading the clause correctly requires asking two questions for each item: who owns it, and what use is permitted.