The Mission Brief: A One-Page Scope Template for Production AI

Every production AI mission at Quantabase starts with a single page. The Mission Brief names the workflow, the people who own it, the evidence that will prove the system works, and the condition under which the mission ends. It is short by design: if a mission cannot be described on one page, it is not yet ready to build.

Why one page matters

AI initiatives move fastest when the team has agreed, in writing, on what success looks like, who decides, and what happens when the system is unsure. Public research points to the same pattern. Gartner predicted that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, citing poor data quality, inadequate risk controls, escalating costs, and unclear business value.¹ Research from MIT's NANDA initiative, based on 150 leader interviews, a survey of 350 employees, and analysis of 300 public deployments, reported that roughly 95% of generative AI pilots were not producing measurable revenue acceleration, and attributed the gap to tools and organizations that do not learn from or adapt to real workflows rather than to model quality.²

The organizations that do capture value behave differently. McKinsey's 2026 State of AI survey found that nearly three-quarters of AI high performers report fundamentally redesigning workflows because of AI, compared with about one-quarter of other respondents, and that high performers are twice as likely to have defined processes to measure the impact of AI initiatives.³ The Mission Brief is how we put both of those habits on paper before the first line of code: a named workflow to redesign and a defined way to measure it.

The brief also aligns with established governance frameworks. The NIST AI Risk Management Framework asks organizations to map context, intended purpose, and stakeholders before they measure and manage risk.⁴ ISO/IEC 42001, the first international standard for AI management systems, frames AI governance as a cycle of establishing, implementing, maintaining, and continually improving controls.⁵ A Mission Brief is a practical, mission-level expression of that discipline.

The fields, and why each one exists

1. Mission name

A short, specific name that describes the workflow and the outcome, such as "Invoice intake: touchless posting for PO-backed invoices." Avoid names that describe technology ("GenAI copilot"). A good name keeps the team anchored to the business result.

2. Business owner

One named person who owns the workflow today and will own the outcome after launch. This person accepts or rejects evidence at each gate. Without a single accountable owner, decisions drift to committees and timelines extend.

3. Workflow in scope

The specific process, its start and end points, and what is explicitly out of scope. The UK government's AI procurement guidelines recommend focusing on the challenge rather than a specific solution and writing output-based requirements; the workflow field does exactly that.⁶

4. Current baseline metrics

How the workflow performs today: volume, cycle time, cost per unit, error rate, and backlog. Baselines must be measured, not estimated, and recorded with their source and date. A system cannot be shown to improve a process whose current performance is unknown.

5. Data sources and access

Every system, document store, and dataset the solution needs, who grants access, the access method, and any data handling constraints (residency, personal data, retention). The UK guidelines advise conducting a data assessment before procurement begins.⁶ Access delays are among the most common causes of schedule slip, so this field lists the date by which access must be live.

6. Definition of done

The observable state of the world when the mission succeeds, stated as business outcomes plus the operational conditions that must hold (for example, "running in production on live volume for 30 consecutive days with the accuracy bar met").

7. Accuracy bar

The written, quantitative threshold the system must meet, the metric used, the sample size, and the confidence level. Our companion template, The Written Accuracy Bar, covers how to set it. The point here is that the bar is fixed before build, so it cannot quietly move to match results. This mirrors the evaluation guidance from model providers, which warns against "vibe-based" evaluation and recommends task-specific evals that reflect real-world distributions.⁷

8. Evidence gates per milestone

Each milestone has a gate: the evidence that must be presented and who must accept it before the mission proceeds. Gates turn a project plan into a sequence of decisions. They also give both sides a dignified, low-cost point to stop or re-scope if evidence is not there.

9. Exception path

What happens to the cases the system should not handle: low-confidence outputs, out-of-policy inputs, and failures. Name the queue, the human role that works it, and the target turnaround. The EU AI Act requires that high-risk systems be designed so that people overseeing them can disregard, override, or reverse outputs and can stop the system.⁸ Even for systems outside that scope, a designed exception path is what makes partial automation safe and valuable from day one.

10. Risks

The top risks to delivery and to operation, each with a likelihood, impact, mitigation, and owner. Keep the list short and specific; five well-owned risks are more useful than twenty generic ones.

11. Named owners on both sides

For each role (business owner, data access, security review, IT integration, delivery lead, forward-deployed engineer), name a person on the client side and on the Quantabase side. Named owners shorten every decision loop in the mission.

12. Exit condition

How the mission ends: handover to client operations, transition to a managed operations agreement, or a documented stop. Every mission has a defined end so that success, or a decision not to proceed, is explicit.

13. Timeline

Milestones with dates, each tied to an evidence gate. A typical forward-deployed mission is measured in weeks, not quarters, and the timeline shows where the critical dependencies sit.

How to use the brief

1. Draft together. The delivery lead and business owner draft the brief in a working session, ideally while observing the workflow in person.
2. Measure the baseline before signing. If a baseline number is unknown, the first milestone is to measure it.
3. Sign it. Both named owners sign. Changes after signature are recorded as dated amendments.
4. Review at every gate. Each gate review starts with the brief: is the evidence in front of us the evidence we agreed to?
5. Archive it with the system. The brief becomes part of the system's documentation and supports later audit, monitoring, and change management.

The template

Worked example

Example: invoice intake for a mid-size distributor. This example is illustrative. The company, people, and figures are fictional and are provided only to show how a completed brief reads. They do not describe any Quantabase client.

Notice what the example does. It records a measured baseline with its source. It sets an accuracy bar with a sample size and a confidence bound rather than a single headline number. It routes the highest-severity case, bank details, to people regardless of model confidence. Every milestone has a gate with an explicit decision.

Common improvements on review

• Replace estimates with measurements. If the baseline says "about," schedule a measurement milestone.
• Narrow the workflow. Start with the highest-volume, most structured segment and expand once the gate evidence is in.
• Name individuals, not departments. "IT" is not an owner; a named engineer is.
• Make the exception path concrete. Name the queue, the role, and the turnaround target.
• Plan for operation. The NIST framework treats risk management as continuous across the lifecycle, and the UK guidelines ask buyers to plan for lifecycle management, including testing, knowledge transfer, and end of life.⁴⁶ The exit condition is where that plan begins.