0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

How Teams Replace Paragraph Judgments With a Typed Decision

0
Posted at

Most teams that ship an LLM judgment today do it the same way: they hand a model some text, ask for a verdict, and get back a paragraph. Then they immediately regret the paragraph. Somewhere in those three or four sentences is a word that means "yes" or "no," and the only way to extract it reliably is to beg the model to end with a single token, parse the result, and hope it didn't slip a "not" in there or wrap the whole thing in a JSON block that isn't valid JSON.

That workflow is brittle, but the instinct behind it is sound. Teams don't usually want prose. They want a value they can branch on. A support ticket is either a billing issue or it isn't. A review is a four out of five. An incoming request is safe to route to the fast path or needs a human. When the output you actually consume is a label, a score, or a probability, the prose in between is overhead you are paying to generate and paying again to strip out.

The problem is the output shape, not the model

The interesting realization is that this is not a prompting skill problem. No amount of "reply with only the word yes or no" turns a generative model into a reliable classifier, because the model is still generating tokens and you are still decoding them into meaning by hand. The failure mode is built into the contract. You asked for text and got text; the fact that you only needed one bit of that text is your problem to solve.

A typed decision inverts that contract. You specify the question up front, in a fixed schema, and the model's job is to return a probability, a label, and a score for each question you asked. There is no paragraph to parse, no JSON to rescue from prose, no streaming tokens to assemble. One request asks up to twenty questions about a single piece of text, and the response comes back as structured values you can feed directly into an if statement or a routing table.

This is exactly what Jev AI is. Jev is TypeSafe AI's System One decision model, released in early access in September 2026. It is not a chat model and makes no attempt to be one. It answers typed questions about text and returns probabilities, labels, and scores. There is no prompt tuning, no conversation, no coaxing. You declare the question type—a yes/no judgment (called noul), a choice among categories, or a numeric score—and the model fills in the answer.

Start with one real decision before writing code

The cheapest way to find out whether a typed decision fits your problem is to run one by hand before you touch an endpoint. The playground is built for exactly this: paste a piece of text, define a question or two, and look at the labels and probabilities that come back. Treat it as a design exercise. If you cannot express the decision you care about as a clear yes/no, a choice, or a score, that's a signal you were about to bolt a classifier onto something that's actually a summarization or drafting task.

Click Here to try that first decision in the playground. New accounts get a small number of welcome credits, so you can validate the shape of the answer against a handful of real examples before spending anything. The trial exists to let you see the output shape, not to run production volume for free—TypeSafe stopped handing out free credits to new signups in late September 2026, and the free tier is a playground trial, not a production plan. Go in knowing the difference.

The value of that five-minute check is mostly about your own specification. Write out your twenty candidate questions and score them against each other before you call the API. The hard part of this kind of work has never been the model call; it's deciding what "escalate" means for your business and whether two of your categories overlap enough that a single question is ambiguous. A structured answer exposes that ambiguity immediately, because you can't hide it in a paragraph.

Pick a model deliberately

Once the decision is specified, the model choice is mostly about determinism versus currency. The pinned default is jev-1.13, and the rolling alias is jev-latest. Pinning gives you a fixed model so a deploy doesn't silently change behavior under your thresholds; the alias tracks updates but should not be the thing your production routing depends on without versioning discipline. Context length is 32,000 tokens, and the single endpoint is a POST to /api/v1/systemone/. The details on both model options are documented at Jev AI Model.

Latency matters here because typed decisions usually sit in a synchronous path—a ticket triage step, a guardrail before another LLM call, a filter before a human reviews something. The homepage reports a median upstream answer around 0.22 seconds and the docs describe typical latency around 0.2 seconds, which is the right neighborhood for decisions that happen inside a request or a short pipeline rather than a background job.

Practical advice for adopting this

Treat the API key like a server secret, because it is one. Keys are created in Settings, shown exactly once, and start with sk-glm5-. If it ever appears in a browser bundle or a client-side log, rotate it. Decisions you want to branch on belong behind your own service boundary, not in the browser.

The pricing model is worth understanding before you estimate cost: you pay for input tokens only, output tokens are free, and yearly plans run about half the monthly rate. The lowest published example run cost starts at a fraction of a cent. That structure is friendly to high-volume classification because you are charged for the text you send in, not the labels you get back.

None of this is magic, and it is worth being clear about what it is not. It is not a model you use when you need an explanation, a summary, or a draft. It is a model you use when you need a label, a score, or a probability instead of a paragraph—support-ticket triage, content moderation, intent routing, review and lead scoring, guardrails in front of other LLM calls, citation checks, résumé screening. The unifying feature across those use cases is the same: somewhere downstream, code branches on the answer.

The teams that get the most out of a typed decision are the ones that stop treating classification as a prompting problem. They specify the question, pin the model, keep the key on the server, and let the paragraph disappear. What's left is a number, a label, and a probability—exactly the three things their code was waiting for.

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?