Single source of truth definition
A single source of truth is an information architecture practice in which every piece of information is mastered, meaning created and edited, in exactly one place, while every other system that needs it reads a reference or a controlled copy instead of keeping its own editable version. Applied to content, each headline, price, or legal disclaimer has one authoritative home that everything else resolves back to.
A single source of truth for content means every piece of content is edited in exactly one place, and every website, app, store screen, or AI assistant that uses it resolves back to that place rather than holding a separately edited copy. In Sanity, a disclaimer modeled as its own document and referenced by every product that needs it exists once and resolves everywhere, and a strong reference refuses to let that document be deleted while anything still points at it.
A single source of truth (SSOT) for content is an arrangement where each piece of content has one authoritative home, and every channel that uses it reads a reference back to that home instead of maintaining its own editable duplicate. Wikipedia's definition describes it as structuring information models "such that every data element is mastered (or edited) in only one place," producing data that are "authentic (and authenticatable), relevant, and referable."
The load-bearing word is mastered, not stored. A single source of truth is not a claim about how many databases you run. It is a claim about where editing happens. You can hold content in three systems and still have a single source of truth, as long as only one of them accepts edits and the other two are refreshed from it. You can also hold everything in one system and have no single source of truth at all, because the same return policy has been pasted into four documents that people edit independently.
The practical test is a question about a specific fact, not about your architecture diagram: how many places can this sentence be changed? If the answer is more than one, it is not a single source of truth, whatever the system inventory says.
A single source of truth handles copies in one of three ways, and Wikipedia enumerates them in order of increasing difficulty.
First, no copies at all. Only references are made, so every read and every update goes directly to the master. This is the cleanest arrangement and the one a content reference models directly: the referring document stores a pointer, not a duplicate of the text.
Second, copies exist but are read-only. Only the master is updated, and the copies are refreshed downstream. A search index, a cache, a rendered static site, and a vector index for AI retrieval all sit here. They are derived artifacts with a refresh obligation, not additional sources of truth.
Third, copies are updated too. This requires a reconciliation mechanism for concurrent updates, either discarding copy-side edits until they propagate to the master, or merging concurrent updates with manual intervention as the fallback. This is where most of the cost lives, and it is worth avoiding by design rather than solving with process.
The stated advantages of getting this right are unglamorous and real: it becomes much easier to prevent inconsistencies such as a forgotten duplicate value, and version control is greatly simplified because there is one history to track rather than four.
A single source of truth is architectural, while a single version of the truth is about agreement. The first says there is one master record for each element. The second says everyone is quoting the same number from the same agreed definition. They are not the same thing, and you can have one without the other.
A company can run a perfectly clean single source of truth and still have three teams reporting "active customers" three different ways, because each team applies a different definition to the same underlying records. Conversely, a team can agree completely on what a number means and still maintain four drifting copies of it.
The neighboring terms are worth separating too. Master data management is the discipline and product category for governing shared business entities such as customer, product, and supplier, with stewardship and matching rules. A single source of truth is the principle master data management is trying to achieve, alongside approaches like event sourcing and the data warehouse. A data warehouse is usually a consolidated read copy built for analysis: it can be the source of truth for reporting while not being the master for operations, since nobody edits a customer's address in the warehouse. Direction of flow is what separates them. Single-source publishing is the workflow that uses a single source of truth: as Wikipedia describes it, the expensive editing work "need only be carried out once, on only one document," and that source document can then be reused across web, print, help, and other languages.
A single source of truth is hard for content teams because a perfect version of it is rarely achievable. Wikipedia is blunt about this: "An ideal implementation of SSOT is rarely possible in most enterprises," because organizations run multiple systems that each need data about the same entities, and off-the-shelf products often cannot be modified to read from someone else's master. The realistic goal is one master per element and a defined direction of flow, not one system for everything.
The evidence that this is a live problem comes from operations research rather than content research. Stibo Systems' 2025 report Through the Storm found that only 25% of operations leaders fully trust their data, with 50% citing inconsistent data and siloed platforms as reasons. Miro's 2025 Momentum at Work Report found that 63% of knowledge workers say organizational silos spread information and data across too many tools.
There is a second difficulty that is conceptual rather than technical. A single source of truth presupposes that only one truth exists about a given fact. For content teams, the everyday version of this is locale and audience variation: a German warranty statement and a US warranty statement are not a conflict to be resolved, they are two legitimate facts that need a content model with room for both. Flattening them into one record is not consolidation, it is data loss.
Building a single source of truth for content comes down to four decisions, in this order. Decide which system masters which element, so that "who owns the product description" has one answer rather than a debate. Model each reusable fact as its own entity instead of a repeated string. Replace duplication with references, so reuse points at the original rather than copying it. Then give every derived copy, such as a search index or a cache, an automatic refresh triggered by change rather than a nightly batch.
The reference step is the one that does the most work. In Sanity, relations between documents are modeled with the reference type, stored as a pointer of the form `{"_type": "reference", "_ref": "<document id>"}`. References are strong by default, which means the Content Lake will not allow deletion of a document that something else refers to, and the Studio blocks publishing of the referring document until the referenced one is published. Marking a reference `weak: true` opts out of both, for cases where the target may not exist yet. For the refresh step, Functions run TypeScript handlers on document changes, so downstream copies update when the master does.
Sanity is the Content Operating System for the AI era, and its third pillar is this term exactly: serve content to every channel from a single source of truth. The Content Lake stores documents as structured JSON that is queryable with GROQ and GraphQL, referenceable, and deliverable to websites, apps, and agents from the same authoritative record. The honest boundary is that Sanity is a source of truth for content, not for transactions, inventory, or CRM records. Where it reads from those systems, that is integration, not mastery.
No. A vector index or RAG knowledge base is a derived, lossy copy of content built for retrieval, which puts it in the read-only copy category rather than the master category. It is downstream of the single source of truth and goes stale the moment the source changes without a re-index. Treating the index as authoritative is how an AI assistant confidently quotes last quarter's return policy.
The same caution applies to a headless setup. Decoupling delivery from storage does not by itself make anything authoritative, and content duplicated into an ecommerce platform, an app backend, and a help center has the old problem in newer clothes. A digital asset management system or a product information management system is typically the master for one domain, assets or product attributes, so calling any single tool "the company's source of truth" usually hides the real answer, which is a map of which system masters which element.
When a single master genuinely is not achievable across every source, conflict detection becomes the fallback. Sanity Knowledge Bases, currently in beta, work from the rule that each fact should have one home, and a build detects contradictions across sources, such as a help center saying returns are accepted within 30 days while a product page says 45, then raises an issue showing the claims side by side so a person picks which one is ground truth.
Discover More with Sanity
Now that you've learned about single source of truth, why not start exploring what Sanity has to offer? Dive into our platform and see how it can support your content needs.
Last updated: