The AI Demand Toolkit. Twenty canvases, six gates, one route in.

Write the business outcome in the partner's own words and the measure they already report against it: cases closed within standard, decisions upheld on appeal, cost per transaction, time to a first answer. Good is an outcome a minister, board or executive already asks about.

Name the event that makes this worth acting on in the next twelve months where it was tolerated before: a statute or policy change, a contract ending, a budget line moving, a new data source, a service failure that reached the top. Good has a date or a decision attached; general availability of a technology does not count.

Decisions the partner's people make often and find hard: slow, inconsistent between people, escalated more than they should be, or made without information that exists elsewhere. Write who decides, what they lack and what a wrong call costs.

Tasks done many times a day or week that follow a recognisable shape: classifying, drafting the same letter, checking a submission against rules, moving data between screens. Write the task, the volume in the partner's own unit and who does it.

Waiting, re-keying, chasing, re-checking, rework after an error. Write where in the process the delay sits, whether it is a person's time or the elapsed time of the case, and what the partner already tracks that shows it.

Moments where the people the partner serves wait, repeat themselves, receive an answer they cannot act on or give up. Write the moment, the evidence (complaints, drop-off, contact volume) and whether a vulnerable group feels it first.

Knowledge that exists but does not reach the person who needs it in time: buried in documents, held by one expert, spread across systems that do not talk to each other. Write what is needed, where it lives today and who has to go and get it.

List what we have seen rather than been told: a queue report, a complaint log, a rework figure the partner publishes, a process map. Good is material the partner produced before we arrived, so nobody can say it was shaped to fit.

Use the form exactly: the partner is trying to (outcome), cannot (the thing they cannot do or do well enough), because (the observed cause from the section above), resulting in (the consequence for the outcome, the citizen or customer, or the cost). No tool, model or rung of the autonomy ladder belongs in this sentence.

Name the strategic priority, statutory duty or executive commitment this outcome sits under, and how directly: it is the priority itself, a known blocker to it, or adjacent. Good is a line the sponsoring executive would agree with unprompted; if adjacent is the honest answer, write adjacent.

Write what happens if nothing is done for the next twelve months. If the honest answer is that the partner would tolerate it, the opportunity is weaker than it looks and the decision at the foot of the canvas should say so.

Pick the primary type: cashable, non-cashable, avoided cost, quality or strategic. Add a secondary only if the partner would fund the work on the secondary alone.

Lower and upper bound, in the partner's own unit (hours a week, cases a month, days of cycle time, or money) over the first twelve months after the change lands. The lower bound is the figure the partner would still act on; if there is no such figure, stop here.

State what has to be true for the upper half of the range to arrive: which data must be accessible and owned, which process must stay stable, which team must adopt it, which policy must change. Each condition should be something a named role could check within a few weeks.

Low, medium or high, with one line on why. Keep it separate from the range: a large potential with low probability is a different conversation from a modest one that is nearly certain.

What we are hearing, from whom, in their words, and through which door it arrived. Note whether the same signal has come from other teams. Good: a direct quotation, the roles asking, and a date.

What they asked for, verbatim, before anyone improves it. The disguise is evidence of how the requester sees the problem.

The problem beneath the request, written as a person failing to get something done and what that costs today. Ask why until the answer is an outcome rather than a tool. Good: it reads differently from the request and the requester agrees with it.

Who carries the problem now: citizen or customer, front-line staff, a regulator, a minister, board or executive. Name the role rather than the department.

What happens if we do nothing for 12 months, honestly. If the answer is that little changes, write that; it is a legitimate reason to route to Decline.

What shows the need is real beyond the request itself: a complaint log, a queue, a backlog, an audit finding, a regulator's letter. If the request is the only evidence, say so.

The stated ambition from the strategy, plan or the priorities of the minister, board or executive that this need serves. Quote it. If nothing fits, the request is orphaned and that is a finding.

The single outcome that changes for someone if this works, in the language leadership already uses for it. One outcome, with the person who would notice it.

The money, risk appetite and capacity this must live within, as leadership has stated them. Write the one that bites hardest and who set it.

What improves, from floor to ceiling, in a unit someone will recognise: hours returned, cases cleared, days off a wait, cost avoided. Type the benefit as cashable, non-cashable, avoided cost, quality or strategic. A single figure here is a warning sign.

What has to be true for the top of the range to arrive: adoption by a named group, data of a stated quality, a process change, a policy decision. Each condition needs someone who can make it true.

How likely the floor is and why: a comparable case, a pilot, or a considered guess. Write the basis, since the Business Case canvas will test it.

The rung the request implies, in the requester's language. An assistant that does it for us usually means rung four.

The chosen rung, by number and name, that we carry forward. Everything downstream is governed at this rung.

The specific thing the rung below cannot do for this need. If nobody in the room can name it, go down a rung and write the new answer.

At the chosen rung, what a wrong answer reaches before a person sees it: a draft, a record, a payment, a citizen or customer. This sets the depth of the Agent Assessment canvas.

Describe the process the request sits on. If it is undocumented, unstable or performed differently by different people, write what fixing it would deliver with no model involved. Good: the process, its owner and the cheapest fix.

Tools, licences or services the organisation already pays for that would meet most of the need, including ones people have forgotten. Good: the specific feature, who already has access, and the gap that remains.

Whether this request is an instance of one of the small number of platform plays worth funding properly. Good: the play, its owner, and what this request adds to it or takes from it.

Whether a change to statute, policy, guidance or an internal rule would remove the problem outright, and who could make that change.

Go, Wait, or Build prerequisites first, with the single unticked item that decided it.

Job role, team and business function. Good tells shaping who owns the process the request sits in and whether the requester can commit their function's time to a shaping session.

The senior person who knows about the request and would answer for its outcome. Write 'none yet' where that is true; shaping needs to know before it starts.

How it reached the front door: intake form, service desk, corridor conversation, supplier pitch, executive ask, or discovered already in use. Good tells you whether the requester found the one route in or came sideways, and which door needs relabelling.

Where the relationship with this function sits now: order-taker, trusted advisor or strategic partner. It sets the tone shaping can afford to take and how much capital a pause will cost.

Anyone inside the organisation the requester has already spoken to: product management, the AI centre of excellence, the PMO, finance business partnering, legal, security, data protection. List them so shaping neither repeats nor contradicts those conversations.

The date they want it by and what sits behind it: a statute or policy deadline, a board or executive commitment, a contract expiry, a supplier offer that lapses, an announcement already made. Good separates a real external date from an appetite for speed, and says what happens if the date passes.

The request as the requester put it, in their phrases, quoted where you can. Good is a paragraph they would recognise as theirs; resist tidying it into your language, because the wording is evidence shaping will use.

What they say is wrong today, in whose work, and how they know. Record their diagnosis even if you suspect the process underneath is the real problem; that judgement belongs on Canvas 02.

The solution as they picture it, including any rung of the autonomy ladder they have named (a script, a chatbot, an agent) and anything they have seen demonstrated. Requests are solutions wearing a disguise; record the disguise faithfully.

What changes if it works, in their terms: time freed, cases cleared, citizens or customers served faster, errors avoided. Do not convert it to a number here; that is the value planning conversation.

Which citizens or customers, staff groups or partners live with the problem today, and roughly how many people or transactions are involved. An order of magnitude is enough.

Any supplier, integrator, model provider or delivery partner already in the conversation, described by role rather than brand, and what they have been shown or promised. Say whether the request began as their pitch.

Whether this sits under an existing contract, a framework call-off, a free trial, a pilot agreement or nothing at all, who signed it and when it ends. Good states plainly whether a commitment already exists that shaping will have to work around.

Any budget earmarked, spent or promised, with its source and the person who committed it. Write 'none' if none; an assumed budget is worth recording as assumed.

The organisation's own systems the request would read from, write to or sit beside, described generically (case management, the finance ledger, the service management platform). This feeds the architecture and blast-radius questions later.

Any assessment started or finished: data protection or privacy impact, security review, ethics or equality assessment, accessibility, records management, legal advice. Name each document and its status, or write 'none'.

The requester's own view of who has to say yes. The gap between this list and the six gates is useful to know before shaping begins.

Two or three sentences in your own voice: what kind of request this appears to be, what is already committed, and what shaping will have to deal with first. Describe rather than decide; the five shaping outcomes stay open until Canvas 02.

Any existing request, pilot, platform play or forgotten capability in the portfolio that overlaps. A reference is enough; shaping will test whether the need is already solved.

The shaping session booked on Canvas 02, who from the requesting function will attend, what they have been asked to bring (process documentation, sample data descriptions, the supplier proposal), and which canvases open alongside it. Good has a date within two weeks and a requester who knows why they are coming.

The plain account given to the requester of what happens next and how long it takes. One route in only works if the person who used it can see where their request went.

The need beneath the request as shaped in the Demand Shaping canvas, in one sentence, with the outcome it serves. If it arrived as a solution, write the need and put the solution in brackets.

The rung this need is pitched at: deterministic script, single model call, workflow with model steps, agent with tools, or multi-agent system. Readiness is scored against this rung; a Go one rung lower is a legitimate verdict.

The process, teams, systems and data sets in scope, and the ones deliberately excluded. Name them so a second assessor would draw the same line.

What the organisation loses per month of delay, in the sponsor's own terms: hours, backlog, complaints, avoided cost, risk carried. If the honest answer is nothing, write that; it makes Wait cheap and tells the Rank gate something useful.

The observable event that reopens this canvas: a data owner appointed, the process document signed off, the platform migration complete, a new sponsor in post. Write it so a third party could say whether it has happened. 'When things settle' does not qualify.

The role that owns calling the re-assessment, normally the Business Relationship Manager, and the partner who must be in the room for it to count. One line.

The date on which we re-assess even if the trigger has not fired, so that a Wait cannot become a quiet never. Twelve months is the outside limit.

The role that completes this canvas and keeps the register current, usually the Business Relationship Manager. Good is one role with the time and the access to do it.

The single business role that answers if the system causes harm, normally the sponsoring executive or the business owner who will sign Commit. It cannot be a delivery, supplier or centre-of-excellence role.

The roles whose view the rating depends on: information governance, security, legal or ethics, and the AI centre of excellence at rung four and above. Beside each, write what it is asked to confirm.

The roles that need the rating and conditions without being asked to act: the PMO, finance business partnering, the affected service leads and, where relevant, whoever speaks to the regulator.

List each shaped request by its reference and the quadrant it lands in. Good means every item that cleared the Shape gate is placed and nothing is parked on a line between quadrants.

Write the one-line test used to call a request high value, for example: it moves an outcome the sponsoring executive has committed to. Good means the same test was applied to every request.

State the line that separates high volume from low, as requests per quarter or as a band. Good means the figure comes from the intake log and not from impression.

Name the two or three functions at the top of the volume column and say what most of their requests are for beneath the stated solution. Good means you can name the need beneath the count.

Name the two or three functions whose shaped demand, if built with a number attached, would move a committed outcome. Good means each one can be traced to an outcome named on the opportunity canvas.

Functions on the value list that are absent from the volume list are under-served partners; functions on the volume list that are absent from the value list are consuming attention they do not repay. Write what that tells you about who asks and who does not. Good means each function named here appears on one list only and carries a one-line consequence for next quarter's attention.

Request types assigned to the bottom-right quadrant. Write the rule that decides membership and the exception path back to a person. Good means a requester can tell in advance which route they are on.

Request types assigned to the top-right quadrant. State which gates are form-driven and which are held by a named person, and who that person is. Good means volume gets a route and judgement stays where the consequences are.

Request types kept with a named relationship owner regardless of where volume would otherwise send them, and the reason: blast radius, harm to a citizen or customer, exposure under statute or policy, or a partner relationship being repaired. Good means the list is short and each entry carries a reason.

Functions or request types that received relationship time last quarter and will not this quarter, and how that is being said to them. Good means the partner hears it from the relationship owner, with the alternative route, before they notice the silence.

The identifier the front door gave it at Request and the shaped title agreed at Shape. One line.

The need beneath the request in the words agreed at Shape: who is served, what changes for them, and what happens if nothing is done.

The rung from the autonomy ladder agreed at Shape. If the requester still wants a higher rung, write both and the reason given.

Go, Wait or Build prerequisites first, carried from the readiness canvas, with the date it was given. A Wait verdict caps the item at the hold band unless the prerequisite has a funded owner.

The potential value range from the value map and the probability the relationship layer assigned to it. Ranges only; a point estimate goes back to the value planning conversation.

Build and run cost to reach the first measurement at the agreed rung, as a range with the currency. Include the cost of the people who will change how they work.

Its place among every item ranked this cycle, written as n of N, with the cycle date. The PMO must hold the same N.

The item that drops a place, loses a team or waits a quarter if this ranks. Name it and its owner. If nothing moves, a list has grown and the gate has not been exercised.

The nearest neighbours in the ranking and the single criterion that separates each from this item. This is the line a sponsor challenges first, so have it ready.

The scarce team, data owner, approval route or platform slot this draws on, and which other ranked items draw on the same. Contention here moves rank more than the score does.

Any item in the portfolio serving the same need, the same data or the same rung, and whether one platform play could carry both. Write none only if you looked.

Whether ranking this crowds a rung, a theme or a supplier the organisation is already heavy in, or fills a gap the leadership layer has named.

Where the sponsoring executive placed the item before seeing the weighted total. Write it down without arguing with it yet.

Each criterion where the sponsor's score and the room's score differ by two points or more, with both numbers.

The evidence or context behind the sponsor's higher or lower view that the criteria did not capture. Write it so the sponsor would recognise it as fair.

The criterion result the sponsor discounts and why the room holds to it. It is usually data availability, risk or the absence of a named owner for the change.

Any criterion score changed after the conversation, the new value and the evidence that moved it. A change without new evidence is recorded as a disagreement and the original score stands.

Whether the relationship layer holds the score against the sponsor's view or concedes, and what the relationship asks of the sponsor in return: a named change owner, a baseline, a data agreement.

Groups of rows that share a capability, a data set or a user population, listed by row number with the shared thing named. Good is three or four clusters with a one-line reason each; a cluster that contains most of the table is telling you nothing.

Pairs or groups of rows solving the same need for different sponsors. State which is furthest through the gates and what the others would lose by joining it. Good describes the shared need in the requester's own words.

Outcomes in the prioritised strategic demand from leadership that have no row at all. Write each as the outcome it serves. Good is honest about whether the gap is a lack of demand or a lack of a route in.

Where value, cost or risk piles into one function, one supplier or one rung of the ladder. One sentence per concentration and what breaks if that one thing fails. Good separates concentration we chose from concentration that happened to us.

Two or three sentences describing what goes wrong, for whom, and how often. Good: a specific activity, a specific group of staff or citizens or customers, and a frequency. Poor: a restatement of the requested solution.

The teams, roles, citizens or customers who carry the problem now, and roughly how many of them. Name roles, not individuals.

Split into time, money, quality and risk. Give a range for each where you can, in the organisation's own units (hours per week, cases reworked, complaints, findings). This is the baseline every benefit will be measured against, so if you cannot state it, say so and record how you will establish it.

What happens if we do nothing for the next 12 to 24 months. If the honest answer is that nothing much changes, the case is weak and the forum should hear that here rather than discover it.

Describe the same activity after the change, in words a minister, board member or executive would use. Say what people stop doing, what they start doing, and which rung of the autonomy ladder the design sits on. No product names.

Three or fewer conditions that, if met at month nine, mean this worked. Each must be observable and tie to a row in the benefits table below.

Up to five, each as cause, event, effect, with the selected response and an owner. Include at least one delivery risk, one adoption risk and one risk to the citizen, customer or regulator position.

It is twelve months on and this failed. Write the story of what happened in the past tense, as the review gate would tell it. Then list the two or three earliest signs that story was coming true and who watches for them.

State the committed number as a range and say what you believe sits at the low end, the likely point and the high end. Separate benefit potential from benefit probability.

The two or three assumptions that, if wrong, move the range most (adoption rate, volume, data quality, unit cost at scale). For each, say how and when it will be tested.

Any Wait or Build prerequisites first verdicts from the readiness canvas that must be cleared before build starts, and who clears them.

What the centre of excellence, the PMO, product management and finance business partnering have each agreed to do, in one line each. Blank lines are a finding.

Name the category by the need beneath it, not the tool asked for: for example, drafting correspondence from case records, or summarising inbound documents for triage. One playbook per category; if two needs share a name, split them.

The role in the relationship layer that maintains this playbook and answers for its routing decisions. A named role, not a team inbox.

The role that owns the outcome for this category and carries the number at the Commit gate. Good is the same role that signed the business case.

The rung on the autonomy ladder that solves most requests in this category (deterministic script, single model call, workflow with model steps, agent with tools, multi-agent). State the lowest rung that works; requests above it are engagement triggers, not defaults.

Roughly how many requests per month, from which parts of the organisation, and whether they arrive as tickets, conversations or side-door asks. Ranges are fine; the point is to know whether routing rules will be exercised weekly or yearly.

Requests that resemble this category but belong elsewhere, and where they go instead. Prevents the playbook silently absorbing neighbouring demand.

The conditions that must all hold for a request to self-serve or route without the relationship layer touching it: data classification within an agreed tier, no citizen or customer facing output, rung at or below the typical rung, cost per task under a stated ceiling, a pre-approved pattern already in the catalogue. Good is a list of five to eight testable conditions, each with the evidence the requester must supply.

The conditions that pull the request into a shaping conversation with the relationship layer: rung above the typical rung, a new data source, an outcome nobody has committed a number to, a request that is a solution wearing a disguise, or a requester who has asked twice before. Good states what the trigger is and what the conversation is meant to settle.

The conditions under which the relationship layer cannot decide alone and the request goes to the sponsoring executive, the risk and ethics forum, legal, or the regulator-facing function: decisions affecting individual rights, statutory duties, external publication, contract or supplier change, or a blast radius beyond one service. State who receives it and the maximum time before they respond.

How often the playbook is reread against actual routing outcomes, and the trigger events that force an earlier review (a new data source, a change in statute or policy, an incident, a shift in the typical rung). Good is a stated interval of no more than 6 months plus named triggers.

What will show the playbook is working: proportion of requests routed without rework, time from request to route decision, number of escalations later found unnecessary, number of automatic routes later found unsafe. Structural measures only; no targets invented in the room.

Which parts of the route logic the intake tooling is permitted to apply automatically, and which must remain a human decision regardless of what the tooling could do. Write it as a boundary the tooling administrator can configure to.

Version, date, what changed, why, who approved. The first entry is the creation of this playbook. Every later routing change must be logged before it is applied to the tooling, never after.

Name the rung. Good: one rung, stated plainly, with the job it is being asked to do in one line.

For each rung below the chosen one, one sentence on what part of the need it cannot meet. Good: the reasons cite the work, not the request wording or the supplier's pitch.

What happens if we stop one rung lower and accept the residual manual effort. Good: an honest cost of the cheaper option, which often turns out to be acceptable.

Decisions the agent may take with no person involved, each with the boundary that keeps it small (value limit, case type, confidence threshold). Good: a short list; if it runs long, the rung is probably too high.

Each action it may perform and the system it calls to do so, including whether it reads, writes, sends or spends. Good: every write and every send is listed separately from every read.

The data it may see, by category and by record set, and what it must never see. Good: the scope is the minimum the task needs, and the exclusions are explicit.

The credentials and access it runs under, and whether they are its own or borrowed from a person. Good: least privilege, its own identity, no standing access it does not use.

Low and high estimate of one completed task including model calls, tool calls, retries and human review time. Good: a range with the assumptions that drive the high end.

Expected monthly task count multiplied through, plus what changes if volume doubles. Good: shows the point where the cost stops being trivial.

What a completed task is worth against the value plan (canvas 6), so the cost range can be read as a margin. Good: a plain statement of whether the margin survives the high-cost case.

The test cases, including deliberately awkward ones, the agent must pass before go-live, and the pass threshold. Good: cases drawn from real past work, not invented examples.

The measure that tells us in production that tasks are completing correctly, checked by whom and how often. Good: a signal that would show a slow drift, not only a loud failure.

The person who runs the evaluation before go-live and owns the live signal after. Good: a name and a role, sitting in the business, not in the build team.

Who the agent hands to when it is unsure or blocked, and who a person contacts when it misbehaves, with response times. Good: a route that works out of hours.

Who can stop it, how quickly, and by what means (a control a named person can reach without engineering help). Good: tested before go-live, not described.

How actions already taken are reversed or corrected, and what cannot be undone. Good: the irreversible actions are the ones with an approval point above.

The events that reopen this canvas: scope change, new tool, volume increase, incident, or model change by the provider. Good: a short list with an owner for watching it.

The need from canvas 2 and the number from canvas 9, in our words. Good: 'Reduce the time a caseworker spends assembling a case file, target range agreed, owner named.' Bad: any sentence containing the product name.

The autonomy rung from canvas 11 (1 to 5). Record whether the supplier's product sits on that rung or higher. A product two rungs above the need brings cost, blast radius and evaluation difficulty we did not ask for.

Ask the supplier to define, in writing, what 'agent', 'AI-powered', 'autonomous' and 'learns' mean in this product: what it touches, who approves what, at which step. Record their answer verbatim and note where it differs from ours.

Name any platform, licence or team we already have that covers part of this need. Good: an honest statement of the overlap and what the supplier adds beyond it. Empty is a warning sign, not a clean sheet.

Two organisations of similar size and regulation, using the product for a comparable need, spoken to without the supplier present. What did they say about the gap between the demo and month nine?

What happens to the shaped need if we do not buy this. If the honest answer is 'nothing much', return to canvas 9 before spending further evaluation effort.

Where our data is stored and processed, in which jurisdictions, and who else can see it (sub-processors, the model provider). Good: a named data flow diagram reviewed by our data protection lead, with residency matching statute or policy.

Whether our prompts, documents or outputs are used to train or tune any model, by default or by opt-out, and whether that is contractually excluded. Record the clause reference, not the sales assurance.

Which independent assurance reports, certifications, penetration test summaries and audit rights the supplier has actually provided, and their dates. Note anything offered only 'under NDA on request' and whether we have received it.

Do they have an AI policy, named accountable roles, an impact assessment process, lifecycle controls and a route for us to report harmful outputs. Good: documents in hand and a named contact. Bad: a web page.

How and how fast they tell us about breaches, model changes, outages and behaviour drift; whether we can pin a model version; who decides to roll back. Record contractual notification periods.

List every claim we could not verify in the session. Each becomes either a contract condition or a reason to lower the score. Do not leave this blank.

What we pay per (seat, task, token, transaction, outcome) and which of those grows when adoption succeeds. Good: a worked cost at pilot volume, planned volume and three times planned volume, against the value range in canvas 9.

The answer to the third agent question: what a single task costs and what that becomes at full use. Record the point at which the cost curve overtakes the benefit range and who is watching for it.

Contract length, notice periods, uplift caps and what happens to price if the model provider changes their rates. Note anything that lets the supplier reprice mid-term.

How we get our data, prompts, configurations, fine-tuned assets and audit logs out, in what format, in what time, at what cost. Good: a written exit plan agreed before signature and a rehearsal date. Bad: 'standard export'.

What we would have to rebuild to leave: integrations, workflows, prompt libraries, staff habits. Estimate the months of effort to switch supplier or bring it in-house. Rate low, medium or high with the reason.

Open interfaces, standard formats, identity integration and whether it fits the architecture layer (business, data, application, technology) we already run. Name the integrations the build would depend on and who owns each.

List the assistants, copilots and workflow platforms whose prompts this canvas governs. Good names the tool by its role in the organisation (the general-purpose assistant, the case handling workflow engine) and states whether personal chat use is included or excluded.

Name the tasks these prompts perform, grouped as general use (drafting, summarising, searching) or embedded in a workflow (a step that classifies, extracts or drafts inside a process). Good states which of the two receives the heavier controls and why.

Record the highest rung on the autonomy ladder these prompts operate at, taken from the agent assessment canvas. Good says single model call or workflow with model steps; if agent with tools appears, say which prompts and confirm they carry the agent controls as well.

Name what is deliberately excluded (personal experimentation, vendor-supplied system prompts, model training data) and who governs it instead. Good gives an owner for every exclusion rather than leaving it unowned.

Name the roles permitted to write prompts for general use and, separately, for embedded workflow steps. Good allows broad authorship for general use and restricts embedded prompts to people who have completed the testing routine in this canvas.

Name the approver for each class of prompt and what approval attests to (tested against the set, no prohibited content, owner named). Good keeps approval with the business owner of the use case for meaning and with the centre of excellence for safety, not with a single gatekeeper for everything.

Name the single role accountable for the prompt library as a whole: its structure, access, retirements and the review calendar. Good is a role that will still exist in eighteen months, not a project post.

State where creator, approver and owner must be different people, and where one person may hold two roles. Good separates them for every embedded prompt and for any prompt touching personal, financial or safety-related data.

Say who a creator or user goes to when an approver declines, when a prompt misbehaves in use, or when the library owner is absent. Good names a role and a response time in working days.

Record what product management, the centre of excellence, the PMO and finance business partnering each hold in this arrangement, so the relationship layer is not quietly doing all of it. Good lists one responsibility per neighbour.

Name the system of record for prompt text and history (a repository, a document library with version history, a feature of the workflow platform). Good is one place, with read access for all users and write access controlled by the roles above.

State how versions are numbered and what counts as a change requiring a new version (any edit to wording, any change of model, any change to attached examples or data). Good treats a model version change as a prompt version change even when the text is untouched.

List what every change must record: version, date, author, approver, reason, test result reference, and the model version it was tested on. Good adds a one-line statement of what changed in behaviour, not only what changed in text.

Say how a prompt is withdrawn, how users are told, and how a previous version is restored if a new one fails in use. Good gives a rollback time measured in hours and names who may trigger it.

Describe the cases each prompt is tested against: typical inputs, edge cases, inputs designed to provoke a wrong or harmful answer, and inputs the prompt must refuse. Good gives a minimum case count per prompt class and names who curates the set.

State what a passing result looks like: which outputs must match a reference answer, which are judged by a person against a short rubric, and what failure rate blocks approval. Good separates factual correctness, tone and refusal behaviour into distinct checks.

Name who executes the test set, who reviews the results, and whether the creator may test their own prompt. Good has a second person review embedded prompts before approval.

Say what is kept after each test run (inputs, outputs, model version, date, reviewer, verdict) and where. Good is enough that a reviewer eighteen months later can re-run the same set on the current model and compare.

State the review interval per prompt class in months, and what a review covers (still needed, still owned, still passing the test set, still within scope). Good gives a shorter interval for embedded prompts than for general-use ones and names who runs the calendar.

Say how the library owner learns of a model version change from the provider, and what happens next: which prompts are re-run against their test sets, within how many working days, and who signs the results. Good re-runs every embedded prompt before the new model is allowed into production use.

List the signs that a prompt has drifted without a known model change: user complaints, rising manual corrections, refusals on inputs that used to pass, changed output length or format. Good names one measurable signal per prompt class and where it is reported.

State what an internal auditor or regulator must be able to see for any governed prompt: the current text, its version history, approvals, test evidence with model version, the data it touches, and the user or workflow that ran it on a given date. Good confirms the log retention period and who can produce the record within a stated number of working days.

The role that convenes the month-nine review and reports value against the committed number. Usually the relationship layer; write it here even if it seems obvious, because this is the row most organisations leave empty.

The month and the governance forum that will receive the review, fixed now. Good looks like a calendar entry that exists before the build starts.

The baseline, the target, the measure and the source system the owner will report from. If the measure cannot be named today, the number in the business case is not yet real.

List the decisions the business owner can take without a forum: prompt edits within an approved scope, minor supplier changes, pausing the service. Good is a short list that lets the owner act in a week rather than a quarter.

List the decisions that must go to a named forum: changing the model or provider, widening what the service is allowed to touch, moving up a rung of the autonomy ladder, exceeding the run budget, extending to a new citizen or customer group. Name the forum for each.

The artefacts the delivery team must supply before it is released: evaluation results, the prompt library with version history, data lineage, the risk register with open items, the supplier contract and exit terms, the runbook and the cost per task at current and expected volume.

The conditions under which the business owner signs acceptance, and what happens if they are not met. Good is a dated acceptance with named exceptions, not a slide that says 'live'.

The measurable conditions that trigger retirement: value below a stated floor at review, cost per task above a stated ceiling, an unresolved risk above appetite, or the process underneath being replaced. Write thresholds, not sentiments.

The role and forum that can retire the service, and the notice period owed to users, the supplier and any dependent services.

Data disposal or return, licence termination, prompt archive, redirect of the demand it served, and the lesson fed back through the return rail into the review gate.

Two or three sentences on what a person does differently once the AI is live: what they stop doing, what they now check, what decision they no longer make alone. Good is concrete enough that a resistor would agree it is accurate.

The rung from the autonomy ladder the build sits on and who is inside its blast radius when it is wrong. Good names the group who carries the error, not the system that produces it.

The benefit and value figure from the Commit gate, as a range, and the month it is due. Good is copied from the business case, not re-negotiated here.

The single group whose behaviour the number depends on most. If they do not change, the number does not arrive. Good is one group, named by role.

The population affected by the AI decision or output, in plain terms, including any group more exposed than the average (language, disability, digital access, vulnerability). Good names the exposed group, not just the general public.

The person, forum, panel, advocate or data that stands in for them in this work, and how much weight it carries. Good is a named role or forum with a date; 'we assume' is a flag, not an answer.

Whether they will know AI was involved, how they ask for a human to look again, and where a complaint goes. Good is a route that exists today or a dated commitment to build one.

For each group: format (in the flow of work, short session, self-serve), when relative to go-live, and who delivers it. Good is training that happens within a week of first use, not a month before.

Where a user goes when it does not work: named floorwalkers, a channel, office hours, and the hours it is staffed. State who answers questions about the model's output being wrong, as opposed to the tool being down.

The one-page guides, approved prompt patterns (from canvas 13) and worked examples that will exist on day one. List what is written, not what is intended.

For each audience: the message, the messenger, and why that messenger carries weight with that audience. A frontline group hears it from its own supervisor, not from the programme.

The sequence of communications from announcement to ninety days, with dates. Include the moment we tell people what has changed as a result of their feedback.

Claims we decline to make (time saved, jobs safe, accuracy) because we cannot yet evidence them. Good is a short list that protects credibility for the value review.

How champions are chosen (peer credibility, not seniority), one per team or site, the time they are released for it, and who backfills that time. Name the champion lead.

The specific tasks: first-week floorwalking, collecting examples of good and bad output, relaying issues, running a short show-and-tell. Good is a list short enough that a busy person accepts it.

The channel, who triages it, and the time within which a user gets a response. Separate three kinds: tool broken, output wrong, process does not fit. Each goes to a different fixer.

How and when users hear what changed because of what they reported. Include the review meeting cadence in the first ninety days and who attends from the business side.

What happens, who is on the floor, which measures are read weekly, and the decision taken at day 30 (continue, adjust, pause). Good is a plan that names the meeting and the person who chairs it.

Widening, retraining where the first block showed gaps, withdrawal of parallel running if agreed, and the decision at day 60.

Handover from programme support to business-as-usual support, the measures that must be reached for the value realisation conversation, and what is passed to the benefits realisation canvas (canvas 18).

The measure, the threshold and the date at which we say adoption has not happened. One line, agreed now, so nobody argues about it later. Example form: fewer than half of eligible tasks done the new way by day 60 in the primary user group.

The options we commit to considering: redesign the working practice, retrain, narrow the scope to the group where it works, or withdraw and record the lesson. Name who convenes the decision and within how many days.

Which relationships are spent if this fails visibly, and what the BRM does to protect them before the trigger date rather than after. Good is a candid line about which sponsor's credibility rides on this.

Name the capabilities the changed work demands more of, such as checking model output, framing a request well, judging exceptions or explaining a decision to a citizen or customer. Good is specific enough to appear in a role profile.

Name the capabilities the change removes demand for, and say honestly whether they were a source of pride or identity for the people who hold them. Good acknowledges the loss rather than dressing it up.

Give a range per team, drawn from the task table, with the assumption behind it. Good separates time released with confidence from time that depends on adoption.

State the single decision: backlog cleared, service extended, quality raised, posts not backfilled, or hours returned to staff. Name the option chosen and the one rejected.

Name the role that made the reinvestment decision and the date. If the answer is nobody yet, write that and escalate before Build.

List role titles and grade or band, with headcount range per team and location. Good includes contractors and outsourced staff, who are often forgotten.

For each role, say whether the effect is a changed task mix, a changed role profile, a reduced number of posts, or a new post. Good is one line per role with no hedging.

Write the three to five things the organisation commits not to do as a result of this change, in words a member of staff could hold us to: for example, no compulsory redundancy from this change within a stated period, no individual performance measures derived from system output without agreement, no removal of a task before its reskilling route is open. Good is specific, dated where it can be, and signed by the business owner.

Name the AI capability and the autonomy rung it runs at. One line, exactly as it appears in the intake record.

The role that committed to the number and is accountable for harvesting it. A role title, not the project manager and not the delivery team.

The number signed at Commit, its unit (money, hours, cases, error rate) and the date by which it was due. Write the range that was committed, not a single tidied figure.

When delivery signed off and the organisation took ownership. Benefits are counted from here, not from project start.

Which review this is (for example month three, month nine, month eighteen) and the date the next one is booked for.

Who provided the current readings in this canvas and from which source system or report. If a reading is an estimate rather than a measurement, say so here.

Total realised value to date as a low and high figure against the committed number, in the same unit. Separate what has been measured from what has been estimated, and state which benefits are contributing and which are not yet moving.

The difference between the committed range and the achieved range, and the honest reason for it: behaviour not changed, measure not tracked, assumption wrong, or capability underperforming.

The condition that forces action before the next review, stated as a reading. For example: if the current reading is below the low end of the committed range at month six, or if two consecutive reviews show no movement. Name who is notified when it fires.

Where value is escaping: unmeasured use, a pilot that has not scaled, the old process still running, or costs not counted. One line per leak, with the owner who can close it.

The value we signed at the Commit gate, in the range we agreed (low, expected, high), with the benefit type: cashable, non-cashable, avoided cost, quality or strategic. Copy it from canvas 18; do not restate it from memory.

What has actually been realised by month nine, in the same unit as the commitment, and who harvested it after handover. Good states the measure, the baseline it moved from and the date of the reading.

High, medium or low, with the reason: direct measurement, proxy measure, sampled, or self-reported. State what would raise it to the next level.

Difference between committed and measured, and whether it comes from adoption (people not changing how they work), the capability itself (quality, cost, reliability), or the number (it was never achievable). Name one cause as primary.

Total cost of running and maintaining the capability since commitment, including per-task model cost at actual volume, against what the business case assumed. One line, with the variance.

Is the value still rising, flat or falling at month nine, and what does the next twelve months look like on current evidence? Good is a range, not a point estimate.

Two or three things that happened which none of the shaping canvases predicted: value in a place we did not look for it, resistance where we expected welcome, a use nobody designed. State the surprise and its consequence.

The specific things that did not work: a step the model could not do reliably, an integration that never landed, a group that did not adopt. Cause, event, effect. Good separates failures of the capability from failures of the organisation around it.

Where people are using the capability outside its intended scope, or have built their own alternative because this one did not fit. This is unmeasured value or unmanaged risk; say which.

Any risk from canvas 05 that became an event, and any event nobody had on the register. For each, whether the selected response worked.

The one or two changes that would raise realised value: wider adoption in a named group, a broken upstream process fixed, a second use of the same capability. Estimate the uplift as a range and name who would have to act.

The changes that would lower cost per task or total cost: a lower rung for part of the work, a cheaper model tier, fewer human review steps where evaluation shows they add nothing, a licence not renewed. Estimate the saving as a range.

Controls set at Build that nine months of evidence show are heavier than the blast radius warrants. Name the control and the evidence. If nothing can relax, say so and why.

Where the capability has drifted beyond what it was allowed to touch, or where approval steps are being skipped. Name the control and the owner of the fix.

Requests this capability has generated: adjacent processes, the next rung up, the same pattern in another business area. List each as a one-line request for the Request gate, not as a decision made here.

The single most useful thing the shaping canvases should ask differently next time, written as a question a BRM can put to the next requester. Feeds canvas 02.

What this initiative proved or disproved about a platform play, a data prerequisite or a skill the organisation needs. Feeds canvas 20.

How the position of this initiative on canvas 08 should change: value band, confidence band, and whether it now anchors a platform play or stands alone.

Name the prerequisite in the words the readiness canvas used, for example named data ownership for case records. Good is a blocker that has appeared in at least two assessments.

List the request or opportunity ids that returned Wait or Build prerequisites first because of this blocker. Good shows the demand that unlocks once it is fixed.

State the horizon by which the prerequisite is met and the named role accountable. Good is a role that already exists or is created on this roadmap.

Describe the shared capability in one sentence and the demand cluster it serves, for example document summarisation across three casework services. Good names the highest autonomy rung it needs.

State where the money comes from (portfolio budget, sponsoring directorate, reallocated licence spend) and the horizon in which the play is live. Good has a finance business partner already consulted.

Write dependencies as A before B, for example data ownership before any agent above rung three; prompt governance before skills rollout. Good has three to six chains, each traceable to a table cell.

Identify which chain, if late, delays the whole roadmap, and where there is room to slip. Good names the single dependency the relationship layer will watch most closely.

State the interval (quarterly is typical) and the forum in which the refresh happens. Good ties refresh to the month-nine value reviews so measured outcomes update the plan.

Name the role that owns the refresh and who they must consult. Good is the relationship layer, with the centre of excellence and finance as standing contributors.

List the events that reopen the roadmap before the next cadence, for example a regulator changes a rule, a supplier exits, a platform play misses its number. Good has three to five triggers.