Is a Single Source of Truth Actually Achievable?

Almost every data warehouse business case lists single source of truth as a primary benefit. Very few of the people who wrote those business cases have seen one delivered.

That is not a rhetorical setup. It is the most common observation in the field, and practitioners say it more plainly than vendors do. From a heavily-discussed thread on r/dataengineering:

almost every single project and business case for a data warehouse project has "single source of truth" listed as one of the primary benefits. The problem is though, I have never seen a single source of truth implemented

If you have watched this fail, you were not watching a badly run project. You were watching a category error, and it is worth naming precisely before talking about what does work.

Why does single source of truth keep failing?

Because the programme was a storage answer to a meaning problem.

The promise is that the organization has too many versions of the truth, scattered across systems that disagree. The remedy is consolidation: move everything into one place, model it once, declare the place authoritative. The warehouse gets built. The pipelines land. The modelling is competent. And the arguments continue, unchanged, in exactly the meetings they were happening in before.

They continue because moving data never touched the reason the versions differed. Two systems held different customer counts because two departments count customers differently, and both are right about something. Consolidating the rows puts the two definitions in adjacent tables rather than adjacent systems. It does not adjudicate between them, and nothing about the new location gives anyone the standing to.

The same thread that opened this piece, and many like it, keep arriving at that point from a different direction:

The biggest data problem I keep running into isn't dirty data. It's teams defining the same metric differently.

And its top reply, which names the mechanism almost exactly:

Our proverbial question is how many customers do we have? Then people get upset when I start asking questions about how they want to define a customer.

People get upset because the question is not technical. Asking how they want to define a customer is asking someone to give up a definition that works for their purposes, in favour of one that works for somebody else's. That is a negotiation with consequences, and no amount of infrastructure performs it on the organization's behalf.

So is it achievable, or not?

Not as promised. The version of single source of truth that means one place where all data lives and every question resolves identically is not achievable in an enterprise of any size, and programmes that pursue it either stall or quietly redefine success.

What is achievable is narrower, and the narrowness is the point: one agreement per contested concept, with a named owner and a record of when it changed and who signed it.

That is a much smaller claim. It says nothing about consolidating storage: the agreement can sit over systems that stay exactly where they are. It does not require every question to have one answer; it requires every contested question to have one decided answer, and it requires you to know which questions those are.

It is also the version practitioners reach for on their own. Further down that same thread, someone proposes the shape of the answer without any vendor prompting:

I think having a metrics dictionary is the only way to fix this. If you make finance own it most folks have to go through them to change it

That comment is doing two things at once, and the second is the important one. It names an artifact, and then it names an owner and a change path. The dictionary without the ownership is a document. The ownership is what makes it settle anything.

What does the achievable version look like in practice?

Four things, and none of them is a migration.

Find the contested few. Most of your data is not disputed. Nobody argues about a timestamp. The terms that need agreement are the ones where two competent teams answer differently and both can defend it: customer, active, revenue recognized, complete, eligible. In most organizations this is a list of tens, not thousands, and writing it down is a week of conversations rather than a programme.

Get an actual decision, from someone with standing. Not a working group consensus that everyone can live with and nobody is accountable for. One person or one role owns the term, decides what it means for the purposes where it is contested, and is the person you go to when it needs to change. If nobody has the authority to make the call, that is the real finding, and it is an organizational problem that no tooling resolves.

Record it where systems can reach it, not where people can read it. A definition in a document is a reference. A definition a system resolves against at query time is a control. The difference shows up the moment something automated asks the question, which is now constantly.

Keep the review trail. What it was, what it is, when it changed, who signed it. This is the part that gets dropped first and is needed most, because the question that eventually matters is not "what does this mean" but "what did this mean in March, when we gave that answer."

Notice what is absent. No consolidation, no migration, no single physical store. Systems keep their own copies and their own schemas. What becomes single is the agreement, and agreements travel better than data does.

It is also worth knowing what success looks like, because it does not look like a launch. The signal is that a specific argument stops recurring. If the customer-count question came up in three meetings last quarter and comes up in none this quarter (not because people gave up, but because there is now a decided answer with a name attached), that is the whole return. It is unglamorous and it compounds, because the same mechanism works on the next term, and the marginal cost of the second one is much lower than the first.

The failure signal is equally clear and worth watching for. If the agreed definition exists and teams keep using their own anyway, the definition was never actually agreed; it was published. Adoption without agreement produces a governed artifact nobody consults, which is the same outcome as the warehouse, reached faster and more cheaply.

Why this has stopped being optional

For as long as the consumer of a definition was a person, ambiguity was survivable. An analyst reading a report knows their department's definition of active, notices when a number looks off, and asks. The disagreement was absorbed by human judgement, continuously and invisibly, at the point of use.

Software acting on the same definition absorbs nothing. It takes the number, treats it as true and proceeds. And it will do that on behalf of both teams simultaneously, answering the same question two different ways depending on which pile of material it happened to retrieve, with no indication that a second answer exists.

Which is why the old failure has a new cost. The single source of truth programme that quietly underdelivered for a decade was expensive and tolerable. The same gap under an agent is neither.

For the discipline that grew up around this problem, see context management. For why an inferred or derived definition cannot settle the argument regardless of how good the derivation is, see inferred context. If you want the mechanics of the structure that carries agreements over systems that stay where they are, see what a context graph is.