Decision intelligence, explained: from a recommendation to a signed decision

Most enterprise decisions are snap judgements. Is this claim urgent? Is this invoice a duplicate? Which team should see this complaint? Each one is small. Together they set how fast an operation moves and how many skilled hours it spends on routine work.

Why rules and large models both fall short

Rules break on messy inputs: a scanned repair estimate, an email in two languages, a PDF with the total on page three. Large language models read those well, but running one on every event is slow and costly at enterprise volume. People can do both, until they run out of hours. Decision intelligence sits between: a fast, small model for every case, and a person or a larger model for the hard ones.

What a decision looks like

In elan1 Decide, business teams define each decision as one of three kinds of answer, without writing code, and every version is kept:

• Yes or no: is this claim a likely total loss?
• A choice from a list: which queue should this ticket go to?
• A score: how severe is this complaint, from 1 to 5?

A small, fast model answers every question for a case in one pass, with a confidence for each answer. Personal data is masked first and stays in-region.

From recommendation to route

A confidence is only useful if it is calibrated, meaning that answers given at 90% are right about 9 times in 10, and if someone has decided what a wrong answer costs. Your risk owner signs the line for each answer. Then confidence and risk choose one of four routes:

1. 01Act: the answer is clear and the cost of error is low, so the case moves on.
2. 02Review: a person sees the case, the answer and the evidence, and confirms or corrects it.
3. 03Escalate: a larger reasoning model takes a second look before anything else happens.
4. 04Hold: the case waits, for example because a system it depends on is down.

When in doubt, the case fails toward a human, never toward an action. Our brief Fail toward a human explains why that rule matters most when systems are failing.

From route to signed decision

A recommendation becomes a decision when it changes something. If the answer would change a record, such as approving a claim payment or closing an alert, it goes through elan1 Govern, which allows it, asks a named person or refuses it, and records the outcome. That record is what makes the decision signed: it shows the answer, the confidence, the line in force, the route taken and the person, or the signed rule, behind it.

Where it should only recommend

Some domains are recommend-only however confident the model is. In elan1 Decide, credit, anti-money-laundering outcomes, clinical intake and hiring always end with a person. The model can rank, summarise and suggest. I explain the reasoning in Recommend only.

Learning without drifting

Real outcomes are joined back to each decision so that confidence stays honest as cases change. The design aim is that fewer cases need a person over time. But a line only moves when your risk owner signs the new one, and every version is kept.