A dashboard that recommends is a colleague who points. Useful once. Expensive forever.
It is the interesting part. It is not the expensive part. Think about what you have actually bought when a system tells you that an order is at risk and should be expedited. You have bought a sentence. Somebody now has to decide whether the sentence is right, find out who can act on it, write the mail, chase the reply, check that the supplier really did move the date, and then go back and tell the system it was right — except there is nowhere to tell it, so nobody does. All the labour survived. It just moved downstream of the screen and out of view. Thirty-six pages out of the two hundred and twenty in our corpus sell some version of getting past pilots and into production. Very few of them describe what happens after the recommendation, which is where pilots actually die.
Five things, and each one is a record rather than a feature. An attempt: the system tried to do this specific thing at this time on this case. A result: the call came back, here is what it said. An outcome verification: an independent check that the intended effect exists in the world — that the purchase order is really in the finance system, that the date really moved, that the document is really filed. A feedback write, so the verified outcome updates shared state and the next prediction is made by a system that knows how the last one turned out. And a compensation path, because some attempts half-succeed and somebody has to unwind them.
Miss the third and you have logs. Miss the fourth and you have a very well-instrumented amnesiac.
No, and this is the single most common failure in the category. A successful call means the other system accepted your message. It does not mean the business effect happened. The message can be accepted into a queue that later rejects it. It can post to the wrong period. It can create a duplicate that a human silently deletes on Thursday. Treating the response code as proof is the software equivalent of counting a letter as delivered because the postbox accepted it.
The clearest peer walkthrough we have read runs an invoice through validation and routing, flags what needs a person, then posts it to the finance system. It is genuinely good — deterministic path, human only at the decision node, a named external system rather than a vague integration. And it stops at the post. There is no step in that story where anything asks the finance system whether the invoice is actually there.
We already walked the loop as an evaluation instrument. That matters here because recommendation dashboards fail the last door the same way.
Verify is missing almost everywhere, including in the best peer walkthroughs, and a loop that ends at a successful call is not closed, it is abandoned politely.
— from Observe → truth → propose → gate → humans decide (the loop as product spine)
Same gap, different product shape: pointing is cheap; confirming is the product.
Three numbers, and they are cheap once the records exist. Verified-outcome rate: of everything the system attempted, how much was independently confirmed to have landed. Not attempted, not succeeded — confirmed. Loop-close latency: how long from attempt to that confirmation, because a loop that closes in eleven days is closed on paper and open in practice. Orphan attempts: things the system started and never resolved either way. That last one is the honest one. Every operations product has orphans and almost none of them count.
Put those three on a page and you have said something falsifiable about your own product, which almost nobody in this market does. Twenty-three of seven hundred and twelve captured screens lead with eval or monitoring chrome — enough to show that measurement is marketable — and almost none of that chrome is a verified-outcome rate.
Keep it, demote it. The recommendation is real work and the model that produced it is not the problem. What is missing underneath is the plumbing: a situation the recommendation attaches to, a gate where somebody accepts or refuses it, an execution that names what it touched, a verification that asks the system of record, and a write back into the state that produced the recommendation in the first place. Add those and the dashboard becomes a view of a loop. Skip them and you can add a model every quarter forever and the same person will still be sprinting between filing cabinets behind the screen.
The tell is in the language, by the way. Products that close the loop describe adapt as a stage. Products that do not describe insights as an outcome.
You're set. Find verify before insights.
