What does Explain this do?
Every KPI card on the Dashboard, the product analyst, the inventory analyst and the other surfaces carries a small Explain-this marker. Clicking it sends the card's figure, its date range and its filters to the chat analyst, which calls the same backend tools that produced the card and writes an explanation of what the figure is, what it is made of, and what moved it.
The recomputation is independent in the sense that the analyst does not read the card; it asks the tools. If the two agree, the reader has a second route to the same number. If they disagree, something is wrong with the inputs and the analyst says so, which is the point of having the marker at all.
What is in the trust footer?
Under every chat answer, the trust footer lists the tools that were called to produce the figures in the answer, and for each system those tools read from, how fresh the data is: the store's last sync, the returns platform's last nightly run, the people-counting feed's last hour. A figure in the answer is chipped to the tool that produced it.
The footer is generated from the actual tool calls the analyst made, not from a template. If the analyst answered a question without calling a tool, because it was a question about how the engine works rather than about the store, the footer says no data tools were used.
Why freshness per system matters
The commerce store syncs every fifteen minutes; heavy sources run nightly; inventory updates by webhook in real time. An answer that joins net sales to return reasons is joining a figure from ten minutes ago to one from last night, and the reader should know that. Freshness per system makes the join honest.
It also surfaces problems early. A footer showing the returns source last succeeded three days ago is telling the reader the integration needs attention before the answer is trusted, and the run ledger on the System page shows what went wrong.
How do the two surfaces enforce the second law?
The second law says the AI interprets and never produces a number of its own. A promise like that is easy to make and hard to check, unless the product shows its work. Explain this shows the work for any figure on a card; the trust footer shows the work for any figure in an answer. Between them, there is no number on the platform whose source is hidden.
That is what makes the commerce engine usable for money decisions. A buyer approving a reorder, a CFO reading a margin, an owner signing a win-back list, can each trace the figure they are acting on to a tool and a time.
What to do when the recomputation disagrees
A disagreement between a card and its recomputation almost always points at an input: a cost record that changed, a sync that partially failed, a filter on the card the reader did not notice. The analyst names the tools it called and the filters it used, so the difference can be traced in a minute.
Treat it as the engine catching something. The honest-data promise means the platform would rather show a disagreement than hide one, and the run ledger and the Integrations page are where the cause usually lives.
Does the same rule hold inside the Digital FTE workspaces?
On ftes.ai every proposal a Digital FTE makes carries its evidence: the sources it used, the verdict it reached and why. The Explain-this marker and the trust footer are the engine-side version of the same rule, so a manager questioning a Buyer FTE's reorder from the Approvals tab gets the same kind of answer, with the same kind of footer.
Start by connecting the store and clicking Explain this on the first KPI card you doubt. Watching the recomputation land on the same figure, with its tools listed, is the quickest way to understand why the platform can be trusted with numbers.