Skip to main content

03.21Framework

Client delivery framework for AI projects

The seven-phase process AR Labs uses to take an AI project from first conversation to a running system, with an evidence gate between phases.

The process, as a visual
On this page
  1. The problem it prevents
  2. The seven phases
  3. AI-specific gates
  4. How it connects to the engineering practices
  5. What the client controls
  6. Where it came from

AR Labs takes client work on AI projects through seven phases, grouped into three engagements: understand the problem, prove the approach, then build and run the system. Every phase produces something the client keeps even if the work stops there, and no phase starts until the previous one has passed a gate, a point work cannot pass until a condition is met: here, evidence and the client's sign-off. The framework is for a business weighing an AI project and for the engineers who run one. A visual of the process is on the process page.

The problem it prevents

AI projects fail in ways ordinary software projects do not. The data may not exist or may not be usable. A simple rule-based system may already do most of what the AI was meant to do. A model that performs well in a demonstration may drift once it meets real conditions. A process that commits to the whole build up front discovers these problems late and expensively. Splitting the work into separately agreed engagements, each ending in a go or no-go decision, finds them early, and gives the client control at every step.

The seven phases

Each step of the staircase is a phase, labelled with what the client keeps from it, and each riser is the gate into the next. At the two boundaries between engagements the client decides whether to go on. The AI-specific gates, described below, are marked along the bottom.

A staircase of seven phases, Discover to Evolve, grouped as Engage, Prove and Deliver, with a gate on each riser, client decisions at the engagement boundaries, and AI-specific gates beneath. Seven phases rise left to right in three engagements. Engage: 1 Discover (outcome statement, workflow map, data readiness) and 2 Define (scope with non-goals, success criteria, context diagram, roadmap). Prove: 3 Prototype (working prototype, baseline comparison, go or no-go) and 4 Validate (validation report, acceptance criteria, container diagram). Deliver: 5 Build (working increments, architecture record, test results), 6 Launch (live system, monitoring, runbook, training) and 7 Evolve (health reports, quarterly value reviews). Each riser is a gate: outcome statement complete; scope signed off; prototype beats the baseline; approach confirmed in context; all acceptance criteria pass; stable in production. Beneath, the AI-specific gates: data readiness, baseline, ethical screen, model validation and drift monitoring. At the two engagement boundaries the client decides whether to continue, keeping everything delivered so far. Client delivery: seven phases, three engagements EACH STEP LEAVES THE CLIENT SOMETHING THEY KEEP · AT EACH ENGAGEMENT BOUNDARY THE CLIENT DECIDES WHETHER TO GO ON FIGURE CLIENT DELIVERY STAIRCASE DRAWN BY AR LABS SHEET 1 / 1 1 Discover CLIENT KEEPS outcome statement workflow map data readiness 2 Define CLIENT KEEPS scope, non-goals success criteria context diagram 3 Prototype CLIENT KEEPS working prototype baseline compared go or no-go 4 Validate CLIENT KEEPS validation report acceptance tests container diagram 5 Build CLIENT KEEPS increments, demos design record test results 6 Launch CLIENT KEEPS live system monitoring runbook, training 7 Evolve CLIENT KEEPS health reports quarterly value reviews outcome statement complete scope signed off beats the baseline works in the client's context all acceptance criteria pass stable in production ENGAGE understand the problem PROVE test the approach DELIVER build and run it client decides whether to go on client decides whether to go on AI-SPECIFIC GATES data readiness baseline ethical screen model validation drift monitoring Every phase ends at a gate; no phase starts until the one before has passed.
Seven phases in three engagements; each step leaves the client something they keep, and each riser is a gate.
Phase Purpose The client keeps Gate to the next phase
1. Discover Understand the client's world, workflow and pain before assuming a solution An outcome statement, a map of the current workflow, a data readiness assessment The outcome statement is complete
2. Define Agree what will be built, what will not, and how success will be measured A scope agreement with non-goals and testable success criteria, a system context diagram, a recommended approach, a roadmap The client signs off scope and success criteria
3. Prototype Test the riskiest assumption with the smallest working build A working prototype, a comparison against the current baseline, decision records, a go/no-go recommendation The prototype beats the baseline
4. Validate Test with real users, real data and real conditions A validation report, refined requirements, acceptance criteria in Given/When/Then form, an updated container diagram The client confirms the approach works in their context
5. Build Design and build the production system in visible increments Working increments with demos at each sprint boundary, architecture documentation, a full decision log, test results All acceptance criteria pass
6. Launch Deploy with monitoring, a rollback plan and handover The live system, monitoring dashboards, a runbook, handover documents, team training The system is stable in production and the client's team can run it
7. Evolve Monitor, detect drift, optimise and grow Health reports, optimisation recommendations, quarterly value reviews A quarterly review of business outcomes against the original targets

The outcome statement from Discover follows a fixed shape: "By implementing [solution], we will [action] [metric] from [X] to [Y], resulting in [business value]." It states the result the work is for, and every later gate is checked against it. The music school automation case study shows the framework's first two phases, Discover and Define, applied to a real engagement as discovery and design work for a music school.

AI-specific gates

Ordinary software projects skip these. AI projects pass each one.

Gate When Question
Data readiness Discover to Define Does enough clean, accessible, legally usable data exist?
Baseline Prototype Does the AI beat a naive baseline, such as simple rules or the human average?
Ethical screen Prototype to Validate Does the system affect people in ways that need governance?
Model validation Validate to Build Does performance meet the agreed thresholds across the conditions that matter?
Drift monitoring Launch to Evolve Are data drift, concept drift and model degradation being tracked?

The baseline gate keeps the comparison fair: if a simple rule-based system already gets 85% right, the AI has to beat 85%, not merely work.

How it connects to the engineering practices

The documentation the client receives is our standard architecture record (see architecture documentation). A system context diagram arrives at Define, a container diagram at Validate, and both are kept current through Build. Decision records start at Prototype. Acceptance criteria are written in Gherkin at Validate, in language the client can read, and become the tests the build is checked against, the same Gherkin-to-test discipline our own coding pipeline uses.

What the client controls

Three things build the client's confidence, and the framework is designed around them. The process is visible and explicit. The decision points belong to the client, because each engagement is agreed separately and there is no commitment to the whole programme up front. And any gate can end the work: if the data is not there or the approach will not work, the recommendation is to stop, with a clear account of why.

Where it came from

The framework adapts established methods for a small AI engineering practice: the UK Design Council's Double Diamond, IBM Enterprise Design Thinking (outcome statements and frequent playbacks to the client), Neil Rackham's SPIN questioning for discovery, Rob Fitzpatrick's The Mom Test, the Stage-Gate model extended with data and baseline gates, Dan North's behaviour-driven development for acceptance criteria, BCG X's ACTIVATE and McKinsey's Rewired for decision gates with real consequences, and Christensen's Jobs-to-be-Done with Ulwick's Outcome-Driven Innovation for framing problems as outcomes.