The Rise of Judgment Models: How Jev Uses Probabilistic Decision-Making to Reinvent Enterprise Automation

A New Paradigm for AI Models

The AI industry has been dominated by large language models (LLMs) for the past few years. Since ChatGPT launched, nearly every conversation has centered on making models generate better text. But a new class of architecture called Judgment Models is proposing something fundamentally different: instead of producing long-form text, these models output probabilities for specific questions.

The model in question is Jev, from startup Typesafe. Its core capability isn't "writing" — it's "judging." Is this customer angry? Does this email introduce new dependencies? Does this draft make claims the source material doesn't support? Jev's answer isn't a paragraph — it's a number between 0 and 1, or a set of classification probabilities.

Jev co-founder Diogo Almeida (who describes himself as one of ChatGPT's co-inventors) posted on X that he spent two years developing a new training method called RLCD (Reinforcement Learning for Calibrated Decisions). The performance numbers he's claiming are aggressive: 20 to 200 times faster than LLMs, 40 to 400 times cheaper, with output tokens that are free.

What Actually Makes Judgment Models Different

Faced with claims like "200x faster, 400x cheaper," skepticism is warranted. But the key point is that Jev is not another LLM — it's an entirely different technical stack.

Typesafe explains in their blog that existing LLMs are optimized for "human preference" — the kind of writing and conversational responses that human raters prefer. Models like Jev are optimized for "calibrated decisions" — epistemically honest probability answers.

Every's Mike Taylor offers a useful analogy: think of it as a smart if-then statement. Say you're building a customer support ticket prioritization system. You ask the model, "Does this customer sound angry?" Jev might return 0.9, meaning there's a 90% chance the customer is angry. You can also define custom categories — irritated, offended, angry, furious — and learn that the customer has a 60% chance of being "angry" and only a 10% chance of being "furious."

The contrast here is sharp: if you ask a chatbot the same question, it'll reply, "You're right, this customer does seem upset — would you like me to help draft a friendly response?" That polished text will immediately break your program, because the program expects a number between 0 and 1, not an essay.

It's worth being clear about the trade-off: Jev doesn't generate text. It's not a replacement for LLMs — it replaces a specific category of work that LLMs have been awkwardly pressed into handling, like hammering a square peg into a round hole.

A note on "Calibrated Decisions": This concept comes from probability theory and decision theory. A "well-calibrated" probability judgment means that when a model says something has a 70% chance of occurring, it actually happens roughly 70% of the time across a large number of similar predictions — not that the model confidently says 90% when the true rate is only 50%. Traditional LLMs, after being aligned through RLHF, tend to produce answers that sound confident and assertive, because those answers tend to score higher with human raters. But this causes probability estimates to become distorted. RLCD is designed to do the opposite: using reinforcement learning to directly reward "honest uncertainty" and penalize both overconfidence and excessive hedging, so that the model's output numbers genuinely reflect its confidence level. This calibration is critical in scenarios where downstream programs need to make decisions — a programmer can set entirely different trigger rules based on the difference between a 0.9 and a 0.6 probability, whereas a vague natural-language description can't be reliably automated.

Which Business Processes Can It Plug Into?

How much office work comes down to "read some content, then decide what to do next"? Does this message need a reply? Which department should handle it? Did this document answer the question? Is the customer describing a bug or a feature request? These are all judgments about meaning — and they're notoriously hard to capture in fixed rules.

Jev is designed to take in relevant information, return a narrowly scoped answer as a probability, classification, or score, and then let the surrounding software handle routing, ranking, flagging, or advancing the workflow. Typesafe's documentation explicitly recommends breaking complex decisions into small questions and using code to combine the results.

Practical use cases aren't hard to imagine:

• Customer support: Assess whether a customer is frustrated, whether a previous reply failed to resolve the issue, and decide whether to reroute, escalate priority, or transfer to a human agent.
• Sales leads: Determine whether an inbound message is a purchase inquiry, whether the prospect is a product fit, or whether they're requesting a meeting — for scoring and routing inbound leads.
• Marketing and editorial: Assess whether copy adheres to specific style guidelines, whether an offer is communicated clearly, and flag paragraphs that need revision before publishing.

YC founder Nathan Flurry describes a typical workflow: the LLM proposes options, Jev makes the decision, and code handles execution. For example, a customer writes: "This is the third time I've reached out and we still can't export reports — and our renewal is next week." A Jev-powered workflow could simultaneously ask: Is this a product issue? Does the message indicate multiple failed attempts to get help? Is there a commercially significant deadline approaching? Which team is best equipped to handle this? The software then combines that with real account data (like the renewal date) to escalate the ticket.

Cheap Enough to "Check Everything"

Low-cost judgment unlocks something that previously wasn't practical: frequent checking. If a single check introduces noticeable latency or expense, teams often run it only on a subset of cases or at the end of a task. When it's fast and cheap enough, you can run it on every request, every draft revision, across large batches of candidate documents.

Mike Taylor ran an experiment: he fed Jev all 27 of his own articles along with 10 deliberately AI-written comparison pieces, then fired the same 21 questions at all the documents in parallel to detect an "AI feel." The questions included: Does the text repeat a point without adding supporting evidence? Does it force a symmetrical "both sides" argument? Does it over-explain simple points?

The result: in under 0.7 seconds, Jev "read" all 37 documents, answered 21 questions for each, returned 777 total judgments, and the estimated cost was about a quarter of a cent. That's fast and cheap enough to run an AI check on everything everyone at a company has ever written and get results instantly.

Taylor compared it to a "linter for knowledge work" — in software development, a linter can near-instantly flag syntax errors, catch bugs, identify bad patterns, and enforce style conventions. Pair Codex or Claude with Jev and a checklist of questions, and AI can quickly verify whether its own output violates whatever constraints you've set.

Matt Stockton offered another interesting perspective: many business problems are fundamentally classification or regression problems, and many companies don't realize these can be solved with classical machine learning — so they handle them with headcount and manual processes. The classical approach requires labeled data, model training, and deployment infrastructure, with a much higher barrier to entry than calling an LLM API. From this angle, Jev is essentially "classical ML capabilities with LLM-style UX."

A note on classification and regression: The two most fundamental task types in machine learning. Classification assigns inputs to discrete categories — for example, determining whether an email is spam. Regression predicts a continuous value — for example, estimating the probability a customer will churn. Most business decisions can in principle be reframed as one of these two problems. But the traditional ML pipeline involves data collection, manual annotation, model training, hyperparameter tuning, and deployment — a process that typically requires a data science team and can take weeks or months. LLMs made it possible to describe tasks in natural language, but their free-text output isn't naturally machine-parseable, and their cost and latency are relatively high. Judgment models aim to fill the gap between these two worlds: they preserve the convenience of describing requirements in natural language, while constraining output to structured probabilities that programs can consume directly — approaching the output format of traditional ML without requiring labeled training data.

From Individual Tools to "Multiplayer" Intelligence

Is this kind of capability for individuals or teams? The answer is both — but it highlights the "multiplayer AI" theme that's been gaining traction in recent discussions.

Individuals can use it to sort their inbox by personal priorities, check drafts against editorial rules, or rank saved articles by research interest. But where it really shines is in team collaboration. When an AI agent serves a single person, learning that person's preferences is enough. When it operates across teams, it needs to understand the relationships between people's work: Who owns this? Whose work is affected? Is someone waiting on this decision? Does this commitment create obligations for another team?

A classic example: a salesperson tells a customer, "We should be able to support that integration before your renewal." For the salesperson's personal AI agent, the next step is simple: update the account record, draft a follow-up, create a reminder. But inside the organization, that sentence carries multiple responsibilities: a delivery commitment of uncertain work for engineering, a potential roadmap priority change for product, and a managed expectation for customer success. A judgment model could evaluate: Does this message imply a delivery commitment? Does the commitment involve work outside the speaker's authority? Does it conflict with the provided roadmap? Is there evidence the relevant teams agreed?

An Incomplete — But Important — New Category

It's worth acknowledging the inherent limitation of judgment models: by definition, they're incomplete. They can't carry the full workload of generative AI today. They're destined to be just one component in a more complex model stack — the "model stack" architecture that's been a recurring topic of discussion over the past few months.

But their advantage is extreme low cost, which makes them exceptionally easy to integrate into all kinds of processes. Risk, fraud detection, content moderation, PR QA, lead scoring, compliance, workflow orchestration, agent routing — all of these are potential use cases.

Jev just launched, and whether this concept can sustain a genuine product category still needs time to prove out. But the deeper you look at it, the more it has that quality of something that feels both important and obvious — the kind of thing that, once it exists, makes you wonder how we got along without it for so long.

A note on the "Model Stack" architecture: An emerging design paradigm in AI engineering, built on the idea that different task types should be handled by different specialized models in layers, rather than routing everything through a single general-purpose large model. A typical three-layer structure includes: a generation layer that produces candidate content or options (usually handled by an LLM); a judgment layer that evaluates and filters (where judgment models fit naturally); and an action layer that executes and calls external tools (code or API calls). The motivation for this division is the cost-quality trade-off — calling a general-purpose large model for every task creates unnecessary expense, and some tasks (like binary classification) simply don't require generative capability. The judgment model's value as a middle layer lies in its ability to perform high-frequency, low-cost quality checks on the generation layer's output, or to make routing decisions before the action layer is engaged — letting the overall system maintain accuracy while dramatically reducing operational overhead.