Evidence Before Claims
Why the smallest useful next move is a better place to start than an AI transformation program
A practical framework for choosing one useful, testable AI move without turning a broad ambition into an unbounded first project.
“Transformation” is a direction, not a starting scope
The phrase “AI transformation” can refer to broad and important change: new products, redesigned operations, different skills, better data, and a new way of making decisions.
The problem is not the ambition. The problem is treating the ambition as the first unit of delivery.
A transformation program can contain dozens of workflows, systems, data sources, affected roles, vendors, and risk decisions. Before the organization has learned which of those dependencies matter, a large program turns uncertainty into a budget and a schedule.
That makes basic questions harder to answer:
- Which business problem are we solving first?
- Who owns the result after the project team leaves?
- What evidence would justify expanding it?
- What information is safe to use?
- Which decisions must remain human?
- What happens if the model, vendor, or process fails?
- Can we stop without leaving an unsupported system behind?
I prefer to start with the smallest useful next move: a bounded decision or workflow change that produces enough value and evidence to justify what happens next.
That is a starting method, not a ceiling on ambition.
“Small” is not the same as “bounded”
A two-day chatbot demo is small. It may still be unbounded if nobody defines what information it can see, who reviews its answers, or who will support it.
A six-week workflow pilot may be larger, but properly bounded if it has a named owner, controlled inputs, measurable acceptance criteria, a human decision point, and a removal plan.
I use six boundaries to distinguish useful work from a demo that merely looks busy.
1. A workflow boundary
Name the trigger, the work performed today, and the output somebody uses. “Improve operations” is not a workflow. “Draft a classification and response for incoming warranty requests” might be.
2. An outcome boundary
Record the current baseline and the change worth testing. The measure should fit the workflow: handling time, correction rate, queue age, rework, completion rate, or another observable result. Do not invent a metric merely to make the project sound quantitative.
3. A data boundary
Specify permitted, prohibited, and synthetic-only information. Identify where inputs, prompts, outputs, logs, and evaluations will be retained. A narrow use case can still create broad privacy or confidentiality risk if the data path is undefined.
4. An action boundary
Separate reading, drafting, recommending, approving, and executing. Human review is not a decorative checkbox: name the person with authority, the information they see, and what the system cannot do before approval.
5. An evidence boundary
Define positive tests, negative tests, and the conditions under which the result is inconclusive. A few impressive examples do not establish reliability. The test set should include routine work, awkward edge cases, and inputs the system must refuse or escalate.
6. A lifecycle boundary
Decide who will monitor, support, update, hand off, pause, and eventually retire the result. If nobody owns the workflow after the pilot, the work is not ready to scale no matter how good the demo looks.
A worked example: exception triage, not “automate operations”
Consider a fictional distribution company whose operations team manually reviews order exceptions. The numbers below are illustrative, not results from a client engagement.
The broad idea might be:
Use AI to transform order management.
That statement is too large to test. A smallest useful next move might instead be:
For one category of non-urgent order exception, draft a reason code and a recommended next step from approved fields. A coordinator reviews every recommendation before anything is written to the order system.
The one-page boundary could look like this:
| Decision | Illustrative definition |
|---|---|
| Business problem | Coordinators spend too much time assembling the same facts before triage |
| Current baseline | Measure handling time, correction rate, and queue age for two weeks |
| Input | Approved, minimized order fields; synthetic records during development |
| Output | Draft reason code, short rationale, and recommended queue |
| Prohibited action | No customer message, order change, refund, or automatic closure |
| Human owner | Operations manager owns policy; coordinator approves each result |
| Acceptance | Pre-agreed quality and handling-time thresholds on a representative test set |
| Negative tests | Missing fields, conflicting records, sensitive free text, and requests outside the chosen category |
| Stop condition | Material quality failure, unsafe data handling, no usable time improvement, or no operating owner |
| End decision | Expand one boundary, revise and retest, hand off, or remove |
This scope does not require the company to choose an enterprise-wide AI stack first. It creates evidence that will inform architecture later: input quality, exception patterns, review burden, integration needs, failure modes, and actual operating cost.
It can also reveal that AI is not the best answer. A validation rule, required form field, queue redesign, or conventional automation may solve the problem with less variability and less support work.
That is a successful decision too.
How to choose the first move
Do not select the first use case solely because it is visible or exciting. Compare candidates on a small set of decision factors.
| Factor | A stronger first candidate | A weaker first candidate |
|---|---|---|
| Value | Frequent friction with a meaningful operating cost | Novelty without a clear user consequence |
| Observability | Baseline and result can be measured or reviewed | Success depends on vague sentiment |
| Ownership | One leader and one workflow owner will make decisions | Responsibility is distributed or absent |
| Data readiness | Permitted inputs are accessible and understandable | Critical data is unknown, unowned, or unsafe to use |
| Reversibility | Work can remain advisory and be removed cleanly | Early changes create hard-to-reverse commitments |
| Consequence | Errors are detectable and recoverable | Errors could materially harm people or create regulated decisions |
| Adoption | The people doing the work can test and improve it | The workflow is being imposed without user involvement |
The highest-value use case is not automatically the best first use case. A moderate-value workflow with clear ownership and recoverable errors may teach the organization more than a high-stakes process it cannot yet govern.
The one-page next-move brief
Before discussing models or vendors, answer these questions on one page:
- Workflow: What happens today, from trigger to useful output?
- Friction: What delay, cost, error, or missed opportunity is visible?
- Owner: Who owns the business rule and the go, hold, or stop decision?
- Alternatives: Could a process change, rule, form, report, or ordinary automation solve it more simply?
- Permitted data: What may enter the test, and what must not?
- Permitted action: May the system read, draft, recommend, or execute?
- Baseline: What evidence describes the current process?
- Acceptance: What result would be useful enough to keep?
- Failure: What would make the organization stop immediately?
- Lifecycle: Who operates, monitors, supports, hands off, and removes it?
- Next decision: At the review date, will the organization expand one boundary, revise, hold, or stop?
If those answers do not fit on one page, the first move may still be too broad—or the organization may need discovery before implementation.
Why this aligns with responsible AI guidance
This method is my synthesis, not a named standard. It does align with several authoritative sources.
NIST's AI Risk Management Framework organizes work around Govern, Map, Measure, and Manage. Its Map function emphasizes intended purpose, users, context, impacts, limitations, and non-AI alternatives. Its Manage function includes a decision about whether a system achieves its purpose and whether development or deployment should proceed.
The Government of Canada's generative-AI guidance similarly recommends using these tools only where risks can be managed. It emphasizes accountability, security, transparency, oversight, performance measurement, and human responsibility for outputs.
The G7 SME AI Adoption Blueprint, developed during Canada's 2025 presidency, is particularly direct: value-driven roadmaps can align adoption with business goals, while pilots and phased rollouts can reduce risk and support scaling. It also notes the important counterpoint that limited pilots can struggle to become deeply integrated or useful.
That counterpoint prevents “start small” from becoming lazy advice. A bounded first move is valuable only if it ends in an explicit operating decision.
When a broader transformation program may be appropriate
Some organizations do need coordinated portfolio-level change. A broader program may be justified when:
- several valuable workflows depend on the same broken data or identity foundation,
- policy, procurement, training, and operating-model changes must be coordinated across business units,
- duplicated experiments are creating material cost or risk,
- regulatory or customer obligations require organization-wide governance,
- or leadership has enough evidence to fund shared capabilities deliberately.
Even then, the program should be decomposed into reviewable decisions. A broad roadmap does not remove the need for bounded implementation.
What I am applying in my own work
My current Service Foundry artifacts use this pattern in several places:
- public intake is a qualification route, not a quote or capability promise;
- one workflow, sponsor, and owner are preferred over a broad automation brief;
- ballparks remain non-binding until assumptions and human approval are present;
- implementation candidates include acceptance, recovery, rollback, and handoff;
- production release and ongoing operations remain separate decisions;
- and offers that exceed demonstrated capability move to discovery, specialist-supported work, or a decline.
Those controls have been designed and implemented in working artifacts. The commercial offer is not yet evidence of customer delivery, and managed AI operations are not currently available. That limitation belongs beside the method, not hidden after it.
The practical conclusion
The smallest useful next move is not the smallest thing a vendor can sell. It is the smallest decision that gives the organization honest evidence.
It should improve something worth improving, expose the work needed to operate it, and preserve the option to stop.
The goal is not to avoid transformation. It is to avoid pretending the organization can purchase certainty before it has learned what must actually change.
References
- NIST AI Risk Management Framework — voluntary framework for incorporating trustworthiness into the design, development, use, and evaluation of AI systems.
- NIST AI RMF Core — Govern, Map, Measure, and Manage outcomes, including purpose, context, measurement, and proceed-or-stop decisions.
- Government of Canada: Guide on the use of generative artificial intelligence — risk-based use, accountability, security, transparency, oversight, and performance management.
- G7 Industry, Digital and Technology Ministerial Statement on the SME AI Adoption Blueprint — value-driven roadmaps, pilots, and phased rollout for responsible SME adoption.
- G7 SME AI Adoption Blueprint — adoption barriers and the difficulty of translating small experiments into sustained integration.
- GOV.UK Service Standard: iterate and improve frequently — early real-world use and continued iteration across a service lifecycle.
Further reading
- OECD SME AI Readiness Tool — a short, privacy-preserving pilot tool for considering organizational readiness and support options.
- NIST AI RMF Playbook — adaptable actions for applying Govern, Map, Measure, and Manage.
- Government of Canada: Toolkit for SMEs deploying AI — responsible-deployment guidance tailored to smaller organizations.
- GOV.UK guidance on deploying software regularly — small, auditable changes, feedback, and smoke testing.
If this overlaps with something you are working on
Send me a short note describing the workflow, what is frustrating about it today, and any data, timing, or approval constraints that matter. Start a conversation.
Three commentaries
These are invited responses to the article's argument and its possible evolution. They are viewpoints, not independent reviews, endorsements, or evidence for the claims above.
Codex
The article is persuasive because it defines a bounded first move by its owner, inputs, decision, recovery, and stop condition—not merely its small size. Its next evolution should be a continuation rule: before a pilot begins, name which boundary may expand next, who can authorize it, and what evidence must exist. That makes success an accountable transition rather than a vague invitation to scale.
Qwen, local model
The article effectively argues against treating broad AI transformation as an initial delivery unit, favoring bounded, testable moves that generate honest evidence. This approach mitigates the risk of converting uncertainty into unmanageable budgets and schedules. A concrete direction for evolution is developing a standardized boundary maturity metric that organizations can use to objectively assess when a pilot has generated sufficient evidence to justify scaling, moving beyond subjective review dates to data-driven decision gates that validate operational readiness before expansion.
Claude
Small is not the same as bounded is the line that does the work; the six boundaries are a better filter than most pilot checklists. The weakness is the one the article half-concedes via the G7 counterpoint—the method is much stronger at starting than at continuing. I'd add a second-move rule: define, before the pilot ends, which single boundary expands first and on what evidence.