Two dashboards, two revenue numbers, one awkward meeting. Every growing company hits this moment — and it is rarely a tooling problem. It is the absence of a single source of truth (SSOT): one governed place where metrics are defined once and used everywhere.
What a single source of truth actually is
An SSOT is not “one database with everything in it.” It is an agreement, enforced by infrastructure:
- One definition per metric — revenue, active user, churn — written down, owned, and versioned.
- One pipeline per source — each system’s data enters through a single governed path, not five ad-hoc exports.
- One place to ask — dashboards, reports, and AI assistants all read from the same modeled layer.
Which data actually needs one
Not all of it — and the distinction saves months.
Events are things that happened: orders placed, pages viewed, matches played. They are append-only, and teams rarely disagree about them. A purchase happened, at a time, for an amount. Where two teams differ on an event count, they are differing about the definition above, not about the data.
Master data is the opposite: customer, product, employee, account, supplier. It is small, it changes, it lives in several systems at once, and each system is convinced its own version is correct. This is where “two dashboards, two numbers” usually comes from — far more often than from the arithmetic.
So define your metrics once, yes. But start the physical work on the four or five master entities that everything else joins to. Those are the single source of truth. The events are just events.
Why it matters
- Decisions speed up. When nobody has to reconcile numbers, meetings move from “which figure is right?” to “what do we do about it?”
- Trust compounds. Every consistent answer builds confidence; every contradiction spends it.
- Self-serve becomes safe. Teams can explore data without creating parallel truths, because the definitions travel with the data.
A pragmatic implementation path
1. Start with the metrics that cause arguments
Do not model everything. List the five numbers leadership sees weekly, and make those unambiguous first.
2. Centralize ingestion before modeling
Get every relevant source landing in one warehouse through automated, monitored pipelines. Manual exports are where truth goes to die.
3. Write definitions as code
Metric logic belongs in versioned SQL models, not in a wiki or someone’s memory. Reviews and history come free.
4. Put quality checks at the boundaries
Freshness, volume, and schema tests on every source table — so a silent upstream change breaks a check, not a board meeting.
5. Make the governed path the easy path
If asking the SSOT is harder than exporting a CSV, people will export the CSV. Invest in the interfaces — dashboards, and increasingly, plain-language access.
6. Decide what makes two records the same thing
Every SSOT project reaches this one, and a lot of them stall here. The CRM has ACME Ltd. Billing has Acme Limited. The product database has an account registered to acme.com. Is that one customer or three?
This looks like a fuzzy-matching problem and mostly is not. It is a decision, and it has to be made by someone in the business:
- Pick a key. A company registration number, a verified domain, an internal customer id issued once and pushed everywhere. Something that does not change when marketing renames an account.
- Write the merge rule down. When two records collide, which field wins? Different answers for different fields is fine — billing owns the legal name, the CRM owns the account owner — but every field needs an answer, written somewhere.
- Keep the losers. Never delete the records you merged away, and store the mapping alongside them. The day somebody disputes a number, that mapping is the only thing that can explain where it came from.
An algorithm can propose matches. It should not be the thing that decides.
7. Put a name next to every definition
A person, not a team. “Revenue is owned by finance” means it is owned by nobody at six o’clock on a Thursday when a definition needs to change and a release is waiting.
The job is small — approve changes to the definition, and be able to say why it is what it is. But without it, definitions fork quietly. Someone needs a slightly different cut, builds their own model because that is faster than finding who to ask, and now there are two numbers again with nobody actually in the wrong.
Keeping it true after month three
A single source of truth does not usually get broken. It gets routed around.
So audit for that specifically. Once a quarter, take your five numbers and compare them against whatever the teams are actually using — the spreadsheet on someone’s desktop, the export that feeds a weekly deck. You are not hunting arithmetic errors. You are looking for divergence, because every divergence is somebody’s answer to a need the governed path did not meet.
When you find one, the useful question is not “who is wrong?” It is “what did they need that they could not get?” Half the time the answer is a legitimate cut of the data nobody had modelled, and the fix belongs in the SSOT. The other half it is a definition genuinely worth arguing about — and now you are having that argument on a Tuesday, in a review, rather than in front of the board.
Step 4 catches the data going wrong. This catches the organization going around.
The takeaway
A single source of truth is a habit backed by infrastructure: define once, govern the path in, and make the trusted route the convenient one. Start with five metrics and the handful of master entities underneath them, and grow from there.
The technical work is the smaller half. The two decisions that actually determine whether it holds — what makes two records the same thing, and whose name is next to each definition — are both organizational, and both cheaper to make now than after the first disputed number.
This is the foundation Datablast builds for every customer — shared definitions, governed pipelines, and Flare answering questions from the same trusted layer everyone else uses.
Originally published April 2024. Expanded September 2026 with the sections on master data, entity resolution, definition ownership and quarterly audits.
See it on your own data
20 minutes, your questions, a live walkthrough.