Jev returns typed answers for routing and scoring tasks

A support router may need only one word from a model: the name of the team that should receive a ticket. Asking for a paragraph and extracting that word adds work without necessarily improving the decision. The more interesting problem starts after the answer is easy to parse: did the ticket reach a team that can help, or did a neat response merely send it to the wrong place?

Jev, introduced by TypeSafe on September 15 as a System One model, is built for bounded judgments of this kind. An application supplies the information to assess, called the state, and questions with specified answer types. The service returns structured answers and probability information. A queue recommendation can therefore arrive in a form code can consume directly. Following one ticket through that exchange shows both the attraction and what remains for the application to establish.

Choice, Score and Noul answer different questions

The input is deliberately narrower than a general multimodal assistant. TypeSafe’s System One documentation says Jev accepts text, JSON objects and arrays of text, but currently no images, audio or video. It does not generate code or explain its reasoning in prose. Instead, the application chooses the type of judgment it wants back.

The three documented primitives divide that work into Choice, Score and Noul. Choice selects among supplied alternatives, such as queues. Score evaluates information against a rubric describing the score levels. Noul returns a zero-to-one value for a yes-or-no statement. Choice and Score also include distributions across possible answers and a confidence field, giving application code more to inspect than the selected answer alone.

Primitive	Example question	What application code receives
Choice	Which queue best fits this ticket?	A selected option, probabilities across options, and confidence.
Score	How well does this report describe a reproducible failure?	A score against the supplied rubric, probabilities across levels, and confidence.
Noul	Does this ticket describe an authentication failure?	A zero-to-one value for the statement.

These questions share input, not a reasoning chain. TypeSafe says each is evaluated independently against the state in a request. An answer to one does not become evidence for the next. If routing genuinely depends on a prior decision, the application needs to compose those steps explicitly; putting both questions in one call does not create that dependency.

A token-rotation report enters the router

Consider a hypothetical ticket: “My access token was rotated this morning. The dashboard still loads, but every API request returns 401.” The support application asks which queue should investigate and, separately, whether the report concerns authentication. Neither question authorizes a credential reset or account change. They define an initial routing judgment that a program can use.

This illustrative request uses the shape documented in TypeSafe’s quick start. Its input is synthetic, and its queue criteria include triage. That last option matters: a report that lacks evidence or fits none of the specialist queues should have a representable destination rather than forcing a false choice.

{
  "model": "jev-latest",
  "state": "My access token was rotated this morning. The dashboard still loads, but every API request returns 401.",
  "questions": {
    "queue": {
      "type": "choice",
      "instructions": "Select the queue that should investigate this report.",
      "criteria": {
        "access": "Authentication, credentials, or authorization failures",
        "application": "Application behavior unrelated to access",
        "network": "Connectivity or transport failures",
        "triage": "Insufficient evidence or no suitable specialist queue"
      }
    },
    "authentication_related": {
      "type": "noul",
      "instructions": "The report describes an authentication failure."
    }
  }
}

The documented POST https://api.typesafe.ai/v1/systemone endpoint returns an answer for each question. The request is an integration sketch, not a tested prediction about where Jev would send this ticket. In a trial, retain the versioned model returned by the service as well as the requested alias. An alias such as jev-latest is convenient, but by itself cannot establish that two later runs used the same model.

The next step belongs to the application. Resolve the recommended queue against its existing directory, preserve the report for the recipient and check that the destination is usable. The model need not invent a team or an address. If the directory changed or the selected queue is unavailable, the established triage path can carry the ticket forward.

“Network” can be valid and still unhelpful

The launch post describes schema matching as a guarantee, so a Choice response is constrained to the defined answer space instead of returning an arbitrary string. This solves a real integration problem. The same post explicitly separates its zero figure for schema-related hallucination from an empirical claim of overall factual accuracy.

In the hypothetical example, network is an allowed output. Choosing it for an authentication report could satisfy the schema perfectly and still cost the user another transfer. A type constraint tells code how to handle the answer. The content of the report and the queue criteria determine whether that answer was a useful judgment.

The numbers accompanying it need similarly careful interpretation. TypeSafe’s confidence documentation defines confidence as a statistic derived from the returned distribution. A concentrated distribution expresses a more definite preference among the options supplied. It is neither simply the winning option’s probability nor a universal probability that this particular routing decision is correct.

To assess calibration, examine groups of labeled predictions: do stronger stated probabilities correspond to more correct choices on representative tickets? Keep unfamiliar product names, sparse reports and conflicting symptoms visible beside short, familiar requests. Averaging them together can conceal the cases where the router is most likely to need a person.

Routing cost includes transfers and triage

TypeSafe reports large speed and cost improvements in its own evaluations, while disclosing that several workflow comparisons use other models’ predictions as reference probabilities. Agreement with those references answers a different question from independently verified correct routing in your service. The launch results justify examining the interface; the team’s labeled tickets are what can establish its local value.

The alternatives deserve the same task. Hugging Face’s zero-shot classification interface accepts text and candidate labels without training on those exact labels. A conventional classifier, deterministic rule or LLM with structured output may also fit. Neither Jev’s launch comparison nor an unrelated community benchmark determines which will complete this team’s routing work best.

Our synthetic report may be simple enough for a maintained rule covering token rotation and 401 responses. A semantic model becomes more useful when people describe symptoms differently, combine conflicting clues or need nuanced label criteria. Run those varieties through the same labeled set and preserve disagreements, so the comparison reveals where the extra capability is buying something.

Measure time and cost through an accepted routing outcome, including transfers, corrections and human triage. That is the accounting developed in our agent cost and quality guide: an inexpensive attempted decision is useful only in relation to the work it successfully completes. If lower call cost creates more bouncing between teams, the total router may have become more expensive to operate.

Where Jev fits in an existing router

Begin by leaving the established router in place while Jev proposes destinations for sanitized, team-labeled examples. Include clear reports, missing symptoms, unfamiliar language and cases without a suitable specialist queue. Keep the input and queue definitions with the model version, answer, probabilities, latency and reviewed destination. A disagreement then has enough context to ask whether the problem was the input, the choices or the model’s judgment.

Also record what happened after selection. A correct recommendation delivered to an unavailable queue is an application failure, not evidence that a different classifier is needed. At the other extreme, sending almost everything to triage may avoid misroutes while saving little work. Both belong in the same outcome record because both affect how much useful routing the system provides.

For the token-rotation ticket, Jev supplies a queue choice that application code can read directly. The directory lookup, delivery and any later transfer determine whether that choice saves work. If correction and triage erase the saving, the existing router remains the better option for those reports. A team can still use Jev for ticket classes where the complete route takes less effort, leaving ambiguous reports with its established triage process.