TL;DR: Where JEV fits against a generative model
The Challenge:
Many LLM calls ask for a decision, not text.
Key Takeaways:
- Typed Answers: JEV returns choices, scores, and probabilities.
- Built-In Discipline: It replaces guardrails teams coded by hand.
Bottom Line: Save the generative model for work that needs language.
Heard about JEV? Here’s why it’s making waves, and why we think the real story is less flashy than the hype. The generative model should be saved for the work that actually needs language.
Most LLM calls in a typical AI production AI workflow aren’t really asking for text. They’re asking for a decision: route this ticket, flag this transaction, approve this tool call. Yet we keep sending those decisions to conversational models and parsing the prose back into JSON.
JEV, TypeSafe AI’s first “System One” model, flips that. Instead of a system prompt and a text response, you pass it two things:
1️⃣ State: unstructured text, JSON, or logs
2️⃣ One or more typed questions: Choice (pick from options you define), Score (a position on a rubric you define), or Noul (a probability between 0 and 1 for a yes/no question)
JEV evaluates every question against that state in a single parallel pass and returns typed answers with probabilities. No text generation. TypeSafe reports response times of a few hundred milliseconds.
The developer pattern
Treat JEV like a fast, unexpensive, probabilistic logic gate inside your code:
- Bundle your questions with the payload
- “Is this account locked?” → Noul
- “Customer frustration” → Score
- “Routing queue” → Choice
- Send one request to JEV’s decision endpoint
- Branch on the result: high confidence routes itself, low confidence goes to a human
Our GAP assessment
JEV is not a revolution in agentic architecture. Separation of concerns, single output prompts, and schema enforcement were already feasible (and recommended) when building enterprise solutions on generalist LLMs.
The difference is execution. Before models like JEV, developers had to build those guardrails by hand, even with today’s current automation to support, which is generally inefficient. We were prompting a conversational engine to fake a software primitive, spending time, latency, and tokens generating text just to strip it back down to JSON.
JEV bakes that discipline into the runtime. You get the exact primitive your code needs (a classification, a probability, a ranked option) with real gains in latency and cost, allowing for a gate that used to be too slow or too expensive to run on every request to turn into something you can run on all of them.
Where we see it fitting
When we review an AI workflow, one of the first questions we now ask is: which of these model calls are really decisions? Routing, triage, approval gates, and guardrail checks are the obvious candidates. Those steps belong in a decision model. The generative model should be saved for the work that actually needs language.
How the community is using it
The awesome jev list on GitHub already catalogs roughly 680 public projects, integrations, and discussions (see image). The biggest clusters are infrastructure, SDKs and integrations (124), classification and routing (76), agent decisions (66), and verification and guardrails (62). Compliance and legal (6) and finance and trading (10) are still nearly empty.
👉 https://github.com/yibie/awesome-jev
So, are you using JEV or something like it? Which decisions in your stack are you still paying a generative model to make? Please share your thoughts and usage!
#AI #AIEngineering #LLM #AgenticAI #SoftwareArchitecture
