AI Value Canvas Working Template

Use this AI Value Canvas (AVC) template as a working document for one initiative. Complete the sections that matter for its current Horizon; do not present an assumption as evidence. Mark each material statement A (assumption) or E (evidence-backed), and link or name the evidence where possible.

Project context and decision

• Initiative name:
• Prepared by / role:
• Date started / last updated:
• Strategic Intent: What organizational outcome is this intended to

support?

• Accountable Project Owner: Who can make the next funding, scope, or

stop decision?

• Current Horizon: Experiment / Pilot / Scale
• Horizon success criteria and budget band: What must be true, and what

budget range applies, before moving to the next Horizon?

• Decision needed now: Proceed / test / rescope / defer / stop
• Decision gate and date: What evidence is required by when?
• Scope and constraints: Jurisdictions, sectors, policy, procurement,

budget, dependencies, or timing constraints:

Domain 1: Customer Understanding (Desirability)

Customer/User Segments

• Primary user segment (one only): Identify the role that performs the

task or acts on the output. Record the industry, organization size, team or reporting line, geography if material, and observable evidence that this is the highest-priority segment.

• Secondary user segment (maximum one, if material): Identify the role,

industry, organization size, and team or reporting line. Explain why this segment needs distinct treatment rather than being an affected person or a stakeholder.

• Affected people: Who may be affected without choosing to use it?
• Decision stakeholders: Who approves, controls, or is accountable for

the decision?

• Economic buyer: Who funds the work or receives the economic benefit?
• Change sponsor / operational owner: Who will support adoption after

launch?

• Workflow context: What triggers the task, how often does it occur, and

what decision or action follows?

• Current tools and hand-offs: What people, systems, documents, queues,

and hand-offs are used today?

• Reporting context: What incentives, targets, service levels, or

reporting requirements shape the current behaviour?

• AVC AI-literacy rubric (1–5): This is an AVC operational rubric, not a

validated measurement scale or a legal compliance test. Score the primary segment from observable behaviour, not self-description. 1: users need facilitated support to interpret and review an output. 3: users can independently use the specified service, recognize ordinary uncertainty, and follow the escalation path. 5: users routinely check outputs against their own sources, document corrections, and can describe when not to rely on the system. Record the score and supporting evidence separately from accessibility and access constraints. Where European Union (EU) scope applies, record the provider or deployer measures relevant to AI literacy under Article 4 of the EU AI Act, taking account of the people, use context, and affected groups involved.

Jobs to Be Done & Pains & Gains

• Primary Jobs to Be Done: Write one outcome-focused job: “When ___

happens, I am trying to _, but I struggle because _. Help me _, so I can _ without ___.”

• Current baseline: Time, cost, error, delay, service level, completion

rate, or other measurable starting point. State the source and date.

• Current workflow evidence: What observation, interview, data, or

artefact confirms the problem and the hand-offs?

• Ranked pains: For each pain, record the affected person, frequency,

severity, evidence, and rank.

• Desired gains: What measurable or observable improvement would matter

to each user or stakeholder?

• Pain-to-opportunity link: Which pain is the proposed intervention

intended to address, and why is that the priority?

Trust and adoption

• Trust and adoption barriers: What would make each user hesitate to

start, avoid acting on an output, or stop using the service after a bad experience?

• Adoption conditions: What disclosure, training, support, proof,

workflow change, accessibility measure, or human escalation path is needed?

• Adoption measure: Define eligible-user denominator, activation,

repeat use, and the evidence that adoption improves the intended outcome.

Domain 2: AI Opportunity & Solution (Feasibility)

AI Opportunity Fit

• Specific user decision or action: What decision or action is being

improved, and who owns it?

• AI task: Is the system retrieving, classifying, predicting, generating,

recommending, detecting, or orchestrating a bounded task?

• Five tests: For ambiguity, prediction/generation, value delta,

error tolerance, and alternatives: what is the evidence or key uncertainty?

• Feasibility confidence: High / medium / low. What single uncertainty

could most change this assessment?

• Alternative comparison: Compare the proposed AI approach with:
• spreadsheet or simple model;
• rule-based workflow;
• person or process change;
• doing nothing or improving access to existing information.
• Why AI now: What expected advantage remains after that comparison, and

what would cause you to choose a non-AI alternative instead?

Solution Concept / Interaction Flow

• Interaction mode: Recommendation / Approval / Alert / tightly bounded

automated action. Explain why this mode is appropriate for the decision’s consequence and error tolerance.

• Decision authority: Who may act on the output? Who approves or can

override it? Who receives an escalation?

• Explanation and correction: What information helps the user challenge,

correct, or appeal an output before it causes harm?

• Named participants and tools: Identify the user, action, system, and

connected tool or service at each step.

• Six-step flow: Trigger → input → AI processing → output → next action

→ failure path.

• Feedback loop and disposition: Define how feedback is captured and

classified, who reviews it, and the cadence. For each material item, record its disposition (accepted, rejected, or needs investigation), rationale, and the accountable improvement owner.

• Change type and owner: Does accepted feedback change a prompt, rule,

model, retrieval source, or evaluation criterion? Who makes the change?

• Validation threshold: What evidence and threshold must the change meet

before release?

• Release approval and deployment: Who approves release, and how is the

validated change deployed?

• Post-release monitoring: What is monitored after deployment, who reviews

it, and how does it return to the production improvement cycle?

• Fallback path: What happens when input is missing, confidence is low,

a user disagrees, or the system is unavailable?

Conditional controls for agentic systems

Complete this only if the system selects or calls tools across multiple steps.

• Objective and stop condition: What task may the agent complete, and

when must it stop and ask for help?

• Permitted tools, actions, and data: What is explicitly allowed? What is

prohibited?

• Approval checkpoints: Which actions require human approval before the

agent continues?

• Sandbox and tool brokering: How are high-impact tools and external

effects isolated or mediated through a controlled intermediary?

• Budgets: Maximum steps, time, tokens, spend, and retries:
• Context and token controls: State the usable context-window limit (the

maximum information the model can consider at once), source-prioritization and truncation rules, what happens when relevant context cannot fit, and how token use and cost scale with task volume, retries, and tool results.

• Audit trail: What input, tool call, approval, output, and exception is

recorded?

• Kill switch and incident owner: Who can disable the agent, and how is

recovery handled?

Domain 3: Data, Model & Risk (Sustainability)

Data & Model Considerations

• Named data systems: What systems, documents, feeds, or vendors supply

the data?

• Data required: Describe key fields, example records, expected volume,

refresh rate, and historical coverage.

• Data acceptance thresholds: Define the minimum acceptable volume,

population or workflow coverage, freshness, and quality before a data source may be used. State each threshold, measurement method, evidence date, owner, and what happens if it is missed.

• Quality gaps: Missingness, timeliness, bias, inconsistencies, drift,

and any known limitations:

• Labels or ground truth: What reference answer defines a correct output,

who provides it, and how representative is it? Identify the evaluation dataset or split, its sampling method, the target users and cases it covers, important gaps, and the representativeness check.

• Data owner, access, and rights: Who owns the source, grants access,

controls retention, and confirms lawful or contractual use?

• Personal or sensitive data and purpose: What data is involved, and why

is each category needed for this initiative?

• Applicable privacy and sector requirements: Which privacy, consent, or

sector requirements apply? For Malaysia, consider the Personal Data Protection Act 2010 (Act 709) and the Personal Data Protection (Amendment) Act 2024 (Act A1727), alongside current legal advice.

• Data-minimisation decision: What data will not be collected, retained,

or exposed to the system, and why?

• Data-subject requests: Who owns the time-bound process for applicable

access and correction requests and withdrawal of consent?

• Retention, disposal, and deletion: What retention or disposal duties

apply? Separately identify any deletion obligation under another applicable law or contract and any lawful retention or deferred-deletion exception.

• Vendor and processor propagation: How are applicable requirements and

requests propagated to vendors, processors, retrieval stores, and backups?

• Approach comparison: Compare rules, classic or simple models,

pre-trained models, fine-tuning, and training from scratch. State why the selected approach is proportionate.

• Model rationale and rejected alternatives: What was selected, what was

rejected, and why?

• Required performance: What accuracy, reliability, latency,

interpretability, robustness, and cost level is necessary for this use?

• Offline evaluation: What dataset, metrics, and pass thresholds apply

before launch?

• Production monitoring: What quality, safety, latency, and drift measures

are monitored in production, and what alert thresholds apply?

• Release rule and exceptions: What threshold must be met before release?

If it is not met, who may document and approve a time-bound exception?

• Evaluation ownership and cadence: Who owns evaluation, who is the

pre-launch approver, and what post-launch review cadence applies?

• Infrastructure, integration, and sizing: State hosting, security,

identity, logging, interfaces, and performance constraints. Size compute, storage, expected and peak throughput, availability target, development, test, and production environments, monitoring coverage, and monitoring-data retention.

• Deployment rationale: Explain why cloud, on-premises, or hybrid hosting

is appropriate for the data, integration, resilience, cost, and regulatory constraints.

• Build / Buy / Partner decision: Compare capabilities, cost, data terms,

vendor lock-in, exit path, and accountable owner.

• Lifecycle ownership: Who owns versioning, evaluation, monitoring,

incident response, rollback, update or retraining decisions, and retirement?

AVC data, model, and operating-readiness rubric (1–5)

This is an AVC operational rubric, not a validated measurement scale or a legal compliance test. Score this domain from 1 to 5 and cite the evidence behind the score.

• 1 — unready: Data access, rights, minimum quality, evaluation method, or

operating controls are assumptions or are not yet owned.

• 3 — conditionally ready: Named sources meet documented minimum

thresholds for the intended test, an evaluation dataset covers the core workflow, and owners and release criteria exist; material coverage, performance, or production-control gaps remain.

• 5 — ready for the stated Horizon: Production-relevant data meets its

acceptance thresholds, evaluation evidence covers target users and known edge cases, operating and rollback controls have been tested, and the named owner accepts the residual risk for the stated Horizon.

Risks & Guardrails

Create one row for every material risk.

Check specifically for:

• unfair or biased outcomes: Identify affected groups, contextually

relevant attributes, and any legal protections that apply; protected status varies by jurisdiction and context. Define appropriate subgroup testing, the disparity or harm threshold that triggers action, the response, and the accountable owner. Where testing requires sensitive attributes, document the purpose, minimisation, source, access restriction, retention, and applicable legal basis, consent, or other authorization; obtain privacy or legal review where required.

• inaccurate, fabricated, unsafe, or out-of-scope outputs;
• over-reliance, automation bias, weak disclosure, and inadequate recourse;
• harmful use, security abuse, prompt injection (untrusted content that tries

to override system instructions), or unauthorized tool use;

• privacy, confidentiality, retention, data-rights, PDPA, and sector issues;
• vendor, model, data-source, and service-continuity risks;
• escalation requirements for employment, healthcare, financial access,

safety, or another sensitive-decision context;

• conditional agentic controls, including permissions, sandboxing, budgets,

audit traces, approval gates, and a kill switch.

Twelve-month pre-mortem

Assume this initiative has failed or caused an unacceptable outcome within 12 months. Record the likely cause, earliest warning signal, prevention, contingency, and accountable owner.

Domain 4: Value & Cost (Viability)

Value & Metrics of Success

For each material outcome, define the baseline, target, deadline, owner, and method before claiming value.

• Attribution plan: What baseline or comparison group distinguishes the

intervention from normal variation or another change?

• Adoption assumptions: State the eligible population, adoption forecast,

evidence basis, and an early-adoption stress case. A 20–30% adoption case is an AVC illustrative planning stress case, not an external benchmark; replace it with project evidence where available.

Cost Drivers

• Currency, volumes, and evidence basis: State the currency, usage volume,

period, and whether each input is an assumption, vendor quote, observed cost, or estimate.

• Cost classification: Classify every cost as fixed, variable, or

step-fixed. State the cost driver, unit basis, and whether it changes at 50% of forecast volume.

• Build costs: Discovery and research; data acquisition, cleaning, and

rights; design and engineering; model or vendor setup; integration; evaluation and red-teaming; security, privacy, legal, and governance; change management and training; contingency.

• Recurring costs: Model or application programming interface (API) use;

infrastructure; data refresh; monitoring and evaluation; support; incident response; vendor fees; licences; human review; maintenance and improvement.

• Build / Buy / Partner economics: Compare one-time investment, monthly

run cost, capability, lock-in and exit cost, delivery risk, and owner.

• Economics summary: Total investment; monthly run cost; Year 1 value;

Year 1 net result; payback month; and the return on investment for a stated period.

• Formulae: Define every input, period, monetary basis, and treatment of

tax and cost of capital. For example, Year 1 net benefit = Year 1 monetised value − build cost − Year 1 run cost and Year 1 ROI = Year 1 net benefit ÷ (build cost + Year 1 run cost). Define payback as the first month in which cumulative monetised benefits equal or exceed cumulative cash costs, and state timing and discounting assumptions. Keep unmonetised benefits outside ROI arithmetic or report them separately.

Unit economics and reconciliation

Use the same unit throughout: an eligible user, active user, completed task, or transaction. State why the selected unit represents both cost and value. Calculate the Forecast volume and 50% of forecast volume columns using the same time period and assumptions used in the Year 1 sensitivity test.

Sensitivity test

Show the same economics under each scenario; do not use optimistic adoption as the only case. The percentages below are AVC illustrative planning stress cases, not external benchmarks; replace them with project evidence where available. Recalculate the selected-unit volume, step-fixed thresholds, variable cost, Year 1 run cost, and value for every row. Year 1 net result = scenario Year 1 value − scenario build cost − scenario Year 1 run cost. Each net result must reconcile to the stated unit-cost, volume, and value assumptions.

Evidence, assumptions, and next decision

Critical assumptions register

List the three to five assumptions that would most change the decision if they proved wrong.

Self-score and gate

Set a Green/Amber/Red gate status for each domain before moving to the next Horizon.

AVC default gate rule: If more than two domains are red, pause rather than treating the Canvas as a box to complete. Adapt this governance rule only with a documented accountable decision. State whether the next move is to proceed, test, rescope, defer, or stop, and record the accountable owner and decision date.