Single Source of Truth

A single source of truth is an arrangement in which each business measure has one agreed definition, calculated in one place, and consumed by every report and system that references it. Its purpose is to eliminate the situation in which several teams present different figures for the same measure and the meeting is spent reconciling them rather than deciding anything.

The problem it solves is familiar in most organizations of any size. Marketing reports one revenue figure, finance another, and the commerce platform a third, each defensible under its own definition. The differences usually arise from legitimate variations in treatment of returns, cancellations, tax, shipping, currency conversion, timing, and attribution, but because the definitions are implicit, the discussion becomes about whose number is right rather than about what the number means.

The remedy is definitional rather than technological, which is the point most frequently missed. Buying a business intelligence platform does not resolve disagreement about what counts as an active customer; it provides a new place for the disagreement to be expressed. The necessary work is agreeing, explicitly and in writing, what each measure includes and excludes, and that agreement requires the functions who use the measure to participate rather than being handed a definition.

Implementation follows from the agreement. Each measure is calculated once, in a defined layer, and every dashboard, report, and downstream system consumes that calculation rather than reimplementing it. Semantic layers and metric definition tools exist for exactly this purpose, and their value is that a change to a definition propagates everywhere rather than requiring a hunt through dozens of separately maintained queries.

The alternative, in which every analyst writes their own calculation, produces drift that is invisible until it matters. Two dashboards built six months apart embed slightly different logic, both are used, and nobody notices until someone compares them. This is not a discipline failure by the analysts; it is the predictable outcome of an arrangement that requires each of them to re-derive the same logic independently.

The arrangement also needs a route for changing a definition, since business definitions legitimately evolve. Without a process, the alternatives are that definitions never change and drift out of relevance, or that they change without notice and historical comparisons silently break. A defined change procedure, including who must agree, how history is treated, and how consumers are notified, keeps the definitions both stable and current.

Certification is what makes the arrangement usable in practice. Not every dataset needs to be governed, and attempting to control all analysis stifles the exploratory work that produces insight. The workable pattern designates a set of certified measures and datasets that are governed, documented, and authoritative for decisions and external reporting, while leaving exploratory analysis unrestricted with the understanding that it is not authoritative until certified.

Documentation must be accessible at the point of use rather than in a separate repository. A definition recorded in a data dictionary nobody opens does not prevent misinterpretation, whereas a definition visible in the reporting tool beside the number, stating what is included and when it was last changed, is read by the people who would otherwise guess. Recording the reasoning, not only the rule, prevents definitions being changed casually.

Because agreement across functions is the binding constraint, this work is organizational at least as much as technical. In practice the definitions and governance sit with data analytics, the implementation in the warehouse and semantic layer with product development, and securing the cross-functional agreement that makes any of it stick is frequently a task for strategic planning and consulting rather than for the analytics team alone.