Most enterprise AI programs fall behind for the same reason. They were planned for the organisation described in the org chart, and the one that actually exists runs on email and Excel.
That organisation works. It closes the books, restocks the shelves and pays its vendors through thousands of handoffs that nobody ever designed and everybody depends on. Any transformation that ignores those handoffs will stall on them, however good the models are.
The pilot worked and the rollout did not
The pattern is familiar. A pilot does well in a controlled setting with clean inputs and a motivated team. Leadership approves a rollout. Six months later, adoption has stalled, the dashboards are open in meetings and ignored afterwards, and the regional teams are still sending the same spreadsheets they sent before the program began.
Two explanations usually follow: people are resisting, and the data is dirty. Both are observations, not causes. The spreadsheet the regional manager keeps sending and the column that breaks the model point to the same thing. The business has rules, and nobody wrote them down.
The original promise also contributed. Transformation was sold as a destination with a date on it. Businesses don't change on a date. They change one handoff at a time.
Every anomaly is an unwritten contract
Look at the sheet a regional manager sends every Monday before ten. It has fourteen columns in a set order. Northern stores use a different code scheme from the rest. A blank in column nine means the store was audited that week, not that the value is missing. Finance opens it, checks three numbers and forwards it.
That is a contract. It has a shape, a schedule, a sender, a recipient and a set of rules for exceptions. It has been honoured every week for years. When the AI pilot read that column-nine blank as missing data and imputed a value, it didn't find dirty data. It broke an agreement it didn't know about.
Seen this way, the anomaly log is the most valuable document the program has. Each entry points to a rule the business already follows. Each case of "resistance" is someone continuing to keep a contract that the new system ignored.
Not every rule deserves to survive. A spreadsheet is an archaeological record: institutional knowledge and accumulated accident sit in the same cells, and the file can't tell you which is which. The job is to read it as evidence. Find the rule, find who depends on it, decide whether it still holds, then ratify it or retire it deliberately. That is the sense in which spreadsheets are the spec. They are where the current one becomes visible.
Reading the record is the first of five steps. Observe the handoffs as they actually run. Formalise the durable ones as contracts. Govern those contracts through the people who know why they exist. Capture the judgment those people carry. Build small tools on top. Each step makes the next one cheaper.
A contract is small enough to own
Every large enterprise has data owners on paper. Ownership stops meaning anything when what is owned is an entire domain, platform or lake. Nobody can vouch for something that size, so nobody does.
A contract is the right unit. It describes a single handoff between two steps, and it fits on a page:
- Shape. The fields, their types, their units and what each value means, including what a blank means, and how conformance is checked.
- Owner. One person responsible for the handoff. Not a department, not a committee.
- Cadence. When it arrives and at what point it counts as late.
- Tolerance. How wrong a number can be before someone has to act, and who that someone is.
- Direction. Who reads it, who can propose changes, and who commits changes under it.
- Version. How the contract changes without silently breaking whatever depends on it.
Someone can own one of these. A small set of contracts, each with a named owner, covers more operational ground than a data lake with owners in name only.
The view is the cheap part
With contracts in place, the argument about Excel versus dashboards stops mattering. Both are views over the same governed record, and once the contract exists, another view costs very little. A team that wants a live dashboard can have one. A finance head who wants the Monday sheet exactly as it has always looked can have that too, generated from the same source, arriving at the same time.
The rule that makes this safe is direction. Excel becomes a lens, not a ledger. It opens read-only in the browser, with the frozen panes, filters and conditional formatting people have relied on for years. People can work in the margins as much as they want, with a quick formula or a what-if column in their own copy. Changes reach the record only through a path that enforces the contract. The shadow copy can still exist, but it no longer silently becomes the authoritative version.
Whether a business reads its numbers in rows or in charts has nothing to do with whether it has transformed. The contracts underneath determine that.
The last transformation's leaders hold the keys to this one
The executives most sceptical of the AI program are often the same people who led the ERP rollouts twenty years ago. They were the disruptors then. They replaced paper ledgers and local systems with one process model and one source of truth, and they took a lot of criticism doing it.
What they built was less about the software than about agreement: a shared definition of what a purchase order is, what a goods receipt is, and what happens between the two. That work was the contract layer. The opaque system on top of it was a limitation of the time.
That makes them the natural stewards of this transformation. The right structure for them is a standing council, a sabha, of the people who know why each field exists. The sabha is the constitutional layer, not a help desk. Routine cases are settled by the contract itself. Proposed changes move asynchronously, reviewed by the owners of the handoffs they affect. Only disputes that cross functions reach the council. When two regions disagree about what column nine means, the sabha decides, and the decision goes into the next version of the contract.
That is a role with real authority. It respects decades of judgment without asking those people to adopt a new interface first. Things are the way they are for a reason. The sabha keeps the reason, and decides whether it still holds.
Judgment has to become queryable
A council that meets monthly can't keep up with a business that runs every hour. The sabha's knowledge has to be available when the anomaly happens, not three weeks later.
So the next step is to capture that judgment in a form the system can consult. Each senior member's knowledge is gathered from their own material: the memos they wrote, the exceptions they approved, the explanations they have given a hundred times. When a tool hits a case the contract doesn't cover, it retrieves the relevant precedent and proposes an answer, labelled by source: grounded in something the expert said, drawn from general knowledge, or flagged as unknown.
Precedent can propose. Only a ratified rule can act. The system tests four things separately: who said it, whether it became policy, whether it still holds, and whether it can be applied without a person in the loop. Only a rule that passes all four can trigger an automatic action.
The flagged gaps are what matter most. Each one becomes a specific question for a specific person: "When a store is mid-audit and the count is blank, do we carry last week's figure or hold the order?" The expert answers once. The answer goes into the corpus and, once it has been ratified as a rule, into the contract. The next time that case comes up, nobody needs to be interrupted.
This changes how the experienced people relate to the program. They aren't being replaced by a system that learned from them without asking. They are being consulted, and every use of their judgment is attributed and reviewable. The thing they most feared the transformation would lose, their knowledge of why things work the way they do, becomes the part that grows over time.
Small tools on shared contracts
Once contracts exist, useful tools become cheap. A tool that turns two phone photos into product dimensions. One that reads expiry dates off a label. One that flags a Monday sheet that arrived with a column out of order. None of these is a transformation on its own. Each can be built in days or weeks rather than planned in quarters, and each one built on a shared contract makes the next one cheaper.
Anyone should be able to build one: the program team, a vendor, an analyst with an afternoon free and a good idea. The requirement is that the tool uses the contracts. Any data it reads or writes conforms to the contracted shape. Tools that do this go into a shared registry, and tools that don't are not used. That rule is the centre of the governance model. Versioning, permissions, monitoring and retirement all follow from it, and it's what keeps a thousand small tools from turning into shadow IT.
It also gives the program a report leadership can believe. Adoption percentages measure a destination the business was never going to reach on schedule. Features shipped measure output. Contracts ratified and tools reused measure the capacity the program leaves behind. A target of forty ratified contracts and a dozen reused tools gives the first two quarters a concrete definition of progress.
A retail shelf is a good test
We are testing this in retail, through dg2n by GMetri. A single store involves planograms, replenishment, labels, audits and fixtures, with each handoff running through a different team, often a different spreadsheet, and very often an expert whose knowledge exists nowhere else.
The architecture has two parts. OpenShelf defines the shared schemas: an open vocabulary for the things a store runs on, such as a product's dimensions tied to its barcode, a fixture's slots, or the intent behind a planogram. Each business turns those schemas into contracts by attaching ownership, cadence, tolerance, direction and version. Tapas is a growing collection of small tools built on those contracts, each doing one job, each free or close to it. None of them is meant to replace a system of record. Each is meant to make the next tool easier to build.
Leave the raft on the bank
The Buddha described his teaching as a raft. You build one from whatever is at hand to cross a river. On the far side, you don't carry it on your head for the rest of the journey out of gratitude. You leave it on the bank and keep walking.
Enterprise transformation has spent two decades building bridges: large, permanent, expensive structures meant to take the whole organisation across in one go. The ground was always better suited to rafts. Small tools get built for one crossing and are dropped when something better appears, with no ceremony and no failed program to explain. What lasts is what they're built on: the contracts, the people who keep them, and their judgment, now available when it's needed.
The Excel users and the dashboard builders were never really arguing about tools. Both were holding on to a particular raft. The river is the same one, and the business has been crossing it every Monday before ten.