Skip to main content

AI-Ready Data Needs Transactions, Not Copies

· 7 min read
Dan Peacock
Dan Peacock
Chief Hustler

In the previous post we argued that AI-ready data starts with master data — that until an organisation has one definition of "customer", nothing built on top of it can be trusted.

That is the foundation. It is not the whole building.

Master data tells an AI system who your customers are. It cannot tell it what they did. Answers that mean anything to a business — which accounts are growing, which are quietly churning, where the cross-sell actually is — come from transactional data. And transactional data is only useful to AI if it is linked to the master data that gives it meaning.

An invoice line on its own is close to meaningless. It becomes meaningful when it is attached to a known customer, a known product, a known location and a known point in time.

That linkage is the business context. It is what lets a question like "which of our top accounts have reduced order frequency this quarter?" resolve into an answer, because every element of the question maps to something the model already understands.

This is the part that gets skipped. Enormous effort goes into collecting transactional data and comparatively little into connecting it to the business objects it describes. The result is a great deal of data that a model can read and cannot interpret.

Why "copy everything" does not get you there​

The prevailing approach is to copy everything into a lake or lakehouse and work out the meaning later. Storage is cheap, the reasoning goes, so capture it all and defer the modelling.

We have written about where that ends up — the super swamp — but there is a more specific problem for AI.

When you copy everything, you copy the source system's structure along with it. The data arrives shaped by the application that produced it, carrying that application's field names, its conventions, its idea of what a customer record looks like. Nothing about the copy adds business context. It preserves application context, which is a different thing and is not what an AI system needs.

So the meaning has to be reconstructed afterwards, for every use case, by whoever happens to need it. That work is done repeatedly, inconsistently, and by people who often were not there when the source system was designed.

More volume does not help. A larger swamp is still a swamp.

A copy is not an asset​

Here is the distinction that matters most, and it is the one most often missed.

A copy of your Salesforce data is not a data asset. It is a dependency on Salesforce, stored somewhere else. Its structure is Salesforce's structure. Its meaning requires Salesforce knowledge to interpret. And when Salesforce changes — a new object, a renamed field, a version upgrade — the copy and everything downstream of it change too.

A genuine data asset has a property the copy does not: it does not depend on the application that fed it.

That is not a subtle difference. Applications have a lifespan of a few years. Your customer history should have a lifespan measured in decades. If the second is stored in the shape of the first, you have quietly tied the life of your most valuable data to the life of a subscription.

Applications come and go. The asset should remain.

What that looks like in practice​

CryspIQ® gives you the asset from day one. The enterprise data model exists before any of your data arrives — the master elements are already defined, and the structures that hold transactional detail are already there. You are not building the asset. You are connecting sources to one that already exists, and adding from there.

Because the model owns the structure rather than the source system, three things become possible that are otherwise painful.

You can replace an application without losing its history​

Run Salesforce as your CRM. Decide in three years to move to Pipedrive or HubSpot.

In a copy-everything architecture that is a migration project: the history is in Salesforce's shape, so it either gets transformed into the new system's shape, gets left behind in an archive nobody queries, or gets kept in a legacy warehouse that someone must maintain indefinitely.

With CryspIQ® the customers are Entities and the transactions are already stored against them, independent of the system that supplied them. Swapping CRM means mapping a new source into the model. The history does not move, because it was never in Salesforce's shape to begin with. Your reporting continuity is not a migration deliverable — it simply continues.

You can run several applications at once​

This is where it earns its keep during acquisitions.

You acquire a business. You run Salesforce; they run HubSpot. The conventional answer is to migrate them onto your CRM — which means disrupting a business you have just bought, during the period when you least want to disrupt it, and losing months before you can see combined numbers.

The alternative is to map both CRMs into the same model. Their customers and yours become Entities in one enterprise data model. Their transactions and yours sit against those Entities. You can measure across both from a single source without either business changing the tools it uses to run day to day.

The integration decision then becomes a business decision made on its merits and its own timeline, rather than a prerequisite for being able to see anything.

You can see across the whole picture​

Once customer data and transactional data from every source converge on one model, the questions that were previously unanswerable become ordinary ones. Which customers do we serve in more than one business unit? Where is the same account being sold to twice with no coordination? Which relationships look small in one system and significant when combined?

Those opportunities are usually not hidden. They are simply split across systems that nobody can query together.

Accuracy is part of the asset, not a separate project​

An asset that is not trusted is not an asset.

This is why data quality is built into CryspIQ® rather than bolted alongside it. As data loads, quality is assessed against the model — the Data Quality module provides steward and function dashboards, quality rules and an organisation-wide data quality score so accuracy is visible and owned rather than assumed.

Quality applied at the point of loading means the asset stays trustworthy as it grows. Quality applied afterwards, per project, means every consumer forms their own view of whether the numbers can be relied on — which is where confidence in enterprise reporting usually goes.

The question worth asking​

There is a simple test for whether you have an asset or a collection of copies.

If you replaced your CRM tomorrow, what happens to five years of customer history?

If the answer involves a migration project, a legacy archive, or a warehouse someone has to keep alive to answer questions about the past, then what you have is a dependency rather than an asset. That is worth knowing before you build AI on top of it — because every model you train inherits not just the data, but its attachment to the applications that produced it.

Further reading