What is happening

A month full of decision models

On 15 September TypeSafe released Jev, for now as a limited release. Two weeks later it was already in use by 35 percent of paying teams on Vercel's AI platform, which describes it as the fastest adoption any model has seen in its first two weeks. From there, things moved fast. Within four weeks around twenty comparable models had appeared, from Cloudflare, Perplexity and Liquid AI among others. OpenAI announced its Decisions API on 29 September, in public beta since 6 October, and Microsoft released Decision-1 on 9 October. Snowflake and Databricks are building the technology in as well, although those versions are not yet generally available.

A language model writes, a decision model chooses

The difference lies in what comes back. A language model answers in text, whether a summary, a reply or a proposal. A decision model is handed a question whose possible answers have been fixed in advance, picks one and attaches a probability to it: a number between 0 and 1. Nothing more comes back.

It works like a multiple-choice form. The question can be a choice from a list ("which discipline?"), a score on a scale ("how urgent, from 1 to 5?") or the likelihood that something is true ("is this an emergency callout?"). No explanation of the choice comes with it, and the model cannot calculate either, so the advice is to work out amounts, dates and thresholds beforehand in ordinary software.

So why all the excitement? Price and speed. A million classifications of 500 tokens each cost around $21 with Jev and around $50 with OpenAI, and OpenAI says its Decisions API is roughly ten times faster than its regular language model. Data company MotherDuck had Jev sort 100,000 news articles, which took 40 seconds and cost 50 cents, with 89 percent of the answers correct. A language model from OpenAI needed 32 minutes, cost $37.58 and reached 88 percent.

What the numbers do not tell

Almost all the figures come from the vendors themselves or from companies that have only just built the product in, and the comparisons contradict one another. On a test with banking questions Cloudflare's model clearly beats Jev, while on scientific questions it is the other way round. Nor does the speed with which Jev was adopted say anything about how well it classifies.

Then there is the claim that a decision model cannot hallucinate. It holds in so far as the model cannot invent text, since the answer is always one of the options; it can still pick the wrong one. The probability it gives is said to be calibrated: across many answers, a 0.8 should be right roughly 80 percent of the time. Whether that holds for a company's own fault reports is something it will have to test for itself. Researchers at HiddenLayer also showed that Jev can be led astray by hidden instructions in the text it reads. Under the bonnet a decision model is still a language model, and a fixed answer format offers no protection against that.

Finally, the practical side for a European company: Jev is closed software running in the United States, whereas OpenAI does offer EU data residency for the Decisions API.

What it means for technical service

How it works today

Where service companies currently turn AI loose on their fault reports, the setups Captain Workflow comes across usually have a single language model doing everything at once: it reads the customer's email, decides the category, estimates the urgency, pulls out the address and error code, and writes a summary for the planner. That works, but every one of those steps leans on the same model, and the actual judgement ("emergency or not?") is buried in a block of text.

Fixed questions, large volumes

A decision model comes into its own with a question that keeps recurring and whose answers are fixed. A service company has no shortage of those:

• Is this fault report an emergency callout? Yes or no, with a probability.
• Which discipline does it belong to: heating and gas, cooling, electrical or plumbing?
• Is this job sheet complete: signature, materials and hours filled in?
• Does this invoice line fall within the maintenance contract, or is it extra work?

Take the email "upstairs boiler is dead, flashing F28 or something, we're home from 3pm, grandma lives with us". A language model turns it into a tidy summary. A decision model answers only whether it is urgent, and might come back with: yes, 0.92.

The probability is the real news

For a COO, that number matters more than the price, because a probability attached to every answer makes doubt measurable. A company can agree that anything above 0.9 goes straight into the schedule as an emergency callout and anything below lands with the planner. That threshold is a business decision, and so is the list of possible answers: whoever decides which disciplines appear on it also decides what the schedule looks like. A pick list is policy dressed up as a setting. That decision belongs with operations.

Where it does not fit

A decision model does not write job sheet text, does not summarise a job for the engineer, does not multiply hours by rates and does not draw up a rota. Hard rules, such as assigning work by postcode area and certification, belong in ordinary software, which is cheaper, faster and does the same thing every time. Companies already working with these models recommend three layers: what a fixed rule can decide goes to a rule; large numbers of similar, fuzzy judgements go to a decision model; only what is genuinely difficult goes to a large language model.

A sober calculation

The price differences sound spectacular, but a service company operates on a modest scale. Let us assume, as an indicative example, 300 fault reports a day at 500 tokens each: that comes to over 100,000 reports a year. Assessing them costs about $2 a year with Jev and about $8 with a small OpenAI language model. At volumes like these, price is no argument. What a decision model does deliver is a fixed answer with a probability, one that slots into the schedule without further interpretation.

Where the scale is large is the archive. Sorting five years of job sheets and fault reports in one go by cause, discipline or recurring complaint costs a few dollars with a decision model and, going by the MotherDuck test, probably takes a few minutes.

Hype, useful, and when

The hype is in the big words. "Never hallucinates" holds only as far as invented text goes, and speed claims such as "35 times faster" or adoption figures say nothing about quality on the fault reports of a Dutch installation company. On top of that, the products are only weeks old: Jev is a limited release and OpenAI's API is still in beta.

For now its main use is one-off work on historical data, where no daily schedule depends on the outcome and the results can be checked against a sample. For the daily flow of fault reports it makes sense to wait until scheduling software builds the technology in and it is clear where the data is processed.

Anyone who wants to make a start regardless can put the promise to the test in three steps:

1. Have a few hundred of the company's own fault reports assessed and set the outcome alongside the planner's judgement. Is a 0.9 really right nine times out of ten?
2. Find out where the model runs and whether there is a data processing agreement suited to customer data.
3. Record who manages the answer options and the threshold, and make sure it is someone from operations.