Data & Analytics
The ‘single source of truth’ is the wrong promise
Enterprises rarely need every answer in one system. They need governed sources of record, explicit metric definitions and traceable reconciliation across legitimate contexts.
July 2, 2026
“We need a single source of truth” usually appears after two reports show different numbers in an executive meeting. It sounds like an architecture requirement. Most of the time, it is a demand for a reliable decision.
Putting data in one platform does not create that reliability. Finance, sales, marketing and operations can query the same warehouse and still disagree because they use different definitions, time boundaries, identity rules, currencies or levels of finality.
Truth in an enterprise is not a storage location. It is an explicit, governed claim with context.
One fact can have several valid views
Consider revenue. Finance may report recognised revenue under accounting policy. Sales may report booked contract value. Marketing may report attributed purchase value. Operations may track shipped value. These numbers should reconcile, but they should not be forced into one definition.
The error is not having multiple views. It is using the same label for different measures without making the difference visible.
A useful data architecture distinguishes:
- system of record: where an authoritative business event or attribute is created and maintained;
- version of facts: preserved observations and transactions, including their history;
- semantic definition: the agreed rule that turns facts into a metric for a purpose; and
- decision view: the representation appropriate to a role, time and action.
The enterprise may have several systems of record for different domains. What it needs is governed reconciliation and clear semantics across them.
Centralisation solves some problems, not meaning
Consolidating data can improve access, lineage, control and performance. It can reduce duplicated integration and make shared modelling practical. Those are meaningful benefits.
But a central warehouse or lakehouse still contains choices. Which customer identifier wins after a merger? When is an order considered complete? How are returns allocated? Does “active” mean logged in, paid, shipped or engaged? The platform cannot decide these questions without business authority.
When teams promise a single source of truth, stakeholders may assume conflict will disappear. In reality, the conflict moves into transformation code and dashboard filters. If those choices are not governed, centralisation hides disagreement rather than resolving it.
Replace universal truth with bounded contracts
Define authoritative sources and metrics for specific decisions.
For a governed metric, record:
- its business purpose and decisions it supports;
- calculation, grain, filters and time basis;
- source facts and identity rules;
- owner and approval authority;
- freshness and quality expectations;
- known exclusions and inappropriate uses;
- effective date and version history; and
- reconciliation to adjacent metrics.
This is a semantic contract. It does not require every team to use one dashboard. It requires teams to know when they are using the same definition and when they are intentionally using another.
Reconciliation is a product capability
Disagreement will still occur. A mature system makes it diagnosable.
Preserve lineage from metric to transformation and source. Retain effective-dated logic. Make identity matching and late-arriving adjustments visible. Provide reconciliation views that explain the bridge between recognised, booked, shipped and attributed value.
The goal is not to force one number into every meeting. It is to prevent unexplained numbers.
When an executive sees two figures, the organisation should be able to answer: Are they intended to match? If not, why? If yes, where does the variance begin, who owns it and when will it be corrected?
Federated ownership without semantic chaos
Domains closest to the business process should own the facts and context they produce. Central teams should provide shared infrastructure, interoperability rules, identity patterns, policy and metric tooling.
This federated model accepts that “customer” may have different bounded meanings in service, billing and marketing. It also requires explicit mapping where cross-domain decisions need a combined view.
The alternative extremes both fail. A central team cannot understand and approve every domain change quickly enough. Fully autonomous domains create incompatible identifiers and repeated semantic debates. Federated governance assigns local meaning while enforcing global interfaces.
The role of a semantic layer
A semantic layer can centralise metric definitions and make them reusable across BI tools and applications. It reduces repeated SQL and improves consistency. It is not governance by itself.
Definitions still need owners, tests, change control and versioning. Consumers need to understand grain and scope. A technically central measure can still be wrong, stale or inappropriate for a decision.
Treat the semantic layer as executable policy: a place where agreed meaning is implemented and tested. Do not treat it as a machine that generates agreement.
Security, privacy and regional truth
Legal and regulatory context may make one global record inappropriate. Data residency, consent, purpose limitation and local retention can constrain how data is combined and who may use it.
An enterprise identity graph that is technically comprehensive can be legally excessive. A single customer view should not collapse the difference between data the organisation possesses and data a particular user or purpose is entitled to access.
The governed model must retain policy context with the data, enforce access at consumption and support deletion or restriction without corrupting required records.
A practical path out of metric conflict
- Select the ten metrics that drive material decisions.
- Collect every current definition and report without judging them prematurely.
- Identify source facts, grain, timing, identity and adjustment differences.
- Decide which distinctions are legitimate and which are defects.
- Name a business owner with authority to approve each definition.
- Implement definitions as tested, versioned semantic contracts.
- Build reconciliation where adjacent measures must coexist.
- Expose definition and lineage beside every report.
- Track disputes and repeat causes.
This is intentionally narrower than “create an enterprise source of truth.” Solve the decisions important enough to govern, then expand.
What to measure
- time spent reconciling executive reports;
- critical metrics with approved, active definitions;
- duplicate calculations outside the governed layer;
- unexplained variance between measures intended to reconcile;
- definition changes with assessed downstream impact;
- consumer understanding of grain and appropriate use; and
- decisions delayed by data disagreement.
These measures reflect operational trust more honestly than the percentage of data copied into one platform.
When a literal single source is correct
For a specific attribute within a bounded domain, one system of record is often exactly right. There should be one authoritative place to change a product’s legal identifier or an employee’s payroll status. Replicas can serve performance, but mastery should be clear.
The mistake is stretching that valid pattern into a universal promise that one physical platform can own every interpretation across an enterprise.
Adovo’s view
Leaders are not asking for one database. They are asking to stop wasting meetings arguing about numbers nobody can explain.
Give every critical fact a source of record. Give every critical metric an owner and semantic contract. Preserve legitimate context and build reconciliation into the product. That is less marketable than a “single source of truth,” but it is much closer to how trustworthy enterprises actually operate.