SEI AI Adoption Framework capability model
Status: Practitioner-reviewed framework reference; case application remains to be tested
Date: 2026-09-18
Catalog: Version 0.2, 63 capabilities
Purpose
This model defines how each capability will be described, assessed, taught, and converted into roadmap actions. It replaces maturity for maturity's sake with a practical question:
What level of capability does this organization need for its objectives, consequences, delivery modes, and operating context?
Here, capability means an organizational capability: an outcome the organization can reliably deliver and sustain. A technology capability is what a tool can do; a human competency is what a person can reliably do. Both may contribute, but neither by itself establishes the organization's capability level.
An organization may appropriately target a lower level for a low-consequence or short-lived use. The assessment should expose an unjustified gap between the required level and current evidence, not reward the largest program.
Standard capability record
The standard record has two parts. The capability description is written once for each of the 63 capabilities and does not change from case to case. The case assessment is completed for a specific adoption case and records who owns the capability there, what the evidence shows, and what to do next.
The fields below are marked by part. The five worked examples and the 58 detailed records in Part 4 are capability descriptions. Practitioners reviewed the descriptions as written in October 2026. They have not yet been tested against a real adoption case. Each description gives the typical applicability state; the state for a case is set in the case assessment.
| Field | Part | Purpose |
|---|---|---|
| ID and name | Description | Stable catalog reference and plain-language capability name |
| Purpose | Description | Why the capability exists and what failure it prevents |
| Intended outcome | Description | The observable condition when the capability works |
| Decisions enabled | Description | Decisions that depend on this capability's evidence |
| Applicable workloads | Description | W1 through W4, including authority levels where relevant |
| Applicable delivery modes | Description | A through D |
| Applicability state | Case assessment | Required, Shared, Conditional, Lightweight, or Not applicable for the assessed scenario. The description gives the typical state. |
| Lifecycle phases | Description | Phases where the capability supplies or reviews evidence |
| Accountable owner | Case assessment | Role accountable for ensuring the outcome, not necessarily performing every activity |
| Contributors | Case assessment | Roles, providers, and affected groups that perform or inform the work |
| Competency source and dependency | Case assessment | Whether important competency is internal, shared, or externally supplied, including knowledge-transfer, continuity, and exit implications |
| Key activities | Description | Minimum recurring work required to produce the outcome |
| Required evidence | Description | Records that demonstrate the capability exists and works |
| Measures and thresholds | Case assessment | Evidence used to judge effectiveness, sufficiency, and change |
| Dependencies | Case assessment | Other capabilities or external conditions required for useful performance |
| Common failure patterns | Description | Predictable ways organizations perform the form but miss the outcome |
| Capability levels | Description | Observable progression from inconsistent work to adaptive operation |
| Target-level rationale | Case assessment | Why the selected level is sufficient for this scenario |
| Gap and roadmap action | Case assessment | Difference between current evidence and target, with owner and sequence |
| Review and exit triggers | Description | Events that require re-evaluation, replacement, or retirement action |
| Sources and assumptions | Case assessment | Authoritative guidance, internal decisions, forecasts, and unresolved assumptions |
| Last reviewed and next review | Case assessment | Currency and maintenance record |
Applicability states
Applicability and capability level answer different questions. Applicability determines how much responsibility the organization has for a scenario. Capability level determines how reliably that responsibility is performed.
| State | Meaning | Assessment treatment |
|---|---|---|
| Required | The organization must own and perform the capability. | Assess organizational evidence directly. |
| Shared | A provider or partner performs part of the work. | Assess provider evidence and the organization's explicit acceptance, integration, and monitoring. |
| Conditional | The capability becomes necessary when a defined condition is present. | Record the condition, current state, and trigger that changes applicability. |
| Lightweight | The capability applies, but low consequence or limited dependency makes a short decision sufficient. | Require a named owner and documented rationale; do not require unnecessary infrastructure. |
| Not applicable | The capability has no material relationship to the scenario. | Record why when the omission may be questioned later; assess no level. |
Not applicable means the capability has no material relationship to this scenario, so no level is assessed. It does not mean the organization is free of responsibility in general. It is a recorded decision, not an oversight, and it is revisited when the scenario changes.
Four capability levels
Level 1: Emerging
Work occurs through individual knowledge or local practice. Results depend on who is involved. Ownership, criteria, and evidence may be incomplete.
This can be sufficient for time-limited exploration with low consequence, isolated data, no external authority, and easy reversal. It is not sufficient merely because the organization calls the work a pilot.
Level 2: Defined
The organization has an owner, scope, criteria, minimum activities, and retained evidence. The practice works for named use cases or populations and can be repeated by another qualified person.
This is often sufficient for bounded production use when consequences, scale, integrations, and dependency remain limited.
Level 3: Managed
The capability is applied consistently across the relevant portfolio. Depth varies by consequence. Measures, thresholds, exceptions, provider evidence, and corrective action are reviewed. Related teams use compatible records and responsibilities.
This is generally required when AI supports important operations, affects customers or workers, uses sensitive information, acts through connected systems, or creates material dependency.
Level 4: Adaptive
The organization uses evidence from outcomes, incidents, provider change, external developments, and emerging capability to revise the practice. Changes can be deployed, tested, and reversed across the relevant portfolio. Leaders understand tradeoffs and redirect investment when assumptions change.
This level is appropriate where AI capability is strategically important, rapidly changing, widely distributed, or authorized to produce consequential external effects. It is not the required destination for every organization.
Level construction rule
Each level description must address five observable elements:
- Ownership: Who ensures the outcome?
- Scope: Where is the practice applied?
- Method: What repeatable work occurs?
- Evidence: What proves the work and outcome?
- Response: What happens when evidence shows a problem or change?
Avoid level descriptions based only on tool acquisition, document count, centralization, automation, or organization size.
Reading the levels for a single adoption case
Targets are set for one adoption case, but Level 3 (Managed) describes consistency across a portfolio. A first or only case has a portfolio of one, so read Managed this way: the capability follows records, thresholds, and responsibilities that are not local to the case team, and someone outside the case team reviews exceptions and corrective action. Where neither exists, the honest level is Defined. The target-level rationale should say so and name what would be needed to reach Managed.
Progression and borrowed competency rule
An organization may skip the time normally spent developing a capability, but it cannot skip the outcomes and evidence that support the higher level.
The levels are cumulative in outcome, not necessarily chronological. An organization can accelerate development by hiring experienced people, acquiring technology, using consultants, or engaging a managed service. It does not need to spend a prescribed period at each level. It must still demonstrate the ownership, scope, method, evidence, and response expected at the claimed level.
Apply four rules:
- Competency can be bought or rented; accountability cannot. External specialists and providers may perform work, but the organization still defines the objective, judges whether evidence is sufficient, makes decisions, and remains accountable for its use.
- Provider capability does not automatically become organizational capability. A provider may operate an Adaptive service while the customer lacks ownership, acceptance criteria, interpretation skills, corrective authority, oversight, continuity, or exit capability.
- Borrowed capability must be visible. Record whether important competency is internal, shared, or externally supplied. Identify the provider evidence, organizational acceptance decision, knowledge-transfer need, dependency, continuity, and exit risk.
- Accelerated progression increases integration and dependency risk. The organization may be unable to challenge advice, recognize poor performance, operate without the provider, or transition later. The target-level decision must address that risk explicitly.
Use this shorthand during assessment:
You can skip development history. You cannot skip prerequisite evidence.
When lower-level outcomes are missing, do not award a higher level because sophisticated technology, automation, or external experts are present. Record the externally supplied strength and the organizational gap separately, then create roadmap actions for acceptance, integration, knowledge transfer, continuity, or exit as appropriate.
Target-level selection
Select a target level by considering:
- business importance and dependency;
- potential harm and reversibility;
- sensitive data and legal obligations;
- scale and affected population;
- degree of AI authority;
- external interaction or commitment;
- integration depth;
- provider and component change rate;
- replacement difficulty;
- expected solution lifespan; and
- evidence required by customers, partners, regulators, insurers, or leadership.
The target decision must name the reason the selected level is sufficient. A higher target requires an operational justification, not a desire to appear advanced.
Five representative capability records — not a consecutive catalog
The following five worked examples test the record format across value, governance, evaluation, agent control, and lifecycle exit. Their capability IDs are deliberately nonconsecutive: 1.3, 3.3, 6.3, 7.2, and 6.9. A jump between these headings does not mean the intervening capabilities are missing. The complete list of all 63 capabilities appears in the next part, Complete 63-capability catalog. These five records illustrate how to assess a capability in depth. The other 58 capabilities have detailed records in the same format in the next part, under Capability records, which follows the catalog.
Worked example 1 of 5 — 1.3 Value definition and realization
Purpose
Prevent AI investment from being justified by activity, novelty, license use, or technical performance that does not improve the intended business or human outcome.
Intended outcome
Decision makers can compare expected and realized value, cost, adverse effects, and opportunity cost throughout the lifecycle and can change or stop investment when evidence does not support continuation.
Decisions enabled
- whether to prioritize or fund an opportunity;
- whether to expand, constrain, redesign, renew, replace, or stop it;
- whether cost and organizational attention remain justified; and
- whether value claims can support pricing, planning, or external communication.
Applicability
Workloads: All
Delivery modes: All
Typical state: Required
Key activities
- define the intended outcome and affected population;
- choose direct measures and credible supporting indicators;
- record the pre-adoption baseline or comparison method;
- estimate complete cost, including people, change, evaluation, integration, operation, and exit;
- define material adverse effects and unacceptable tradeoffs;
- review realized versus expected results; and
- decide whether to continue, change, expand, or stop.
Required evidence
- value hypothesis and assumptions;
- baseline and comparison design;
- cost model;
- outcome and adverse-effect measures;
- review cadence and thresholds; and
- investment decisions with reasoning.
Measures
Measures vary by objective. Use outcome measures where possible. Adoption, prompt count, time in tool, or license activation may explain behavior but do not prove value by themselves.
Common failure patterns
- retrofitting a value claim after acquiring a tool;
- measuring activity instead of outcome;
- excluding evaluation, change, support, and exit costs;
- ignoring who receives benefits and who absorbs adverse effects;
- expanding before comparing with the baseline; and
- continuing because sunk cost makes stopping uncomfortable.
Capability levels
| Level | Observable condition |
|---|---|
| Emerging | Sponsors state expected value, but baselines, complete costs, ownership, or review decisions are inconsistent. |
| Defined | Each in-scope investment has an owner, outcome, baseline or comparison, cost estimate, measures, and scheduled review. |
| Managed | Portfolio decisions use consistent outcome and cost evidence. Variances, adverse effects, and opportunity costs lead to documented corrective, expansion, or stop decisions. |
| Adaptive | Measurement and investment rules change as the organization learns. Leaders redirect funding across delivery modes and workloads when evidence, providers, or strategic needs change. |
Review and exit triggers
- outcomes remain below threshold;
- complete cost exceeds the approved range;
- adverse effects exceed tolerance;
- assumptions or business priorities change;
- a provider changes capability or price materially; or
- another approach produces greater value at acceptable risk.
Worked example 2 of 5 — 3.3 Risk and consequence tiering
Purpose
Apply review, evidence, oversight, and monitoring in proportion to potential harm and reversibility without forcing low-consequence work through an enterprise-scale process.
Intended outcome
People can classify an AI use consistently enough that the appropriate requirements, approval path, authority limits, evaluation depth, and operating review follow from the classification.
Decisions enabled
- which uses need formal review or specialist involvement;
- what evidence is required before deployment;
- what authority AI may receive;
- what monitoring, transparency, recourse, and continuity are required; and
- who may accept residual risk.
Applicability
Workloads: All
Delivery modes: All
Typical state: Required
Key activities
- define consequence factors and tier thresholds;
- consider people affected, rights, safety, money, operations, reputation, data, authority, scale, and reversibility;
- classify proposed and existing uses;
- connect each tier to minimum evidence and decision rights;
- resolve ambiguous and changing cases; and
- review classifications when scope, authority, data, provider, or impact changes.
Required evidence
- tiering method and examples;
- classification record and rationale;
- applicable evidence profile;
- reviewer and residual-risk authority; and
- reclassification triggers and history.
Common failure patterns
- classifying by technology label instead of consequence;
- calling all pilots low risk;
- treating internal use as harmless;
- ignoring cumulative scale or affected populations;
- allowing the project team to lower its own tier without review; and
- retaining the original tier after adding data, integration, or authority.
Capability levels
| Level | Observable condition |
|---|---|
| Emerging | Teams discuss risk but use inconsistent factors, thresholds, and evidence. Similar uses receive different treatment. |
| Defined | A documented method links tiers to evidence, authority, approval, and monitoring for named scopes. Qualified reviewers resolve exceptions. |
| Managed | Tiering is applied across the relevant portfolio, tested for consistency, connected to inventory and lifecycle gates, and updated when conditions change. |
| Adaptive | Incident, outcome, regulatory, provider, and technology evidence changes the tiering model. The organization can introduce new workload and authority patterns without rebuilding governance from scratch. |
Review and exit triggers
- affected population or scale increases;
- sensitive data or consequential decisions are added;
- AI progresses from assisting to communicating or committing;
- integration expands;
- external obligations change; or
- incidents expose an unrecognized consequence.
Worked example 3 of 5 — 6.3 Evaluation methodology
Purpose
Demonstrate whether an AI capability performs its intended work well enough for the real operating context and consequence.
Intended outcome
Deployment and continuation decisions use repeatable evidence about usefulness, quality attributes, limits, failure patterns, affected people, and comparison with credible alternatives.
Decisions enabled
- whether the capability is acceptable for a defined scope;
- which limitations, safeguards, or human review are required;
- whether authority or exposure may increase;
- whether a provider or configuration change remains acceptable; and
- whether the capability should continue, change, roll back, or retire.
Applicability
Workloads: All
Delivery modes: All
Typical state: Required, with provider evidence Shared where appropriate
Key activities
- define intended tasks, users, contexts, and unacceptable outcomes;
- select representative cases, boundary cases, and credible comparisons;
- define quality attributes and acceptance thresholds;
- evaluate outputs, actions, workflow effects, accessibility, adverse effects, and human oversight;
- record configurations and limitations;
- test changes and regressions; and
- connect results to deployment and operating decisions.
Required evidence
- evaluation plan and ownership;
- representative cases and rationale;
- baseline or alternative comparison;
- measures, thresholds, and results;
- configuration and provider version;
- known limits and residual uncertainty; and
- approval, constraint, rollback, or stop decision.
Common failure patterns
- relying on a demonstration;
- accepting provider benchmarks that do not represent organizational work;
- testing average output while ignoring consequential failures;
- evaluating the model but not the complete workflow;
- excluding accessibility and affected-user experience;
- changing prompts, tools, data, or providers without regression testing; and
- lowering thresholds after seeing results.
Capability levels
| Level | Observable condition |
|---|---|
| Emerging | Teams test examples and demonstrations, but coverage, thresholds, comparison, configuration, and decisions are inconsistent. |
| Defined | Each in-scope capability has representative cases, quality attributes, thresholds, recorded configuration, results, limitations, and an accountable acceptance decision. |
| Managed | Reusable methods, datasets, regression checks, provider evidence, and operating feedback support consistent decisions across the relevant portfolio. Evaluation depth varies by consequence. |
| Adaptive | Outcome, incident, user, provider, adversarial, and external evidence continually improve the evaluation method. New authority and workload patterns receive appropriate tests before promotion. |
Review and exit triggers
- model, prompt, retrieval source, tool, integration, or provider changes;
- tasks, users, data, or authority expand;
- observed behavior differs from evaluation;
- incidents or complaints reveal missing cases;
- quality attributes fall below threshold; or
- a credible alternative changes the acceptable baseline.
Worked example 4 of 5 — 7.2 Agent identity, authority, and tool access
Purpose
Prevent agents from acting through shared, unattributable, excessive, stale, or unrevoked access.
Intended outcome
Every acting agent has an attributable identity, accountable owner, defined purpose, approved relationships, scoped access, authority limits, lifecycle state, and tested revocation path.
Decisions enabled
- whether an agent may enter an environment;
- which data, tools, services, agents, and counterparties it may access;
- whether it may observe, prepare, communicate, change, execute, or commit;
- when human confirmation or separation of duties is required; and
- when access must be constrained, suspended, or revoked.
Applicability
Workloads: W2, W3, and W4
Delivery modes: All; in Mode C, only when the tool has connected authority
Typical state: Required when AI can invoke tools or act; Conditional for output-only assistance and, in Mode C, conditional on connected authority (a tool connected to systems, or able to communicate or commit)
Reading this for an AI coding assistant. An assistant that works only on excerpts a person supplies stays at W2 Assist, and this capability is Conditional. A live connection that lets it read a repository adds W4 Observe, so scoped, attributable access applies. Creating a branch, opening a pull request, or otherwise changing repository state requires a separate W4 authority decision, defined before that action is enabled.
Key activities
- assign unique agent identities and accountable owners;
- register purpose, environment, relationships, tools, data, authority, and lifecycle state;
- apply least privilege and bounded duration;
- distinguish agent identity from the human or service that requested work;
- control elevation and consequential action;
- monitor access and attempted violations; and
- revoke access, credentials, relationships, tools, and retained authority during suspension or retirement.
Required evidence
- agent and relationship inventory;
- identity and owner;
- permission and authority record;
- approval and elevation records;
- access and action logs;
- periodic review; and
- suspension, revocation, and decommissioning tests.
Common failure patterns
- shared service accounts;
- copying the requesting user's full permissions;
- treating tool access as harmless because the agent is internal;
- granting production access during experimentation;
- recording tools but not relationships with other agents;
- revoking a user while leaving an agent active; and
- deleting the agent record before preserving required evidence.
Capability levels
| Level | Observable condition |
|---|---|
| Emerging | Agents use shared or manually managed access. Ownership, relationships, authority, lifecycle, and revocation are incomplete. |
| Defined | In-scope agents have unique identity, owner, purpose, scoped access, authority, records, review, and tested revocation. |
| Managed | Registry, identity, gateways, policy enforcement, monitoring, elevation, relationship mapping, and lifecycle controls operate consistently across relevant platforms. |
| Adaptive | Authority and access respond to evidence, context, incidents, changing relationships, and provider capability. New agent patterns can be introduced without losing attribution or control. |
Review and exit triggers
- tools, data, environments, counterparties, or connected agents change;
- authority increases;
- the owner or business purpose changes;
- anomalous or prohibited action occurs;
- an identity or provider is compromised;
- the agent is inactive or no longer economical; or
- the agent, platform, or workflow is replaced or retired.
Worked example 5 of 5 — 6.9 Rollback, replacement, and retirement
Purpose
Prevent AI capabilities from becoming permanent dependencies after they stop meeting business, cost, trust, technical, legal, or operating needs.
Intended outcome
The organization can return to a known acceptable state, migrate to an alternative, or remove an AI capability while preserving required continuity, evidence, data, access control, and accountability.
Decisions enabled
- when rollback is required;
- whether to repair, constrain, replace, or retire;
- which data, records, configurations, and artifacts must migrate or remain;
- how dependent work continues; and
- when closure is complete.
Applicability
Workloads: All
Delivery modes: All
Typical state: Required, with depth based on dependency and consequence
Key activities
- define rollback, replacement, and retirement triggers during design;
- identify dependent people, workflows, systems, data, identities, providers, and counterparties;
- maintain a known acceptable state or viable alternative;
- test rollback and migration where consequence justifies it;
- communicate and support affected people;
- revoke identities, credentials, tools, integrations, and external authority;
- migrate, retain, or delete data, memory, logs, and evidence deliberately; and
- confirm continuity and closure.
Required evidence
- triggers and decision owner;
- dependency and continuity map;
- rollback or migration procedure and test results;
- communication and support plan;
- data, memory, and evidence disposition;
- access and authority revocation; and
- closure record with unresolved obligations.
Common failure patterns
- planning exit only at renewal or failure;
- assuming a provider export recreates the capability elsewhere;
- preserving data but losing configuration, prompts, tools, or decision history;
- removing the interface while leaving identities or integrations active;
- retiring the technology without redesigning the work;
- ignoring counterparties and commitments; and
- treating sunk cost as a reason to retain an unfit capability.
Capability levels
| Level | Observable condition |
|---|---|
| Emerging | Teams can disable some capabilities, but dependencies, evidence, migration, continuity, access, and closure are managed case by case. |
| Defined | In-scope capabilities have triggers, owners, dependency records, rollback or exit procedures, data disposition, access revocation, and closure criteria. |
| Managed | Replacement and retirement are exercised according to consequence, connected to provider and portfolio reviews, and coordinated across business, technical, data, security, and workforce dependencies. |
| Adaptive | The organization detects declining fitness early, compares alternatives continuously, and can redirect workloads and investment without unmanaged interruption or retained authority. |
Review and exit triggers
- value or quality falls below threshold;
- provider capability, terms, location, safeguards, price, or availability changes materially;
- security, legal, ethical, accessibility, or reliability requirements are no longer met;
- accumulated dependency makes later exit harder;
- a better alternative changes the value calculation; or
- the supported business objective ends.
Pattern test findings
The standard record works across strategic, governance, technical, agentic, and lifecycle capabilities. Five refinements apply to every record, and the remaining 58 detailed records were written to follow them:
- Keep the purpose focused on failure prevented, not a restatement of the name.
- State decisions before activities so the capability remains outcome-oriented.
- Make provider evidence explicit where applicability is Shared.
- Describe levels through ownership, scope, method, evidence, and response.
- Include review and exit triggers in every record, even when the capability itself is not a retirement capability.
Applying the records to a case
The descriptions have been reviewed as framework content, but that review is not proof that a particular organization has any capability at a stated level. When applying the records to a real adoption case, complete the case assessment and check:
- whether the four levels are understandable and useful;
- whether the evidence is proportionate;
- whether capability boundaries remain clear;
- whether a practitioner can turn the record into roadmap actions; and
- whether the record is concise enough to support training and assessment without losing necessary meaning.