A dashboard can tell you what happened. It can’t tell you why. The obvious fix is to put an AI in front of the data and let people ask. Most enterprises have now tried exactly that. Most are still stuck in pilot.
The reason is rarely accuracy. It’s that nobody downstream can check the work.
A number arrives in a chat window. It’s confident, well-formatted, and plausible. The analyst who would normally have produced it wasn’t involved. The reviewer who has to sign it off can’t see how it was made. So the number gets re-derived by hand before anyone takes it anywhere — and the system that was meant to save a week has added a step to it.
That’s the gap this post is about. Not “can the model answer?” but “can a person accept an answer they didn’t produce?”
The panel underneath the answer
The strongest thing we have to show in Equative Insights OS isn’t the answer. It’s the panel underneath it.
Ask Client IQ a question — say, how a client’s revenue has moved this quarter and what’s driving it — and you get the narrative reply you’d expect. Open the trace, and you get the five stages the question actually passed through. Each one states what it decided, why, and how long it took.
- 1. Intent. What the system understood you to be asking: the entity, the period, the comparison, the grain. This is the stage most systems skip showing, and it's where most wrong answers are born — not in bad arithmetic, but in answering a slightly different question than the one asked. If it read "this quarter" as the quarter-to-date and you meant the last full quarter, you find out here, in one line, before you've argued about the number.
- 2. Resolution. Which defined the measure the question mapped to. Not a column guessed from a table name — a measure from the semantic layer, defined once, with its aggregation rule attached. "Revenue" resolves to the revenue measure the business agreed on, and the trace names it. If two measures could have matched, the trace says which was chosen and why.
- 3. Retrieval. What context was pulled in, and from where. Documents, definitions, prior periods, related entities — listed, not summarised. And critically: the entitlement scope that applied, so it's clear the answer was built only from what the person asking is already cleared to see.
- 4. Computation. The statement that produced the figure. This is the part worth being blunt about: the model does not write it. Arithmetic is executed by deterministic code against defined measures, so the same question produces the same statement and the same number every time. The trace shows the statement, the rows it touched, and any caveat the semantic layer attached — a semi-additive measure that can't be summed across months, a filter that changed the denominator of a ratio.
- 5. Narration. The prose written on top of the computed figure. The model's job here is language and judgement — reading what was meant, and explaining what a number means once it exists. It narrates computed numbers only. It doesn't invent them.
Five stages, each accountable. Not a black box with a disclaimer under it.
Traceability is a product decision, not a compliance afterthought
It’s tempting to treat the audit trail as something you bolt on when procurement asks. That gets the order backwards.
If explainability is added at the end, the only thing you can log is the input and the output — a prompt and a paragraph. That tells the reviewer nothing. It can’t tell them which measure was used, whether the period was read correctly, or whether the system could have retrieved something the asker shouldn’t see. You can log every request and still be unable to answer the one question that matters.
Traceability has to be designed into the shape of the system: discrete stages with defined responsibilities, each one able to report what it did. You get that by deciding early which parts of the work a model is allowed to do. Ours does two things — reads intent, and writes prose about numbers. Everything in between is code, rules and defined measures, precisely because those are the parts that need to be identical on Tuesday and on Thursday.
The trace isn’t the feature. It’s what having a defensible architecture looks like from the outside.
What it changes in the room
Watch what happens in a review when the trace is there.
The conversation stops being about whether to trust the system and starts being about the business. Someone disagrees with a figure, opens the trace, sees that the intent stage read a different entity hierarchy than they had in mind, and rephrases. Ninety seconds, not a ticket. Someone in risk asks not “did it refuse?” but “could it have retrieved that at all?” — and the scope line answers them.
And the number leaves the room. That’s the whole test. A pilot becomes a rollout at the moment a person is willing to put their name on an answer they didn’t compute themselves. Nobody does that on the strength of a confident tone.
Show your working. It’s the oldest rule in analysis, and it’s the one enterprise AI quietly dropped.
