Single Source of Truth: The Board Mirrors Reality, the Ledger Is Reality
Pick one authoritative store for every fact in your business, and treat every other screen as a copy that can lie to you.
A row in your CRM that says "paid" is not a payment. It's a note somebody, or something, wrote down after a payment maybe happened. The money lives in the payment processor. The customer's actual words live in the mailbox. Everything else is a photograph of those two things, taken at some point in the past, and photographs go stale.
I learned this the boring way: acting on a board that was confidently wrong.
In this post:
- Why the "one place to see everything" dashboard quietly becomes the least trustworthy screen you own
- The mechanism: authoritative stores, projections, and what a cache actually is
- How I run it in my own back office, including the one command I run before anyone acts
- Where this idea costs more than it's worth
1. Why it breaks
Every small business that gets a little organized ends up building a board. Kanban columns, a spreadsheet with color coding, a CRM with custom fields, doesn't matter. The board feels like the business. You look at the board in the morning and you decide what happens that day.
Then the board starts collecting facts it has no business owning.
Payment status. Whether the customer replied. Whether a document went out. What the balance is. None of those facts are born on the board. They're born somewhere else: in a processor, in an inbox, in a filing system, in somebody's phone. The board learned about them secondhand, from a webhook that fired, or from a human who typed it in between two other tasks, or from an automation that ran at 6am and hasn't run since.
And here's the failure mode that bites: the board is more convenient than the truth. It's one screen. It's sorted. It has the colors. So people, including me, start reading it as if it were the ledger instead of a report about the ledger. Nobody decides to do that. It just happens, because checking two systems takes forty seconds longer than checking one, and forty seconds times a hundred cases a week is a real tax.
The bill comes due in specific, embarrassing ways. You chase a customer who already paid. You skip a customer who didn't. You send a second copy of something that already landed. You tell somebody their thing is handled and it isn't, because the status field got flipped by a step that succeeded and then a later step that quietly failed. I'm not the type to blame the tool for that. The tool did what I built it to do. I built it to store a fact twice and I never said which copy wins.
That's the whole bug. Two copies of one fact and no rule about which one is real.
Common practice I'll push back on, gently: people spend enormous energy making their dashboard prettier and almost none deciding what their dashboard is allowed to know first. The pretty dashboard with unowned facts is a liability. A plain board that's honest about being a mirror is an asset.
2. The mechanism
The idea has a real name and a boring definition. Single source of truth is the practice of structuring your information so every data element is mastered in exactly one place, and every other place that shows that element references it or copies it, but never owns it. Copies are allowed. Copies with authority are not.
So for each fact, you answer three questions:
- Who owns it? One system. Not two. Not "usually the processor but sometimes we override."
- Who projects it? Everything else that displays it. Projections are read models. They can be rebuilt from the owner at any time.
- What happens on disagreement? The owner wins, automatically, no discussion, and the projection gets corrected.
That third question is the one people skip, and it's the one that matters. If you can't state the tiebreak rule out loud, you don't have a source of truth, you have two opinions.
AUTHORITATIVE STORES (reality) PROJECTIONS (mirrors)
------------------------------ ---------------------
+----------------------+
| PAYMENT PROCESSOR | owns: amount, paid/unpaid,
| | refund, timestamp
+----------+-----------+
|
| read
v
+----------------------+ +---------------------+
| MAILBOX | owns: what the | CASE BOARD |
| | customer | |
| | actually said, | shows: status chip |
+----------+-----------+ when they said | balance |
| it | last reply |
| read | |
v | owns: NOTHING |
+----------------------+ +----------+----------+
| FIELD RECORD | owns: what ^
| | happened on site, |
| | when, by whom | rebuild
+----------+-----------+ | (board can be
| | thrown away and
+------------------------------------------+ regenerated)
DISAGREEMENT RULE: processor/mailbox/field record win.
Board is wrong BY DEFINITION.
Look at the "owns: NOTHING" line on the board, and the arrow direction. Every arrow points out of reality and into the mirror. There is no arrow going the other way.
The word I keep coming back to is cache. A cache is a fast copy of slow truth. Caches are great. Caches are also the source of an entire genre of bug, and every one of those bugs traces back to somebody forgetting the copy was a copy. Your CRM row is a cache. Your Kanban chip is a cache. Your morning summary email is a cache. Treat them with the respect you'd give any cache: cheap to invalidate, cheap to rebuild, never authoritative.
Which leads to a test I like. Can you delete it and regenerate it? If you nuked your board tonight, could you rebuild it tomorrow from the processor, the mailbox, and your field records? If yes, it's a projection and you're fine. If no, if some fact only exists on the board and nowhere else, then congratulations, your board is now an authoritative store and you didn't mean for it to be. That fact needs a real home.
Sometimes the answer is that the board should own something. Internal priority, an assignment, a note to self. Fine. Own it deliberately, write it down, and make sure it's backed up like the real thing it now is. The sin isn't owning data. The sin is owning it by accident.
3. How I run it
In my own back office, the case board is a mirror. That's not a philosophy, it's a rule I can point at. The payment processor and the mailbox are reality. When the two disagree, the board is wrong by definition. Not "we investigate." Not "it depends on who updated it last." The board is wrong. Fix the board.
Saying it that way sounds obvious. It wasn't obvious to me until I'd been burned, and it changed how I build.
The snapshot command
The practical piece: I have one snapshot command that pulls all three sources for a case before anyone acts on it. Processor, mailbox, field record. One call, one output, all three at once. Nobody sends a follow-up, nobody makes a call, nobody moves a case forward off the board chip alone.
Why? Because a fact from one source alone has burned me before. That's the entire origin story. One source looked right, the decision followed the source, the source was stale, and the customer got a message that made me look like I wasn't paying attention. I hate that feeling more than I hate writing the extra code.
So the snapshot exists to make the honest path the cheap path. That's the actual design goal, and I'd argue it's the design goal of most good internal tooling. If checking three sources takes three logins and two browser tabs, people will check one source. Not because they're lazy, because they've got twelve other things going and the board is right there. If checking three sources is one command that returns in a second, people check three sources. Behavior follows friction, always.
What that changes downstream
Once you accept the board is a mirror, a bunch of other decisions get simpler.
Status fields stop being state machines. A status chip on my board isn't a thing I set, it's a thing that gets computed from the sources. Paid means the processor says paid. Waiting on customer means the mailbox says the last message came from me. Nobody hand-flips a chip and hopes.
Reconciliation becomes a routine, not an incident. If the board can be rebuilt from reality, then re-reading reality and correcting the board is a normal thing that runs on its own, not a fire drill you do when a customer calls confused. Drift is expected. Drift is fine. Undetected drift is the problem.
Follow-up gets safer. This is where the money is for a small operator, honestly. Follow-up is the highest-leverage thing in a service business and also the easiest thing to get wrong in a way that costs you the customer. Every automated nudge I send is gated on a fresh read, because a follow-up sent against a stale fact isn't a neutral mistake, it's a message that tells somebody you don't have your act together. I'd rather send fewer and have them all be correct.
The phone assistant reads, it doesn't remember. Same rule. When somebody calls in and asks where things stand, the answer comes from a fresh look at the sources, not from a cached summary that was true last Tuesday. Slightly slower. Enormously less embarrassing.
The habit I'd transfer
If I were handing one practice to another small operator, it's this: sit down with your board, go field by field, and write the owner next to each one. Actually write it. Field name, owning system, tiebreak rule. It takes an afternoon and it will surface at least two fields that nobody owns, which is to say two fields your business has been quietly guessing about.
Then build the snapshot. Even a crude one. Even a script that prints three blocks of text in a terminal. The point isn't elegance, the point is that the honest read costs less than the lazy read.
4. Tradeoffs
This discipline costs latency and it costs code, and both of those are real. Reading three sources before every action is slower than reading one field, and if you're running high-volume operations where a hundred milliseconds matters, you'll need to cache deliberately with an explicit expiry rather than reading through every time, which means you're back to managing a cache, just an honest one. It also adds surface area: three integrations to maintain, three sets of credentials, three APIs that can rate-limit you or change under your feet, and if any of them is down your snapshot degrades and you need to decide whether to block or proceed with a warning. And if your business is small enough that one person touches every case and holds it all in their head, this whole apparatus is overhead you don't need yet, because the human is the reconciliation layer and they're doing fine. I'd skip it entirely for a genuinely tiny operation, and I'd skip it for facts that nobody makes decisions on, like an internal tag or a cosmetic label. Build the source-of-truth discipline where a wrong fact produces a wrong action that touches a customer or touches money. Everywhere else, let the copy be a little stale and get on with your day.
Takeaway
- Name one owning system for every fact that drives an action, and write the tiebreak rule down where your team can read it.
- Test each screen by asking whether you could delete it and rebuild it from the owners; if you can't, something on it is secretly authoritative.
- Make the multi-source read one command, so the correct path is also the fast path.
One line: your board is a cache, and a cache that thinks it's the ledger will eventually tell your customer something that isn't true.
Jesse