Single Source of Truth:
Definition, Examples, and Setup

A single source of truth (SSOT) is the agreed authoritative reference for a defined body of information. It establishes which version people and applications should use. IBM describes it as a design principle for making authoritative data available through a central repository.

What does single source of truth mean?#

The term also applies to documentation. GitLab’s handbook guidance directs contributors to keep content in one system and link to it rather than repeat it elsewhere. Related pages can reference the same maintained information without becoming separate places to edit it.

Taken together, these uses suggest a common principle: one recognized authority for the information in scope. For implementation, specify what that information covers, where it is maintained, who can approve changes, and how other users access the accepted version.

The immediate benefit is less repeated maintenance: GitLab explains that duplicated content requires updates in multiple places and tracking the copies that have become outdated. Its handbook structure also gives each item a location and an owner.

Single source of truth and related terms#

These terms describe different parts of a data arrangement:

IBM’s distinction separates the system that holds authoritative records from the broader SSOT design practice. When documenting an implementation, identify both the originating system and the approved reference exposed to consumers.

Can a single source of truth have multiple copies?#

An authoritative source can coexist with derived copies. In Microsoft’s event-sourcing architecture, the event store holds the authoritative history, while separate, read-only materialized views serve queries. A materialized view is a stored representation calculated from that source.

The same documentation explains that snapshots can be regenerated from the authoritative event stream. It also notes that read views can lag behind the source because updates propagate asynchronously. One authority therefore does not necessarily mean one physical storage location or an immediately updated copy everywhere.

This is a documented architecture example, not a requirement to adopt event sourcing. Microsoft cautions that the pattern adds substantial complexity and that traditional data management is sufficient for most systems. Select the implementation according to the required access, freshness, and history.

How to establish a single source of truth#

1. Define the information and its intended use#

Start by selecting the data whose disagreement matters most. The Government Data Quality Framework guidance recommends identifying critical datasets and the fields or tables with the greatest effect on their users.

Document the entity or metric, its definition, identifiers, reporting period, and required update frequency. For a calculated measure, also specify the formula and inclusion rules. These are recommended implementation details for making the scope explicit.

The framework defines data quality as fitness for purpose and recognizes that data is unlikely to suit every use equally. Set the quality and freshness requirements for the stated use before choosing its authoritative reference.

2. Assign authority and responsibility#

Name the approved source for each critical field or dataset, the owner responsible for its meaning, and the process for approving corrections. Include the route by which users report disputed values. Record these decisions alongside the information they govern.

This applies GitLab’s practice of assigning content a location and owner and the government framework’s emphasis on accountability for data quality. For structured records, define authority at the attribute level wherever the selection rules differ between attributes.

3. Specify how conflicting values are resolved#

IBM’s MDM 2.4 release explanation describes survivorship: choosing which contributing attribute values become part of a master record. It documents selection using source, frequency, last-update date, value priority, and conditional sorting rules.

Use that range of approaches to define an explicit rule for each relevant attribute. State the priority of sources, the quality requirements for a candidate value, how ties are resolved, and when a disputed record requires review. Apply the rule consistently and retain the reason for the selection.

Define recency precisely. Specify whether it means the source update time, the business event’s effective time, or arrival in a downstream copy. Document the selected timestamp and its interpretation.

For one concrete technical limitation, Microsoft warns that SQL Server’s last-writer-wins peer-to-peer replication depends on synchronized node clocks. Clock differences can produce an unintended winner. For timestamp-based selection, document the clock assumptions and verify them against the chosen system’s behavior.

4. Preserve provenance and change history#

Provenance explains how information was produced. The W3C’s PROV overview describes it in terms of the data, activities, and people involved in production, and supports representing derivation, versioning, and reproducibility.

A practical adaptation is to retain the source record identifier, relevant timestamps, transformation version, and correction history. For derived data, record the inputs and processing steps needed to explain the output. For approved corrections, retain who authorized the change and its reason.

Treat these fields as an implementation recommendation based on provenance principles. They provide a way to distinguish a changed input, a revised calculation, and a correction when investigating a changed value.

5. Check quality and maintain downstream access#

Define measurable checks for the selected data. The government framework’s quality dimensions cover completeness, uniqueness, consistency, timeliness, validity, and accuracy. Translate them into checks for required fields, duplicate identifiers, conflicting values, update delays, allowed formats, and correspondence with the underlying facts.

Establish a baseline and repeat the measurements. The supporting guidance recommends recurring assessments and metadata updated with the data. Publish the source, definition, update frequency, and known limitations where consumers obtain the information.

For downstream copies, add reconciliation checks against the approved source and route discrepancies to the responsible owner. Investigate their origin: the government guidance recommends fixing quality problems as close to the source as possible, while checking suitability for both the original and subsequent uses.

A practical authority record#

The following suggested template translates the authority, quality, and provenance guidance above into implementation questions:

Keeping the source reliable#

Authority and accuracy need separate checks. The government framework defines consistency as agreement between values and accuracy as correspondence with reality. From that distinction, matching copies alone cannot establish that the shared value is correct.

Maintain the source through documented changes, quality measurements, and corrections. The government guidance calls for continued monitoring and current metadata; use those practices to keep the accepted reference understandable as its data and uses change.