The scaffolding behind Accelerate's discovery engine.

Last week's post ended on a specific question: what's actually inside the Knowledge Bank, how deep it goes, what gets extended, and what makes that depth compound over time. Last week answered the integration layer: how problem discovery runs. This post is the other half: what the Knowledge Bank contains before the organisation ever contributes a single problem.

What context-building usually costs

AI initiatives inside an organisation rarely start from one place. One begins in a function that found a vendor, another in a board mandate, another in a team automating around a bottleneck. Each arrives with its own framing of the problem and its own picture of what success looks like. Getting them onto the same ground (so the organisation can see what it actually faces and where AI should go first) always takes work.

That coordination work is the real cost, and most organisations underpay it. The picture they assemble is two slides and a maturity score, current at delivery and dated by the deliverable. The deeper substrate — the objectives the organisation tracks, the problems it faces, the use cases that apply in its sub-vertical — is what the coordination should produce, and it usually doesn't get built to a useful level of depth and nuance.

When that work isn't done well, the cost doesn't disappear; it carries into the deployment. Three months in, the initiative has drifted from the problem it was meant to solve, and the post-mortem ('we should have done more discovery upfront') arrives after the decision that mattered. The Knowledge Bank changes what the organisation has to build from scratch. Most of the substrate is already there: the objectives framework, the problem types, the use-case library tuned to the organisation's sub-vertical.

What's already there before you start

An organisation doesn't walk into an AI initiative empty-handed. Three things have been accumulating since the last one: the objectives it set, the capabilities it built, and the problems it never got to. The Knowledge Bank holds a place for all three, so each initiative starts from what's already on record rather than from a blank page.

Objectives don't reset at the start of each initiative; they accumulate. This year's evaluation sits downstream of last year's outcomes, not parallel to a fresh interview round. The framework anchors what success means in the organisation's own terms and ties each initiative back to the business goals behind it, so whatever gets built stays aligned with where the organisation is trying to go, not just the initiative in front of it.

Problems get captured against structured types, so two functions naming the 'same problem' actually mean the same thing, and a problem that didn't get solved last cycle is still on the list this one, not rediscovered from zero. Sizing isn't an analyst's estimate; the people experiencing the problem validate the magnitude themselves. Both discovery and sizing go through the contributor-validation layer, so the priority order coming out has the people doing the work behind it.

The use-case library has depth at sub-industry and sub-function level, expanding into finer disambiguation by geography, org size, macro-economic context, and baseline systems. A 'predictive maintenance' use case for a German mid-cap running SAP S/4HANA isn't the same as the one for a US growth-stage industrial running NetSuite. The library carries both shapes, and it keeps pulling in what's new outside the organisation — new use cases, new technology, new industry practice — and lands each one in the organisation's own context rather than as a generic feed. Next quarter's version covers ground this one doesn't.

What shared context does to coordination

Most organisations treat coordination as a separate step. A steering committee, a governance workshop where Finance, Operations, and Technology get in a room and agree on what the problem is. That process can take weeks and produce a form of consensus nobody fully believed in.

With the Knowledge Bank, coordination happens differently: when contributors across the organisation surface problems, they're all working against the same structured problem types, the same ontology, regardless of function or role. Finance's framing of an ERP bottleneck and Operations' framing of the same issue look different in the words. But they're landing against the same problem category, tagged with the same structured attributes, visible to everyone.

They're building a shared picture of the organisation without agreeing on vocabulary first. Each person contributes from their own function, their own problems, and the accumulation is what the Knowledge Bank grows from. Each contribution sharpens the picture. The common ground gets built by contributing, rather than agreed in a room.

An organisation that's run the discovery engine twice has a problem picture that's held up across multiple functions, without a single coordination workshop. The coordination happened inside the engine.

The integration engine needs something to run against

The integration mechanism from last week (problem identification, sizing, contributor validation, use-case matching) runs against this substrate.

The objectives framework gives impact validation something to anchor to. The problems repository populates the discovery engine with structured types, so contributors aren't asked to invent categories; they're asked which ones apply, where, and how badly. The use-case library is what validated problems map against. The two depend on each other: the substrate without the discovery engine is an unused catalog, and the engine without the substrate is slow and noisy.

What Decide and Deliver need from here

Decide and Deliver can only do their work if the context substrate underneath is complete and contributor-validated.

Decide maps the impact of a use case across the value chain and derives value from that traversal. It needs a structured objectives framework to anchor value derivation, and a sized, validated problems repository to set priority order. Deliver carries the workflow redesign and accountability remapping that turns the decision into an operational change. It needs the problem and objective trail to compute the sequencing.

The Knowledge Bank's substrate is what makes both tracks viable.

Where the coordination tax actually comes from

The coordination tax most organisations pay shows up as steering committees, workshops, and two-hour calls to agree on what 'the problem' actually is. It isn't only the cost of those meetings, and it isn't a strategy gap. Finance, Operations, and Technology are each working from their own picture of the same organisation, and every hand-off between them loses some of what each one knows. Nobody has built the shared picture, so the context thins each time it crosses a boundary.

The Knowledge Bank is that picture. Finance's framing, Operations' framing, the floor team's framing: they all land in the same structured substrate, and nothing thins as it crosses between them. The coordination that usually gets scheduled as a separate step happens inside the discovery engine.

One question worth asking before the next initiative

The context picture your organisation is working from: where it came from matters. If an analyst assembled it and a steering committee validated it, it reflects what was visible from that altitude, not what was being experienced at the level where the work actually happens.

When that picture depreciates (a reorg, a leadership change, a system migration), what it was sitting on determines how quickly you're back to zero. A document someone wrote starts over. A substrate the organisation contributed to, built against a structured library that keeps deepening, doesn't depreciate at the same rate.

AI Readi's Knowledge Bank is that substrate: an off-the-shelf foundation of objectives, problem types, and use cases that deepens with each organisation that runs the discovery engine.