What is a single source of truth?

A single source of truth is the principle that every fact in an organisation should have one authoritative home, so that anyone asking a question gets the same answer and nobody has to adjudicate between two spreadsheets. In data architecture it usually arrives as a project: consolidate the systems into one warehouse, point everything at it, and the disagreements stop.

The principle is sound. The usual implementation of it is where the trouble starts, because "one authoritative home" quietly becomes "one physical copy", and those are not the same claim.

What a warehouse is genuinely for

Worth saying plainly, because the rest of this is a criticism: a warehouse is the right answer for analytics. Questions that scan history, aggregate across millions of rows, or join six systems to produce a number for a board pack belong in one place, modelled deliberately, with the transformations in version control. Nothing below replaces that, and an organisation without one is usually worse off.

The failure is specific. A warehouse answers questions about the business well and questions in the business badly.

Why consolidation fails for operational questions

The source systems remain authoritative, and they are right to. The CRM owns who the account manager is, because that is where the field is edited. The ledger owns the invoice amount, because that is where the money is reconciled. The support desk owns the state of the ticket. Copying those values into a warehouse does not transfer authority; it creates a second, lagging opinion with no claim on the original.

Staleness is not an edge case. Analytics tolerates a nightly load; an agent about to tell a customer their renewal date does not, and the gap between last night's extract and the record as it stands is where a confident wrong answer comes from.

Write-back is almost never built. The point of a system of record is that it is where the change is made. A consolidated copy you can only read means every correction happens somewhere else and arrives later, which is the opposite of a single source.

It is the migration nobody finishes. Each system brings its own schema, identifiers and idea of what a customer is, so the modelling cost is paid again for every integration. Two years in, most organisations have a warehouse holding the four systems that were easy, an operational reality spread across the other twenty, and a mapping document describing the plan rather than the state.

The achievable version: truth about where truth lives

The more useful goal is a single source of truth about where the truth lives. Not one copy of every fact, but one place that knows which system owns which field, what it last said, when it said it, and which record it was. The CRM keeps the owner, the ledger keeps the amount, and the layer in front of them knows that — so a question routes to an answer, and an answer carries the record it came from rather than a table name.

This only works if identity is resolved. "The ledger owns the amount" is useless if nothing can establish that BIGCO LIMITED on the invoice, BigCo Ltd in the CRM and bigco.com in the mailbox are one company. Entity resolution is the unglamorous prerequisite, and it is the step most retrieval systems skip, because similarity is not identity and embeddings cannot supply the join.

The natural shape for the result is a graph rather than a table: entities with aliases and external identifiers, edges between them, and facts attached to the entities with a source and a date on each. That is what knowledge graph memory is for. Each system keeps its own shape, and the graph is the thing that knows the same person appears in five of them.

Where this stops

It does not make the systems agree. A graph that resolves identity across the CRM and the ledger will surface that they hold different renewal dates; it will not tell you which is right. That stays a question for whichever system owns the field, and anything claiming to settle it automatically is guessing.

It is not master data management: no golden record written back, no governance workflow, no stewardship queue. If two systems disagree because nobody owns the field, a resolution layer makes the disagreement visible and leaves the organisational problem untouched.

And it is as current as its last read. A layer that syncs on a schedule holds what the systems said then, not what they say now, so a figure it reports is a figure as stated on a date and anything consequential should be checked against the system that owns it. Resolution is also irreversible in practice: two records folded into one are hard to separate afterwards, which is why a shared identifier should be the only evidence acted on without confirmation.

Memtro takes the second position. Each connected system keeps its own shape, and the graph resolves the same person or company across all of them: entities carry aliases and external ids, a connector's records are anchored by their own identifiers, people are keyed by email so a CRM contact who is also a correspondent stays one node, and every fact keeps the system, record and date it came from. Across 146 connectors that is the join nobody has to build. How Memtro's memory works goes through it.