Many questions inside a process do not call for an explanation: they call for picking an option and moving on. Decision models aim at that space. What they are, where they fit, what changes compared with asking an LLM for JSON, and how to evaluate Jev, Kev and Laya before investing in training.
Many companies already use language models to answer queries, summarise documents or help their teams write code.
But inside a business process, much narrower questions come up:
Which team should handle this complaint?
Does the document contain the information needed to continue?
Does this case need human review?
At those points, the system needs to pick an option and keep working. Generating a full explanation can add time and cost without contributing much to the next action.
Decision models aim at that space: turning information into a structured answer that an application can use directly.
Jev, Kev and Laya are three proposals for exploring this idea. They share a kind of interface, but differ in important ways in deployment, capability and how much adaptation they need.
What a decision model is
Think of it as a function that takes context, a question and a set of possible answers.
For example, the context could be this message:
I was charged twice for this month's subscription. I need you to look into the payment.
The question would be: which team should handle the case? And the options:
- Billing.
- Technical support.
- Sales.
- Manual review.
The result can include the selected option and a probability for each alternative.
{
"team": "billing",
"probabilities": {
"billing": 0.93,
"technical_support": 0.03,
"sales": 0.01,
"manual_review": 0.03
}
}
This JSON is an illustrative example, with made-up values and a simplified format. It does not represent a real run or the exact contract of any API.
The application receives that evaluation and applies its own rules: assign the ticket, ask for more information or send it to a person.
The model estimates; the system decides what to do with that estimate.
What changes compared with asking an LLM for JSON
A language model can also classify messages and return structured answers. In many projects, that is a good first implementation.
Models specialised in decisions try to optimise that work: scoring predefined alternatives without generating a long text answer.
TypeSafe presents Jev as part of a category it calls System One, built around typed, probabilistic answers for software: the possible outputs are defined in advance and every answer comes with its probability. It pitches it for classifying, routing, scoring or branching a flow, with the goal of cutting the cost and latency of those repeated operations.[1]
And the cost gap is large. For this kind of task, a decision model is far cheaper than a general-purpose LLM: it does not generate text, it only scores options. TypeSafe charges US$0.042 per million input tokens, does not charge for output and, in its workflow evaluations, reports a cost about 445 times lower than frontier LLMs.[1]
- ~445×
- cheaper than a frontier LLM, according to TypeSafe's evaluations
- US$0.042
- per million input tokens; output is free
- 70–500 ms
- end-to-end response time
These are the vendor's figures, measured on its own tests, and the company admits it still has to prove that the price is sustainable. But the underlying reason is structural: choosing between known options takes far less compute than writing an answer. That is also why a small open model like Kev can handle these queries on much less hardware than a general LLM.
Automatic classification existed long before this category. Specific problems can also be solved with rules, traditional classifiers or language models with constrained outputs. The choice depends on what the process needs and on how much each alternative costs to maintain.
| Need | Approach worth evaluating |
|---|---|
| Apply an exact rule to structured data | Code or a rules engine |
| Classify a stable task with plenty of labelled examples | Specialised classifier |
| Evaluate text against options described in natural language | Decision model or LLM with structured output |
| Write, explain or elaborate an open answer | Generative model |
These pieces can live side by side in the same application.
Three responsibilities inside the process
Say we want to automate part of complaint handling. We can split the work into three responsibilities.
The decision model evaluates the content: the topic of the complaint, its urgency, or whether more information is needed.
The business code checks permissions, looks up the customer's status and decides which actions are allowed.
The generative model, if needed, writes a reply using the validated information.
For example, detecting a possible duplicate charge can trigger a lookup in the payments system. The refund will depend on that check and on the company's authorisation rules.
This separation makes it possible to swap the classifier without rewriting the whole process. It also makes it easier to find out whether an error came from how the message was read, from wrong data or from a misconfigured rule.
Jev, Kev and Laya: where to start
All three let you explore structured decisions, with different trade-offs.
| Model | Format | What to evaluate first |
|---|---|---|
| Jev | Proprietary TypeSafe service, in early access | Quality on the task, network latency and API terms of use |
| Kev | Open family based on Qwen; Apache 2.0 licence | Model size, available memory and performance on new questions |
| Laya | Open models under the Apache 2.0 licence; English and multilingual variants | Choice of checkpoint and improvement when tuned to the domain |
Sources: TypeSafe documentation and the Kev and Laya repositories.[1][2][3]
Jev lets you try the idea through a managed service. Kev and Laya let you run the models on your own infrastructure, in exchange for owning deployment and operations.
Self-hosting avoids depending on an external API for every inference, but it still carries hardware, maintenance and monitoring costs.
Is fine-tuning needed?
This is one of the most important questions before choosing.
A model accepting questions in natural language does not guarantee it will correctly read a company's own categories. "Critical incident", "priority customer" or "sufficient documentation" need definitions the model can apply.
It helps to tell three interventions apart:
- Improve the context: describe the options, clarify the rules and supply the relevant data.
- Calibrate: adjust how probabilities are read, using labelled examples.
- Fine-tune: change the model's parameters to adapt it to the task.
They do not cost the same, and they do not solve the same problem. Calibrating can make a probability more useful, but it does not replace the ability to tell categories apart.
What happens with Laya
Laya shows a strong dependence on the checkpoint in some evaluations. Its repository reports 36.2% accuracy for the English base model on typed-decisions, against 76.6% for the variant tuned to those workflows.[3]
This helps explain why a first test can be disappointing and then improve a lot with task-specific training. It does not mean every task with Laya requires tuning either: you have to evaluate the right checkpoint on the real problem.
What happens with Kev
Kev publishes models already trained for decisions. You can try them with your own questions and options without doing any extra tuning first.
In its development evaluation on new sources, the project reports 64.8% accuracy for Kev-0.8B and 81.7% for Kev-4B. Jev scores 85.7% on that same set.[2]
These results suggest that size can make a meaningful difference once you step outside known tasks. They are the project's own measurements and cannot predict the result at a specific company. Nor can they be compared directly with Laya's figures: they come from different evaluations.
For a first test, it makes sense to evaluate a published model before investing in training. If the error persists with well-defined options and enough context, fine-tuning becomes a concrete option.
A high probability can still be wrong
Getting an answer with a probability of 0.95 can give a sense of certainty that is hard to justify.
A well-calibrated probability should match the observed rate of correct answers on comparable cases. But that relationship can shift when the language, the domain or the distribution of the data changes. Laya's own repository warns that its checkpoints ship over-confident and recommends calibrating them before relying on their probabilities.[3]
On top of that, always returning a valid option only guarantees that the answer belongs to the allowed set. The chosen option can be wrong.
An independent study of Laya and Jev found significant differences when evaluating them on identical inputs: Jev was more accurate on nine of eleven tasks, while Laya changed 30% of its answers when the order of the options was reversed. It is evidence about the versions and tasks studied, not a permanent ranking.[4]
That is why a threshold such as "automate if the probability exceeds 0.90" has to be validated. The right value depends on how much error the process can tolerate.
How to test them on a real case
A first evaluation can be organised in five steps.
1. Pick a narrow decision
For example, assigning tickets to four teams. It is an easy task to describe and lets you review the errors without first building the whole automation.
2. Prepare representative examples
Gather real cases and agree on their correct answers with the people who know the process. Include ambiguous messages, incomplete information, similar categories and the language that will be used in production.
It is also worth setting aside cases that will not be used to tune instructions, thresholds or parameters.
3. Compare against a simple baseline
Measure the model against the current solution, a few basic rules or an LLM with structured output. A new architecture has to justify its complexity with observable improvements.
4. Measure the whole automation
Beyond the accuracy rate, record:
- Errors by category and their impact.
- Share of cases that can be resolved automatically at the accepted error level.
- Median and 95th percentile latency.
- Total cost per processed case.
- Behaviour when the order of the options changes and when information is missing.
A fast model can add little if it forces you to manually review almost all of its answers.
5. Add an exit for doubtful cases
The process needs to be able to escalate to a person, ask for more data or use another model. That route must exist even when the model returns high probabilities: the evaluation can reveal errors its confidence does not detect.
Where they add value
Decision models are especially interesting when an application repeats a well-defined evaluation over varying information: classifying complaints, prioritising documents or determining whether a request has enough data.
They can be brought in gradually. First they run in parallel with the current process, then the cases that meet the quality criteria are automated, and the scope grows with evidence.
The useful question to start with is a concrete one:
Which decision do we repeat every day, and how will we know whether a model is getting it right?
Answering it lets you choose between a service like Jev, an open model like Kev or Laya, or a simpler solution. It also defines what data is needed and when training is worth it.
A good first implementation can be small: one decision, clear options, a reproducible evaluation and a route for the cases that need extra attention.
Technical information reviewed as of 23 October 2026. The results cited belong to specific versions and evaluations; they should be checked again when selecting a version for production.