Foundational Chapter 1
The Truth Plane
"Complex systems fail when they forget where truth lives."
— Rick Collette
Abstract
Every system that matters eventually starts lying to itself.
Not on purpose. It just accumulates copies. One in the primary database. One in Redis. One in the search index. One in an analytics warehouse, one projected into a graph, one inside an AI embedding store nobody quite remembers building.
Every copy is useful. Only one is allowed to be true.
This chapter introduces the Truth Plane — the architectural layer responsible for authoritative business facts — and contrasts it with the five planes that derive from it: the Acceleration, Projection, Intelligence, Observation, and Control planes. The argument is developed across the parts of this chapter: this part establishes the problem and the model; the parts that follow take each plane in turn and ground it in systems that were actually built and run in production.
The central thesis is simple, and everything else is a consequence of it:
Intelligence may be derived. Performance may be cached. Search may be projected. AI may infer. Truth must remain singular.
1. The problem
Ask ten engineers where a customer's account balance lives.
One answers PostgreSQL. Another answers Redis, because that is what the hot path reads. A third points at Elasticsearch, because that is where support searches. Finance exports a data warehouse and treats that as the real number at month's end. An AI assistant retrieves an embedding of the customer's recent activity. The frontend keeps a cached copy so the dashboard renders instantly.
Each answer is locally reasonable. Each datastore exists for a good reason: speed, resiliency, reporting, search, recommendation, offline access, analytics, machine learning. The trouble is not that the copies exist. The trouble is that, somewhere along the way, the team stopped being able to say which copy is authoritative — which one the others must agree with, and which ones are merely fast or convenient representations of it.
This is how a distributed system slowly accumulates multiple representations of reality without anyone deciding that it should. No single commit introduces the problem. It arrives as a drift: a value written to the cache "just this once" because the database write was slow; a report that becomes the number leadership trusts; a search index that support treats as gospel because it is what they look at all day. Each step is defensible. Collectively they are corrosive, because the day the copies disagree — and they will — every incident becomes an argument about which datastore is right, conducted under pressure, with no agreed answer.
The premise of this chapter is that the answer must be decided deliberately, in the architecture, before the first line of code is written — and that the cleanest way to decide it is to name the layers of a system by their relationship to truth.
2. Defining the Truth Plane
The Truth Plane is the smallest possible set of systems allowed to answer questions of ownership, identity, authorization, financial state, legal record, and irreversible business fact.
Its contents are the facts a business cannot afford to be wrong or ambiguous about:
- Identity records
- Organization ownership
- Orders
- Payments and settlements
- Tickets and rights ownership
- Membership and access state
- Policy and approval records
- Audit events that constitute the legal record of what happened
Two properties define the Truth Plane, and both are deliberate.
First, it is conservative. Truth changes only through explicit, well-defined business operations — never as a side effect, never implicitly, never as a cache warm-up. This is what makes it trustworthy: an authoritative fact moves only when the business intends it to.
Second, it is small. The Truth Plane is defined by what it excludes. The discipline is to keep the authoritative set as narrow as it can be, because every system admitted into it inherits the obligation to be correct, durable, and consistent — an expensive obligation that most data does not warrant. Everything that can be derived, should be derived, and lives downstream.
That word — downstream — is the organizing idea. The other five planes are all downstream of truth. They are faster, or more queryable, or more insightful, or more legible, or more governed than the Truth Plane — but each is, in the end, a consequence of it, and none is allowed to become a competing source of it.
3. The six planes: a map
This chapter divides a system into six planes, named by their relationship to truth. Only the first owns it; the rest derive from it. The remaining parts of the chapter take each derived plane in turn; what follows here is the map.
flowchart TB
CP{{"Control Plane<br/>identity · policy · approval · kill switches<br/>(enforces; owns nothing)"}}
T[("Truth Plane<br/>identity · ownership · money · rights · audit<br/>ONE authoritative home")]
AP["Acceleration Plane<br/>caches · counters · locks<br/>disposable — rebuilt in ms"]
PP["Projection Plane<br/>indexes · read models · graphs<br/>rebuildable, but expensively"]
IP["Intelligence Plane<br/>recommendations · AI reasoning<br/>provisional — proposes, never disposes"]
OP["Observation Plane<br/>logs · metrics · traces<br/>lossy — explains, never decides"]
T -->|"events, truth-outward"| AP
T -->|"events, truth-outward"| PP
T -->|"events, truth-outward"| IP
T -.->|"described by"| OP
CP -.->|"enforces facts in"| T
CP -.->|"gates"| AP
CP -.->|"gates"| PP
CP -.->|"gates"| IP
Truth Plane. The authoritative layer: identity, ownership, money, rights, access, audit, policy state, legal records, irreversible facts. Exactly one home for each truth. (This part.)
Acceleration Plane. Caches, counters, rate limits, presence, sessions, locks, and ephemeral state — disposable by design. If it vanished, the system would get slower and nothing would become wrong. (Part III.)
Projection Plane. Search indexes, materialized views, CQRS read models, and graph projections — read-optimized views of truth, rebuildable but expensive. They own no facts; every field traces back to truth. (Part IV.)
Intelligence Plane. Recommendations, rankings, embeddings, predictions, and AI reasoning — insight derived from truth and projections. Provisional and non-authoritative: it proposes; it never disposes. (Part V.)
Observation Plane. Logs, metrics, traces, dashboards, telemetry — a lossy account of what the system did, kept to explain and debug. It describes the system without being the record of business fact. (Part VI.)
Control Plane. Identity enforcement, policy, authorization, approval, orchestration, and kill switches — the machinery that governs how the system may behave. It enforces authoritative facts; it does not own them. (Part VII.)
The single rule that runs through all six: one plane owns the truth, and the other five derive from it without ever becoming it.
4. The architectural consequence
The model collapses to one question that every datastore in a system must be able to answer:
Are you authoritative?
If the answer is yes, the datastore is in the Truth Plane, and it inherits the full weight of correctness, durability, and consistency.
If the answer is no, then a second question must have an answer: from what authoritative source can you be rebuilt? A cache rebuilt from truth in milliseconds, a projection rebuilt from truth and events in hours, an index re-derived from a governed corpus — each is legitimate precisely because it can point upstream. The derived plane that cannot answer the second question has quietly become authoritative, and the architecture has acquired a second source of truth without anyone choosing it. Part II calls this "technical debt masquerading as optimization," and finding it is largely a matter of asking these two questions of every store in the system.
This is the whole payoff of the plane model. It does not eliminate the copies — the copies are useful and necessary. It eliminates the ambiguity about which copy is real, by forcing every store to declare its relationship to truth up front.
5. Ampriot: the model in a real system
Ampriot — a relationship-first social and commerce platform for music — is the recurring proof point for this chapter, because it was built around exactly this separation rather than discovering it after an incident.
Its authoritative facts live in MariaDB: identities, organization ownership, orders, rights, settlements, approvals, and audit records. That is the Truth Plane, and it is deliberately the only thing that owns those facts.
Everything else is explicitly downstream, and the platform names it as such:
presence, and disposable cache. Ampriot's own rule states the boundary in one sentence: "Redis is not durable truth. Any queue or lock use must be recoverable by scanning MariaDB." Lose Redis and the platform slows; nothing becomes wrong.
from MariaDB and kept current by events, serving the relationship-shaped questions the relational schema answers poorly.
truth and projections, proposes ranked suggestions, and owns nothing.
written to MariaDB, an event is published, and the derived planes update as a consequence — never the other way around.
subsystem can be gated or stopped without a deploy.
- Redis is the Acceleration Plane — locks, hot queues, leases, rate limits,
- A graph layer is the Projection Plane — a read model of relationships, rebuilt
- A deterministic recommendation engine is the Intelligence Plane — it reads
- NATS JetStream is the event spine that ties the planes together: truth is
- A module registry with kill switches is part of the Control Plane — any
The consequence is the promise this whole chapter is arguing toward, stated as a property of a running system:
Recommendations, analytics, and discovery may degrade. Orders, rights, ownership, and settlements remain correct.
The derived planes are allowed to be slow, stale, imperfect, or briefly unavailable, because none of them owns a fact the business cannot afford to lose. The Truth Plane is allowed to be conservative and small, because everything that needs to be fast, queryable, or smart is someone else's job, derived from it. Ampriot is not correct and fast and intelligent by accident. It is all three because it decided, up front, which single layer is allowed to define reality — and built the other five to serve it.
Where this chapter goes next
Part II examines the most common lie a distributed system tells itself — that "everything is synchronized" — and why the right question is not how do we keep every copy in sync but which copy is allowed to disagree. From there, Parts III through VII take the five derived planes in turn, each grounded in a real system, and the chapter closes by drawing the six back into a single discipline and asking what that discipline demands of the systems we are about to build.