Dashboards, predictions and decision systems

Three things, one word

"We need better data for this decision" is one of the most common sentences in an operations review, and it usually leads to one of three very different projects. They get discussed as though they are the same thing. They are not, and picking the wrong one is expensive.

Most organisations already have the first two. The gap between them and an actual decision is not a data problem, and adding more data will not close it.

Why dashboards stop short

A dashboard answers "what is happening?" It is a reporting surface, and reporting surfaces are genuinely valuable. But they place the entire analytical burden on whoever is looking at them.

The person has to hold the objective in their head, apply the constraints from memory, mentally rank the options, and decide. Ten people looking at the same dashboard will reach different conclusions, and none of those conclusions will be written down anywhere.

That inconsistency is invisible, which is why it persists. Nobody sees the distribution of decisions, only their own.

Why predictions stop short

A prediction answers "what will happen?" This feels much closer to a decision, and it is where a great deal of machine learning effort goes.

But a forecast is an input, not an output. Knowing that a customer has a 70% churn probability does not tell you whether to call them, discount for them, escalate them, or leave them alone — and it certainly does not tell you what that action costs, what it risks, or whether you have the capacity to do it for all 4,000 customers scoring above 60%.

The prediction is silent on every question that determines what to actually do.

What a decision system adds

A decision system answers "what should we do, and why?" It differs from the other two in that it needs three things stated explicitly, and those three things are usually where the project gets difficult:

• The objective. What is being optimised for. Not "improve outcomes" — something a system could rank two options against.
• The constraints. What must never happen, regardless of how good the numbers look. Risk ceilings, capacity limits, regulatory prohibitions.
• The decision owner. The named person who accepts or rejects the ranking and is accountable for the result.

If an organisation cannot agree on the objective, no amount of engineering will resolve that. The system will simply encode the disagreement and make it operational.

The ten components

A working decision system tends to contain all of these. A system missing the last two will look impressive and quietly stop being trustworthy.

1. Data ingestion — reaching the sources that bear on the decision, at the cadence they actually update.
2. Context construction — assembling one coherent picture per decision, rather than several partial views.
3. Option generation — producing the realistic candidates, including the option of doing nothing.
4. Ranking — ordering candidates against the stated objective, so the output is a comparison rather than an answer.
5. Scenario evaluation — showing how each option behaves under different conditions. This is what makes risk discussable.
6. Confidence and uncertainty — calibrated where possible, and stated plainly where the context is too thin to be confident.
7. Risk constraints — encoded as rules, so an option that breaches one never reaches the shortlist.
8. Explanation — why each option ranked where it did, in a form the decision owner can challenge.
9. Human decision — a named person chooses, and the record shows what they were shown when they did.
10. Outcome feedback — what actually happened, captured so ranking quality can be measured rather than assumed.

Components 9 and 10 are the ones most often dropped for schedule reasons. Drop 9 and there is no accountability. Drop 10 and there is no way to know whether the system is getting better or worse, which means confidence scores become decoration.

A worked example

PSX Invest is this pattern running in production, which makes it a useful illustration of each component in something concrete.

• Ingestion. Exchange data for the full listed universe, pulled after the session closes so every symbol is evaluated on the same complete picture.
• Context. Seven indicators computed consistently per symbol, alongside pattern and structure.
• Options and ranking. The universe is ordered, so attention goes to a shortlist rather than to everything that moved.
• Confidence. Scores calibrated against real outcomes, so a number means something historically rather than expressing enthusiasm.
• Constraints. A minimum 2:1 reward-to-risk on any published call. Below that, it is not published.
• Explanation. The indicators behind each call travel with it.
• Human decision. Execution is entirely manual. The system has no route to the market and places no orders.

That last point is the one that makes it a decision system rather than an automation. The boundary is deliberate, and living with it is what forced the control layer to be built properly.

How to tell which one you need

Ask what the person receiving the output does next.

• If they need to see the state of things, build a dashboard.
• If they need to know what is likely, build a prediction.
• If they need to choose between options and defend that choice later, build a decision system.

And if the answer is "it depends who is asking", the objective has not been agreed yet. That is the real project, and it is worth doing before any of the three.

The decision intelligence page has an interactive explorer that composes the structure of a system around the signals, objective and constraints you select. It builds an architecture, not a business outcome, which is the honest limit of what a tool like that can do.