A decision support tool feeds accurate data to the people who need it, and that part works. What it does not do, in any configuration I have seen, is test what those people are assuming about the data. That is where material commitments fail.
I have spent much of my career inside organisations that invested heavily in decision support infrastructure and still made poor calls. The systems presented the numbers correctly; the people in the room were carrying assumptions about supplier behaviour or regulatory stability that nobody had named. In several cases those assumptions were so deeply embedded that the committee did not recognise them as assumptions at all.
Roger Estall and I wrote Deciding because the gap between good data and a sound decision has no software fix. It requires a structured conversation about what the data assumes. I built the Walk so that those assumptions get tested before the commitment proceeds.
A decision support tool is any system or structured process that presents data and analysis to the person who must commit to a course of action.
What a decision support tool covers
The category is broad and the function is real. Clinical decision support systems flag drug interactions before a clinician prescribes. Financial dashboards surface liquidity positions overnight so a treasury team can act before markets open. The common thread is that raw data gets processed and presented so a human can act on it faster than manual assembly would allow.
A decision making tool in this category compresses hours of work into a view the Decider can read in minutes, and that compression is genuine value.
The problem starts when the room assumes that because the tool surfaced the right data, the decision sitting on top of that data must also be right. I have been in enough of those rooms to say plainly that these are different claims. The dashboard tells you what the numbers say; it tells you nothing about whether the numbers will still hold once the commitment has been made and the conditions behind those numbers start to shift.
When a decision support tool is enough
If the choice is bounded and the downside is containable, a decision support system is enough. Routing a delivery fleet against live traffic data is a reasonable example: the assumptions are stable within the shift, and a wrong call costs fuel and time rather than a plant or a career. Operational choices with short feedback loops and reversible consequences sit comfortably inside a dashboard.
If the team keeps circling the same operational question instead of acting, the bottleneck is more likely analysis paralysis than a missing tool.
The picture changes when the commitment is material and the consequences run beyond what the system can see. A decision to close a manufacturing line or restructure a division rests on assumptions about demand and regulatory direction that no dashboard can validate on its own. The data may be current, but whether that data describes conditions that will persist through the implementation period is the Decider's judgement call, not the system's.
The Walk exists because that second category of decision, where assumptions carry genuine uncertainty, is exactly where decision support systems reach their limit. If you are trying to make that kind of difficult business decision, the gap between what a support tool covers and what it skips determines whether the commitment holds.
Name the assumption your decision support tool cannot test and write the evidence that would settle it before the commitment proceeds. Start the Walk →
What a decision support tool skips
The gap sits in what the user assumes about the data, not in the data itself. Ferrari's decision support system at the 2010 Abu Dhabi Grand Prix is the cleanest case I know. The system processed real-time data correctly: tyre degradation, lap times, gaps to competitors. It recommended a pit-stop strategy that looked sound on every input the model could see.
Aversa, Cabantous, and Haefliger analysed what went wrong and found that the assumptions about competitor behaviour did not hold under the specific race conditions. The system answered "what should we do given these inputs" without testing whether those inputs would remain stable once the strategy was executed.
The data was accurate and the model was sound. The assumption was wrong. Ferrari lost the World Championship because nobody in the garage asked whether the recommendation would survive contact with what the other teams were about to do.
Aversa, Cabantous, and Haefliger identified a failure mode that extends well beyond motorsport: performativity. The system's own recommendation, once broadcast over team radio, altered what competitors did, which changed the conditions the recommendation had assumed. A decision support system that does not account for the fact that acting on its output can shift the environment it relied on is structurally blind to its own influence on the outcome. That is a category limit, not a bug to be patched.
I have watched the same failure at a slower speed in boardrooms. When a decision support system presents a "risk score" or a "confidence level," those labels carry embedded definitions the user may not share. In my work on international standards, I found that ISO alone carries more than forty formal definitions of the word "risk." A statutory definition and an insurer's definition can sit in the same boardroom without anyone noticing they refer to different things.
A tool that displays "high risk" or "medium confidence" without defining those terms for this specific decision has already introduced an untested assumption about shared language. The Walk forces the room to name each assumption and judge its significance before the commitment proceeds.
The research literature calls this pattern automation bias. A 2024 empirical study of healthcare professionals found that users over-relied on automated decision support outputs and discounted contradictory information, even when the system recommendation was wrong; the effect was stronger under time pressure.
Lyell and colleagues mapped the causal pathways from automation bias to patient harm and found that existing safeguards, including training and override logging, address the symptoms rather than the root cause. The user stops performing independent verification once the system appears authoritative. That is what happens when a decision support tool is treated as the decision rather than as an input to one: active reasoning gives way to approval.
What the Walk produces
The Walk produces a Decision Document: a dated record of the commitment, the assumptions it rests on, and the monitoring arrangements that will tell the owner when any of those assumptions shift. That record outlives the dashboard. If someone asks in eighteen months why the commitment was made, the document carries the reasoning rather than relying on the cached state of a system that has since been overwritten by newer data. Useful outside expertise feeds the process; it does not replace the owner's judgement.
Monitoring is the component that most decision support systems omit entirely. A dashboard shows current state; it does not specify which conditions would require the Decider to reopen the decision. Without that specification, a commitment made on solid grounds in June can drift into failure by October with no mechanism to detect the movement. The Decision Document includes explicit monitoring triggers: which assumptions carry the most volatility and what observable changes would signal that one has shifted.
The distinction matters because most decision support tools end at the point of display. The Agency for Healthcare Research and Quality found that clinicians override 90 to 96 per cent of clinical decision support alerts. The alerts fire and the clinician dismisses them because the system treats every possible concern as equally significant.
A drug-interaction warning for aspirin and a warning for a potentially fatal combination arrive in the same format with the same urgency. The system has no framework for distinguishing a critical assumption from a limited one, and without that distinction the human stops reading. That is not a user-discipline problem; it is a design problem in the category itself.
A different design solves this. Instead of presenting every data point as a warning, the method asks the Decider to identify the assumptions that actually matter to this commitment and judge them by influence and confidence. The Universal Decision-Making Method is structured around that sequence.
A decision support system feeds the first two steps well: framing and developing options. The method covers the three that follow, from recognising assumptions through designing monitoring, which determine whether the commitment is sound.
You could feed the system better data and still leave the assumption underneath the commitment untested.
Work through your decisionNo sign-up. Just pick your decision and start.
Grant Purdy is the co-author, with Roger Estall, of Deciding (2020), and the architect of the Universal Decision-Making Method.