The AI use case that isn't wrong, just early

Last week I named the five layers between AI strategy and AI build (Knowledge Bank, Accelerate, Decide, Deliver, Digital Nervous System), and promised a walkthrough built around the most common pattern: the AI use case that isn't wrong, just early. This is that walkthrough. Each layer closes a different limitation, and the easiest way to see why all five are needed at once is to follow a pattern that recurs across most readiness conversations.

Second of three posts introducing the five layers. The next post closes the introduction by showing what changes when an organisation runs them together.

The pattern: a good use case with an unbuilt prerequisite

A function leader identifies a use case that genuinely fits the function: say, a customer-service triage assistant that pre-classifies incoming tickets. The business case holds up. The technology is mature. The vendor demos are convincing. And then the organisation discovers, halfway into scoping, that the customer ticket data is fragmented across three systems with three different category taxonomies, and that nobody owns reconciling them.

The capability isn't built yet, and won't be for two quarters, when a separate data-quality initiative is supposed to land.

Three things tend to happen next. The use case gets force-fit on the existing data and produces a low-quality assistant that fails its pilot; it gets quietly dropped, with no record of why and no condition under which it should be revisited; or, nine months later, a different team re-evaluates it from scratch, reaches the same conclusion, and never finds out the org has already had this conversation.

Each of the five layers carries one piece of preventing that.

Knowledge Bank: the shared scaffolding

The Knowledge Bank is the running start. It's the off-the-shelf scaffolding every user gets on day one, regardless of whether they're running it for their function, their team, or themselves. Context schema (industry, function, role, AI maturity). Objectives library, organised by OKR pattern. Capability framework that names what an organisation has to be good at to run a given use case. Use case library, still growing. And expanding into process patterns, orchestration patterns, and operating-model templates.

Every user in the org pulls from the same body of knowledge, curated to their shared context and described in the same language. The same use cases get evaluated by business, tech, and ops, each looking at it through their own angle but working off one definition. Compare that to the usual setup: business hires a strategy consultancy, tech engages a vendor or integrator, ops contracts a BPO. Three engagements, three different framings of the same problem. The Knowledge Bank doesn't start engagements from a blank slate; it just has to close the gap between the angles those functions bring (different terminology, different priorities, different sense of what counts as evidence).

In the customer-service triage example, the Knowledge Bank is what supplies the use case description, the capability prerequisites (data unification, taxonomy reconciliation, queue routing logic), and the standard objective patterns the use case typically maps to. The organisation doesn't have to invent any of that.

What it closes: every engagement starting from a blank slate, and the rebuild-from-scratch tax that comes with it. By giving organisations a standardised reference for expected outcomes against their context and capability profile, the Knowledge Bank turns the which 3–4 use cases beat 10 pilots question into a structured selection rather than a guess. The shared structure also makes downstream contributor input slot into a frame rather than producing an unstructured pile of insight nobody can act on.

Accelerate: standardised matching with two paths

Accelerate is the matching engine. It takes a user's context (function, domain, team, or just their own remit, plus what they're trying to achieve) and matches it to use cases, on one of two starting paths. The platform doesn't try to be a single space for the whole org. Orgs are too multi-angled for that, so each user runs Accelerate against the slice they own.

Selection-first is for organisations that already know what they want, common at large enterprises with a function-level outcome in mind. The org enters the conversation at "we want a customer-service triage assistant"; Accelerate runs problem discovery to validate that the use case lands where leadership thinks it will, and runs value-chain analysis to size the impact across upstream and downstream processes.

Problem-first is for organisations that need to find both the problem and the solution, common at SMEs and smaller orgs. The org enters at "customer wait times are too long"; Accelerate finds the bottleneck (queue routing, ticket misclassification, agent skill mismatch), then matches to the family of use cases that addresses each.

In the example, a large enterprise usually has the technical specialism to know it wants the customer-service triage use case from the start; what it doesn't have is a clear read on what will stop the implementation. Accelerate's selection-first path is what surfaces the data-unification dependency before scoping starts. An SME has the opposite problem: deep domain expertise (it knows wait times are too long and roughly why) but not the technical chops to map that to a solution. Accelerate's problem-first path takes the symptom, finds the bottleneck, and points to the use cases that address it. The SME ends up at the same triage use case as the enterprise, with the same dependency surfaced just as early.

The limitation it removes: the top-down trap on the selection-first path (executives picking use cases that don't fit operational reality) and the bottom-up discovery gap on the problem-first path (small orgs not knowing what AI use cases exist for their problem). The contributor-evaluation step inside Accelerate is also what aggregates the distributed knowledge that external interview rounds can't reach. The same step does the work of three different fixes.

Decide: impact first, value second

Decide runs in two steps, in that order. The unfolding traces where the AI deployment's effects propagate, multiple hops upstream and downstream — closer to a cascade map than to two boxes and an arrow. The impact map then converts into a value calculation: for each affected node, what value is created or lost, the magnitude, and the confidence.

The output of Decide is a decision: pursue, defer, reject, or revisit if context shifts. Defer and revisit get the same weight as pursue and reject.

In the example, Decide unfolds the customer-service triage use case and finds three downstream dependencies (data unification, taxonomy reconciliation, and a queue-routing change) that have to be in place for the value to land. Today, that finding is where the use case dies quietly. With Decide, the use case is deferred, with the conditions named.

Without this layer, the ROI exercise starts from the use case and guesses at the impact, which gets the order wrong. Decide grounds the decision in where the change actually lands, rather than in the sponsor's optimism.

Deliver: the workstream nobody names

Deliver is the work strategy decks describe and integrators wait for, and it has three pieces: workflow redesign, accountability remapping, and sequencing.

Workflow redesign names what changes about how the function operates once the use case is in place. In the example, the triage assistant changes how an agent picks up a ticket; the change propagates to how managers measure agent throughput, how complex cases escalate, and how training is sequenced.

Accountability remapping comes next: named owners at every handover, with scope, trigger conditions, and escalation paths. Without it, the workflow change is documented but not operationalised. Accountability ends up as a redesign output, not a governance principle to declare.

Sequencing is captured as a dependency graph rather than a Gantt chart. Deliver computes which capabilities have to land first because downstream initiatives depend on them. In the example, data unification and taxonomy reconciliation are sequenced ahead of the triage assistant, and the dependency is recorded so the triage decision resurfaces automatically when those land.

This is what closes the unowned operating-model decision layer: the work gets named, scoped, and given an owner. Each pass through Deliver leaves a stream of decisions in its wake (some executed, some deferred to specific triggers), and that stream needs somewhere to live and somewhere to be checked back on.

Digital Nervous System: the compounding layer

The Digital Nervous System (DNS) is what keeps deferred decisions (and the rest of an initiative around them) from quietly evaporating. Every initiative and campaign leaves a residue here: the strategic objectives behind it, the processes contributors mapped, the capabilities that surfaced as gaps, and the use cases considered, chosen, or rejected. Each one carries its rationale, the context that drove the call, and the trigger conditions for revisiting it; the drift in that context over time stays attached to the decision.

Impact tracking sits on top of all of this. Every executed decision gets watched as it unfolds: actual value against projected value, where it overshoots, where it falls short, whether the original case still holds. Every deferred decision gets watched too, but for a different signal: whether its trigger conditions are moving closer or further away. The result is a live read on where each AI initiative actually sits today, not a snapshot from when someone last reviewed it. Together, this is what makes the DNS the org's working memory for AI decisions — a current account of what was committed to, what's playing out, and what's waiting for the right moment.

In the example, the customer-service triage decision is captured as deferred-pending-data-unification, with the rationale (current taxonomy fragmentation), the trigger conditions (unification project completion, taxonomy reconciliation completion), and the projected revisit date. Two quarters later, when the data work lands, the system surfaces the deferred decision automatically. The org doesn't re-evaluate from cold.

This is the layer that makes "revisit when X is built" operational. Without it, that phrase is a meeting-minute decoration that nobody reads.

Without it, institutional memory leaks out between cycles, and the same pilot-purgatory pattern recurs every twelve months.

Why all five matter at once

Drop any layer and the customer-service triage example breaks at a different point.

• Drop the Knowledge Bank: the use case has to be defined from scratch, six weeks of consultancy time before matching can even start.
• Without Accelerate, matching is ad hoc and tilts toward whatever the loudest stakeholder wants.
• Skip Decide, and the data-unification dependency stays invisible until scoping. The use case launches and fails.
• Pull Deliver out and the dependency is identified, but the sequencing and accountability stay unowned. Two quarters pass, the data work doesn't land, and nobody flags it.
• Without the Digital Nervous System, the deferred decision lives in a deck somewhere, and the next time someone asks about customer-service AI, the question gets re-evaluated from scratch.

Each layer closes a specific limitation. What matters is how they compound across layers, not that there are five of them.

Where this leaves us

For organisations running AI transformation with strategy decks and integrator engagements, the gap shows up concretely: as the use case that didn't ship, the capability that wasn't built first, and the deferred decision that nobody can find. The five layers carry that work explicitly.

For the SME without an analyst, all five layers compress into a single guided flow. The discipline that historically required a consultant becomes self-serve.

Before your next AI transformation review

Pick one AI use case currently scoped in your organisation. Walk it through each layer.

For Knowledge Bank, check whether the use case sits on a shared definition or whether someone rebuilt it from a vendor deck. For Accelerate, whether the matching was standardised or whether the loudest stakeholder picked. The hardest one is Decide: has the impact actually been unfolded several hops out, before anyone scoped resources? Deliver covers three things: workflow, accountability, and sequencing. Most teams have the first and skip the other two. For the Digital Nervous System, if the call is to defer, the rationale and trigger conditions need to be somewhere queryable. A deck isn't queryable.

Most organisations will find the answer is "yes" for one or two layers and "no" for the rest, and the layers where the answer is "no" are where the next failure usually starts.

AI Readi runs all five layers as a single platform — the Knowledge Bank for shared scaffolding, Accelerate for standardised matching, Decide for impact-then-value, Deliver for workflow, accountability, and sequencing, and the Digital Nervous System holding the compounding decision memory.