Source of Truth
A source of truth is the single, designated place where a specific piece of information is officially maintained and kept current. When copies or summaries disagree, the source of truth wins. The related principle, single source of truth (SSOT), means each piece of information is edited in only one place, and every other document, tool or system refers back to it instead of keeping its own version.
How a Source of Truth Works
The idea comes from information systems: store each data element once, in a master location, and let other systems reference it rather than duplicate it. When a value changes, it changes in one place, and everything that points to it stays consistent.
In product development, the same logic applies to knowledge rather than database rows. A team decides which artifact owns which kind of information, for example:
- Requirements: the PRD or specification owns what the product must do.
- Work items: the backlog owns what is being built and in what order.
- Decisions: a decision log or architecture decision record owns what was decided and why.
- Implemented behavior: the code and its tests own what the product actually does today.
Other artifacts link to these owners instead of restating them. A ticket references the requirement it implements; it does not rewrite the rule in its own words.
A source of truth is a designation, not a tool. It only works if the team agrees where each kind of truth lives and updates it there first.
Why a Source of Truth Matters
Duplicated information drifts. When a rule lives in a PRD, three tickets, a slide and a chat thread, a change reaches some copies and not others. Teams then argue about which version is right, or build from the wrong one without noticing.
The problem grows when AI agents do part of the work. An agent will use whatever version of a requirement is loaded into its context. If several conflicting versions exist, it has no way to know which is current. A clear source of truth gives both people and agents one place to check, and makes requirements traceability possible, because every downstream item can point back to the same origin. In spec-driven development, the specification is explicitly treated as the source of truth that drives what gets built.
Source of Truth Example
A subscription app sets a rule: refunds are allowed within 14 days of purchase. The team records it once, in the requirements document, with an ID. The refund ticket links to that ID, the support macro links to it, and the acceptance tests reference it.
When legal extends the window to 30 days, the product manager updates the requirement. The linked ticket, macro and tests are flagged as affected, and the coding agent that picks up the change loads the current rule from the requirements document. Nobody has to hunt for every place "14 days" was written. Preserving decisions and their reasoning across stages so the source stays trustworthy is covered in cross-stage product memory.
Source of Truth vs. Product Context
Product context is all the knowledge someone needs to make a good product decision. A source of truth is the authoritative home of a specific piece of that knowledge. Healthy product context is assembled from sources of truth rather than from copies.