Every stalled AI project has a moment, usually around month three, when someone asks a question the team should be able to answer instantly — 'why did we exclude that data source?', 'what did we say the accuracy bar was?', 'who agreed to this scope?' — and the answer requires archaeology: digging through chat threads, meeting notes and three versions of a slide deck. The scoping document exists to make those questions boring. It's not bureaucracy; it's the single artifact that holds the project's decisions in one place, written well enough that a new team member can read it in twenty minutes and disagree with something specific. Here's the anatomy, section by section, with the quality bar each section has to clear.
The nine sections and what each must answer
The structure below is deliberately boring. Novel document structures are a tax on every reader; the value is in the specificity of the answers, not the originality of the headings. For each section, the middle column is the test: if a reader can't extract that answer, the section isn't done, however long it is.
| Section | Must answer | Quality bar |
|---|---|---|
| 1. Problem | What is slow, costly or error-prone today, and for whom? | One paragraph, zero mentions of AI or any technology. If the problem needs the solution to describe it, it isn't understood yet. |
| 2. Users & workflow | Who touches the output, in which system, at which step of their day? | Named roles and named systems. 'The ops team' fails; 'claims handlers, inside the triage queue, before assignment' passes. |
| 3. Success metrics | What number moves, from what baseline, to what target, measured how and when? | Primary metric with a real baseline. A target without a baseline is a wish. Include the counter-metric (what must not get worse). |
| 4. Data inventory | What data, where it lives, who owns access, how complete and how fresh? | Per source: location, owner, a measured completeness figure, known quality issues. Adjectives fail; percentages pass. |
| 5. Constraints | What is fixed: latency, cost ceilings, compliance, systems that can't change? | Numbers and named regulations, not vibes. 'Fast' fails; 'under 2 seconds p95' passes. |
| 6. Risks | What could sink this, how likely, and what's the mitigation or tripwire? | 3-7 real risks with named owners. If every risk is 'timeline may slip', nobody thought about it. |
| 7. Phasing & scope | What ships in phase one, what's explicitly out, what triggers phase two? | In-scope and out-of-scope lists side by side, plus a stated condition for expanding — a metric threshold, not a date. |
| 8. Team | Which roles, what commitment level, which gaps and how they're filled? | Roles with fractions ('data engineer, 50% for 8 weeks'), gaps marked hire/train/bring-in. Names optional, shapes mandatory. |
| 9. Budget envelope | What band of spend does this scope imply, including run costs, not just build? | A range with stated assumptions, split build vs. run. False precision fails; an honest band with assumptions passes. |
The quality bar, generalized: factual beats adjectival
Almost every weak scoping document fails the same way: it substitutes adjectives for facts. 'High-quality data', 'fast response times', 'experienced team', 'significant ROI'. Each of these is a decision someone avoided making. The mechanical test for any sentence in the document: could a reasonable person disagree with it? 'The data is good enough' — nobody can disagree, because it asserts nothing. 'The customer-notes field is populated in 61% of records and free-text quality varies by region' — a person can check that, dispute it, or plan around it. A scoping doc composed of checkable sentences is doing its job; one composed of agreeable sentences is a press release. The second common failure is asymmetric effort: three pages on the problem and solution vision, four bullet points covering data, risks and budget combined. The neglected sections are exactly the ones that cause month-three archaeology, because they're the ones where the hard conversations were skipped.
A mini example: invoice-coding assistant
Here's a compressed, illustrative example — a fictional mid-size services firm scoping an AI assistant that suggests general-ledger codes for incoming supplier invoices. Note what makes each line specific rather than agreeable.
- Problem: AP clerks manually code ~3,200 invoices/month against 240 GL codes; coding takes 90 seconds each and ~6% are recoded later by finance, causing month-end rework.
- Users & workflow: four AP clerks, inside the existing approval tool, at the point where the invoice is first opened — suggestions appear pre-filled, clerk confirms or overrides.
- Primary metric: recode rate from 6% to under 3% within two months of rollout; counter-metric: median time-per-invoice must not exceed the current 90 seconds.
- Data: 26 months of coded invoices (approx. 80k rows) in the ERP; supplier master data is clean; historical codes before a 2024 chart-of-accounts migration are unreliable and are excluded.
- Constraint: invoice content cannot leave the EU; the ERP vendor's API allows read access but writes only through the approval tool.
- Top risk: the 2024 migration means only ~20 months of consistent training data; tripwire — if suggestion acceptance is below 70% in week two of shadow mode, pause and review the code taxonomy before touching the model.
- Phase one scope: suggestion only, top-3 codes with confidence shown, clerk always confirms. Out of scope: auto-posting, PO matching, any invoice over €10k. Phase two trigger: acceptance rate above 85% for four consecutive weeks.
- Team: one AI engineer (full-time, 10 weeks), one data engineer (50%, 4 weeks), AP team lead (2 hrs/week for labeling review). Gap: no internal AI engineer — brought in externally.
- Budget envelope: build in the €40-60k band on the stated team; run costs estimated under €300/month at current volume, dominated by inference — assumption documented, revisited at phase-two decision.
Versioning: the doc is a ledger, not a monument
Scope legitimately evolves — the data turns out worse than inventoried, a constraint appears, a phase-one result changes the phase-two plan. The failure mode isn't change; it's silent change, where the document is quietly rewritten and three months later nobody can reconstruct what was originally agreed or why it moved. The fix is a changelog at the top of the document: date, what changed, why, and who agreed. Version the metric targets especially — 'we relaxed the accuracy bar from 95% to 90% on 12 March because the labeled data supported only 90% at launch, agreed by X and Y' is one line that prevents an hour of recrimination later. A useful discipline: any change to sections 3 (metrics), 7 (scope) or 9 (budget) requires the same sign-off that approved the original document. Changes to those three sections are re-decisions, not edits.
- Changelog at the top: date, change, reason, who agreed — one line per change.
- Metrics, scope and budget changes need the original approver's sign-off; everything else can move faster.
- Never delete an out-of-scope item silently — moving something into scope is the most expensive kind of change and deserves the most visible line in the log.
- Re-circulate on every material change; a scoping doc that's current but unread protects nobody.
Where it sits in the process
The scoping document is the second artifact, not the first. It expands the one-session project outline — the outline argues the project is worth investigating; the scoping doc records what the investigation found and what was decided. Writing the scoping doc first, before the data reality check and stakeholder conversations, produces a document full of assumptions dressed as decisions. It's also not the last word: the requirements work goes deeper on behavior, and the ongoing documentation set (decision log, data inventory, runbook) carries the project through delivery. This is the shape of the sequence Aiporate's intake follows for clients — a sentence-level brief becomes an outline in one session, the outline becomes this scoping document, and the document defines the team assembled against it. Whoever writes yours, the anatomy above is the checklist for whether it's done.
