A scope document written only for engineers will get signed by a buyer who did not understand it. That signature becomes the source of every disputed change order later.
The fix is not a longer document. It is a document with a deliberate structure — one that gives engineers the precision they need and gives buyers the clarity they need to approve and hold the line.
Two Audiences, One Document
Every AI project scope document has two readers with different success conditions.
The engineering team needs to know exactly what they are building, what they are not building, and what done looks like in measurable terms. Ambiguity here produces rework.
The buyer needs to know what they are paying for, what is out of scope, and what happens when something unexpected surfaces. Ambiguity here produces disputes.
Most scope documents serve one audience well and ignore the other. Engineers write in system terms — endpoints, latency budgets, model versions. Buyers read in outcome terms — leads generated, hours saved, cost per action. Neither translation is wrong. Both need to live in the same document.
The structure below forces that translation.
Four Sections Every Scope Document Needs
1. Boundary
State exactly what the system does. One paragraph. Plain language.
Example: This system ingests a list of up to 5,000 company records per week, enriches each record with firmographic data from two sources, scores each record against a defined ICP, and delivers a ranked output file to a specified S3 bucket by 6 AM Monday.
That sentence works for an engineer and a buyer. The engineer sees the data volume, the sources, the output format, and the delivery window. The buyer sees what they are getting and when.
If you cannot write the boundary in one paragraph, the scope is not defined yet.
2. Exclusions
This section is the most skipped and the most expensive to omit.
Exclusions state what the system does not do. Not what it might do later. Not what is out of budget. What is explicitly outside this engagement.
Example exclusions for the system above:
- CRM write-back is not included. Output is delivered as a file only.
- The system does not validate or clean input records. Malformed records are skipped and logged.
- Real-time enrichment is not in scope. Processing runs on a weekly batch schedule.
- Human review of scored records is not included.
Without this section, buyers assume everything adjacent to the boundary is included. Engineers assume the buyer knows it is not. That gap costs real money — typically in the form of a mid-project conversation where both sides are right and both sides are frustrated.
Write the exclusions list before the first sprint starts. Review it with the buyer explicitly. Get acknowledgment in writing.
3. Success Criteria in Measurable Units
Success criteria must be numbers, not adjectives.
Bad: The system should perform well and deliver accurate results.
Good:
- Enrichment match rate ≥ 85% on valid input records
- Weekly batch completes and delivers output file within the 6 AM window on ≥ 95% of scheduled runs
- Scoring latency per record ≤ 200ms at the 99th percentile
- False positive rate on ICP scoring ≤ 12% measured against a 200-record holdout set
These numbers do two things. They give engineers a target to build toward. They give buyers a definition of done they can verify without reading code.
If a buyer cannot evaluate success criteria without engineering help, the criteria are not buyer-readable yet.
4. Escalation Path
Scope documents almost always omit this. It is the section that prevents the most expensive conversations.
The escalation path answers: What happens when something outside the boundary surfaces during the project?
It should specify:
- Who identifies the out-of-scope item (engineer, PM, or buyer)
- How it gets documented (a written change request, not a Slack message)
- Who approves scope changes and in what timeframe
- Whether the change affects timeline, cost, or both, and how that gets communicated
A one-paragraph escalation path prevents the situation where an engineer builds something adjacent to scope because it seemed helpful, the buyer sees it and expects it to be maintained, and the next engagement starts with a disagreement about what was promised.
What Skipping Exclusions Actually Costs
A realistic example: a team scopes a lead enrichment pipeline. Exclusions section is blank. Buyer assumes CRM sync is included — it was in the demo environment. Engineer assumes it was never discussed. Three weeks in, the buyer asks when CRM sync goes live. Engineer says it was never in scope. Buyer pulls the contract. Contract is silent.
Resolution options: build it for free, bill for it and damage the relationship, or negotiate a partial. All three options cost more than writing the exclusions section in week one.
The rework cost is not just engineering hours. It is the trust cost, the delay cost, and the distraction cost to every other project running in parallel.
Applying This to AI Systems Specifically
AI systems have a specific scope failure mode: buyers assume the system will handle edge cases it was never trained or designed for. A document that defines the boundary and exclusions precisely reduces that assumption gap before it becomes a support ticket.
At DK1.AI, scope clarity is built into how we structure every engagement. AI Brand Presence is one example — the boundary, exclusions, and success criteria are defined before any production work starts, so both sides know exactly what is being built and what is not.
That discipline applies across every system we run.