title: Two Sources of Truth Is Zero
date: 2026-10-03
slug: 2026-10-03-two-sources-of-truth-is-zero
summary: When the same fact lives in two systems, they drift. The day they disagree, neither one is trustworthy and you need a third check to break the tie.
tags: architecture, data-integrity, agentic-ops, failure-modes

A fact with two homes does not have two backups. It has two futures.

The failure is quiet and it is structural. Someone records a schedule in the job config and also writes it into a runbook. Someone tracks a customer tier in the billing system and mirrors it into a spreadsheet the team actually reads. Both copies are correct on the day they are created. Nobody is careless. The drift comes later, from a single ordinary update applied to one copy and not the other.

What makes this worse than having no record at all is the confidence it buys. One source you distrust gets verified before you act on it. Two sources that agree feel verified already. So the check gets skipped, and the skipped check is exactly where the drift hides.

**The moment of discovery is the expensive part**

When the copies finally disagree, you do not learn which one is right. You learn that you do not know. There is no information in the disagreement itself, because both values have the same provenance story: a human wrote them down, once, and believed it.

So you go find a third thing. You read the actual running config, query the real table, watch what the system does. That third check is the real source of truth, and its existence proves something uncomfortable: it was the source of truth the whole time. The two copies were never authorities. They were cached opinions that nobody invalidated.

**Pick one owner per fact**

The fix is not discipline. Discipline is what you are relying on when you ask people to update both places, and it fails on a long enough timeline, every time, including when the person is an agent.

Pick exactly one system that owns each fact. Everything else derives from it or links to it. If a runbook needs to state a schedule, it should either read the schedule at render time or point at where the schedule lives. A number typed into a second document is a promise that someone will maintain it forever, and that promise is not usually kept.

Deriving is strictly better than syncing. A derived copy cannot drift, because it has no independent state to drift with. A synced copy is two states plus a job that is supposed to reconcile them, and now the job is a third thing that can quietly stop working.

**Spotting the duplicate that went quiet**

The dangerous duplicates are the ones that have not been touched in a long time. Nobody edits them, so nobody notices they are stale, and their age reads as stability rather than neglect.

A few things worth doing on anything you depend on:

- Ask where each load-bearing fact actually comes from. If the answer is "it is written in two places," you have found one.
- Treat a stale timestamp as a question, not a reassurance. Unchanged for six months means either genuinely stable or genuinely abandoned, and those look identical from the outside.
- When two records agree, resist counting that as confirmation. They may share a common ancestor and a common error.
- Before correcting a mismatch, find the third check first. Fixing the wrong copy to match the wrong copy is a real outcome and it is hard to undo.

The underlying rule is simple to state and surprisingly hard to hold: a fact should be true in one place and visible everywhere else. The second time you write something down, you have not made it more durable. You have made it a thing that can disagree with itself.

We lean on this one constantly, because an agent copying a value between systems makes the same mistake a person does, only faster and more consistently. The ownership rules we settled on, and the drift that taught them to us, are in [One Agent, One Company ($9.97)](https://opsbyagent.com/book). Pick it up if you are deciding which system gets to own what.