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. Good is a decision the partner's own people would name unprompted.

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. Good is a task with a volume the partner already counts.

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. Good is a delay the partner already reports, not one we inferred.

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. Good is a moment with evidence the partner collected before we arrived.

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. Good is a gap a named role can confirm in one conversation.

List what we have seen rather than been told, against the cells above: 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.

Write four parts in order: the need (what the partner must deliver), the gap (what they cannot do to standard), the observed cause (drawn from the grid above), and the cost (to the outcome, to the citizen or customer, or in money). 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.

Who is asking (roles, not names), how often the same signal has arrived from other teams, and when it started. Good: three roles and a date range, no solution language.

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 and what fixing it would deliver with no model involved. Good: the process, its owner and the cheapest fix. Use the Readiness checklist below for whether the process is stable.

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; the record is still signed in, and shaping starts once a sponsor is named or the requester confirms they will find one before the session.

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.

What they believe they want built, 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, an order placed under a standing agreement or panel arrangement, 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, as a list. Then write the gap in one line: which of the six gates they have not heard of, and which approver they name who sits at none of them. Good is a list shaping can correct in the first ten minutes.

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, and what they have been asked to bring (process documentation, sample data descriptions, the supplier proposal). 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 role that will be named as owner at Commit; it must be identified here, not deferred to that gate. 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.

One or two sentences: what the tool influences, who is affected, and which guidance you read. Link the authoritative guidance your jurisdiction publishes rather than paraphrasing it.

The named role that owns the answer (transparency lead, data protection officer, legal) and the gate it must be settled before. Unconfirmed at Commit means the request waits.

Name the groups on each side. If the same group appears on both sides, say how the balance falls for them.

Groups disproportionately affected, groups not consulted, and people who cannot effectively advocate for themselves. If the answer is nobody, say how you know.

Are rights or entitlements affected? Are there accessibility implications for people using the service or working in it? Route to the equality and accessibility assessments you already run.

Can affected people challenge the outcome? Is there meaningful human review before consequence? Is there a route to redress, and who operates it?

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. For each function on only one list, write one line naming it as under-served or over-attended and the action that follows: a booked value planning conversation, or a route.

Name the request types going through self-service or a deterministic script with no relationship time attached, the rule that puts them there written as a requester would read it, the exception path back to a person, and the throughput and complaint measure that will be read at quarter end. Good means a requester can tell in advance that they are on this route and nobody has to look at the request for it to move.

Name the request types on the fixed path, the path itself in a few steps, which gates keep a person (Shape, Commit and Review), who owns the path, and the exception path back to a named relationship owner. Good means volume moves along a path a requester can see, and judgement stays at the gates where the consequences sit.

Request types handled by a named relationship owner regardless of volume, and why: 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 us, 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. The rule each verdict applies to the decision is stated in the Rank gate decision.

The potential value range and the benefit probability carried from the demand shaping record, checked against where the value map placed the request. Ranges only; a point estimate goes back to the value planning conversation.

The coarse build and run range, with currency, from the demand shaping record or the value planning conversation, for reaching the first measurement at the agreed rung. If the rung has changed since that estimate was made, the cost goes back to the value planning conversation before this item is scored.

Its place among every item ranked this cycle, written as n of N, with the cycle date.

The item that drops a place, loses a team or waits a cycle if this ranks. Name it and its owner.

The nearest neighbours in the ranking and the criterion that most 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 scoring began and before seeing the weights. Write it down without arguing with it yet.

Each criterion where the sponsor's column and the relationship layer's column 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. Record it in the sponsor's own words, read back and agreed in the room.

The criterion result the sponsor discounts and why the relationship layer holds to it, with the evidence behind the score rather than the score alone.

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 layer 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.

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 over the next 12 to 24 months if nothing changes. If the honest answer is that nothing much changes, the case is weak and the forum should hear that here rather than discover it. This narrative is the basis for the Alternative: do nothing row in the investment table; cost it there and record the reasons for refusing it in the output Recommendation and rationale field.

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 the Value Realisation Review, 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.

The Value Realisation Review has just met. This failed. Write the story of what happened in the past tense, as the review would tell it. Then list the two or three earliest signs that story was coming true and who watches for them.

For the range in the output block, say what sits at the low end, the likely point and the high end, and 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.

For each readiness dimension (leadership, data, process, technology, people) whose verdict was Wait or Build prerequisites first, write the prerequisite the readiness canvas named, who clears it and by when. Leave blank for dimensions marked Go.

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: drafting correspondence from case records, 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. Any request above it is an engagement trigger.

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 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.

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 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 route conditions from the logic above that the intake tooling is permitted to test and act on with no person involved. List them by name. Write it so the tooling administrator can set the tooling up from this text alone, with no further meeting.

The conditions that stay with a named role regardless of what the tooling could do, and why. List them by name.

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 six 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.

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: each reason is drawn from how the task actually runs, and would still hold if the request had never used the word agent.

What happens if we stop one rung lower and accept the residual manual effort. Good: the residual manual effort stated in hours per period and who carries it, so the cheaper option can be chosen on its merits.

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 come from real past work, with the awkward ones taken from complaints and reworked items.

The measure that tells us in production that tasks are completing correctly, checked by whom and how often. Good: the signal shows a slow drift as well as a loud failure.

The person who runs the evaluation set before go-live and signs the pass threshold. Good: a name and a role; the owner sits in the business and has seen the agent fail a case before signing.

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: the kill switch has been operated by the person who holds it before go-live, and the time it took is recorded.

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 and the number as restated in 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; the rung is one dimension of the risk, read alongside the data and security section below.

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. An empty field usually means nobody has checked.

Record which reference checks have taken place without the supplier present (organisations of similar size and regulation, using the product for a comparable need) and what each said about the gap between demo and the Value Realisation Review. If none, enter the check as a condition in the table below with an owner and date.

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 and who on our side verified it. A verbal assurance from the sales team scores as unproven.

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

Record which of these the supplier has provided in writing: an AI policy, named accountable roles, an impact assessment process, lifecycle controls, 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 and who on our side verified it.

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 units grows when adoption succeeds. Good: the unit named, the growing driver identified, and any minimum commitments or tiers noted. Volumes are modelled in the next field.

The answer to the third agent question. Work the cost at pilot volume, planned volume and three times planned volume, against the value range in canvas 9. 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 and rate it with the reason. Low: under six months to switch. Medium: six to twelve months. High: over twelve months or no credible route out.

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, and confirms the acceptable use guidance that covers general-use prompts and the date users acknowledged it.

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 for meaning with the business owner of the use case and approval for safety with the centre of excellence; a single gatekeeper for both slows everyone down without making the prompt safer.

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. Where one person currently holds all three, record it as a risk with an owner and a date to resolve it.

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 each neighbour holds so the relationship layer is not quietly doing all of it: product management owns prompts embedded in its own product, the centre of excellence owns the test tooling and the model change notice, the PMO tracks re-test milestones, finance business partnering holds the cost of evaluation at volume. Good names a role against each line and marks any line nobody will take.

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.

Record the version rule delivery and the centre of excellence have committed to apply, and what they count as a change requiring a new version (any edit to wording, any change of model, any change to attached examples or data). Good confirms a model version change is treated as a prompt version change even when the text is untouched; where no rule has been committed, write that as a gap for the decision block.

List what every change must record: version, date, author, approver, reason, test result reference, the model version it was tested on, and for embedded prompts the source of any data the prompt is given and the retention rule for that data. 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.

Record the test set delivery and the centre of excellence have committed to maintain for each prompt class: typical inputs, edge cases, inputs designed to provoke a wrong or harmful answer, and inputs the prompt must refuse. Good names who curates the set and confirms it exists today; where no set exists for a prompt class, write that as a gap.

Record the pass criteria the centre of excellence has set: which outputs must match a reference answer, which are judged by a person against a short rubric, and what blocks approval. Good confirms factual correctness, tone and refusal behaviour are checked separately; where no criteria have been set, write that as a gap.

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.

The audit record for any governed prompt is assembled from the change record and test evidence fields above. State only what is new here: the log retention period, the role that can produce the record, and the number of working days within which it can be produced. Good names a standing role rather than an individual.

The role that convenes the Value Realisation 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 list wide enough that ordinary running never waits on a forum, so the owner acts 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, and make sure it matches the Escalates to column in the table above.

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, and the owner has the standing to withhold it.

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. Good is one role, one forum and a notice period in weeks that the supplier contract and dependent services can actually honour.

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. Write the steps as a dated list with an owning role against each; good is a list the supplier exit terms and the data retention row above already support.

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.

Copy the rung and blast radius from the agent assessment (the rung is one dimension of the risk; the blast radius and the data scope carry the rest); if none was completed, record the rung the business case assumes and flag it in the verdict. Good names the group who carries the error when the output is wrong; naming only the system that produces it leaves nobody to consult.

The committed number from the Commit gate, as a range with its confidence, and the month it is due. Copy it from the business case; renegotiating it here reopens Commit.

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 specifically; 'the general public' hides the people most likely to be harmed.

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' means nobody represents them and the verdict should say so.

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. Schedule each session inside the week of first use for that group; if a session is planned earlier, write down why and what will be repeated at go-live.

Where a user goes when it does not work: named floorwalkers, a channel, office hours, and the hours it is staffed. State who answers when the model's output is wrong and who answers when the tool is down; these are usually different people.

The one-page guides, approved prompt patterns (from canvas 13) and worked examples users will have on day one. For each aid write its author and the date it will be signed off before go-live. Anything without an author and a date is struck from the list.

For each audience: the message, the messenger, and why that messenger carries weight with that audience. A frontline group takes the message from its own supervisor; a message from the programme is read as noise.

The sequence of communications from announcement to ninety days, with dates. Good is a list a communications lead could run without asking a further question.

Claims we decline to make (time saved, jobs safe, accuracy) because we cannot yet evidence them. A short, specific list protects credibility at the value review.

How champions are chosen (colleagues already ask them, whatever their grade), 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. Keep the list short enough that a busy person accepts it without negotiation.

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.

State which groups are added, what retraining the day 30 review showed was needed and who delivers it, the date parallel running ends and who agrees it, and the decision taken at day 60 with the person who chairs it.

Handover from programme support to business-as-usual support, the measures that must be reached for the value realisation conversation, what is passed to the benefits realisation canvas (canvas 18), and the decision taken at day 90 (adopted, adopted for a subset, or trigger called) with the person who chairs it. Good is a named business-as-usual support owner and a dated handover.

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 [agreed proportion] 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. Write one candid line naming 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, marking each as confident or dependent on adoption. Put the assumptions in the task table, not here.

State the single decision: backlog cleared, service extended, quality raised, positions left vacant, or hours returned to staff. Name the option chosen and the strongest alternative you rejected, with the reason.

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 positions, or a new position. Good is one line per role with no hedging.

Name the two or three relationships (a representative, a line manager, a sceptical team lead) that decide whether this change lands, the stance each holds now, the stance needed before Build, and who on the relationship layer owns each conversation. Good is one line per relationship with a named owner and a date for the first conversation.

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 involuntary job loss 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.

One line, exactly as it appears in the business case canvas, including the autonomy rung.

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 this date rather than from project start.

Which review this is, for example month three, the Value Realisation Review (default at month nine) or month eighteen, and the date the next one is booked for.

Who provided the current readings in this canvas, by role, and from which source system or report.

Total realised value to date as a low and high figure against the committed number, in the committed unit; rows in other units are listed, not converted. Keep the M and E portions apart using the marks in the benefits table, 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 reading is below the low end of the committed range at the Value Realisation Review, or if two consecutive reviews show no movement. Name who is notified when it fires.

Where value is escaping now: unmeasured use, a pilot that has not scaled, the old process still running alongside the new, 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 the Commit gate record (canvas 09); do not restate it from memory.

What has actually been realised by the Value Realisation Review, in the same unit as the commitment, and who harvested it after handover. Take the reading from the benefits tracker (canvas 18). 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.

State whether value is rising, flat or falling at the Value Realisation Review, then give a range for the next twelve months on current evidence, with the assumption behind each end of it.

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 the register on 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 the evidence since handover shows 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 (canvas 03). Decisions on them belong to the front door.

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 can proceed 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, the sponsor's own budget, 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 Value Realisation 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.