The decision hiding inside every routing step
Somewhere in your workflow there is a step that does not need a paragraph. A claim comes in and has to go to the right queue. An application clears or it does not. A transaction gets scored and either passes or gets flagged. An invoice matches a purchase order within tolerance or it does not. Nobody wants a written explanation at this point. They want an answer, and they want it to be the same answer every time the same facts show up.
Then, a few steps later in the same workflow, there is a different kind of moment. A client sends an email that does not fit any form. An exception needs a reason written down for the file. A policy question needs an answer with a citation behind it, because whoever asks it will act on what comes back. This is not a routing decision. It is a judgment expressed in language, and it has to read like someone made it.
A lot of AI project trouble in production comes from putting a large language model where the first kind of decision belongs, or trying to force the second kind through a system that only knows how to output a category and a number. TypeSafe's Jev model, and decision models like it, are built for the first case. Understanding the difference between the two is a decision you now own, whatever you end up building.
What a decision model actually is
An LLM generates text. Ask it to route a claim and it will produce a sentence that says which queue the claim should go to, and it will usually be right, but the output is still language. Something downstream then has to parse that sentence back into a code your system can act on, and has to guess what to do if the model phrases the answer slightly differently than expected, or hedges, or adds a caveat nobody asked for.
A decision model like Jev is built the other way round. It is trained to take structured input and return a typed output: a category from a fixed list, a probability attached to that category, sometimes a small set of features that explain the weight it put on each input. There is no sentence to parse. The output is already the shape your system needs, because the model was built to produce that shape and nothing else.
That sounds like a small distinction. In production it changes four things at once: what the output looks like, how reliable it is, what it costs to run, and how you prove what it did.
Output shape
An LLM's output is text, and text is inherently unpredictable in its exact form even when the content is right. A typed decision model's output is a value from a known set, or a number in a known range. If your downstream system needs to route a case, price a risk, or trigger an approval, a typed output plugs directly into that logic. A text output needs an interpretation layer in between, and that layer is one more place for something to go wrong.
Reliability
Ask an LLM the same classification question twice, worded slightly differently, and you can get two different answers, or the same answer with different confidence framing. A decision model trained on a fixed input schema and a fixed output set does not have that room to wander. Given the same inputs, it gives the same answer. That consistency is not a nice-to-have in a regulated workflow. It is close to the whole point.
Cost
A frontier LLM call carries the cost of generating language: tokens in, tokens out, reasoning steps for anything non-trivial. A decision model built for a narrow task runs cheaper and faster, often by an order of magnitude, because it is not doing any of the work of composing prose. At the volumes that routing, scoring and approval decisions run at, thousands or tens of thousands of times a day, that cost difference compounds fast.
Auditability
When a regulator or an internal auditor asks why a transaction got flagged, "the model wrote a paragraph that seemed to lean toward high risk" is not an answer anyone wants to give. A probability attached to a named category, produced by a model trained on a fixed feature set, is a record you can defend. You can show what went in, what came out, and what threshold triggered the next step. That is a materially different conversation with an examiner.
Where the line actually falls: worked examples
Take routing. A new case arrives and has to reach the right team. The inputs are structured: case type, dollar amount, jurisdiction, a handful of flags. The output is one of a known set of queues. This is a decision model's job. No language is required at any point in the transaction.
Take scoring. A loan application, a claim, or a vendor risk assessment needs a number that reflects likelihood of a bad outcome. Again, structured inputs, a bounded output, a threshold that triggers a next step. A decision model does this well and does it the same way every time, which matters when the threshold is the thing compliance signed off on.
Now take the policy question a member of staff asks about an exception they are handling. The answer depends on which document applies, how it applies to this specific case, and how to phrase that so a person can act on it. There is no fixed output set here. The value is in the retrieval and the language: finding the right passage, explaining it, citing it. That is an LLM job, and it looks like the internal assistants described in how-we-work style projects: an answer drawn from the firm's own documents, with a citation attached so a person can check it before acting.
Between those two sits the case that looks bounded but is not quite. An approval that is usually a yes or no, except when the file has an unusual combination of facts nobody wrote a rule for. This is where a decision model's confidence score earns its keep. When the model returns a high probability, act on it. When it returns a probability near the boundary, that is the signal to route the case to a person rather than force the model to decide something it was never trained to be confident about.
Why production systems end up combining all four parts
Almost no real workflow is one decision end to end. A claims process routes a claim, then may need someone to read a complex exception and write a note, then updates a dozen fields in a case system, then needs a person to sign off before money moves. That is four different kinds of work happening in sequence, and each one wants a different tool.
The routing and the scoring are decision model territory: bounded outputs, high volume, cheap to run, easy to audit. The written exception, the summary for the file, the answer to a policy question: that is LLM territory, where the value is in language and explanation. Updating the case system, checking a threshold, moving a record from one state to another: that is deterministic code, plain business logic that does not need a model at all and should not carry one, because it is cheaper and more reliable without it. And wherever the decision model's confidence drops, or the LLM's output touches something material like an approval, a payment, or a client-facing statement, a person reviews it before it counts.
The mistake we see most often is treating this as one build rather than four. A team picks a frontier model because it is the most capable thing available, and then asks it to do the routing, the scoring, and the write-up, all through one interface. It works in the demo. In production it is slower and more expensive than it needs to be for the bounded steps, and the audit trail for the decisions that matter most is a paragraph of prose instead of a number and a threshold.
The decision this puts on your desk
Walk your own workflow and mark each step by what it actually asks for. Where the output is a category, a score, or an approval from a fixed set of possibilities, and the same inputs should always produce the same answer, that step wants a typed decision model, not a chat interface. Where the output is language that someone has to read and act on, and the value is in explaining or drawing on unstructured documents, that step wants an LLM with retrieval and a visible source. Where the step is pure logic with no judgment in it, code alone does the job, and adding a model only adds cost and risk. And wherever a decision is material enough that getting it wrong has a real cost, whether financial, legal or reputational, a person needs to see it before it acts on the business.
That mapping is the decision you now own, not a vendor comparison. It determines what you build, what you buy, and where a person has to stay in the loop, and it is usually visible once you actually look at the workflow step by step rather than at the workflow's name.
Where we come in
Alppoint builds the systems that sit across this line: decision models for the bounded steps, LLMs with retrieval for the steps that need language and a citation, deterministic code for the rest, and review points placed where the cost of an error is real. We do this end to end, as a defined workstream, or alongside a client's existing AI and engineering team, and the system ships into your environment as your asset.
