Single Source of Truth: Decide Which Data Wins

The customer appears active in the sales system, cancelled in billing, and absent from this morning’s executive dashboard. Someone exports all three records into a spreadsheet, chooses a value, and promises to “fix the single source of truth.” A week later, another team makes a different choice because it is answering a different question.

That is the recognizable failure behind most searches for a single source of truth. The organization does not merely have duplicate data. It lacks an agreed way to decide which value should be used, for which purpose, at what time, and who must correct it when the values disagree.

A useful single source of truth is therefore not one enormous database. It is a controlled decision about authority. For every important data element, the organization names the authoritative source, defines the business meaning and acceptable delay, records how the value changes, and gives someone responsibility for resolving exceptions. Other systems may hold copies or purpose-built calculations, but they do not quietly invent a competing answer.

The distinction matters because a company can consolidate every record into a warehouse and still argue about revenue, customers, inventory, or campaign performance. Central storage makes data easier to find. It does not, by itself, settle definitions, timing, ownership, or conflict rules.

A single source of truth is a rule, not a place#

The phrase is easiest to use precisely when it is broken into three parts. “Source” identifies the system or process entitled to originate or approve a value. “Truth” means the value accepted for a named business use, subject to known limits. “Single” means there is one approved resolution path when alternatives conflict. It does not mean that only one physical copy may exist.

Consider an illustrative customer record. A customer relationship management system may be authoritative for the account owner. A billing platform may be authoritative for payment status. An identity service may be authoritative for the login email. A curated analytics model may be authoritative for the company’s published monthly active-customer measure. These assignments can coexist because the fields and uses differ. Declaring the entire customer object to belong to one application would be simpler to say but harder to operate honestly.

This is also why authority must be narrower than “the customer table.” The useful unit is often an attribute or a defined metric: legal customer name, shipping address, contract start date, recognized revenue, or active-customer status. Each needs a definition, an owner, an update path, and a time reference. When a value is derived, its approved formula and inputs matter as much as its storage location.

The UK Government Data Quality Framework guidance treats quality as fitness for a stated purpose and recommends identifying critical data, tying checks to a specific use, and setting rules that reflect user needs and business objectives. It also notes that the importance of fields varies with use, so assessments of the same data can produce different results (Government Data Quality Framework guidance). A dataset is not permanently “good” or “bad.” Its suitability changes with the decision being made.

That principle prevents an expensive category error. A weekly marketing extract may be suitable for retrospective channel reporting but too old for suppressing a promotion immediately after a customer opts out. A provisional sales total may help an operations team allocate tomorrow’s workload but be unsuitable for a signed financial statement. The organization does not need to pretend that one value serves both jobs. It needs to name the use and make the status visible.

One enterprise-wide winner usually creates false confidence#

The appeal of a universal master database is understandable. If every team looks in the same place, disagreement should disappear. In practice, the difficult disagreements are about meaning and time, not just location.

Consistency and timeliness illustrate the problem. The UK framework defines consistency in terms of values not contradicting other values for the same entity. It defines timeliness by whether the delay between collection and availability is appropriate for the intended use. It explicitly recognizes trade-offs among quality dimensions: faster data may be less complete, while more complete data may arrive later (Government Data Quality Framework). One universal quality score would hide the decision the user actually needs to make.

Suppose an order platform reports an order as shipped at 10:03, while a finance model incorporates shipments in a controlled nightly close. For a customer-service call at 10:05, the operational event is the better answer. For yesterday’s approved revenue report, the closed model may be the better answer. Neither result licenses the teams to redefine “shipped” or “revenue.” It means the source-of-truth rule must include the purpose, effective time, and publication state.

I would therefore avoid appointing one application as the truth for an entire business domain unless it genuinely creates and controls every material fact in that domain. The more durable design assigns authority at the smallest level that changes the answer. It then exposes those assignments through shared definitions and reliable interfaces.

This approach costs more at the beginning. Teams must settle terminology, map fields, document exceptions, and sometimes change the workflow that creates bad data. The return is not the absence of copies. It is the absence of unowned disagreement.

Start with a decision that conflicting data is already harming#

A single-source-of-truth program should begin where inconsistent answers change an action. “Improve customer data” is too broad. “Stop sending retention offers to accounts that have already cancelled” identifies a decision, a population, a timing need, and a visible failure.

For that decision, write a compact authority record. It should answer these questions:

• What business object and attribute are being decided—for example, subscription status rather than the whole customer record?
• Which action consumes the value, and how fresh must it be for that action?
• Which system may create or approve the value, and which stable identifier joins it to other records?
• Which transformations produce the published value, including effective-date and time-zone rules?
• What happens when a copy disagrees, a value arrives late, or a manual override is requested?
• Who owns the definition, who operates the pipeline, and who resolves a business exception?

The answers should be specific enough that two competent people reach the same result from the same inputs. “Use CRM unless billing looks newer” is not a rule. A workable rule might say that the billing platform controls paid, overdue, and cancelled status; its event time determines when the status took effect; the customer platform receives the status within an agreed interval; and only the billing operations owner may approve a correction. That example is illustrative, not a universal allocation of authority.

Next, define the grain. A total called “customers” can count people, accounts, contracts, or organizations. An order total can refer to orders placed, accepted, fulfilled, invoiced, or not yet returned. A source cannot be authoritative for a metric whose unit and inclusion rules remain unsettled. The definition must also state how late events, deletions, refunds, merges, and reopened records affect earlier results.

Then choose the source closest to the controlled business event, provided it can meet the use. Contract status should normally come from the process authorized to change a contract, not from the dashboard that displays a copy. Product availability should come from the process that records stock-affecting events, not from a sales presentation that refreshes periodically. A curated model can become the approved source for a derived measure, but its authority comes from an accepted definition and reproducible processing—not from being the last table in a pipeline.

Preserve origin and history so the accepted value can be explained#

An authoritative answer without history is brittle. When a number changes, users need to know whether the underlying event changed, a correction was applied, a definition was revised, or a pipeline simply caught up.

This is the practical value of data provenance. NIST describes a data-origin record as information about where data came from and its history, including movement between databases (NIST data provenance glossary). Movement history alone cannot decide which business definition wins, but it can show how the value reached the place where it is being used.

For critical fields and metrics, preserve the original source identifier, source event time, ingestion time, transformation version, and publication or approval state. If corrections are allowed, retain the prior value and the reason for change rather than silently overwriting it. These details answer different questions. Event time says when the business occurrence took effect; ingestion time says when a system learned about it; version identifies the logic applied; approval state distinguishes a provisional output from an accepted one.

Versioning matters especially for derived truth. NIST’s Research Data Framework treats versioning as a way to track changes, revert to earlier revisions, trace data, and correct errors. The same framework places metadata, provenance, curation, access, and quality across a continuing data life cycle rather than treating storage as the finish line (NIST Research Data Framework 2.0). Applying that research framework to business reporting is an adaptation, but the operating lesson is sound: a metric definition that changes without a version creates unexplained history.

I would publish both an effective date and a definition version for any measure used in recurring management reports. If the definition of an active customer changes on July 1, users should be able to tell whether June was recomputed under the new definition or remains on the old one. There is no universally correct choice. The correct choice is the one stated, approved, and applied consistently.

Make copies subordinate without making them useless#

Copies are not the enemy. Operational applications need local data for speed and resilience; analytics systems need historical and combined data; customer-facing products may need a cache. The risk appears when a copy can change independently and no reconciliation path exists.

Every approved copy should therefore carry enough context to remain subordinate to its source: a stable key, the source name, the source or event timestamp, the last synchronization time, and the applicable definition version. Consumers also need a visible freshness promise. A dashboard refreshed nightly should say so; it should not present yesterday’s balance as if it were live.

Conflict handling should be deterministic. Prefer an explicit field-level priority or event rule over whichever record arrived last. “Latest wins” fails when clocks differ, backfills arrive, or an older business event is processed late. Manual overrides should have an owner, a reason, an expiry or review condition, and a record of the superseded value. Otherwise, the exception becomes an invisible second source.

Reconciliation belongs in the normal operation of the data product. Compare authoritative values with important copies, quantify mismatches, and route exceptions to the owner who can correct the originating process. The government guidance recommends fixing quality problems as close to the source as possible and keeping metadata current with the dataset. It also connects metadata with ownership and responsibility throughout the data life cycle (Government Data Quality Framework guidance). Correcting only the reporting layer may improve one chart while leaving every other consumer exposed.

The acceptance threshold should reflect the decision. A missing fax number and an incorrect payment status do not carry the same consequence. Define checks for the critical fields and the named use: allowed values, required completeness, maximum delay, uniqueness of identifiers, and permitted inconsistency. The threshold might be zero for an invalid regulatory identifier yet tolerate a measured delay in a low-risk descriptive field. The framework offers examples of percentages, counts, ratios, and pass-or-fail checks, but it does not prescribe one universal score. The owner must choose the threshold and accept its trade-off.

Technology should enforce the decision, not substitute for it#

A data warehouse, lakehouse, master-data platform, catalog, semantic layer, or API can support a single source of truth. None can decide authority on its own. Buying a consolidation tool before agreeing on definitions usually centralizes the conflict.

Choose technology after the rule is clear. Use the source application’s interface when consumers need a current operational state. Use a curated historical model when the answer combines systems or must reproduce a reporting period. Use a shared metric layer when multiple tools need the same calculation. Use a catalog to publish ownership, definitions, lineage, freshness, and known limits. The architecture may include all four because they solve different parts of the problem.

Avoid forcing every consumer to query the originating application directly. The source may not retain history, support analytical load, or expose the calculation users need. Conversely, avoid calling the warehouse authoritative for facts that can change in an operational system before the next load. Authority and delivery are separate design choices: one component may originate the fact while another distributes an approved, time-bounded representation of it.

The right architecture is the least elaborate one that preserves the rule under real failure conditions. Ask what happens when an event is delayed, a record is merged, a definition changes, an upstream system is unavailable, or a correction must be backdated. If the answer depends on an analyst remembering a private workaround, the organization does not yet have a dependable source of truth.

The finished system makes disagreement visible and resolvable#

Success is not a claim that all company data is now true. It is a narrower, more useful condition: for a critical decision, users know which value to use, what it means, how current it is, where it came from, and who resolves a conflict.

Test the arrangement with concrete disagreements. Present two different subscription statuses and ask the team which wins. Change the event order and ask again. Backdate a correction. Revise a metric definition. Trace a dashboard value to its source and version. A sound design gives repeatable answers and preserves the reason for each change.

Then expand one decision at a time. Prioritize conflicts with meaningful operational, financial, customer, or reporting consequences. Reuse the same authority-record format, identifier standards, version practice, and exception route. Do not promise a finished enterprise truth layer; data uses and systems keep changing, so ownership and quality checks must continue with them.

The central choice is straightforward. Build a single source of truth as a network of explicit authority decisions, not as a slogan attached to a database. The cost is sustained definition work, ownership, and reconciliation. The benefit is that when two systems disagree, the organization no longer asks which screen looks more convincing. It follows a rule that was designed for the decision at hand.