What a single source of truth really means (and what it doesn't)

The phrase "single source of truth" is everywhere in business software. What it actually requires, the common misunderstandings, and how to move toward one without a big-bang migration.

“We need a single source of truth” might be the most common sentence in business software conversations. It’s also one of the most misunderstood. It doesn’t mean one enormous database, and it doesn’t mean throwing out every other tool. It means something narrower and more achievable.

A working definition

A single source of truth means that for each piece of information, everyone agrees on one authoritative place to find it and one authoritative definition of what it means.

Two parts, both necessary:

  1. One authoritative location. When a customer’s address and the spreadsheet disagree, there’s no debate about which one is right.
  2. One authoritative definition. Everyone means the same thing by “address”, “active customer” or “completed job”.

What it doesn’t mean

It doesn’t mean one tool for everything. Your accounting package can stay your source of truth for invoices while another system holds customer and property data. What matters is that each kind of information has one home.

It doesn’t mean no copies. Information can be displayed, cached or synced elsewhere, as long as everyone knows which copy wins.

It doesn’t mean perfect data. A source of truth can contain mistakes. The point is that when you fix one, you fix it in the place everyone relies on.

Why it’s hard

Most organizations don’t lose their single source of truth; they never had one. Information arrives through whatever channel is convenient — an email, a paper form, a web form, a phone call — and lands wherever the person handling it works. Over time each channel grows its own copy. Nobody decided to have five versions of a customer list; it just happened.

Definitions drift the same way. Two forms ask for an address slightly differently. A report counts “active” customers differently from the dashboard. Each difference is small, and together they make every number arguable.

How to move toward one

You don’t need a big-bang migration. A practical sequence:

  1. Pick the information that causes the most arguments. Usually customers, locations or open work.
  2. Decide where it lives. Choose one system as authoritative for it, and say so out loud.
  3. Define it. Write down what fields it has, which are required, and what they mean.
  4. Route new information there first. Point intake forms at the authoritative system so new data starts in the right place.
  5. Retire or downgrade the copies. Make old spreadsheets read-only, or remove them.
  6. Connect other systems by identifier. Where information must also live elsewhere, store a shared ID so records can be matched exactly.
  7. Repeat for the next kind of information.

Signs it’s working

  • Meetings stop starting with “which numbers are these?”
  • New team members are told where to look, not who to ask.
  • A correction made once shows up everywhere it should.
  • Reports and dashboards agree, because they read the same definitions.

Choosing the authoritative system

When two systems both hold the same information, pick the authoritative one with these questions:

  1. Where is it created? The system where information first enters is often the natural home.
  2. Where is it maintained? The team that keeps it current should work in the authoritative system.
  3. Which system enforces structure? A system with types, formats and required rules protects the definition.
  4. Which system can others read from? If other tools need the data, an authoritative system with an API is far easier to build around.

Write the decision down. “Customer contact details live in X” is a sentence every team member should be able to repeat.

Handling copies you can’t avoid

Some copies are unavoidable — a marketing tool needs email addresses, an accounting package needs billing details. Manage them deliberately:

  • Copy in one direction only, from the authoritative system outward.
  • Match on a shared identifier, not on names.
  • Make corrections in the authoritative system, and let them flow out.
  • Document which copies exist, so nobody wonders why two lists differ.

An exercise: the disagreement audit

For two weeks, note every time two sources disagree about a fact — a wrong address, a different total, a stale status. For each, record which sources were involved and which turned out to be right.

Two weeks is usually enough to reveal the pattern: a handful of information types, and one or two systems, cause most disagreements. That’s your consolidation shortlist, based on evidence rather than intuition.

What it takes to keep

A single source of truth degrades unless it’s maintained:

  • Someone owns each kind of information and resolves conflicts.
  • New tools are checked against the question “does this create another copy?”
  • Definitions are versioned so changes are deliberate and old data keeps its meaning.
  • Intake routes into the authoritative system rather than around it.

Frequently asked questions

Is a data warehouse a single source of truth? A warehouse is usually a single place for analysis, fed by operational systems. It doesn’t replace deciding where each fact is authored and maintained.

What if two teams genuinely need different definitions? Then name them differently. Two clearly named measures are better than one ambiguous one.

Can a spreadsheet be a source of truth? For a while, for a small team. It struggles as soon as several people edit it, structure matters, or other systems need to read from it.

Definitions are the underrated half

Most efforts focus on location — moving data into one system — and neglect definition. But a single system full of inconsistently defined data is still arguable. The most durable fix is to define reusable pieces of information once, and build every form and record from those definitions.

That’s the approach Stratosphere Atlas takes with data schemas: a field group like Service Address is defined once, versioned when it changes, and reused by every form and record that needs it. For more on the location half, see One home for business data.

Ready to build your business graph?

Start with reusable schemas today. Scale into enterprise APIs when you need them.