Every operational system in a large enterprise is organised around an artefact. Fraud has alerts. Claims have notices. Service has tickets. Legal has documents.
None of those are the thing the business cares about. The business cares about the decision that gets made — pay or don't, block or don't, escalate or don't — and the artefact is just what triggers it.
That distinction sounds like semantics until you look at what it changes.
What it changes about measurement
Measure alerts and you get alert metrics: volume, clear rate, backlog. All of them can look excellent while the business outcome is bad. A team that clears 26,000 of 40,000 alerts a week has a 65% clear rate and an unbounded backlog, and the number does not tell you which is which.
Measure decisions and the questions get sharper. How long from trigger to decision. What fraction of decisions were later reversed. What each decision cost to make. What evidence supported it.
Those are answerable, comparable to the manual baseline, and they are the numbers a CFO recognises.
What it changes about architecture
If the decision is the unit, it needs somewhere to live. In most estates it lives nowhere: it is implicit in a status field that got updated, with the reasoning in an analyst's head and possibly a free-text note.
Make it an object. A decision record holds the trigger, the assembled evidence with record-level lineage, the constraint checks that ran, the confidence per evidence lane, the policy gate that applied, the outcome, and who or what made it.
Once that object exists, several things you have been struggling with become easy. Audit is a query. Explaining a decision to a customer is a render. Training the next model version on your own history is a join. Detecting drift is a comparison over time on a stable schema.
What it changes about where humans go
If work is organised around alerts, humans review alerts, and the queue grows with volume.
If it is organised around decisions, you can ask a much better question: which decisions actually change when a human makes them? For most operations the honest answer is a minority — and it is a specific, identifiable minority, at the policy boundary, where the lanes disagree, or where a party is vulnerable.
That is where humans belong. Everywhere else, a human is adding latency and a signature.
The uncomfortable part
Adopting this framing usually reveals that nobody owns the decision. The rules belong to one team, the model to another, the queue to a third, and the audit obligation to a fourth.
That is not a technical finding, and no platform fixes it. But it does explain why the previous three attempts stalled, and it is better to know in week two than in month nine.
- Architecture
- Decisioning
- Design