Automated Decision Systems
Automated decision systems continuously evaluate conditions and route actions without depending on ad hoc human interpretation for every event.
Definition
Core meaning
An automated decision system evaluates conditions and selects an action without a person in the routine path. The defining property is that the system's output is the decision itself rather than a recommendation someone else acts on.
In practice
What separates automated from assisted
The distinction is not how sophisticated the evaluation is — it is whether the decision requires a human to become real. A system producing perfect recommendations that all queue for approval is assisted, not automated, and carries the latency of the queue.
- The decision proceeds unless something intervenes, rather than waiting to be approved
- Human involvement is defined by exception policy, not by default
- The system records its own reasoning, because no person will remember it
- Escalation is a designed branch with its own criteria, not a fallback
Boundaries
Commonly confused with
The term is applied loosely, and the looseness hides where the latency and the liability actually sit.
- Not AI-assisted decisions: those keep a human owning the final action
- Not workflow automation: that runs steps, this chooses which steps apply
- Not autonomous operations: autonomy is the broader state, this is one decision class
- Not a rules engine: the engine is a component, the system includes routing and execution
Diagnostic
How to tell what you actually have
Count the approval steps. Many systems described as automated turn out to have a person at the last gate, which is where all the delay lives.
- Does any routine decision require a click before it takes effect?
- If the approver is unavailable, does the decision wait indefinitely?
- Is the approval a genuine judgement, or a rubber stamp nobody has removed?
- What proportion of decisions are actually overridden at that gate?
Category link
Where it fits in OADI
Automated decision systems are what the architecture produces when all five stages are connected. They also raise the governance questions the architecture exists to answer: what is recorded, who is accountable, and how a wrong decision is detected and reversed.
FAQ
Frequently Asked Questions
Are automated decisions legally risky?
They carry obligations that vary by jurisdiction and sector, and in regulated contexts some decisions require human involvement or a right to explanation. The practical response is the same either way: record inputs, logic version, and outcome for every decision, and define explicitly which classes never automate. That record is both the compliance artefact and the debugging tool.
What rubber-stamp approval rate justifies automating a gate?
There is no universal number, but the question to ask is what the approver actually changes. If overrides are rare and cluster around identifiable conditions, encode those conditions as escalation criteria and automate the rest. If overrides are frequent and varied, the evaluation logic is not yet good enough to remove the human.
How do we build trust in an automated decision?
Run it in shadow mode first. Let the system decide without acting, log what it would have done, and compare against what the humans did. Weeks of that data tell you the real disagreement rate and, more usefully, exactly which conditions the logic gets wrong — before anything is at stake.
Operational Context
See how this concept appears in real operational systems
The audit maps this concept to the decisions, signals, and execution pathways inside your operating environment.
Keep Exploring
Related concepts and next steps
Suggested Reading
Related reading
Systems that turn operational data into automated decisions.
An assessment that turns category understanding into an implementation path.
The operating model for converting signals into decisions and decisions into execution, taught as a cohort curriculum.