The number moved at nine. By ten, leadership had an explanation.
It came from the AI assistant built into the dashboard. It was clear, well argued, and backed by a chart. A senior leader read it and asked for a fix by Friday.
The explanation was wrong, although it did not look wrong at all.
Explanations got cheap
Some years ago, an explanation like that cost an analyst days of work. So there were few explanations, and each one was usually checked before it reached a senior meeting. The cost acted as a filter. It was not perfect, but it was real.
That filter is gone. A language model can produce a fluent analysis of why a number moved in seconds, in the voice of a senior analyst. It will do this even when the data does not support the story. Fluency is what these models do best.
An old gate stopped working. A well written explanation used to mean that someone had done the work. Now it means very little. A system that explains without testing is an articulate guesser, and a guess about a cause does the most damage, because people act on it.
When explanations cost nothing, sounding right is no longer evidence of being right.
A wrong cause costs twice
The first cost is the visible one. Money, time and goodwill go into a remedy aimed at the wrong target, and the remedy often has side effects of its own.
The second cost is quieter. The real problem keeps running, and it gets older. The next meeting argues about why the fix failed, not about the cause.
The cause went unquestioned. It got its budget, and the problem stayed.
Three tests a cause has to pass
In the R.E.C.U.R.S.E. framework, this work belongs to the Reasoning layer, and it starts at Correlate. Standard analytics asks which story fits the chart. Correlate asks which story survives three plain tests.
Timing. Did the suspected cause come first, and does the gap make sense? Effects trail their causes, sometimes by days and sometimes by months. A cause that appears after the effect began is not the cause. A cause that appears long before it needs a mechanism that explains the delay.
Exposure. Is the effect limited to the places the cause could reach? A cause touches some customers, products, or regions and leaves the rest alone. The ones it touched should change. The ones it left alone should not. An effect that also shows up outside that reach is not explained by this cause alone. An effect that fills only part of the reach points to something narrower.
Footprint. What else would be true if this explanation were right? A real cause rarely leaves just one mark. List the other marks it should have left, then check whether the data shows them. Missing marks weaken the story. Marks that point the other way end it, however well it reads.
Footprint is where fluent systems tend to fail. They explain the fact in front of them and rarely look at the facts the explanation implies.
The cause often sits outside your view
The person who owns a metric sees the metric. The cause often sits somewhere else. It is a change made by someone with no reason to think it mattered here: a release, a supplier switch, a new process, even a new definition of the metric itself.
A system that reads only the owner's data has the same blind spot. It keeps finding explanations inside the owner's domain, because that is the only place it can look.
The fix is a wider map. Correlate connects the metric to the changes around it: what was released, switched, or redefined, when it happened, and what it touches.
For the builders reading: this is a causal map, a graph of entities and events, the dependencies between them, and the time each one happened. Correlation over metrics shows what moved together. A causal map lets the system ask what could have moved what. It can only reason about changes it has seen, so the change records of other functions belong on the map, including the ones kept in other departments' tools.
One honest limit. Observed data rarely proves a cause on its own. Correlate removes the stories that fail the three tests, ranks the ones that remain, and says what evidence would settle the question.
Hold more than one story
The next stage is Understand, and its rule is simple: do not settle on one answer early. The system keeps several explanations alive, ranks them, and attaches a confidence level to each, along with the evidence that would change the ranking.
The first summary offered one cause and no doubt. A reasoning system offers a ranked list. The explanation that sounded best often ranks low. The one at the top is often less dramatic, and often sits outside the view of whoever asked.
The output is a Situation Model: the ranked explanations, the confidence in each, what is known, what is uncertain, and what is still unknown. It also names the cheapest check that would separate the leading explanations. That check is often small. Where a suspected change can be reversed, reverse it for a slice of the population and compare. If the effect moves with it, the case for that cause becomes strong, and the remedy is often far cheaper than the one the first story called for.
A chain, not a verdict
In the framework, a person validates the Situation Model before the system builds anything on it. Here is why that gate works.
A verdict names a cause and stops. A person can accept it or reject it, and rejecting a confident, well written summary takes more nerve than accepting it.
A chain shows how it reached the cause: what changed and when, what that change touched, what moved after it, what does not fit, and how sure the system is at each link. A person can point at one link and say that part is wrong. The system reworks from there, and the rest of the chain stands.
That correction does not disappear. It becomes a signal Evolve can learn from. A rejected verdict teaches a system very little. A corrected link shows it where it was weak.
A verdict can only be accepted or rejected. A chain can be corrected.
Three questions for any AI explanation
You do not need to read the architecture to test this. Next time a system explains why a number moved, ask it three things.
- What else did you consider, and why did it rank lower?
- What would we see in the data if you were wrong?
- What has changed since the last time I asked?
A system that reasons can answer all three. It holds the rival explanations, it knows what would count against its top one, and its answer changes only when the evidence does. A system that guesses tends to hand you a new confident story each time.
Back to the first hour
Go back to the explanation that arrived by ten. It was fluent and confident, and it reached a decision maker without passing a single test.
A reasoning system could have delivered its answer in almost the same hour. The difference is not speed. It is what the system has to show before anyone acts: the timing, the exposure, the footprint, and how sure it is.
Fast was not the problem. Unchecked was.