SEI AI Adoption Decision and Roadmap Workbook

Status: Working draft for validation
Version: 0.1
Date: 2026-09-22
Companion example: sei-ai-adoption-worked-case-customer-purchase.md

Purpose

Use this workbook to turn one proposed or operating AI adoption case into a defensible decision and prioritized roadmap.

The AIAF architecture views explain how the lifecycle, recurring assessment method, and evolving case record fit together. Workbook Parts 1–10 organize information; they are not ten lifecycle phases or ten mandatory approvals.

The workbook does not assume that AI is the correct intervention. It may lead to a decision to improve information, process, policy, skills, conventional software, or another capability instead. It may also lead to a decision to pause or stop.

Complete it with the people accountable for the outcome and materially affected by the decision. Do not assign the workbook to a technical team and treat completion as organizational acceptance.

Outputs

A completed workbook should produce:

an objective and value record, including a clear value hypothesis and a comparison of AI and non-AI alternatives;
workload, authority, and delivery-mode classification;
consequence and applicability decisions;
a capability profile: the applicable organizational capabilities with current and target levels;
an evidence, assumption, and uncertainty register;
shared-responsibility and dependency decisions;
a sequenced adoption roadmap;
measures, triggers, owners, and review dates;
continuity, replacement, and retirement conditions; and
lifecycle decisions and their evidence.

These ten correspond one-to-one to the ten required output types in the framework overview. The comparison of AI and non-AI alternatives is recorded within the objective and value record.

Use rules

Begin with the outcome, not the technology.
Separate facts, assumptions, decisions, and forecasts.
Retain evidence or a link to evidence for important claims.
Use provider evidence only after an accountable person judges its applicability and sufficiency.
Select proportionate target levels; do not reward unnecessary maturity.
Do not average capability levels into one score that hides a critical weakness.
Record who owns a decision even when a provider performs the work.
Design continuity, replacement, and retirement before deployment.
Revisit earlier sections when new evidence changes the case.

Traceability convention

Assign stable identifiers to important records so the final decision brief can point back to its basis. Keep the same case ID as the opportunity moves through investigation, evaluation, deployment, operation, change, and retirement. A changed name or proposed technology does not by itself create a new case. Bolding may improve scanning, but it does not replace traceability.

Label	Meaning	Example
`CASE`	One adoption case across its lifecycle	`CASE-001`
`OBJ`	Objective or intended outcome	`OBJ-1`
`VAL`	Value hypothesis	`VAL-1`
`BND`	Boundary or stop condition	`BND-1`
`E`	Evidence, assumption, provider claim, or forecast; state its type	`E-1`
`DEC`	Accountable decision or request	`DEC-1`
`GAP`	Critical capability or evidence gap	`GAP-1`
`ACT`	Roadmap action	`ACT-1`

Later records should cite the case ID and the earlier objective, evidence, boundary, and decision IDs they rely on. Compare observed results with the objective's defined measure, baseline, and success criterion to judge achievement. Traceability identifies the intended outcome and decision basis; it does not itself measure success or establish what caused a change. Update or supersede a record when new evidence changes it; do not quietly erase the earlier decision basis.

Part 1 — Define the business objective

1.1 Adoption-case identity

Field	Response
Case ID (`CASE-__`)
Adoption-case name
Business owner
Decision facilitator
Affected business areas
Affected populations
Date opened
Current lifecycle state
Next decision date

1.2 Problem or opportunity

What business or human outcome is not meeting expectations?

Who experiences the problem or receives the potential benefit?

What evidence shows that the problem or opportunity is material?

1.3 Objective and intended outcomes

Objective ID and statement:

ID	Intended outcome	Baseline or comparison	Proposed measure	Desired range or threshold	Evidence owner
`OBJ-__`
`OBJ-__`
`OBJ-__`

1.4 Value hypothesis

ID	Potential benefit	Recipient	How it creates value	Evidence needed	Confidence
`VAL-__`					Low / Medium / High
`VAL-__`					Low / Medium / High

Do not use activity measures such as prompts, conversations, licenses, or generated outputs as proof of value unless the objective is explicitly about that activity.

1.5 Complete cost and opportunity cost

Consider acquisition, usage, data, integration, evaluation, security, accessibility, legal review, change, learning, support, operation, incidents, provider change, continuity, replacement, and retirement.

Cost area	Initial estimate	Ongoing estimate	Basis and uncertainty	Owner

What other work, investment, or attention would this displace?

1.6 Boundaries and stop conditions

ID	Unacceptable outcome or prohibited action	Why unacceptable	Preventive boundary	Detection and response
`BND-__`
`BND-__`

Conditions that should cause the organization to pause, redesign, replace, or stop:

Part 1 decision

The objective and affected population are sufficiently clear to investigate.
Evidence is insufficient; gather the following before continuing.
The opportunity should not proceed.

Decision ID, owner, date, and reasoning:

Part 2 — Understand the work before choosing AI

2.1 Current work and causes

How is the outcome produced today?

Where does work, information, or a decision fail to meet the objective?

What evidence distinguishes symptoms from causes?

2.2 Credible interventions

Compare AI with simpler or established alternatives.

Intervention	Expected outcome	Time to credible evidence	Complete cost	Consequence and reversibility	Principal uncertainty
Improve information/content
Improve process/work design
Improve conventional software/interface
Change staffing, service, or skills
Deterministic automation or analytics
AI-enabled intervention
Combined intervention

2.3 Why AI might or might not fit

What work could AI perform that creates a material advantage?

What uncertainty, variability, scale, or information pattern makes AI relevant?

Where would ordinary rules, search, workflow, analytics, or human judgment be more appropriate?

Part 2 decision

Retain AI as a credible intervention.
Retain AI only as one part of a combined intervention.
Prefer a non-AI intervention.
Gather more evidence before choosing.

Decision ID, owner, date, and reasoning:

Part 3 — Classify the adoption case

3.1 Workload classification

Select every workload that performs material work. Identify one primary workload where possible.

Workload	Applies?	Work AI would perform	Work-specific consequence
W1 — End-user productivity	Yes / No / Uncertain
W2 — Development automation	Yes / No / Uncertain
W3 — Website and conversational interaction	Yes / No / Uncertain
W4 — Connected observation and delegated action	Yes / No / Uncertain

Primary workload and reasoning:

3.2 Connected authority

Complete when W4 applies or when the case may retrieve current information through connected systems, represent the organization beyond the immediate interaction, or make a consequential change.

Authority	In scope now?	Evidence required before authorization	Prohibited or limited actions
Observe
Communicate
Commit

Promotion and revocation authority:

3.3 Delivery-mode alternatives

Do not select a mode merely because a familiar provider offers it.

Mode	Candidate approach	Advantages	Responsibilities and dependencies	Complete cost	Exit difficulty
A — AI as a solution
B — AI as a feature
C — AI as a productivity tool
D — AI as a substrate

3.4 Delivery decision criteria

Criterion	Importance	Evidence	Alternative favored and why
Expected outcome
Time to credible evidence
Control and customization
Provider evidence
Skills and operating capacity
Data and integration
Security, privacy, accessibility, and obligations
Observability and corrective authority
Complete cost and opportunity cost
Continuity, portability, replacement, and retirement

Part 3 decision

Selected workload, authority, and delivery-mode classification:

Rejected alternatives and reasons:

Conditions that require reclassification:

Part 4 — Determine consequence and applicability

4.1 Consequence analysis

Factor	Current condition	Potential effect	Reversibility	Evidence or uncertainty
People and rights
Safety and wellbeing
Money and commitments
Customer or worker experience
Operations and continuity
Data and confidentiality
Security and misuse
Legal and contractual obligations
Accessibility and equitable use
Reputation and external trust
Scale and affected population
Dependency and exit difficulty

Consequence tier or description:

Who may accept the residual consequence?

4.2 Capability applicability states

Required: The organization must own and perform the capability.
Shared: A provider or partner performs part of it; organizational acceptance, integration, monitoring, continuity, and exit remain visible.
Conditional: It becomes necessary when a named condition occurs.
Lightweight: It applies, but a bounded decision and named owner are sufficient.
Not applicable: It has no material relationship to this case; record why.

Use the 63-capability catalog to complete Part 5.

Part 5 — Build the capability profile

Complete one row for every capability that is Required, Shared, Conditional, or Lightweight. Record material Not applicable decisions when omission may be questioned later.

Capability-level shorthand

Level	Required condition
Emerging	Work depends on individual knowledge or local practice and is suitable only where limited consequence and easy reversal justify it.
Defined	Ownership, scope, method, evidence, and response are repeatable for the named use.
Managed	The capability operates consistently across the relevant portfolio with proportional measures, thresholds, exceptions, and corrective action.
Adaptive	Outcome, incident, provider, external, and technology evidence systematically changes the practice and investment.

Capability assessment

Capability ID and name	Applicability	Accountable owner	Performer or provider	Current evidence	Current level	Target level and rationale	Gap or dependency

For every Shared capability, answer:

What exactly does the provider perform?
What evidence does the provider supply?
Who decides whether that evidence is sufficient for this case?
What must the organization integrate, monitor, or interpret?
What knowledge transfer, continuity, and exit capability are required?

Remember: competency can be bought or rented; accountability cannot. The organization may skip development history, but it cannot skip prerequisite outcomes and evidence.

Critical gaps

List gaps that prevent the next lifecycle decision regardless of the overall profile.

Gap ID	Critical gap	Decision blocked	Required action or evidence	Owner	Due date
`GAP-__`
`GAP-__`

Part 6 — Make and revisit lifecycle decisions

Choose the decision function that fits the case's current phase and proposed next action. The nine phases are the lifecycle; the five familiar names below are landmarks within them. Use the phase-to-decision map for what the landmarks are and are not. A delegated team member may decide within ordinary limits; involve leadership or specialists when customer consequence, commitment, exposure, obligation, or spend exceeds those limits. Revisit an earlier decision when important assumptions or conditions change.

Current phase	Decision function now	Evidence to examine proportionately	Named landmark, if any
Envision	Investigate, defer, or stop the opportunity.	Objective, affected people, initial evidence and uncertainty, owner, learning cost and boundary.	Investigate
Discover	Use the findings to compare responses, investigate a material gap, redirect, or stop.	Baseline, plausible causes, affected work, alternatives, dependencies, and evidence quality.	—
Prioritize	Select a response worth design effort, choose another response, or stop.	Comparable AI, human, and other non-AI options; value, full cost, feasibility, consequence, and capacity.	Select
Design	Proceed with bounded acquisition/build and evaluation work, redesign, or stop.	Work design, limits, ownership, source and provider responsibilities, test and response plan, cost and authority.	—
Acquire or build	Take the versioned candidate into representative evaluation, repair it, or reselect.	What was actually configured/built, provider terms, integration, source control, accessibility, security, and test readiness.	—
Evaluate	Expose a specifically bounded use to customers or users, improve it, narrow it, or stop.	Representative benefit and failure evidence, consequence, accessible human route, monitoring, response, rollback, and support.	Pilot
Deploy and adopt	Expand, constrain, redirect, or stop based on observed pilot results; separately decide whether a service is ready for routine operation.	Actual outcomes, adverse effects, full cost, people capacity, ownership, change/incident practice, continuity, and unresolved uncertainty.	Expand (scope); operating acceptance is distinct.
Operate and improve	Continue, improve, constrain, replace, or retire within the evidence-supported boundary.	Realized value, customer effects, review load, complete cost, incidents, provider changes, dependencies, and alternatives.	Continue
Replace or retire	Verify transition/closure or keep named corrective work open.	Customer continuity and remedy, old access/integrations, retained records, obligations, people work, and final charges.	—

Do not infer that selecting a response proves a candidate works; that a successful pilot proves indefinite operating fitness; or that choosing retirement proves closure. The formality of a decision grows with consequence and irreversibility, not with the number of rows in this table.

Current decision record:

Part 7 — Maintain the evidence and assumption register

ID	Claim, assumption, or forecast	Type	Supporting evidence	Confidence	Consequence if wrong	Owner	Review trigger or date
`E-__`	Fact / Assumption / Decision / Forecast			Low / Medium / High
`E-__`	Fact / Assumption / Decision / Forecast			Low / Medium / High

Provider evidence acceptance

Provider claim or evidence	Scope and version	Organizational requirement	Acceptance decision	Residual gap	Reviewer and date
			Accepted / Conditional / Rejected

Part 8 — Build the adoption roadmap

Sequence actions according to decision dependency and consequence, not departmental preference.

Action ID	Roadmap action	Gap or decision addressed	Expected outcome and evidence	Owner	Contributors	Dependency	Cost/effort	Target date	Review trigger
`ACT-__`
`ACT-__`
`ACT-__`

Roadmap checks

Every action enables a decision, closes a capability gap, reduces consequential uncertainty, or preserves value.
Critical prerequisites occur before dependent deployment or authority.
Provider work and organizational work are distinguishable.
Learning, work redesign, accessibility, support, and change are included where needed.
Measures and evidence are planned before exposure expands.
Rollback, continuity, replacement, and retirement actions are funded proportionately.
Actions with no credible relationship to the objective have been removed.

Part 9 — Define operating measures and review triggers

Measure	Baseline	Threshold or expected range	Data source	Review frequency	Decision enabled	Owner
Business outcome
Affected-party outcome
Quality and failure
Accessibility and equitable use
Human oversight and escalation
Cost and unit economics
Security, privacy, and incidents
Provider and dependency change

Events that require immediate reassessment:

Part 10 — Produce the decision brief

Build every material claim in the brief from the identifiers recorded in Parts 1–9. Cite those identifiers beside the claim so a reviewer can move from the summary to its source without repeating the analysis.

One-page decision summary

Question	Decision	Source IDs
What outcome are we pursuing, for whom?		`OBJ-__`
Why is the opportunity material?		`VAL-__`, `E-__`
Why is AI preferable—or not preferable—to alternatives?		`DEC-__`, `E-__`
What workload, authority, and delivery mode apply?		`DEC-__`
What consequence and dependency matter most?		`BND-__`, `GAP-__`
What is the current lifecycle decision?		`DEC-__`
Which capability gaps block or condition it?		`GAP-__`
What evidence supports the decision?		`E-__`
What uncertainty remains?		`E-__`, `GAP-__`
What are the next three roadmap actions?		`ACT-__`
Who is accountable?		`DEC-__`, `ACT-__`
When will we review, change, or stop?		`BND-__`, `DEC-__`

Final disposition

Proceed as proposed.
Proceed with conditions.
Redesign or select another delivery mode.
Prefer a non-AI or combined intervention.
Pause for evidence or capability.
Replace or retire the operating capability.
Stop the adoption case.

Decision ID, disposition, accountable decision-maker, delegated limit or escalation, conditions, date, and next review:

Validation questions

After using the workbook, record:

Which prompts changed a decision or exposed an important assumption?
Which prompts repeated information without improving the decision?
Which capabilities were difficult to classify or assess?
Did the level model produce proportionate targets?
Did provider evidence remain distinct from organizational capability?
Did the roadmap sequence prerequisites before desired technology activity?
Could another qualified person understand and continue the case from retained evidence?
What should change before the next use?

Thank you!