AI-ADOPTION MATURITY CLIMB

Most AI pilots never reach production. This is the operating discipline for the ones that do.

ai-fde: the implementation lifecycle behind AI that ships and gets measured, not AI that stalls in a pilot.

A specification you can read front-to-back, and a map of every moving part.

In 60 seconds · for the non-specialist

This page lays out an operating discipline for getting AI genuinely adopted into the way a team already works, so it earns its keep in production rather than looking good once in a demo. The hard part is rarely the model. Most enterprise AI efforts stall on adoption and workflow fit, where a capable tool never quite lands in anyone's daily job. The approach: embed with a team, find the place where AI creates the most value, agree up front on what a correct result looks like, then ship it and measure it with a person holding the final decision. Much of that is human work: hearing out the real concern behind any hesitation, building trust, and earning buy-in, since people adopt what they helped shape. Everything below spells out how that happens, with the technical depth there for anyone who wants it. That paragraph is the whole idea.

What this is. A companion specification from Brandon McPeak that operationalizes the AI-adoption maturity climb: the L0 to L5 framing that Andrew Choflet's adoption-maturity framework maps. Andrew's model names the levels; this specifies the operating discipline that moves a team up them. Read it front to back; every load-bearing claim carries its own caveat.

The binding constraint on enterprise AI is not model quality; it is adoption and workflow integration. The discipline that fixes it has one rule underneath everything: the human is the decision gate, and AI drafts, scales, and captures around that judgment. ai-fde is a single Claude Code skill (a packaged, reusable AI workflow) that runs the full delivery lifecycle: orient, harvest, land, discover, solution, govern, adopt. This document specifies the system; every load-bearing claim carries its source and its caveat inline.

Glossary · terms in this specification 14 terms · open if needed

ai-fde: The internal engine: a forward-deployed-engineer mindset pointed at AI adoption. The settled internal slug for the skill.
FDE: Forward-deployed engineer: embedded with the customer, owns production outcomes, treats context extraction as the primary engineering problem.
eval set: An executable set of input/output examples that defines what "correct" means for a build. It runs, so it passes or fails; a prose brief cannot.
golden / edge / adversarial: The three graded eval buckets: must-pass happy path (golden), boundary and ambiguity cases (edge), and inputs designed to break the system loudly (adversarial).
acceptance layer: The eval set sitting on top of a conventional brief as the falsifiable test of done. When the two conflict, the eval set wins and the brief updates.
L0 to L5: An adoption-maturity ladder from no use (L0) to company-wide adoption (L5). Andrew Choflet's adoption-maturity framework, used here as the external lens this specification operationalizes.
maturity climb: The external frame: most teams stall low on the ladder; the system is the discipline that moves a team toward the top.
pharmacy cost-management: The regulated domain the overlay pack targets: optimizing drug spend for payers (prior-authorization, formulary, claims repricing, compliance calendar). The transparent optimization layer beside the pharmacy supply chain, not a bundled PBM.
AI-BOM: AI bill of materials: a record of what the AI touched in a build, for audit and rollback.
stated scaffold: A deferred or thin capability shown honestly as four parts (shape, named fill-material, provisional marker, presentable floor) rather than hidden or faked.
decision-trace ledger: An append-only log of AI-involved decisions, with sunset and rollback fields, so a human gate is enforced and auditable.
HITL: Human-in-the-loop: a human approval step. The design enforces a real gate, not a rubber stamp.
EARS: Easy Approach to Requirements Syntax: a constrained template for writing testable requirement statements.
the 5 guardrails: Five elicitation failure modes run as named regression checks: sycophancy, anchoring, probe-drift, productivity-illusion, premature-solutioning.

1 The wall: why most AI pilots stall

The problem, stated as settled fact-framing.

Most AI pilots stall before production: ~95% never reach P&L impact. — Two funnels converge on one wall: enterprise pilots collapse to a thin sliver that reaches measurable P&L impact, and the maturity ladder shows the population thinning at the same height. The shared binding constraint is adoption and workflow integration, not model quality.

The thing stopping enterprise AI from paying off is not the model; it is adoption and workflow integration. Roughly 95% of enterprise generative-AI pilots show no measurable P&L impact, and about 94% of organizations never get past one-off, individual AI use. The model is good enough. The wall is everything between a pilot and a production workflow people actually run.

~95%

of enterprise GenAI pilots show no measurable P&L impact (directional)Directional, not precise. Traces to a single primary source (MIT NANDA); audited citations reduced to that study plus a write-up of it. Atlas insight 8.

~94%

of organizations never pass one-off, individual AI use (different metric)A population-distribution figure (L0 ~45% plus L1 ~49%), not the same thing as the 95% project-impact number. They corroborate the shape of the problem, not the same metric twice.

Adoption

is the binding constraint, not the capability of the underlying model

Two independent vantage points describe the same wall.

Project lens (MIT NANDA). About 95% of enterprise generative-AI pilots produce no measurable profit-and-loss impact. The failure is organizational, not technological. The gap is the path from pilot to production: adoption, workflow integration, and the absence of a defined, measurable outcome before the build begins.
Population lens (the maturity ladder). About 94% of organizations never climb past one-off AI use (L0 at ~45% plus L1 at ~49%). Only ~5% reach team-level adoption; ~1% reach function-level; company-wide is ~0%. Most usage is a person pasting into a chat window, not a system that compounds.

This is the empirical spine of everything downstream. If the constraint were model quality, the answer would be a better model, and you would buy it. Because the constraint is adoption inside a domain, the answer is a discipline: redesign the workflow, define what "correct" means, instrument the measurement, and drive the climb. That discipline is what the rest of this document specifies, and it is the work the role exists to do.

Hold these caveats honestly (the numbers carry their provenance)

Read every magnitude as directional, not precise. The 95% figure traces to essentially one primary source (MIT NANDA). When the underlying research corpus audited its own citations, the apparent multi-study triangulation reduced to that study plus a write-up of the same study. The direction is well-supported; the exact percentage is not a hardened constant.

The two lenses corroborate direction, not arithmetic. 95% (pilots with no P&L) and 94% (organizations stuck at one-off use) measure different things. They agree on the shape of the problem; do not read them as the same metric confirmed twice.

The maturity ladder is a practitioner framework, not a survey. Andrew Choflet's L0 to L5 distribution is a conceptual map of the climb rather than a surveyed dataset. We cite it as a corroborating independent lens; the value of that corroboration is the direction it shares with the project and population data.

None of these weakens the conclusion. Across project data, population data, and field practice, the constraint that decides whether AI earns its ROI is adoption and integration. That is the wall.

2 The wrong ways across

The obvious crossings, and the documented reason each fails. This is what the answer has to beat.

The wall is real, so the obvious ways across get tried first. They share one root error: they let speed, tooling, or the model itself stand in for the human judgment that decides what "correct" even means. Each fails for a documented reason. The answer that follows is a discipline; a tool alone never gets across.

When RAND traced why AI projects actually fail, the most common cause was not weak models. It was misunderstanding the intent and purpose of the project; technology limitations were the least common real barrier. Premature solutioning is the killer. Hold that finding next to the four ways teams try to cross the wall.

Wrong way: "point a copilot at the requirements gathering"

Why it looks like the win
Elicitation is slow and expensive; letting AI run it looks like the obvious automation win, and it produces an authoritative-looking artifact fast.

The R6 reality
Current models surface under half of a stakeholder's implicit requirements even in controlled conditions, and a stated user belief induces agreement at a 63.7% meanAcross seven model families; up to 95.1%. Under pushback, models flip from correct to incorrect in roughly 14.7% of cases. Stated as a research finding with its source, not a universal constant. across model families. The agent manufactures agreement, not truth, then provides cover for skipping real discovery.

Wrong way: "ship the pilot, measure later"

Why it feels like progress
A working demo is concrete and persuasive. Shipping fast is a real advantage, so a pilot that runs looks like evidence the deployment will run too.

The productivity-illusion reality
Pilots answer "does this technology work?" Production demands "can this run sustainably, at volume, with governance, in our actual operation?" Most pilots are never designed to answer the second question, and speed as a substitute for problem decomposition just reaches the wrong destination sooner.

The four wrong ways, named

1. Prose requirements that drift. A brief gets written, everyone nods, the build begins. But prose cannot be falsified: "reduce hallucinations" and "improve accuracy" stay unactionable, and no one defined what "correct" means, what evidence a claim requires, or the penalty for being wrong versus staying silent. The misalignment surfaces at QA, when it is most expensive to fix.

2. AI-run discovery. The most dangerous shortcut, because the failure is invisible. Even the narrow safe use, generative follow-up questions, breaks under load: one study found AI failed to probe a surprising or unclear answer in 88% of opportunities once the prompt drifted.

3. The POC trap (velocity theater). A demo built to prove the technology becomes evidence for a deployment it was never designed to support.

4. Build-by-default. Treating "build it ourselves" as the reflex rather than the exception. Externally sourced solutions succeed at roughly twice the rate of internal-only builds, yet the pull toward bespoke construction overrides the boring, higher-odds move: buy the commodity layer, build only the domain-owned last mile.

The tell that separates winners. Organizations that saw real financial return were about twice as likelyThe ~2:1 buy-versus-build and workflow-first edge is single-source-anchored; read it as strong-directional, not settled law. Atlas insight 8. to have redesigned the workflow before selecting tools. Every wrong way above inverts that order, reaching for a tool, a model, or a demo before the work is understood. That inversion is the wall.

3 The answer: ai-fde and the dual identity

The discipline that crosses the wall.

The way across the wall is a discipline, not a better model. ai-fde borrows the forward-deployed-engineer mindset (embedded, owns production outcomes, treats context extraction as the primary engineering problem) and points it at AI adoption, with one rule underneath everything: the human runs the elicitation that produces the brief; AI drafts, formats, scales, and captures around it.

ai-fde is a single Claude Code skill that runs the full delivery lifecycle end to end: orient, harvest, land, discover, solution, govern, adopt. It is not an FDE skill in general (most forward-deployed roles have nothing to do with AI). It is the FDE approach aimed squarely at the thing that actually blocks AI value. A nine-year healthcare build put it bluntly: the hardest part of building AI agents is extracting context from clients; the coding is now the easy part.

The human is the gate; AI does the rest

This is the line the whole system turns on, and the evidence is unambiguous. Current models surface fewer than halfStated as a research finding with its source, not a universal constant. Models miss tacit organizational knowledge by structure, not by a model-quality gap that scale will close. of implicit requirements even under controlled conditions, and AI sycophancy is a near-invisible elicitation failure (agreement at a 63.7% mean across model families). So the discipline splits the work where each side is actually strong: humans elicit; AI drafts and formats once the brief exists. Never let AI run the elicitation that produces the brief. ai-fde automates the scale and the capture, not the judgment.

The dual identity: internal engine, external value

One name would flatten two jobs into one, so the design keeps them separate.

Layer	What it is	What it does
Internal: `ai-fde` settled slug	the engine plus the FDE mindset	keeps the build anchored to the value it delivers
External: the AI-adoption maturity climb	the value plus the outcome	the story a reviewer reads: most teams stall, this is the climb

You design the engine; you present the climb. One contains the other. The external frame is honest about the stakes it answers to: this is among the fastest-growing enterprise roles, with postings reported up roughly 729% to 800%+The better-corroborated band (Indeed and corroborators). A single source claims as high as 1,165% (Live Data Technologies); read the high end as single-sourced. Directional and range-bound. year over year, and the discipline is newly formalized with no standard playbook, which is precisely the opening.

Note. The internal slug ai-fde is settled; the external brand-line is the sentence this page opens on. The eval-as-acceptance-layer thesis you meet next is previewed here as settled; its single-pillar caveat is carried loudly in its own section.

4 The spine: evals as the acceptance layer

The one idea the whole system turns on, and the most contestable claim here.

The eval set as a falsifiable acceptance layer over a conventional brief. — A conventional brief at the base; the eval set (golden, edge, adversarial) as the falsifiable acceptance layer on top. When the two conflict, the eval set wins and the brief updates to match.

Discovery does not end in a document; it ends in an executable eval set, and that set becomes the falsifiable acceptance layer sitting on top of a conventional brief. This is the most novel and the most contestable claim here, so it is stated as a thesis to validate in use, not as settled practice. The four locked pillars: the human is the decision gate; the eval set is the falsifiable acceptance layer; when eval and brief conflict, the eval set wins; guardrails are regression tests, not advice.

A prose brief drifts. It reads as agreement, it survives review, and it cannot be falsified: there is no moment where the brief fails. An eval set can. The reframe is to make discovery converge on three graded sets that together define what "correct" means for the build.

Set	Size	What it pins down
GoldenThe must-pass behavior; the happy path made concrete as input/output pairs.	40-80 pairs	the must-pass behavior; the happy path made concrete
EdgeThe boundary and ambiguity cases real operators actually hit.	20-50 inputs	the boundary and ambiguity cases real operators hit
AdversarialInputs designed to make the system fail loudly, so failure is visible early rather than in production.	10-20 break inputs	the inputs designed to make the system fail loudly

The source-of-truth rule. The eval set does not replace the brief, it judges it. When the two conflict, the eval set wins and the brief updates to match. The moment a stakeholder's stated requirement collides with an example that must pass, the example is ground truth and the prose gets corrected. It resolves the question spec-driven development never settled (is the spec or the code the source of truth?) by making the falsifiable artifact authoritative.

The artifact, made concrete

The shape, for the technically curious; skip if not. Each line is one test case that passes or fails.

// eval-set.schema.jsonl  (excerpt, one line per example)
{ "id": "g-014", "bucket": "golden",      "input": "<representative happy-path input>", "expect": "<required output>", "must_pass": true }
{ "id": "e-007", "bucket": "edge",        "input": "<boundary / ambiguous input>",     "assert": "asks-for-clarification | flags-low-confidence" }
{ "id": "a-003", "bucket": "adversarial", "input": "<designed-to-break input>",         "assert": "fails-loudly | refuses | escalates", "penalty_if_silent": "high" }
// counts: golden 40-80 · edge 20-50 · adversarial 10-20
// the set RUNS: each line passes or fails. That is the difference between a contract you can measure and a paragraph everyone nodded at.

Guardrails are regression tests, not advice

The five failure modes the research surfaces are not coaching notes pinned to a wall; they are named checks the system runs:

SycophancyThe elicitation re-encoding a stakeholder's prior instead of testing it.: re-encoding a stakeholder's prior instead of testing it.
AnchoringAn opening hypothesis quietly biasing every requirement that follows.: an opening hypothesis quietly biasing every requirement that follows.
Probe-driftGenerative follow-up questions degrading or vanishing under prompt change.: follow-up questions degrading or vanishing under prompt change.
Productivity-illusionFeeling faster while measuring slower, with no measurement in place to catch it.: feeling faster while measuring slower, with no measurement to catch it.
Premature-solutioningJumping to a build before "correct" is defined.: jumping to a build before "correct" is defined.

The honest tension on this reframe

Why it holds
Evals are executable and falsifiable exactly where prose requirements drift. The set runs, so "correct" stops being a sentence everyone nodded at and becomes a check that can fail. That is a real, demonstrable improvement on the brief.

Why it is a bet
The reframe rests largely on a single research pillar (R6) and is not yet in BABOKRequirements-as-eval is ahead of the likely mental model in the room, which cuts both ways. Stated as a thesis to validate in use, not a doctrine to assert. or standard business-analysis practice. Requirements-as-eval is ahead of the likely mental model in the room. It is a bet worth running and measuring, named as one.

5 The system at a glance: an orchestrator core plus one standalone spine-skill

How the pieces fit together: the whole moving-parts picture.

ai-fde architecture: Tier-3 core plus one standalone spine-skill. — One orchestrator core holds the cross-cutting layers; `ai-fde-discover` is split out as the one standalone spine-skill; two agents do the narrow, dangerous work; the pharmacy-cost overlay snaps on as a detachable pack. Dispatch arrows reach the owned sibling skills.

One orchestrator core holds the cross-cutting layers; exactly one capability is split out as its own skill (the crown jewel, ai-fde-discover); two agents do the narrow, dangerous work; and a written graduation path governs what gets promoted later. Build only what earns its place.

The system is deliberately small at the seams. ai-fde is a Tier-3 orchestrator core (a coordinator that sequences other skills rather than doing one narrow job): it sequences the lifecycle and owns the layers every phase needs, rather than scattering them across a dozen sub-skills. Only one capability stands alone today, because it is the one most likely to grow and to be invoked on its own.

The internal structure, for anyone who wants to see how it is organized

ai-fde/                          # the Tier-3 orchestrator core
├── references/                  # doctrine + operating detail
│   ├── lifecycle-spine          # eval-as-acceptance, human-gate, source-of-truth
│   ├── guardrails               # the 5 failure modes as named regression checks
│   ├── provenance-caveats       # sources and caveats, carried
│   ├── interop-map              # capability → owned-skill dispatch (+ contract + fallback)
│   ├── cost-model · identity · maturity-ladder · stated-scaffolds
│   ├── phase-*  (×7)            # orient · harvest · land · discover · solution · govern · adopt
│   └── pharmacy-overlay/        # loadable domain pack (detachable)
├── assets/                      # canonical artifact templates
│   ├── eval-set.schema.jsonl    # golden / edge / adversarial line shapes
│   ├── spec triplet             # requirements / design / tasks
│   ├── steering files           # product / structure / tech / constitution
│   └── decision-trace-ledger
└── scripts/                     # deterministic checks
    └── eval-lint · guardrail-regression · spec-trace

ai-fde-discover/                 # the ONE standalone spine-skill (crown jewel)
agents/
├── discovery-interviewer        # safe AI-in-elicitation: guided probe, under the human gate
└── redteam                      # adversarial check on the eval set + the build/buy call

ai-fde-discover (the one standalone spine-skill). Discovery is the heart of the thesis: it maps decision logic, defines "correct" and the penalty asymmetry, and emits the golden / edge / adversarial eval set. It is split out for three concrete reasons: it is the crown jewel, it is likely to grow, and it is independently invocable. Everything else stays a reference until it earns the same.

The two agents, narrow by design. discovery-interviewer is the safe form of AI-in-elicitation: a guided follow-up probe layer that runs strictly under the human gate, never the elicitation itself. redteam runs an adversarial check on the eval set and the build/buy call, countering the anchoring the rest of the system is built to resist.

Everything the lifecycle needs that already exists as a skill is dispatched, not rebuilt. The system amplifies capability already owned rather than piling on new tools. Enablement is systems, not tools.

The graduation path (why the core stays thin)

A phase-* reference graduates to a standalone skills/ai-fde-<phase>/ only when it earns it: when the reference outgrows roughly 500 lines, when it needs invocation outside the lifecycle, or when real friction in use shows it carries enough distinct workflow to stand alone. Until then it stays a reference.

This is the calibrated middle, stated as a bet rather than a certainty. A full multi-skill build would over-engineer thin phases; a single flat skill would bury the lifecycle's legibility. A Tier-3 core, one earned spine-skill, and a written promotion rule is the shape that fits what exists today and grows only on evidence. The structure is intentionally incomplete-by-design; the order phases graduate in is logged, not pre-built.

6 The lifecycle: orient, harvest, land, discover, solution, govern, adopt

The operating spine and the largest spec payload. Each phase answers "so what" in one line, then the mechanics.

Seven phases, run in sequence, with the human as the decision gate at every step. AI drafts, scales, and captures; the human decides. The loop closes: adopt re-enters at orient, so each engagement raises the next one's floor.

orient

Read the landscape and place the team on the L0 to L5 ladder before anything gets built.

artifact · interop · guardrail

Artifact. Maturity scorecard; data-readiness verdict.

Interop + contract. Dispatches titan-research for landscape depth.

Guardrail. Self-flattering assessment; counting shadow AI as real adoption.

harvest

Elicit the actual needs, human-led, AI-assisted for capture only.

artifact · interop · guardrail

Artifact. Raw-needs corpus.

Interop + contract. meeting-analyzer via a new ai-needs-harvest meeting type. Contract: session transcript plus stakeholder map in, structured needs plus value-stream signals out. Degraded-mode fallback if meeting-analyzer is absent: an inline structured-capture template.

Guardrail. AI-run elicitation that misses what no one says out loud.

land

Secure what discovery needs: sponsor, value-case, data access, internal pitch.

artifact · interop · guardrail

Purpose. Placed deliberately between harvest and discover because it secures the inputs discover depends on: qualify the use-case, build the value-case, win an executive sponsor, procure data access, run the internal pitch.

Artifact. Sponsor map; value-case memo; data-access plan.

Interop + contract. Stated scaffold; fill-material drawn from sales-engineering and internal-champion sources.

Guardrail. Building before sponsorship or data access exists, the single most common way implementations quietly die.

discover spine · PHI pre-check

Map decision logic, define "correct" and the penalty asymmetry, emit the eval set.

artifact · interop · guardrail

Artifact. The eval set (golden, edge, adversarial); the correctness spec.

Interop + contract. titan-research for domain edge-cases. Contract: domain plus correctness frame in, edge and adversarial candidates out; fallback is manual edge-case enumeration. A PHI / data-classification pre-check runs here, upstream, not only later at govern.

Guardrail. Skipping the correctness pre-mortem; an eval set that just re-encodes existing priors.

solution

Four gates to a buildable plan; decide build, buy, or blend on evidence.

artifact · interop · guardrail

Artifact. Build/buy/blend decision; spec triplet; dependency-sequenced roadmap.

Interop + contract. product-discovery, deliberation-modes (a council on build-versus-buy), senior-architect, writing-plans, harnesslab-build, llm-cost-optimizer.

Guardrail. Premature solutioning; the POC trap; building by default.

govern

Stand up the accountability layer: ledger, AI-BOM, dual-audit, escalation boundaries.

artifact · interop · guardrail

Artifact. Ledger schema; escalation map; anti-pattern register.

Interop + contract. legal-compliance, ai-security, legal-privacy.

Guardrail. Rubber-stamp human-in-the-loop; autonomous high-stakes actions crossing a boundary that should have escalated.

adopt

Measure from day one, track system-wide ROI, drive the climb; loop back to orient.

artifact · interop · guardrail

Purpose. Track system-wide ROI, not per-task wins, and drive the maturity climb. Includes the eval-driven debrief loop: debrief, run the transcript and outputs back through the skill, rewrite. Closes with an explicit measure-to-orient re-entry, so the lifecycle loops and the next engagement starts higher.

Artifact. Measurement plan; ROI model; the next graduation gate.

Interop + contract. product-analytics, change-management, culture-architect.

Guardrail. Velocity-pitch-without-measurement (the productivity illusion); mistaking per-task wins for system ROI.

7 Governance and the own success metric

The accountability layer, and the quiet climax: what the system optimizes for.

Treated right, governance is a performance lever rather than a drag. The stack: a decision-trace ledger (with sunset and rollback), an AI-BOM, dual-audit, and machine-readable escalation boundaries so a human gate is enforced, not rubber-stamped. The companion's own success metric is deliberately not a demo that impresses; it is adoption, measured against a human-only baseline.

Two anti-patterns are hard-blocked by design and named as seniority signals: autonomous prior-authorization denial (state-law and litigation exposure) and rebate-steering formulary AI (novel FTC exposure). A human gate is enforced through machine-readable escalation boundaries, not a checkbox someone clicks.

A sample ledger row, for the technically curious; skip if not.

// decision-trace-ledger  (one row per AI-involved decision)
{
  "decision_id":  "dt-2026-0142",
  "phase":        "solution",
  "ai_role":      "draft | format | capture",     // never: ran the elicitation
  "human_gate":   { "approver": "<role>", "approved": true, "ts": "<iso>" },
  "ai_bom":       ["model@ver", "skill@ver", "eval-set@hash"],
  "escalation":   { "boundary": "machine-readable", "tripped": false },
  "sunset":       "<iso>",                          // when this decision must be revisited
  "rollback":     "<reversal path>"
}

The own success metric, stated plainly. Per engagement: an eval set exists, the shipped solution passes it at a stated threshold, with a decision-trace ledger and a measured system-wide ROI delta against the human-only baseline. Adoption, the maturity-ladder move, is the optimized outcome, not model quality.

Caveats carried on the metric and the audit

The single-auditable dual-audit framing is an extension of the source corpus, not a settled industry standard. The ROI delta is deliberately system-wide (cost-per-claim including AI spend), because per-task wins can fail to survive a system-wide cost lens. Both are stated, not assumed away.

8 Domain overlay: pharmacy cost-management (neutral mechanics plus a transparency layer)

The most share-sensitive section. The system is loadable, not abstract; the public-safe-depth fork lives here.

The pharmacy-cost pack splits two ways: neutral regulated-domain mechanics (prior-auth, HIPAA/HITRUST, formulary, regulatory calendar, all as a stated scaffold) plus a transparency layer that reframes the two anti-patterns as auditable cost-transparency. It is demonstrated against the public arc only: a documented manual-claims-reconciliation moving toward an analytics-productivity outcome. No private intel; public-safe framing throughout.

The overlay is a detachable module, reinforcing the architecture diagram's detachable-pack motif. The transparency-positioning is a stated framing, not a claim about any specific entity's internals. The worked example stays inside the public record: a documented manual-claims-reconciliation-to-productivity arc, paired with the public ExpionIQ analytics direction. That is enough to signal domain fluency; everything past the public line is left out of a link that travels.

The neutral pharmacy-benefits mechanics (opt-in depth)

Prior-authorization, formulary management, HIPAA / HITRUST posture, the CAA-2026 regulatory calendar scaffold · re-verify, and the workhorse use-cases of a regulated claims domain. The regulatory calendar is a stated scaffold: dates have slipped once and need re-verification at role entry. Presented as neutral, generic mechanics, not entity-specific intelligence.

9 Provenance: why the argument holds

Where the figures come from, what each one is worth, and where the bets are.

The L0 to L5 adoption maturity climb (Andrew's external framework). — The L0 to L5 ladder rendered as the climb from stalled to measured ROI: the population stacks on the bottom two rungs, the ~5% summit sits at the top, and the lifecycle capabilities are the rungs that lift a team. The L0 to L5 ladder is Andrew Choflet's adoption-maturity framework; the distribution shown is directional, used here as the external lens this specification complements.

This is not a deck of borrowed statistics. It is built on a cited research corpus, its load-bearing numbers carry their own caveats out loud, and it converges with an independent external model from two different directions. The parts that are bets are labeled as bets. The success metric is adoption, not a one-off demo.

Where it comes from

Eight research reports, run and quality-gated before any of this design existed.

Report	What it grounds
R1 market taxonomy	the three-tier value map; the ~95% anchor
R2 opportunity selection	data-readiness as a hard pre-gate; the four anti-patterns
R3 elite patterns	what the winning ~5% actually do (redesign workflow before tools)
R4 role / market	why the embedded FDE is the archetype the market pays for
R5 healthcare / pharmacy-benefits governance	the compliance perimeter as the binding constraint
R6 discovery harness	the eval-set-as-acceptance-layer spine and the human-AI division of labor
E bot-wars	the system-wide PA cost reconciliation
E regulatory-timeline	the precondition-dependency build sequence

The corpus went through two internal quality-reconciliation passes, so the figures cited here are taken from the report bodies rather than restated upward. On top of the corpus sit the Executive Atlas (the router across all eight), Andrew Choflet's L0 to L5 adoption-maturity ladder, and the HTML-as-living-specs method this artifact is built in.

Sources and caveats

#	Load-bearing claim	Source + honesty status
1	~95% of enterprise GenAI pilots show no measurable P&L impact	directional MIT NANDA. Single primary; audited citations reduced to that study plus a write-up of it. The apparent six-report triangulation is substantially one thin base echoing. (Atlas insight 8.)
2	~2:1 edge for buy-over-build / workflow-first	directional Single-source-anchored. Strong-directional, not settled law.
3	The eval set is the falsifiable acceptance layer on a brief	single-pillar bet Rests on R6 alone; not yet in BABOK or standard BA practice. A bet to validate in use, not settled practice.
4	The L0 to L5 maturity climb (the external spine)	external lens Andrew Choflet's practitioner model of the climb. Cited as a corroborating independent lens, not a surveyed dataset; its value is directional convergence with the project and population data.
5	94% (population) and 95% (project impact) are the same wall	two angles Different metrics that corroborate the shape of the problem, not two independent confirmations of one number.

The maturity climb converges, and that is the point

The external frame is a climb: most organizations stall low (~95% of pilots show no P&L impact; in the population data ~94% never pass one-off use, L0 at 45% and L1 at 49%). The companion is the capability depth, governance, and measurement that move a team toward the top ~5% that get ROI. The 94% and the 95% are the same wall measured from two angles: one a project-level impact study, the other a population distribution across a six-level ladder. That convergence is the point, and it is also exactly where the honesty has to live.

How this was built (the receipts)

The spec came out of an adversarial pass: four sub-agent lenses plus a local red-team reduced the design to six genuinely-open forks and a gate. That is the rigor behind the confidence, and it is why the bets are labeled as bets rather than asserted as facts.

A companion to Andrew's framework

This specification is offered as a companion to Andrew Choflet's adoption-maturity framework, the L0 to L5 levels that name the climb (the leveling resource). His model maps the levels conceptually; ai-fde is the operating discipline for climbing them. The two fit together: the ladder tells you where a team stands, the lifecycle moves them up it.

10 What happens next

Where this goes next, and what is deliberately deferred.

Three artifacts, in order of readiness: this dialed-in specification (the thing to speak to), then a research-backed companion mini-site (a shareable surface, offered as a complement to Andrew's adoption-model), then a functional eval-set demo (a real eval set run against a concrete problem). Each is buildable from the same corpus; none is hypothetical.

Near-term: this dialed-in spec

The thing to speak to. Built from the research corpus; no heavy build required.

Follow-up: research-backed companion mini-site

A shareable surface presenting the spec and the research narrative. A complement to Andrew's adoption-model, not a replacement.

Next round: functional eval-set demo

A real eval set built and run against a concrete problem: claims data to a measured analytics outcome. The spine, running.

Each rung is built from research already done, so the sequence is a matter of packaging and depth, not of starting over. The honest caveats from the rest of this document travel with every rung: the headline figures are directional and single-pillar; the eval-set-as-acceptance-layer reframe is a bet to validate in use; and the maturity climb is built on Andrew Choflet's adoption-maturity framework, credited as his and used as the external lens this work complements. The swing guardrail: the near-term floor wins every tradeoff.

Tracked and deferred

The functional eval-set demo. The first real build: a concrete eval set run against a claims-data-to-analytics problem. Sequenced after this specification and the companion surface.
The pharmacy regulatory calendar. A stated scaffold; dates have moved once and get re-verified at role entry before any calendar item is presented as current.
The graduation backlog. Which lifecycle phase graduates to a standalone skill next is logged, not pre-built, and revisited on real-use friction, so the system stays honestly incomplete-by-design rather than silently dropped.

Provenance & method

Built 2026-06 from an eight-report research corpus (routed through an Executive Atlas) using an internal HTML-as-living-specs method. Every load-bearing figure carries its caveat inline. The L0 to L5 maturity climb is credited to Andrew Choflet's adoption-maturity framework, cited as the external lens this work complements.

ai-fde specification · generated 2026-06-05, finalized 2026-06-06 · a companion to the AI-adoption maturity climb. Every load-bearing figure carries its caveat inline.