Key takeaways
- AI value is lost between stages more often than inside them. A pilot is funded without a baseline, or scaled without a reconciled cost, and no one is accountable for the gap.
- The lifecycle has seven stages. Each one ends in a gate with a named owner and a written exit condition, and the last one ends in a decision: scale, hold, redesign or stop.
- Every stage reads and writes the same record for each workflow. Without that shared record, the lifecycle becomes seven separate reports.
- It is a proposal, version 0.1. It describes roles and evidence, not products. One tool can fill several roles, and most organisations already own some of them.
Why a lifecycle
The site's other frameworks describe what to manage and how to decide. The AI economics map maps how compute becomes business value. The AI Value Management Layers set out the domains an organisation has to cover. Scale, hold, redesign, stop gives the decision rules.
None of them says when each decision happens, or who signs it off. That is where most AI value programmes break down. The business case assumes a baseline that nobody measured. Engineering optimises cost per token while finance waits for cost per outcome. The value review happens, but it does not change the funding. Each failure sits at a hand-off between teams.
The lifecycle is a sequence of stage gates for a single AI workflow, from the first funding request to the decision that renews, changes or ends it.
The seven stages
| Stage | The question it answers | Accountable owner | Gate to pass |
|---|---|---|---|
| 1. Prioritise and fund | Is this worth trying, and how much proof will it need? | Business sponsor, with the portfolio or investment board | A named owner, an outcome KPI, a budget, a review date and the evidence level the commitment requires |
| 2. Set the baseline | Compared with what? | Process owner supplies it; finance agrees the boundary | An agreed measurement plan: baseline volumes, cycle time, error rate and service level, plus a full cost boundary |
| 3. Design and evaluate | Does a candidate design work well enough, at a cost that can work? | Product or engineering owner | Quality and cost per accepted task meet the thresholds set at stage 1 |
| 4. Approve controls | Is it safe to run, and is spending bounded? | Risk owner, with data protection and the platform owner | Approved models, data use, budgets, quotas and an owner for exceptions |
| 5. Run and account | What does it actually cost, and is it being used? | Platform owner, with the FinOps or cost owner | Cost reconciled to invoices and attributed to each workflow, including review and rework time |
| 6. Prove value | What changed because of it? | Business owner confirms the outcome; finance confirms the benefit | Benefit verified at the evidence level set at stage 1 |
| 7. Decide | What happens next? | The board or committee that funded it | Scale, hold, redesign or stop, recorded with a reason and a review date |
Three rules hold the stages together.
The proof is set at the start. Stage 1 fixes the evidence level the commitment will need, using the proposed pairing of proof and money. A small, reversible pilot can run in the fast lane at E0 or E1 with a cap and a review date. A large or hard-to-reverse commitment needs E3. Setting the bar after the results are in invites the bar to move.
Cost and outcome share a boundary. If the benefit counts the whole support team's time, the cost must include the whole support team's review and rework, not only the model invoice. Stage 2 agrees that boundary before any money is spent. Stage 5 holds to it.
The loop has two returns. A stage 7 decision feeds the next funding cycle. A material redesign, such as a new model, a new data source or a change in autonomy, goes back to stage 3 for evaluation and stage 4 for approval. Changing the design should not quietly inherit the original approval.
Two paths: built and bought
The seven stages fit AI that an organisation builds or assembles: a custom agent, a retrieval application, an automated workflow. Much enterprise AI is bought rather than built: workforce assistants, coding tools and AI features inside existing SaaS products. Bought AI follows a different path through stages 3 to 5.
| Stage | Built AI | Bought AI |
|---|---|---|
| 3. Design and evaluate | Test candidate models, prompts and retrieval designs against quality and cost thresholds | Run a time-boxed trial against the same thresholds. The design choices are mostly the vendor's |
| 4. Approve controls | Set model, data and spend policy, enforced at a gateway where traffic allows it | A procurement and contract gate: data terms, seat and usage commitments, exit terms and admin controls |
| 5. Run and account | Trace each run and attribute cost to each workflow | Use the vendor's admin and usage analytics. Detail is often only available by team and period, not by task |
The bought path usually produces coarser evidence. That is acceptable if the record says so. A value claim built on team-level usage should carry that limit with it, rather than being presented with the precision of a traced workflow. SaaS token opacity explains why the detail is often missing.
The evidence roles
Each gate needs evidence from somewhere. The table lists the roles that supply it, not the products. One platform can fill several roles, and an existing finance system, spreadsheet or business application often fills one well enough. Buy a tool only when a gate cannot be passed without it.
| Evidence role | What it supplies | Stages | Where to look |
|---|---|---|---|
| Portfolio and funding record | Owner, outcome KPI, budget, review date, decision history | 1, 7 | SPM and AI; AI value management |
| Full cost model | Model, platform, infrastructure, labour, data and change costs, allocated to workflows | 2, 5 | TBM / ITFM; FinOps platforms; AI TCO Framework |
| Traces and evaluation | Quality, latency, retries and cost per run, before and after release | 3, 5 | LLM observability and evaluation |
| Runtime spend controls | Model allow-lists, budgets, quotas and routing policy | 4, 5 | Model gateways and routing |
| Risk and approval register | Risk assessment, approval, conditions and exceptions | 4 | Existing risk or model-governance platform. Not profiled in the vendor map |
| Process and outcome evidence | Baseline and current volumes, cycle times, errors and business results | 2, 6 | Systems of record, with process outcomes and benefits realisation tools where they add reliable evidence |
| Workforce usage analytics | Seats, active use and adoption for bought AI | 5, 6 | Workforce AI usage; AI coding tools |
| Infrastructure efficiency | GPU, Kubernetes and inference utilisation, where the organisation runs its own | 5, 7 | Infrastructure and inference optimisation |
The connections between these roles are integration requirements. Vendors describe some of them as built in, but no combination should be assumed to connect out of the box. Check exports, identifiers and permissions in your own environment before relying on a join.
The measures that pass the gates
Four measures do most of the work at stages 3, 6 and 7. The definitions are this site's proposal.
| Measure | Definition | Decision it supports |
|---|---|---|
| Cost per accepted outcome | Total attributable cost, including review and rework, divided by outcomes that passed the quality bar | Comparing designs at stage 3; a quality-adjusted form of cost per business outcome |
| Net realised benefit | Verified benefit less full incremental cost, over the same period | Whether to continue, at stage 7 |
| Released capacity | Time measurably released, and what it was actually redeployed to | Whether a saving is cash, capacity or neither |
| Quality and service impact | Errors, rework, cycle time and service levels against baseline | Whether it is safe to scale |
Two cautions apply. Estimated time saved stays a separate line until it becomes a realised benefit: removed cost, avoided hiring or measurably redeployed work. And a lower token bill can raise total cost if it increases review and rework, which is why stage 3 compares designs on cost per accepted outcome rather than cost per call. The cost of verification explains why.
The record that joins it
The lifecycle depends on one record per workflow that every stage reads and writes. The AI Value Ledger is that record. Stage 1 creates the entry, stage 2 adds the baseline, stages 5 and 6 add cost and outcome, and stage 7 records the decision. The lifecycle adds no new schema to it.
The join that most often breaks is workload identity: the identifier that connects a model call, a workflow run, an invoice line and a business result. The instrumentation blueprint covers how to keep it. Two rules from that article matter most here. Link retries and tool calls to the same workflow run, or cost per task will be understated. And where a source only reports by team or month, keep that grain and say so, rather than spreading it across tasks as if it had been measured.
Starting with one workflow
Do not roll the lifecycle out across the portfolio first. Prove it on one consequential workflow, then extend it with the same identifiers.
| Batch | Work | Exit condition |
|---|---|---|
| 1. Establish ownership | Pick one material workflow. Agree the sponsor, outcome KPI, baseline and full cost boundary | An approved measurement plan |
| 2. Connect and check | Collect traces or usage data, invoices and business results. Test that spend limits actually hold. Reconcile estimated cost to billed cost | A repeatable cost and outcome view |
| 3. Decide and extend | Run the value review. Change the design or the funding. Add the next workflows | A recorded scale, hold, redesign or stop decision |
The first 100 days of AI value management covers the groundwork, most of which needs no new tooling.
Status: Proposal, version 0.1. The lifecycle is a proposed operating model of this publication, not a standard. It builds on stage-gate practice from portfolio management. The evidence levels and decision rules come from The AI Abundance Paradox and Scale, hold, redesign, stop. Challenges and corrections are welcome through the corrections page.