Production Notes #03 · Part of Binary and Beyond. LinkedIn newsletter edition follows.
Every enterprise software programme eventually names its north star.
One source of truth.
One database. One data warehouse. One customer record. One inventory number that every system agrees on, every dashboard reflects, and every executive trusts without asking which system it came from.
The phrase sounds like engineering discipline. It sounds like maturity.
It is usually a wish.
When five systems all claim to be "the truth"
Picture a mid-sized retailer that has done everything the playbook recommends.
The commerce platform holds orders and payments.
The warehouse system holds fulfilment state.
The ERP holds financial records.
The CRM holds the customer relationship.
A cloud data warehouse was added two years ago — explicitly sold as the single source of truth for reporting.
On paper, this is a solved problem. Data flows in nightly batches. A team maintains transformation models. Leadership sees one dashboard.
Then someone asks a simple question in a Monday meeting:
"What is our available inventory for SKU 4471?"
The commerce platform says 142 units — because it subtracts items in open carts using a reservation rule product added last quarter.
The warehouse system says 98 — because it counts only what has passed QC on the dock.
The ERP says 156 — because it includes stock allocated to wholesale orders the warehouse team considers a separate bucket.
The data warehouse says 131 — because yesterday's ETL ran before a large return was processed.
Nobody is lying. Nobody made an obvious mistake. Every number is defensible inside its own boundary.
The meeting does not resolve the disagreement. It assigns an owner to "look into the data quality issue."
That is not a data quality issue.
It is a truth ownership issue dressed in spreadsheet clothing.
Why the myth persists
The single source of truth is seductive for reasons that have little to do with databases.
Executives want cognitive simplicity. Running a business is already an exercise in holding contradictory facts. One number feels like control.
Vendors sell consolidation. Master data management platforms, data lakes, and modern warehouses all borrow the language of unification. The pitch is always some version of: finally, one place where everything agrees.
Engineers want clean boundaries. A shared database or a central event bus feels like an architecture answer to organisational disagreement. If we just route everything through one pipe, the thinking goes, disagreement disappears.
Agencies inherit the brief. Clients arrive with slide decks that already say "single source of truth" in the objectives section. Questioning the premise sounds like scope creep — or worse, like you do not know how enterprise software works.
Production Notes #01 was about what happens when systems hold different versions of reality at the same time.
Production Notes #02 was about how each connection adds another observer with its own timing.
This piece is about the fantasy that you can collapse those observers back into one — and what to do instead.
Truth is not stored. It is negotiated.
Here is the mental model I have come to trust in production:
There is no single source of truth. There are sources of authority — each authoritative for something specific, over a defined period, under stated assumptions.
The commerce platform is authoritative for what the customer was shown and charged at checkout.
The warehouse is authoritative for what is physically pickable right now.
The ERP is authoritative for what finance will recognise in this reporting period.
The CRM is authoritative for what the account team believes about the relationship — including things no transactional system records well.
The data warehouse is authoritative for trend analysis across historical snapshots — not for operational decisions at 2 p.m. on a Tuesday.
When teams treat any one of these as globally true for every question, they are not consolidating data.
They are misassigning authority.
That misassignment is expensive. It produces reconciliation projects, manual spreadsheets, executive dashboards nobody acts on, and support tickets that bounce between teams who each believe their system is correct — because within their boundary, it is.
What "single source of truth" projects actually build
I have watched the same arc play out across ecommerce, B2B services, and government-adjacent platforms.
Phase one: identify the golden record. Usually customer or product. Enthusiasm is high.
Phase two: map fields from six systems into one model. The mapping document becomes a political document. Sales owns status. Finance owns credit terms. Operations owns fulfilment flags. Nobody wants their definition overwritten.
Phase three: build sync jobs, event streams, or nightly merges. Each exception becomes a special case. The golden record grows nullable columns and source_system_override flags.
Phase four: the golden record exists, but teams still check the original systems for anything that matters. The warehouse becomes a fourth opinion, not the first.
Phase five: someone proposes a new single source of truth to replace the one that did not work.
The failure is rarely technical. The failure is treating semantic disagreement as if it were replication lag.
You cannot ETL your way out of two departments meaning different things by the same field name.
Authority beats aggregation
Mature systems do not eliminate multiple versions of reality.
They name which version wins for which decision — and make the boundaries visible to humans and code.
That means:
-
Field-level ownership, not system-level ownership. The ERP owns
invoice_total. The warehouse ownspickable_quantity. The commerce platform ownsdisplay_price. Not "the ERP owns customers." -
Temporal authority. The warehouse is authoritative for fulfilment now. The ERP is authoritative for what was invoiced last month. Conflating those timelines is how dashboards lie calmly.
-
Explicit conflict rules. When two systems disagree, what happens? Last write wins? Human review? Higher-priority source? Silence here is how production incidents become folklore.
-
Disagreement as a first-class state. If finance and operations routinely see different numbers, the architecture should surface that — not hide it behind a blended average in a warehouse table.
This is less glamorous than a data lake keynote.
It is how software survives contact with the business.
The human layer makes it worse
Technical teams are not the only ones who want one truth.
Sales wants the CRM to be right because that is where they work.
Finance wants the ERP to be right because audits care about ledgers, not carts.
Operations wants the warehouse system to be right because pallets do not move themselves when a dashboard disagrees.
Leadership wants the warehouse — the analytics one — to be right because that is what appears in board packs.
Each group is rational. Each group will quietly treat their system as the truth when pressure arrives.
Enterprise software is not only integration between APIs.
It is integration between departments that have never fully agreed on definitions — and may never need to, if the boundaries are honest.
That is why Production Notes #02 noted that organisational integrations fail as often as technical ones. The single source of truth myth is the technical name for an organisational argument postponed.
AI does not dissolve the problem
If anything, AI makes fuzzy ownership more dangerous.
Retrieval-augmented generation pulls from documents, tickets, CRM notes, and warehouse exports — each with its own authority boundary — and synthesises an answer that sounds unified.
The model does not see conflict. It sees context.
When the answer is wrong, teams often reach for better prompts or a larger model.
Sometimes the right fix is humbler: stop asking the model to reconcile sources that have never agreed on what "available inventory" means.
Good AI architecture inherits good data ownership architecture. There is no prompt that replaces a field-level authority matrix.
Questions to ask before the next "golden record" project
I use a short checklist when a client or internal stakeholder asks for a single source of truth — whether the label is MDM, data warehouse, customer 360, or "one dashboard to rule them all."
- Which decisions will this truth support — operational, financial, analytical, or all three?
- For each critical field, which system is authoritative when values conflict?
- Over what time window is that authority valid — real-time, daily, monthly?
- What happens when two authoritative sources disagree during that window — automatic rule or human escalation?
- Who is paged when disagreement persists past the acceptable window?
- Which definitions are genuinely the same across departments — and which only share a column name?
If the answers are vague, you are not scoping a data project.
You are scoping a political consolidation with an ETL budget.
A different standard for "done"
A single source of truth initiative is not done when the pipeline runs.
It is done when a new hire can read a one-page authority map and answer: for this business question, which system's number do I trust — and what do I do if another system disagrees?
Without that map, you do not have one truth.
You have one more place to be confused — with better charts.
The teams I trust in production are not the ones with the cleanest warehouse schema. They are the ones who stopped pretending disagreement was a bug in the data layer — and started designing for bounded authority instead.
Because in enterprise software, the myth is not that data lives in many places.
The myth is that it was ever going to live in only one.
There is no single source of truth. There are only sources of authority — and the discipline to know which one answers which question.
Production Notes #03 · Part of Binary and Beyond. LinkedIn newsletter edition follows. Questions about data ownership in production systems? Start a conversation.