Keeping one source of truth

REQUIRED BACKGROUND: the principal-engineering skill.

Overview

Every fact about the system lives in exactly one place, and every other part of the system reads it from there. This outranks convenience: a second copy is a future contradiction, and the copy that drifts is always the one nobody remembers exists. When two places can hold the same truth they will eventually disagree, and the system then looks healthy while serving wrong data.

The doctrine

1. Before adding data, find who already owns it. Extend that owner; do not start a rival. Finding the owner is cheaper than the incident two owners eventually cause.
2. Derive rather than store. If the platform or an existing source can answer it at read time, read it there; do not copy the answer into a second source where it can go stale.
3. Absorb duplicates you find on the way. When you touch code that hardcodes what a file already knows (or the reverse), fold the two together as part of the work instead of leaving a third variant behind.
4. A missing entry fails loud (see handling-failures): the single source is only authoritative if absence from it is an error, never a silent default.
5. Mark generated versus hand-edited, and never edit generated output. Every artifact states which it is; edits to derived files are lost work plus a divergence.
6. Vocabulary is typed, not stringly. Identifiers, kinds, states, and names that code branches on are constants, enums, sealed types, or registry entries; a free string spelled twice is two sources of truth with a typo between them.
7. When two sources disagree, say so. One of them is stale. Surfacing the contradiction is the first fix. The full fix determines which value is live, collapses to one source, and deletes the loser. Silently following either one launders the disagreement into whichever answer you happened to read first. On a declared critical path, a live disagreement earns a direct message to the owner, not only a tracked item; an unread ticket surfaces nothing.

Boundaries