Most organisations hold far more text than anyone can read: support tickets, call notes, complaints, survey answers, articles. The decisions buried in that text are usually small (which team should handle this, how urgent is it, is it relevant at all), but there are thousands of them. Until recently there was no good way to make them one record at a time. A chat model can do it, but at that volume it is slow and expensive, and it answers in prose that your code then has to parse. A trained classifier is fast and cheap, but it needs thousands of labelled examples and someone to maintain it.

A new kind of model sits between the two. Jev, released by TypeSafe AI in September 2026, reads a record and answers a list of questions you write in plain language. It returns numbers instead of text, in well under a second and for a fraction of a cent. We use it to rank our internal reading list, where it answers about ninety questions about every article. This post explains what a decision model is, where it fits, and what we learned writing questions for one.

Jev is a decision model. Like a chat model it reads text, but instead of writing an answer it returns numbers: for every question you ask, a probability or a score, plus how confident it is. TypeSafe calls it a "System One model", after the fast, intuitive mode of thinking in Daniel Kahneman's work; The term decision model describes it better.

You give Jev a record (an article, a support ticket, a customer note, a JSON object) and a list of questions in plain language. Each question has one of three shapes:

• Yes or no. "Is this email asking for a password?" Jev returns a number between 0 and 1: how likely the statement is true.
• Choice. "Which team should handle this ticket: billing, technical, sales or legal?" Jev returns a probability for every option.
• Score. "How technical is this piece?" with four described levels, from "written for executives" to "code and configuration". Jev returns a position on that scale.

All questions are answered in parallel in one call, so ninety questions take about as long as one. According to TypeSafe's launch post, input costs $0.042 per million tokens and output is free; typical calls return in 70 to 500 milliseconds. Because Jev can only pick from the answers you allowed, it never returns malformed output, and your code can use the result directly.

Two things it gives up for that speed: it cannot write text, and it cannot tell you why it answered the way it did. Both matter, and we come back to them below.

Working with Jev feels less like prompting and more like designing a questionnaire. You decide what you want to know about each record, phrase it as questions, and let ordinary code turn the answers into a decision.

The split of work in that picture is the point. Jev does the reading; your code does the deciding, with rules you can read and change: "route to legal when the legal probability is above 0.8", "rank by relevance, minus a penalty for vendor announcements". Every decision then has a reason in plain language, built from the questions that drove it.

The confidence matters as much as the answer. A model that is right 95% of the time but cannot say which 5% it is unsure about cannot automate anything, because a person still has to check every case. In an independent spam test reported by Arize, emails Jev scored below 0.1 were spam 0.1% of the time, and emails scored 0.9 or higher were spam 99.9% of the time. In the 0.5 to 0.6 band, only 38% were. That middle band is exactly where you hand the case to a person.

The biggest shift is AI applied to every row of a data set, not to the data set as a whole. Until now the practical way to put a language model on top of a large table was to let it write a query: the model reasons about the data, the database does the work. Applying a model to each record individually was too slow and too expensive at scale, and the classical alternative (a trained classifier) needed thousands of labelled examples, a training pipeline and someone to maintain it.

At roughly $0.0003 per record for ninety questions (our own measurement, below), the arithmetic changes. Some places where that pays off:

• Turning text columns into usable columns. Free-text complaint descriptions become a product category, a severity score and a "mentions a competitor" flag, in a regular table that BI tools can use. The community has already wrapped this into SQL: pg-jev for Postgres and an open variant on Databricks.
• Routing and triage. Which team, how urgent, does a human need to look at this. The confidence tells you which cases to automate and which to queue.
• Ranking and filtering. Reading lists, search results, job queues. Simon Willison reranks the top 100 search hits by asking Jev how relevant each is to the query.
• Checking the output of other AI. Scoring every trace of an AI agent, or every generated answer, against a rubric. LangSmith added Jev as an evaluator for exactly this.
• Decisions inside software that must be fast. Games, interfaces and agents that make many small choices per second.

Where it fits less well:

• Numeric, tabular prediction. On a classical bank-marketing data set, one independent comparison found Jev at 59.7% balanced accuracy against 73.3% for a trained ensemble. If your signal lives in numbers rather than language, a classical model still wins.
• Decisions that need a stated reason per case. Jev returns a number, never an argument. If every individual decision must be explained to the person it concerns, you need a different tool, or a second step.
• Decisions about people. A score whose reasoning nobody can inspect can hide bias. Ranking job applicants or credit requests this way is a bad idea, and in Europe it falls under the high-risk rules of the AI Act.
• Anything that has to produce text. Summaries, emails, reports: that remains the job of a generative model.

T-Cloud Public heavily markets its use of standard OpenStack APIs as a major selling point, positioning it as a safeguard against vendor lock-in compared to AWS or Azure. And to be fair, this isn't just marketing gloss, T-Cloud Public's OpenStack fidelity is genuinely deep. Terraform providers, openstack CLI tooling, the standard OpenStack ecosystem works against it largely as-is.

In theory, that meant our infrastructure was vendor-agnostic and portable to any other OpenStack-compatible cloud. In practice, we couldn't actually cash in on that benefit.

Why? Because the European cloud ecosystem is shifting under OpenStack's feet. When we decided to leave T-Cloud Public and migrate to STACKIT (the cloud platform operated by the Schwarz Group), we ran straight into a structural wall: STACKIT has deprecated its OpenStack-compatible API, in favor of their own proprietary IaaS API².

As a result:

• Our "vendor-agnostic" OpenStack configurations could not be reused.
• We had to write entirely new, provider-specific configurations for STACKIT to rebuild our infrastructure.

Our colleagues share one internal reading list: articles, papers and videos about AI and data, pulled in from about fifty news feeds, a few online communities and whatever colleagues post themselves. Some thirty new pieces arrive on a normal day, far more than anyone reads.

Jev reads every piece and answers about ninety questions about it. A handful judge quality ("would a senior consultant at an AI and data consultancy be remiss to miss this?", "is this primarily promoting the author's own product?", "is this a roundup of unrelated news items?"). Five ask which of our business units it serves. Six identify the form (news, tutorial, research, case study). About seventy are topic tags, from agents to EU regulation.

The ranking itself is deliberately simple: a weighted sum of those answers, discounted by age. That simplicity is what makes it workable for people who do not build models:

• Every weight is a slider with a name. Move "vendor announcements" down and you watch the list reorder in front of you, with a count of how many of the top twenty changed.
• Every position has a reason in words. "High on must-read, not a vendor post, first-hand" is generated from the three answers that contributed most.
• Each unit gets its own view. Our Delivery colleagues see case studies and lessons from real implementations; Commercial sees market moves and client adoption. Same articles, same answers, different questions weighted up.
• Weak items never reach the list. An article that answers below a floor on relevance or substance goes to a review queue instead, about one in six.

It is also cheap to change your mind. When we reworded six questions, Jev re-read all 3,450 articles in about eight minutes for $1.15. That is roughly $0.0003 per article for ninety answers, and it means a question is something you can rewrite on a Tuesday afternoon, rather than a model you retrain once a quarter.

What surprised us most was who could work with it. Tuning a classical ranking model means features, training runs and a data scientist. Tuning this one means reading a question, reading the articles it moves, and rephrasing the question until it matches what you meant: work that an editor or a business lead does well.

With Jev the question is the model. Almost every problem we hit was solved by rewording a question, not by tuning a number. Six habits made the difference.

Name what does not count. Our first unit questions asked whether a piece was "useful to data scientists and AI engineers". Jev said yes to 60% of everything, because most AI news is useful to someone. Adding "general AI news, business strategy and data platform pieces are no" brought that to 33%, and the pieces that remained were the right ones.

Ask about the piece, not the topic. "Is this mainly useful to engineers who build data pipelines, rather than to ML engineers or general readers?" separates audiences. "Is this about data engineering?" matches anything nearby.

Prefer yes or no over a scale. Our four-level "how much does this matter to the field" question put almost everything in the two middle levels: 68% "useful", 33% "notable", nothing in the top level. Rewritten as a yes or no question ("would a senior consultant be remiss to miss this?"), the answers spread out and the top of the list became recognisably the week's important pieces.

One idea per question. A question that folds five audiences into one sentence answers yes for all of them.

Watch for the vendor trap. Questions about first-hand experience, new capabilities or practical change tend to answer yes for a vendor describing its own product. Pair them with a direct question such as "is this written by the company that makes the product it is about?"

Test on a small, mixed panel before you trust it. Pick thirty records that cover the cases you care about (the obvious yes, the obvious no, the tricky ones in between) and put the new answers next to your own judgement. With Jev that costs a fraction of a cent, so there is no reason to skip it.

Unsure answers sit in the middle. On a judgement call such as "is this a must-read?", Jev gave a hesitant answer (between 0.35 and 0.65) on about half of our articles. That is honest rather than broken, and it is also how you should use it: act on the confident ends and route the middle to a person or a second, more expensive model.

It is generous by default. Asked whether an article is relevant to an AI and data consultancy, Jev said yes to four out of five, including narrow academic papers. Treat a question that says yes to most records as a question that needs sharper wording.

"Cannot hallucinate" means "cannot break the format". Jev only returns answers you allowed, so your code never receives garbage. It can still be wrong, and a wrong answer arrives perfectly formatted. Independent benchmarks place it well below the strongest models on hard reasoning (82.7% on the MMLU-Pro benchmark, 21.9% on Humanity's Last Exam). It is a fast, solid judge, not an oracle.

It does not explain itself. You get a probability, never a reason. Our way around that is to ask many narrow questions instead of one broad one: the explanation then lives in which questions moved the result. When you need a written argument for a specific case, run that case through a generative model as well. At these prices you can afford to do both.

It is consistent. When we re-read our whole archive with partly new questions, every unchanged question gave the identical answer on all 3,084 articles it covered. Good for testing (one run is enough) and for caching; less good if you were hoping a second attempt would fix a wrong answer.

It is a hosted model from one young company. Jev runs on TypeSafe's servers, so your text leaves your environment, and the pricing may still change. Open alternatives appeared within weeks (Cloudflare's Clef, Perplexity's Decider, and several community versions), which matters for clients who need to keep data in house.

The quickest way to find out whether a decision model belongs in your stack is to look for language models that are already making decisions. Many AI applications contain a call that asks a chat model for a category, a score or a yes or no, and then parses the text it writes back. Each of those calls is a candidate. Rebuild one with a handful of sharp questions, run both versions over a few hundred real records, and compare cost, speed and how well the confidence separates the easy cases from the hard ones.

The second place to look is the text column nobody analyses: complaint descriptions, call notes, free-text survey answers. Those columns used to need a data science project before anyone could count anything in them. Now they need a well-written questionnaire.

That shift is why we think decision models will matter beyond the excitement of their launch week. They move the hard part of applied AI from building a model to asking a precise question, and asking precise questions is something every domain expert can learn.