A CEO wants one number: how many no-shows at the branch that opened two months ago. The question leaves his desk and starts travelling, to the COO, to the rollout lead, to the centre manager. Days pass. What comes back is not a number. It is a negotiation, shaped at every hop by people who are not lying, exactly, but who each hold a private definition of what a no-show is and a target that depends on it.
We have now heard versions of this story from three different industries in a matter of weeks, told by founders, by a manufacturer's leadership, and by the management of a retail group. The pattern underneath is identical, and so is the reason the standard fixes fail. This essay names the problem, walks through the architecture we believe actually solves it, and is honest about the part that is not an engineering problem at all. We also describe where we are with it in our own work, which is early, and what we do not know yet.
The truth problem
Start with the centre manager at the bottom of that relay, where the mechanism is easiest to see. His target is 200 booked meetings. A no-show, reclassified as a reschedule, protects that target, so what counts as a no-show has quietly become his call. Nobody wrote the definition down. In an organisation, a metric without a written definition belongs to whoever reports it, and it will slowly bend toward whatever that person is measured on.
We call this definitional gaming: hitting the target by moving what the target measures. Notice what it does not require. Nobody fabricates a row of data, nobody lies in a way an audit would catch, and the manager may genuinely believe his own classification. The mechanism needs only ambiguity plus an incentive, and every undefined metric in the company supplies the ambiguity. This is why the CEO's question cannot be answered by asking harder. Each hop in the chain re-interprets terms in good-enough faith, and the answer arrives late and pre-flattered.
The organisations we hear this from are not primitive. All three run warehouses, dashboards, and BI teams. One of them put the situation precisely, and we have adopted the phrasing: reports answer "what", while the "why" sits scattered across other systems. We would extend it one step further. The "what" itself is softer than it looks, because the definitions behind every chart still live in people.
Three fixes that don't fix it
More dashboards. A dashboard inherits its definitions from whoever built it. If the underlying terms are contested, the dashboard renders a contested number more legibly, and the centre-manager problem survives the redesign untouched. Dashboards can display truth; they cannot manufacture it.
One blended number. The instinct here is to average across sources until a single figure looks authoritative. Averaging feels rigorous and hides exactly the thing leadership needed to see: that the sources disagree, and where, and by how much. The disagreement is usually the most informative thing in the data, and we will argue below that it should be shown rather than smoothed away.
A language model on the raw tables. The newest instinct, and the one we now push back on most often in scoping conversations. Point an LLM at the warehouse and let leadership ask questions in natural language. The demo is spectacular. The problem is that a model with raw-table access improvises a fresh definition of "no-show" every time someone asks, assembled on the fly from column names and context. That is the centre-manager problem again, automated and running at higher volume.
The architecture of agreed truth
The version we believe in is strict and, frankly, boring. Four layers.
An append-only event store at the bottom. Everything raw, from every source, kept forever: bookings, calendar events, CRM state changes, payment records, message streams. Nothing is edited in place, so the past cannot be quietly revised.
Extraction and normalisation in the middle. Connectors for the structured systems; model-based extraction for the unstructured ones (more on that below). Everything lands as events with provenance attached.
The semantic layer on top. One canonical definition per metric, written down, versioned, owned. In configuration form, the shape looks like this (the metric is real, the format illustrative):
metric: no_show
definition: a booked meeting with no check-in event
within 30 minutes of start time
version: 1.2
owner: COO office
computed_from: bookings + check-in events
never_from: self-report
Answers are computed from the definition, never collected from people. When the definition changes, the version changes, and yesterday's number remains explainable under yesterday's definition. Underneath the metrics sits entity resolution: this chat number, this CRM contact and this payment are the same customer, resolved once, not re-guessed per query.
One door in. Agents and AI clients query the semantic layer, never the raw tables. The model is welcome to be fluent, but only about things the organisation has agreed on. This constraint is what makes the LLM interface safe to give to a CEO: the model has no room left to improvise a definition, and every answer can carry its lineage, definition version included.
Two commitments run through all four layers. The first: prefer machine exhaust over human input. Calendar events, chat timestamps, state changes, payments, all produced as byproducts of work actually happening. Byproduct data has a property that reported data never has: nobody thinks to falsify it, because falsifying it is not how you game your target. The second commitment is the subject of the next section.
Reconciliation is the product
The conventional pipeline treats disagreement between sources as a data-quality embarrassment, to be cleaned before anyone senior sees it. We think that is exactly backwards. Shown side by side, an illustrative read on a single centre:
| source | says |
|---|---|
| bookings system | 100 meetings booked |
| chat analysis | 82 meetings actually happened |
| CRM | 15 marked no-show |
| revenue | ~78 billable sessions |
A blended average would bury the one thing worth knowing here. The four sources cannot all be right under one definition, and the shape of their disagreement points at exactly the numbers being managed. Bookings inflated relative to chat reality suggests padding; CRM no-shows low relative to the booking-to-revenue gap suggests reclassification. The divergence is the finding.
So a leadership question like "how many no-shows" should return the computed answer under the canonical definition, plus how each source voted, plus where they part ways. When three independent sources agree, confidence is high and nobody wastes a meeting on it. When they diverge, that divergence is precisely where management attention should go, which is why we treat the reconciliation view as the product rather than as a debugging screen.
The layer nobody treats as data
The genuinely novel part of this architecture, and the part that makes it more than a metrics store, is the unstructured layer. A centre's WhatsApp group chat is an event stream that nobody treats as one. Cancellations, complaints, staff issues, no-shows mentioned in passing: front-line reality is narrated in those messages every day, hours or days before it appears in any system of record, if it ever does.
The mechanism is a language model classifying each message into typed events, with a timestamp and a confidence score, landing in the same event store as everything else. (This is the "chat analysis" row in the table above.) Soft, ambient, front-line signal becomes queryable next to hard system data, and the reconciliation gets a witness that no one in the reporting chain can pre-flatter. It is also the layer that demands the most care: extraction confidence has to travel with every event, and low-confidence events should widen uncertainty rather than masquerade as facts. We do not consider this part solved anywhere, including by us.
The hard part is nobody's code
The engineering above is tractable. We want to be plain about the part that is not, because pretending otherwise is how these projects die.
A layer like this deletes the information asymmetry that parts of middle management quietly run on. The relay chain in our opening story is a power structure as much as a latency problem, and each hop is a place where somebody currently gets to shape the story before passing it up. Expect resistance. Expect, in the honest version of the plan, attempts to poison data at the entry points once self-report stops being the interface. The design answer is to treat ingestion adversarially from day one: provenance on every answer, lineage on every figure, and human input ranked as the least trusted source in the building. The organisational answer is executive sponsorship that understands what is being changed. Without an owner behind each definition, the layer is the old reporting politics in a new format.
Where this stands for us
The honest answer is: early.
One founder-level build runs today, at GoStudent, where leadership asks questions directly instead of relaying them through four people. A pilot is scoped, not yet shipped, at a vehicle manufacturer: 8 weeks, read-only access against its dealer data, inside the client's own identity and permission system. A retail group with 100 plus points of sale, its own stores growing from 8 toward 15 to 20, is discussing the same shape for store-level visibility. Three industries, one pattern, which is part of why we wrote this up.
The pilot design carries the discipline we argued for above, and one piece of it deserves its own mention: the evaluation gate. Before access widens beyond the first users, the system must answer an evaluation set of 30 to 50 real leadership questions, checked against trusted reports and subject-matter experts. Where answers disagree with the trusted source, the disagreement gets documented and resolved before scale, not after. We size these sets at 20 to 50 questions depending on the engagement. It is the same logic as the reconciliation view, applied to the system itself: prove agreement, surface divergence, then widen.
We also use a maturity ladder to keep scope honest, and we defend staying low on it longer than clients expect:
- Trusted-reporting Q&A. Certified metrics and reports, read-only, every answer tied to its source.
- Cross-source explanation. The "why" behind the KPIs: operational systems, documents, tickets.
- Proactive radar. The system pings leadership when sources diverge, instead of waiting to be asked.
- Assisted execution. Drafted follow-ups and human-approved actions.
Level 3 is the tempting one, and level 4 carries the real risk. Both come deliberately late. Nothing writes back into source systems, no parallel data layer gets built beside the existing warehouse, and the existing BI stack stays the substrate. The fastest way to kill trust in a truth layer is to let it act before the organisation believes what it says.
What we don't know yet
Open questions we are carrying into the pilot, stated so this essay has a falsifiable follow-up. How often do the eval-set answers disagree with trusted reports, and are the disagreements system bugs or genuine definitional conflicts surfaced for the first time? How quickly do entry-point behaviours shift once people know the chat stream is a witness, and does poisoning show up as detectable statistical drift? How far up the ladder should any organisation actually climb? And the measurement we most want: minutes from leadership question to sourced answer, before and after, across a real month. When the pilot produces those numbers, we will publish them.
Try this without us
The first step requires no vendor and roughly an hour. Pick the three numbers your leadership meetings lean on hardest. For each one, write a one-sentence definition, give it a version and an owner, and count the systems that could compute it independently of the person who currently reports it. If a human reports it today, find the machine exhaust that could replace the report. The gap between what you wrote down and what happens today is the honest size of your problem. An hour is usually enough to tell whether it is a tooling problem or a truth problem.
Common questions
Is this the same as the metrics layer in a BI stack? Same family, three differences in emphasis: definitions are versioned with a named owner per metric; disagreement between sources is surfaced as output rather than cleaned away; and AI agents query only this layer, never raw tables. Existing warehouses and BI tools stay in place.
How long does a first version take? The pilot shape we run is 8 weeks against one data domain: read-only access, canonical definitions for the first metrics, and an evaluation set of 30 to 50 real leadership questions checked against trusted reports before access widens.
Does leadership need to learn a new tool? No. The layer is exposed through AI clients a leadership team already uses, such as Copilot or Claude, through a controlled gateway. The interface is a question in plain language; the layer decides what the model is allowed to compute from.
Palantir named itself after Tolkien's seeing-stones, a sphere that shows the whole world to whoever holds it. Companies keep shopping for the sphere. What they need is an agreement about what a no-show is, written down, versioned, and computed from data nobody bothers to fake. The stone, it turns out, is a dictionary.
If this problem looks like yours, we should talk.