The Outcome
Disconnect.

Begin by testing the premise

An AI system can improve the work it touches without improving the result the organization cares about. A service assistant may answer more queries while resolution quality stagnates. An analyst may prepare work faster without shortening the approval cycle. A team may recover hours without reducing expense or creating additional output.

Those outcomes are worth examining. They are not, by themselves, evidence that an operating model is broken.

The Outcome Disconnect asks where an observed AI-enabled improvement stops becoming a verifiable business outcome—and whether that gap is material enough to act on.

The diagnostic starts with an open question. Is there a consequential disconnect? If there is, which mechanism best explains it? If there isn't, the finding should say so. A technical defect, a poor baseline, an attribution error, a change in demand, or an effective adaptation may explain the evidence better than organizational redesign.

What it is: a structured investigation of a bounded AI-enabled value stream. What it isn't: a generic maturity score, a vendor ranking, proof of ROI, or a predetermined case for transformation.

Define the unit of assessment

An enterprise-wide AI program is often too broad to diagnose in one pass. Start with a defined piece of work and the economic claim attached to it. The assessment needs four things:

Define the baseline period, demand and case mix, owner, and known changes outside the AI intervention. The comparison should concern comparable outcomes—not a model token, a draft, or a routed conversation unless that is genuinely the business unit being evaluated.

Follow six links from work to value

The conversion chain is a reasoning device, not a claim that value is created through six perfectly sequential steps. Multiple links may fail together, and feedback can run in either direction. The chain helps an assessor identify the earliest consequential link that the available evidence does not support.

1. Task effectDid AI change speed, quality, volume, or effort at the task level under representative conditions?
2. End-to-end workflow effectDid that task improvement change the complete process, including handoffs, reviews, exceptions, and the limiting constraint?
3. Capacity conversionDid released effort become usable capacity, and was that capacity actually redeployed, removed, or absorbed by demand?
4. Business effectDid the workflow change improve a defined customer, operational, commercial, or risk outcome?
5. Economic realizationWas the benefit converted into attributable financial value relative to fully burdened costs and a credible counterfactual?
6. Evidence and attributionCan the organization distinguish the AI effect from volume changes, staffing decisions, seasonality, other initiatives, or measurement error?

A broken link is not automatically an operating-model defect. It tells the investigation where to look next. The seven dimensions below help determine why the link is weak and what evidence would change the conclusion.

Seven dimensions. Three conditions each.

The dimensions are assessment lenses, not seven independent causes or a scorecard intended for averaging. Each contains three observable conditions. An assessor records the evidence, its limitations, and the confidence in the judgment.

1. Outcome alignment

   Is the intervention connected to a business result that the relevant teams actually share?

   • The target outcome and its unit are measurable.
   • The causal pathway from AI activity to that outcome is explicit.
   • Product, operations, finance, and other consequential owners agree on constraints and tradeoffs.

   Look for: outcome definitions, baseline metrics, operating targets, agreed decision criteria.

2. AI and task effectiveness

   Is there evidence that the technology reliably improves the work it performs?

   • Task improvement is measured against a relevant alternative.
   • Quality, safety, failure, and rework are counted alongside speed or volume.
   • Results hold across representative workloads and cases.

   Look for: test results, quality evaluations, exception logs, controlled comparisons.

3. Workflow integration

   Does the benefit survive contact with the whole process?

   • The end-to-end value stream and its constraint are mapped.
   • Handoffs, escalations, review, and downstream actions are defined.
   • Throughput, cycle time, repeat work, or other workflow effects are observed.

   Look for: process traces, queue data, repeat-contact or rework patterns, journey evidence.

4. Decision rights and accountability

   Can someone make and govern the cross-functional decisions needed to realize the outcome?

   • An outcome owner has a clear mandate and relevant authority.
   • Human and AI decision boundaries, overrides, and escalation rights are explicit.
   • Incentives and governance reinforce the intended result rather than a local activity target.

   Look for: ownership maps, operating reviews, policy decisions, escalation rules.

5. Organizational capability and adoption

   Can people consistently operate the changed system, not merely access it?

   • The necessary skills and judgment are identified by role.
   • Proficiency and actual use are demonstrated, not inferred from training completion.
   • Coaching, feedback, and change mechanisms sustain performance.

   Look for: proficiency checks, adoption by role, supervisor evidence, quality trends.

6. Economic conversion

   Is the operational gain becoming an attributable economic benefit?

   • Theoretical, usable, and financially captured capacity are separated.
   • The mechanism for avoided expense or incremental contribution is specified and reconciled.
   • Remaining human work, recurring AI operations, implementation costs, and the counterfactual are included.

   Look for: staffing plans, cost ledgers, budget reconciliation, unit economics, finance approval.

7. Evidence and adaptive governance

   Does the organization learn enough to scale, change, or stop with justification?

   • Baseline, data definitions, and comparison conditions can be reproduced.
   • Alternative explanations and attribution limits are examined.
   • Decisions, owners, thresholds, and review cadence are documented.

   Look for: analysis plans, confidence statements, test results, decision records.

A case can perform well in one dimension and remain inconclusive in another. That is often the point. Do not force a composite score to conceal which judgment is disputed.

Record evidence without inventing precision

For each of the 21 conditions, record a provisional rating and a separate confidence judgment. The 0–3 rubric describes the support for that condition in the assessed scope, not organizational maturity.

Confidence is recorded independently as low, moderate, or high, based on source quality, coverage, representativeness, and agreement across evidence. A condition could receive a rating of 3 with only moderate confidence, or a rating of 0 with high confidence. Both require explanation.

No composite maturity index, percentile, or organization-wide ranking is produced. The unit of analysis, evidence limitations, and causal hypothesis matter more than a seemingly precise total.

From observation to a testable explanation

The assessor identifies the first consequential unsupported conversion link, then develops competing explanations. A useful hypothesis should survive a challenge, not merely fit the observations.

Use a cause classification to organize inquiry: technology, workflow, accountability, capability, capacity conversion, economics, or evidence and attribution. These labels are not mutually exclusive diagnoses, and the same case may warrant more than one test.

For example, a slow approval cycle after an AI drafting improvement might reflect a downstream queue, a change in the mix of complex cases, stricter review controls, or quality problems hidden by the draft-time metric. The proposed operating-model remedy must compete with those alternatives.

A finding is stronger when it states what observation would prove it wrong.

Safety, privacy, security, and compliance constraints must be reviewed on their own terms. The absence of measurable economic harm is not evidence that a consequential control failure is acceptable.

A worked diagnostic example

Illustrative scenario, not an observed company case. An operations group introduces AI to produce first drafts of routine case analyses. A controlled evaluation shows drafts require 40% less preparation time with no measured decline in draft quality. Six weeks later, the number of approved cases per week is unchanged, and the group has recorded no reduction in expense or attributable increase in output.

The first link has evidence: the AI changes task effort. The next link is unresolved: draft preparation may not be the constraint on approved output. A credible inquiry would inspect the approval queue, compare the case mix, and measure the remaining human review and recovery work.

Provisional finding: task improvement demonstrated; workflow and capacity conversion not yet established. A likely hypothesis is that unchanged approval capacity limits throughput. An alternative is that cases have become more complex. The evidence does not yet justify reducing headcount or redesigning the entire function.

Disconfirmation test: compare queue times and throughput for similar cases under stable review capacity. Intervention test: trial a bounded change to approval routing or review support, with a defined success threshold and a safeguard for quality. Recalculate fully burdened cost per approved case and separate productive capacity from cash benefit.

This is the scale of conclusion the diagnostic is designed to support: specific enough to test, qualified enough to revise.

Two levels of assessment

Neither mode substitutes for a controlled experiment where causal attribution matters, nor for mandatory safety, compliance, or independent audit work. The level of verification should follow the consequence of the decision being made.

What the diagnosis should produce

A useful output is a decision memo, not a heat map. It should state the scoped outcome, reported task effect, strongest confirmed evidence, missing conversion link, competing explanations, economic magnitude or range where credible, risk constraints, owner, and next test.

The disposition should distinguish four outcomes:

• No material disconnect established: observed effects are consistent with the intended outcome, within the assessment's evidence and boundaries.
• Material disconnect supported: a meaningful conversion gap has evidence, with one or more plausible causes and tests.
• Provisional concern: a credible gap is suggested but important evidence or attribution is missing.
• Evidence insufficient: the organization cannot responsibly distinguish performance from measurement uncertainty.

An adaptive improvement that works is not necessarily evidence of a past failure. For example, changing human–AI routing in response to service feedback may be responsible system management. Klarna Case File 001 shows how this distinction matters when evaluating a public company from the outside.

Diagnosis is not the redesign

The Outcome Disconnect identifies whether a material conversion gap exists and what would explain it. The Outcome-Back Operating Model is the separate method for designing a response: define the outcome, identify required organizational capabilities, assign decisions and accountability, redesign the work where warranted, choose the AI and economic mechanisms, then validate the result.

The principle is simple: design backward from value; validate forward through evidence. The method should be invoked only when the diagnosis supports an intervention. A technical fix, a better measurement plan, or a decision to keep the existing service model can be the right answer.

The two concepts serve different purposes. The diagnostic decides what is true enough to act on. The method structures what to change and how to verify it.

Limitations and validation status

This is an original, publicly documented working methodology, version 0.1. The dimensions, rubric, conversion links, and recommended workflow are proposed assessment constructs. They have not been represented here as a statistically validated instrument, a benchmark dataset, or an externally certified standard.

Planned instrument-validation work includes content review with practitioners, cognitive interviews to check interpretability, inter-rater testing on shared cases, the ability to distinguish different underlying causes, practical decision usefulness, and eventual prospective testing of whether its findings predict the effect of interventions. Until then, ratings are structured professional judgments, not psychometric measurements.

The design draws on established concerns in AI governance and unit economics without claiming endorsement by those bodies. The NIST AI Risk Management Framework organizes AI risk work around govern, map, measure, and manage; the FinOps Foundation's unit-economics capability distinguishes technology resource measures from business outcome measures. The Outcome Disconnect is a separate diagnostic synthesis, not an implementation or certification of either framework.

Outside-in public assessments are especially limited. Company-reported performance and estimated savings should be identified as such; unknown internal staffing, routing, or financial attribution should remain unknown. The method should make those boundaries visible, not fill them with narrative certainty.

Continue the research

The framework connects three practical questions: what AI changed, whether that improvement converted into measurable enterprise value, and what evidence would justify a different operating design.

Methodology authored by Drew Peneton · Working version 0.1 · October 2026