TypeSafe Jev: first impressions of typed AI decisions in production

For years we used chat models to do the job of an if.

Classify an email. Score a lead. Say yes or no on an incomplete order. Decide whether a piece of text matches a rule we own. In production that does not want a paragraph. It wants a verdict, a probability, a threshold. Then code decides.

Yesterday TypeSafe AI took me off the waiting list. I got my hands on Jev, their first public System One Model. Not another chatbot. A model that takes a state (text or JSON) and typed questions, and returns Choice, Score, or Noul: closed options, ordered levels, yes/no probabilities, with confidence. Code still owns the flow. Jev is the smart if.

The first impression was easy to name: finally a tool I can picture using cheaply to classify, make sharp decisions, score things, bound to my own requirements, without paying for a conversation every time I need a bit.

What hit me (and what I am not selling)

Jev does not generate strings. It does not write the email. It does not invent a field outside the schema. You define the options. It spreads probability over those options. Then you, in code, set thresholds: above I act, below I send to review, lower I stop.

TypeSafe talks about RLCD (Reinforcement Learning for Calibrated Decisions), not RLHF. For people building products, the paper is not the point. The contract is: typed output, confidence you can route on, latency and price built for automation. Their docs list about $42 per billion input tokens, output free. The "hundreds of times faster/cheaper" multipliers I leave on their site: vendor evals. I only need the order of magnitude.

One thing has to be said plainly, or it becomes marketing. Type-safe does not mean "the same answer bit for bit every time". It does not mean zero judgment errors. It means: no values outside the schema, probabilities and confidence as levers, and the right to still be wrong, inside a perimeter software can handle. I would call it typed decisions, near-deterministic with thresholds. Not a miracle.

The stack I care about

The pattern in my head is this:

1. Something upstream extracts or collects (LLM, regex, OCR, parser, form).
2. Jev looks at that state and answers typed questions in parallel.
3. Code applies thresholds, updates the DB, opens tickets, blocks, approves.

The LLM stays useful where language is messy: pull fields from a badly written order, summarize, propose candidates. Jev steps in where you need a serious supervisor: are the fields complete? does the extraction hold? is the result compliant with our standard? does that operation exist in the catalog?

Below, ten places I can see it land without inventing science fiction.

Ten concrete cases (and a few more)

1. Metal shop, messy orders.
An agent (or an LLM) gathers mail, PDFs already turned into text, WhatsApp notes. Extracts quantity, material, tolerances, dates. Jev supervises: Noul on "data complete", Score on how solid the extraction looks, Choice on "compliant / needs clarification / reject", Noul on "operation exists in master data" with the DB list inside state. The specialist assistant can even draft a purchase order. Jev validates: Excel/CSV compatible with the internal standard? required fields ok?

2. Email classification SaaS.
Choice on spam / invoice / support / sales / other, with your requirements written into state. Noul on "looks like phishing" or "contains a payment request". Low confidence → human quarantine. Here the chat-LLM cost per message is the problem. A typed decision is the product.

3. Support ticket triage.
Intent routing: billing, bug, onboarding, legal. Score urgency. Noul "enterprise customer". The bot does not need to write a novel. It needs to route right.

4. Guardrails on LLM output.
Before you publish or send a generated reply: Choice on tone (ok / aggressive / off-brand), Noul on "contains PII", Noul on "promises something outside policy". Official TypeSafe cookbook. Makes sense.

5. RAG that does not eat garbage.
Retrieved passages → Score relevance, Noul "looks like injection / foreign instruction". Drop before generate. Fewer wasted tokens, fewer invented answers downstream.

6. Citation check.
Model claim vs sources in state. Noul "supported by the passage", Choice "citation correct / partial / missing". Useful when you publish things someone can quote against you.

7. KYC / compliance on already-textualized documents.
Parser or OCR upstream. Jev: Choice document type, Noul required fields present, Score identity consistency vs internal record. Not "upload the PDF and magic": text in, decision out.

8. Moderation and brand safety.
UGC, comments, ad copy. Choice risk categories. Different thresholds per market or client. Same model, different policy in code.

9. Record matching / entity alignment.
Two similar records. Noul "same subject", Score match confidence, Choice "merge / keep separate / send to human". Classic place where a chatty LLM costs money and invents.

10. Typed function calling.
Choice on which tool to call, Choice/Score on allowed arguments. Fewer malformed JSON blobs. Fewer "I called the wrong API creatively".

11. B2B lead scoring.
State = firmographics + behavior. Score fit, Noul "ready for sales", Choice bucket. The CRM does not need an essay.

12. Hierarchical classification for products / tickets / patents.
Cascaded Choice tree. Noise outside the branch cut in code, not "explained" by the model.

What I still do not know (and will not invent)

Vision? Not today. Text / objects in. If I need an image, OCR or a vision model upstream, then text/JSON into Jev.

Native PDF? No. Same pattern: extract, then decide.

Memory across calls? Not a product feature. If you need history, you pass it back in state. No free "I remember last session".

Context? Yes, per request. Limits around ~64k tokens/request on jev-1.13, with tighter caps on state + long question (docs). Fill it with noise and it gets worse. Filter in code. Not a new problem: same smell as context rot, only here it hurts more because Jev will not "fix it" by inventing prose.

Italian / other languages? Docs: English best, other languages ok but measure. Before I trust production IT, I measure.

Official jaggedness: do not make it do serious arithmetic, complex dates, indirect multi-hop. Split the work. Keep the math in code. Conditions are read literally. Vague requirements get vague judgments with a pretty confidence number: worse than a silent bug.

Why I care now

Half the "AI" apps I see are a generic LLM glued where a classifier with thresholds belonged. Works in a demo. In production it burns tokens, changes its mind between calls, and nobody knows where to put human-in-the-loop because there is no honest confidence on the table.

Jev does not solve the whole product. It solves (or at least attacks) the typed-decision layer. The rest is still engineering: extraction, store, policy, UI, data ownership.

For now I have the waiting list behind me and the playground in front. I am already mentally wiring supervisors onto flows that today pay for chat to get a yes/no. Native vision and PDF I will wait for. Memory I will build myself.

If you are looking for "deterministic AI", "classification in production", "token efficiency", or a place to put a supervisor on top of a chatty extractor: this is the stack piece I was waiting to touch. Then you measure. As usual.

Tell us the context, constraints, and goals: we will tell you whether it makes sense to work together and how to set the first step.

Email hello@snowinch.com