Jev and System One Models: how forms and UIs can become intelligent

Dieser Blogpost ist auch auf Deutsch verfügbar

System One Models answer questions about free text with an option from a fixed list plus a probability, in a few hundred milliseconds and without training data. That makes judgments worthwhile where they used to be too expensive or too slow, such as form fields, results lists, and tickets. We show nine places where we would start.

With this post, we mainly want to give you ideas. After a short explanation of how System One Models work, we walk through places in UIs and forms where we would use them. Our hope is that you’ll spot similar places in your own application along the way. You won’t find benchmarks of our own here. Where we quote figures, they come from a hands-on test by an INNOQ colleague. We’re also not making a recommendation, simply because it’s too early for that.

What a System One Model is

A System One Model takes a state and a typed question and returns a value your code can use directly. The state is the text or data the model is supposed to judge. The difference from a language model is easiest to see at the call site. There’s no prompt asking for an answer in a particular shape, and no parser behind it hoping the shape was kept. Instead, each question gets an answer back that looks roughly like this:

{
  "answers": {
    "activity": {                    // the ID we asked the question under
      "choice": "design",            // the most likely option
      "probabilities": {             // how the probability is distributed
        "design": 0.81,
        "implementation": 0.13,
        "not_determinable": 0.06
      },
      "confidence": 0.71             // condenses the distribution into one number for thresholds
    }
  }
}

The model class is named after Kahneman’s System 1: the fast, intuitive judgment a knowledgeable person makes within a few seconds. The model delivers that kind of narrow judgment, with no derivation and no sentence explaining it. In this picture, reasoning models are the counterpart. They work through a chain of intermediate steps before they answer. With System One Models, that decomposition happens in your code instead.

TypeSafe AI, a young seed-stage company, introduced the category on September 15, 2026, together with the first model of its kind, Jev. Access has changed several times since. It started with a waitlist, then sign-up was briefly open to everyone, and since September 22, new sign-ups have been paused due to demand. Existing accounts keep working. You can also call Jev through gateways such as OpenRouter or the Vercel AI Gateway, without a TypeSafe account of your own. Within days of the announcement, several open reimplementations appeared as well. They offer the same interface on top of freely available models, which lets you try the principle locally. Keep in mind that they run on smaller models, and their measurements aren’t directly comparable with Jev’s.

We got our access while the original waitlist was still running and spent a few days building with jev-1.13.0. That isn’t enough for solid statements about the quality of the judgments, but it is enough to get a feel for what you can build. We don’t work with TypeSafe AI: we paid nothing for access and received nothing for this post.

Why this has rarely paid off so far

Judgments over free text aren’t new. They were rarely built anyway, for two reasons, and in recent years the second has replaced the first.

For a long time, the only option was a fine-tuned model of your own. That requires a labeled dataset, a training run, and a deployment. Above all, it requires someone who knows how to do it, and the willingness to operate the result for years. When the business side later wants to add a category, the cycle starts over, and a small request turns into a ticket that runs for weeks.

That effort pays off for a central feature, such as fraud detection or a document classification an entire business process depends on. It never pays off for a small improvement to a form field. So those improvements didn’t get built. Nobody thought they were pointless. They just never survived an effort estimate, and before language models came along, most of them were never even proposed.

Language models removed that effort. A prompt takes ten minutes to write, and the value range lives in the text, where you can change it from one day to the next. But they brought a different problem, and in a UI it matters more: waiting.

Depending on the class, a language model takes anywhere from just under a second to several seconds for this kind of classification. For a nightly batch job, that doesn’t matter. In an input field, it’s long. By then the user has kept typing, left the field, or already hit save. A suggestion that shows up after that only gets in the way, because it changes something the user already considered done. If you’ve ever tried to build autocomplete on top of a language model, you know the pattern: it works in the demo and falls apart in daily use.

Then there’s the probability. Unless the API exposes token probabilities, a language model writes the number into the JSON as part of the generated text. And what that number is supposed to mean, you have to define in the prompt first.

The new model class needs no training dataset and answers in a few hundred milliseconds. According to the vendor, a million input tokens cost $0.042, and output is free. It always returns its probabilities, complete and in the right format. Whether they’re well calibrated is something you have to check on your own data: in our colleague’s hands-on test (in German), the language models it was compared against actually came out ahead. Still, the small improvement to the form field becomes affordable for the first time. More importantly, it can now be proposed. You can bring it to refinement without someone immediately asking who’s going to train that.

The three question types

All three question types send the value range along with the question. They differ in what comes back.

Each question consists of an instruction and, for Choice and Score, the options or the ordered levels. There’s no system prompt with examples or formatting rules. Because the value range lives in your code as a dictionary, you change it in the editor and review it in a pull request like any other code. A new category costs one line. In-between values for Score are fine for a threshold check, but the vendor advises against reading them as an exact quantity between two levels.

With Choice, the answer is always one of the options defined in your code. The model can’t make anything up, and you can use the return value without further checks. That has a flip side, though. If you need an escape hatch for unclear cases, you have to add it as an option yourself. Otherwise the answer can never be “I don’t know.”

The model doesn’t explain why it decided the way it did. A language model does write such a sentence, but you can’t be sure it reflects the actual reason. With System One Models, traceability comes from somewhere else: which sub-questions were asked, and which threshold the code uses to reach its decision, is right there in the code.

The number next to the answer

For Choice and Score, the model returns the distribution across all options or levels along with the value. It also returns a confidence field that condenses this distribution into a single number for thresholds. Only Noul has no confidence, because its value already is the probability for Yes. If you only take the most likely option, your application behaves the same in a clear case as in one where two options are close. If you use the distribution, the application can offer a suggestion instead of committing to it, or ask when the case is unclear. Start with conservative thresholds and tune them on your own data.

One source of error that’s easy to overlook sits in Noul questions. A low value can mean that the state says No, or that it says nothing about the question at all. Because the schema has the same outcome for both, the model answers No when in doubt. In the same hands-on test, Jev answered No to all 40 statements the text said nothing about, even though nearly half of them were true.

Since the cause lies in the schema, the remedy is simple: a Choice with an explicit “cannot be determined” option. With that option, Jev recognized all 40 cases without information in the test. A threshold you’ve already calibrated on a Noul doesn’t carry over directly, though. If you come up with a question of your own while reading the examples below, plan for this escape hatch from the start.

What this opens up for UIs

The following places are meant as inspiration. The specific example will rarely fit your application one-to-one, but the question behind it usually carries over.

While someone is typing

The dropdown where everyone picks the top entry. In the time-tracking tool, there’s a dropdown with forty activity types next to the entry description. It’s been maintained for years. Still, half of all entries end up on the first item, because scrolling takes longer than thinking, and the quarter-end report is about as useful as you’d expect.

A Choice over exactly that catalog is all it takes: “Which of these activity types best describes this entry?” The field now comes pre-filled, and anyone who disagrees changes it. Each change shows where the model got it wrong, though not every case: someone who picked the top entry out of convenience will also accept a wrong suggestion. Add a regular spot check, and after three months you have an eval set that would otherwise have needed a project of its own.

The required field that’s only filled in on paper. “Doesn’t work anymore, please take a look, thanks” is forty-eight characters long. The “Error description” field in the support form requires fifty, so you add two exclamation marks and the ticket goes through.

A Noul running while the user types checks the content instead: “Does this text say what the user did before the error occurred?” If it doesn’t, the hint appears right below the field before anyone submits, rather than two days later as a follow-up question. It shouldn’t be more than a hint, though. If the field blocked the text, users would quickly learn which sentences get through.

The form that shows everything at once. A claim form has just over thirty fields, but depending on the case, only about ten of them matter. Since nobody ever defined the cases cleanly, the user sees all of them anyway and fills half with “n/a.”

Often, the first two free-text entries already reveal what it’s about, and a Choice on those is enough: “What type of claim is this?” The code then shows the fields that belong to that type. This isn’t without risk. If the wrong set of fields appears, it costs the user more time than seeing all of them would have. So we’d only hide fields when the probability is high, and show everything when in doubt.

The duplicates you only notice afterwards. “Do these two entries refer to the same thing?” The best time to ask this is while someone is creating a new contact or part, because the same entry often already exists under a slightly different spelling. An exact search won’t find it, and string similarity produces too many false positives to show in the UI. So a rough pre-search first returns a handful of candidates. They go into the state together with the new entry, and in the same call, one Noul per candidate references that candidate’s key. The hint shows up while the user is still typing, and the nightly cleanup job has less to do.

When someone looks at a list

The subject line that says nothing. In the ticketing system, every fourth ticket is titled “Problem,” “Question,” or “Urgent.” In a fifty-row overview, you have to expand half of them to find out what they’re about. A Choice over the topics that actually come up in the project, plus an escape hatch for everything else, fixes this: “What is this ticket about?” The result appears as a label next to the original subject line.

The attachments nobody can place. A case has seven files attached, all named something like scan_0043.pdf or IMG_2291.jpg. Whoever handles it opens them one by one until they find the invoice. Send the text of each file to a Choice that asks “What kind of document is this?” and the list can show the type next to each file name. Since Jev only processes text, scans and photos need to go through OCR or a vision model first. The options are the document types that occur in the process: invoice, delivery note, correspondence, photo, contract, and unclear.

The search that always finds something. Every results list has a top hit, but you only find out whether it’s any good after you click. In an internal knowledge base with two thousand documents, you click in vain fairly often, especially since the list looks the same for a good query and a bad one.

Here, two questions go into one request. A Choice over the candidates provides the ranking through its distribution, and a Noul asks alongside it: “Does any of these documents answer the question?” You need the second question because the probabilities of a Choice add up to one, so something always lands in first place, even when nothing fits. Only the Noul lets the search say that it has nothing for this query.

The suggestion list with no real order. Below each article in a knowledge base, there are five related posts. They’re found through shared tags and sorted by creation date, because nobody ever defined a better order. One Noul per candidate in the same call is enough: “Does this article go deeper into a topic from the current article?” The code then sorts by the result but keeps all five in the list, since a new order is easier to justify than a hidden entry.

When something slips through

The comment that contradicts the approval. In a purchase approval workflow, the team lead clicks “Approve” and writes in the comment field: “Please check the quantity, 500 instead of 50?” The workflow only looks at the status, so the order moves on to purchasing. The comment stays in a field nobody along that path opens again.

If a Noul checks on save whether the comment contains an objection or reservation, the approval can be flagged “with reservations” when in doubt, and whoever created the order is notified right away. People still make the decision. The reservation just doesn’t get lost anymore.

Where the limits are

What the nine cases have in common is that a model error does little harm and is easy to correct. Not all of them are entirely without consequences, though: in the form, fields disappear from view, and with the comment, a notification goes out. A better yardstick is the three criteria from the hands-on test linked above. A decision is a good fit if it has few consequences, is cheap to correct, and doesn’t rest on an unexplained model judgment alone. As soon as the end result is a booking, an approval, or a rejection, at least one of these criteria is violated.

Whatever is in the state has an effect, even when it has nothing to do with the question. In the same test, an irrelevant detail about the person who wrote a ticket noticeably lowered how urgent the ticket was judged to be. TypeSafe itself lists irrelevant context as a known source of error. For the ticket and claim examples, this means filtering customer free text before it goes into a judgment question.

Another limit follows from the missing explanation. Where someone has to justify a decision to a person, for example in an official notice, the one thing that’s required is exactly what’s missing.

For teams in the EU, though, a different question is likely to come up first: where does the data go? Jev runs as a hosted service in the US, and routing through a gateway adds another provider in between. That has to be settled before claims or contact data are sent there. Where it can’t be, the open reimplementations remain as a local alternative.

What about your project?

UIs are just one area where this applies. Later posts will cover decisions in code, where a heuristic or a sprawling cascade of rules sits today, and LLM agents that call the fast model as a tool instead of spelling out every intermediate step themselves.

Your application certainly looks different from our examples, but the question behind them carries over: where have you built around a judgment because it would have been too slow or too expensive? Maybe it’s the required field everyone fills with “see email,” the regex that’s been accumulating special cases for three years, or the results list sorted alphabetically because nobody could build a sensible order.

All figures refer to jev-1.13.0, as of late September 2026. Prices, response times, and the model version may change.