The phrase "decision intelligence platform" now appears on the homepage of dashboards, workflow tools, GenAI co-pilots, and a few products that still call themselves decision support systems. From the outside, every vendor sounds the same: ingest data, surface insight, recommend action. That uniformity is the problem. If you are a compliance lead, a risk owner, or a regulated-industry engineering leader, you need a structural test that tells which of these vendors actually enforces a rule, and which only visualises one. This guide gives you that test, then turns it into a vendor-evaluation checklist you can use before signing anything.
Key takeaways
- **Enforcement, not visualisation:** A real platform in this category commits or refuses against a binding rule set. A dashboard, no matter how intelligent, only advises.
- **Five capabilities are non-negotiable:** Ingest, verify, decide, refuse, and audit. Missing any one of these reduces the system to a smarter analytics layer.
- **Refusal is the dividing line:** Any vendor that cannot describe the conditions under which the software will refuse to act is selling decision support, not enforcement.
- **Audit trails are not optional:** If you cannot replay a decision after it has been made, regulators and insurers cannot defend it. Append-only logs are the minimum.
- **Most "platforms" are dashboards in a new wrapper:** The vendor-evaluation criteria below give you the exact questions to ask in the third sales call, not the first.
A working definition of a decision intelligence platform
A decision intelligence platform is software that takes a request, runs it through a defined sequence of verifications and constraints, and either commits the decision or refuses it, with every step logged. The platform does not produce a recommendation that someone else acts on. It produces a commitment or a structured refusal, against rules that exist in code rather than in a slide deck.
Two clauses inside that definition do most of the work. First, defined sequence: the rules and checks are written down, machine-readable, and the same on Friday afternoon as on Monday morning. Second, commits or refuses: the system's output is binding inside its scope, not advisory. A product that cannot refuse is a dashboard with extra steps.
Gartner, which coined the term, frames decision intelligence as a discipline that connects data, models, and rules to organisational decisions (Gartner glossary: decision intelligence). The discipline is real; the platform category is where vendor positioning has blurred. To cut through, evaluate against capability, not category.
The five capabilities a real platform must have
A product earns this label only when it implements five capabilities end to end. Drop any one of them and the system collapses into a smarter analytics tool. The diagram below shows the path that every request must traverse, with the refusal branch broken out as a first-class outcome.
Ingest. Every request enters a known queue with a stable identifier. If a request can arrive through three channels and only one of them gets logged, the system has no anatomy. It has a leak.
Verify. Two checks run before any decision is computed. The authority check confirms that the actor invoking the request has the standing to do so. The evidence check confirms that the data backing the decision is present, current, and verifiable. A product that lets either check be deferred is not a platform; it is a hope.
Decide. The constraint gate evaluates the rules. Risk limits, regulatory thresholds, policy boundaries, and counterparty limits all live here. The output of this stage is a single binary: commit or refuse. There is no maybe.
Refuse. The system names the conditions under which it will refuse, and produces a structured refusal that a downstream system or a human reviewer can act on. In regulated jurisdictions, this is not a feature request from compliance; it is a regulatory requirement, made explicit in the U.S. Equal Credit Opportunity Act's adverse-action notice rules and analogous regimes elsewhere.
Audit. Every commitment and every refusal is written to an append-only log with the inputs, the evidence consulted, the rule that applied, and the actor identity. A product whose audit trail is editable, partial, or reconstructable only with effort is not auditable, regardless of marketing copy.
For a slower walk through what "decision system" means in the first place, see our companion guide on what a decision system actually is.
Where the line falls: DI platform vs BI dashboard
The single most common confusion in this space is between an enforcement product and a business intelligence dashboard. The vendor pitches sound similar; the architectures are not.
A BI dashboard ingests data, transforms it, and surfaces a visualisation. A human interprets the visualisation and decides what to do. The dashboard never refuses, because the dashboard is not the decider. Its rules are advisory, and if the human ignores them, nothing breaks at the platform layer.
An enforcement product ingests data and a request, verifies both, evaluates the rules, and produces a binding outcome. The human who initiated the request gets a commit or a refusal, with the reasoning logged. The system is the decider, inside the scope its rules describe. If you cannot point to a request flowing through the vendor's product and ending in either a logged commit or a structured refusal, the product is a dashboard, regardless of what the homepage calls it.
How to evaluate decision intelligence vendors
Use the following criteria in order. The first three exist to disqualify dashboards in vendor clothing. The remaining three separate credible products from each other.
- 01
- Show me a refusal. Ask the vendor to demonstrate a specific request that the system refused, and the structured output that refusal produced. A vendor that cannot show one is selling decision support.
- 02
- Show me the constraint set. Ask to see the rule set the software evaluates, as code or as configuration. If the answer is "our consultants implement it for you," the product does not yet have a constraint gate; it has a services dependency.
- 03
- Show me the audit trail of one decision. Pick any committed or refused decision. Ask the vendor to reproduce the inputs, evidence, applicable rule, and timestamp from the log. If reconstruction requires multiple systems, the audit is incomplete.
- 04
- Authority and segregation of duties. Confirm that the authority check is enforced at the product layer, not via an upstream identity system. Confirm that the same actor cannot both invoke and approve a high-stakes decision unless that combination is itself a logged rule.
- 05
- Refusal contract. Ask the vendor for their list of conditions under which the system will refuse to act, in plain language. The list should be enumerable and short, ideally fewer than ten items. A vendor whose refusal list is open-ended has no refusal contract.
- 06
- Failure mode logging. Ask what happens when a downstream system the product depends on becomes unavailable. The right answer is: it refuses pending requests and logs the refusal with the dependency failure as the reason. The wrong answer is: requests queue silently.
These six questions are the ones that matter in the third sales call, after the demo and the pricing conversation. Vendors who cannot answer them are not platforms yet.
Where these products break in production
Software that passes the five-capability test still fails in production for a small number of recurring reasons. Each of these is a refusal condition Cube A Cloud builds into systems on day one.
Decisions are already irreversible. A product asked to commit something that has effectively already happened, such as a transaction the bank cleared an hour ago, has no decision to make. The right response is refusal with a reference to the human escalation path. Frameworks like the NIST AI Risk Management Framework (AI RMF 1.0) treat this as a governance precondition, not a runtime concern.
Legal authority is required. When the action falls outside the bounded scope, for example a prescription decision where a licensed clinician's signature is statutorily required, the software must refuse and route. Auto-commit in these contexts creates a liability, not a service.
Information cannot be verified. The evidence check is the most common failure point. A KYC record that exists "somewhere in the organisation" is not evidence at the point of decision. Treat missing-but-known-to-exist as missing.
Urgency replaces reasoning. When a request is framed as an emergency override, the system should refuse unless the override path is itself a logged rule. Cube A Cloud's refusal contract on the limits page covers these four conditions in the same language.
For the broader governance frame around these failure modes, our AI risk management framework walks through the operational version.
A practical closing
This category is not something you buy because an analyst named it. It is software that commits or refuses, with the rules visible and the audit complete. The five-capability test and the six-question vendor evaluation give you a way to separate the real platforms from the dashboards inside a single afternoon. If the vendor cannot answer the questions, you have an answer.
If you are evaluating decision intelligence software for a regulated context, the structural definition in our pillar guide on what a decision system is documents the same approach applied to engagements we run.