Imagine that you are building the software for a coffee shop. A customer types: "One big coffee with lots of milk, but no normal milk, please." A barista might guess that the customer means a large latte with plant-based milk. The application needs a more careful process. "Big" probably means large, but "no normal milk" does not tell us whether the customer wants oat, soy, or almond milk. An intelligent component can identify the likely intent. The application should then ask a follow-up question before placing an order that requires a specific milk.
Now imagine a 2nd message: "I have waited twenty minutes for my latte. This is the third time. Please sort it out." The shop might need to judge whether to alert a manager, whether the customer explicitly requests a refund, and how frustrated the customer sounds. These are questions about the meaning of ordinary language. Keyword rules are brittle: someone can be angry without using the word "angry," while "I am not angry" contains that very word.
Other questions have exact answers. The payment database tells us whether an order has been paid. The order timestamp tells us how long a customer has waited. Prices and tax rules determine the total. Code and stored data should answer these questions. Some tasks instead require creating new text, such as an apology, a menu description, or an explanation; a generative LLM is useful there. Jev targets a 3rd kind of task: a bounded judgment about messy information, such as which known team should handle a complaint.
Figure 1 gives each component a job. The creative barista represents a generative LLM, which can compose an answer. The order taker represents a decision model: they listen to what the customer says, select likely options from the menu, and flag uncertainty such as an unspecified type of plant milk. The coffee machine represents application code, which carries out precise steps. The order taker does not decide the refund policy; application rules determine which actions are allowed and when to involve a manager.
| Kind of question | Coffee shop example | Starting point |
|---|---|---|
| Exact fact or calculation | Was order 42 paid? How much change is due? | Database and code |
| Meaning of messy text | Does this complaint need a manager? | Jev or another tested classifier |
| New text or explanation | Write a useful apology in the shop's tone | Generative LLM |
These categories are design aids, not hard product boundaries. An LLM with structured output can also classify a message, and a conventional classifier might be enough. Jev proves useful when an application repeatedly needs predefined semantic judgments with probabilities. Measure it against the simpler approaches already available to you.
What goes into a Jev decision
A decision call has 2 ingredients. First, state describes what is happening now: the customer message, order status, elapsed time and perhaps a concise record of earlier delays. State can be a plain string or structured JSON. It is input data, not an instruction to carry out whatever the customer writes. Keep it relevant: a year of unrelated orders can distract from this complaint. Preserve conflicts, such as a database saying "delivered" while the customer says "not received," so that an explicit workflow can resolve them.
Second, the developer defines questions with bounded answers. "Which team?" might allow BARISTA, SHIFT_MANAGER, CUSTOMER_SERVICE, and OTHER. The model assesses the same state against each question, and several questions can travel in 1 request. The request below shows all three question types for the earlier complaint.
{
"state": {
"order": {
"id": 42, "item": "latte",
"status": "not_prepared", "waiting_minutes": 21
},
"earlier_delays": 2,
"customer_messages": [
"I have waited twenty minutes for my latte.",
"This is the third time. Please sort it out."
]
},
"model": "jev-latest",
"questions": {
"team": {
"type": "choice",
"instructions": "Which team should handle this complaint?",
"criteria": {
"BARISTA": "The drink can be fixed at the counter right now",
"SHIFT_MANAGER": "Repeated or serious failure needing a decision",
"CUSTOMER_SERVICE": "Account, payment or follow-up after the visit",
"OTHER": "None of the known teams fits"
}
},
"refund_requested": {
"type": "noul",
"instructions": "Is the customer explicitly requesting a refund?"
},
"frustration": {
"type": "score",
"instructions": "How frustrated does the customer sound?",
"criteria": [
"Calm", "Mildly annoyed", "Frustrated but civil",
"Very frustrated", "Angry, strong language"
]
}
}
}
3 question types
Choice selects from options that the developer supplies (up to 255). For "Which team?" the model cannot invent a department that the application does not recognize. It returns the chosen option, a probability for every option, and a confidence value, so a close call is visible. Include an OTHER option or a review path for cases where none of the known teams fits.
Noul is TypeSafe's name for a yes or no question answered with a probability. "Please sort it out" does not necessarily mean "Refund me," so ask separately whether the customer explicitly requests a refund.
Score places an assessment on an ordered scale that you describe level by level, with at least two and at most ten levels. Levels are numbered from 0, so the 5 frustration levels in the example request run from 0 to 4.. The returned score is probability-weighted and can land between levels. Define the levels clearly and check whether human reviewers agree on example messages. The following numbers illustrate a possible result; they are invented for this article.
team: choice = SHIFT_MANAGER (probability 0.82)
refund_requested: noul = 0.18
frustration: score = 3.2 (levels 0 to 4)Noul in plain language
A Noul is Jev's type for 1 bounded yes or no semantic judgment. It does not return only true or false. It returns the probability that the answer is yes, from 0 to 1. A value near 1 means yes is likely, a value near 0 means no is likely, and 0.5 means the model considers yes and no roughly equally likely. A value of 0.5 does not mean a medium amount of something. Use a Score when the question is about a level, such as how frustrated a customer sounds.
For the earlier complaint, the Noul question "Is the customer explicitly requesting a refund?" might return 0.18. In plain language, that is an illustrative 18% probability of yes and therefore 82% of no. The customer is clearly unhappy, but has not clearly asked for money back. This answer is separate from another Noul such as "Does this complaint require manager review?" The same state can support several precise questions without mixing their meanings. The optional criteria describe what yes and no mean:
{
"type": "noul",
"instructions": "Is the customer explicitly requesting a refund?",
"criteria": {
"true": "Asks for their money back or requests a refund",
"false": "Complains or asks for help, but not for money back"
}
}
Illustrative answer: { "type": "noul", "noul": 0.18 }Define both sides whenever wording could be interpreted differently. "Is this serious?" is vague. "Does this complaint meet the shop's documented conditions for manager review?" is more useful when those conditions are included in the state or criteria. A Noul supplies evidence to code; it does not authorize a refund, an escalation, or any other action. The application still applies its tested threshold and business policy, and it can send uncertain or consequential cases to a person.
A probability is not permission
Suppose the model judges that manager review is appropriate with probability 0.86. The use case compares that number with a threshold configured by the shop. If the threshold is 0.80, it records the result and creates a manager alert. This is application policy, not a command generated by the model. Another action can have another policy: a low-risk notification might be automatic, while any refund needs human approval. A probability of 0.86 is not a promise that this particular judgment is correct. Choose thresholds after testing examples from your own shop and comparing the cost of a false alert with the cost of a missed complaint.
assessment = classifier.assess(complaint)
if assessment.manager_review >= configured_threshold: # Noul probability
notify_manager(order_id)
else:
queue_for_review(order_id)This is pseudocode, not a TypeSafe SDK example (TypeSafe does offer Python and JavaScript SDKs). A probability should also be checked for calibration: among a large set of predictions near 0.8, does the labeled outcome occur about 80% of the time? The right threshold depends on false positives, false negatives, and local test data.
In coffee terms, confidence creates three lanes. "One espresso, please" can go to the barista when the espresso probability is high. "A coffee with milk" should pause so that the order taker can ask whether the customer wants a latte or a cappuccino. A contradictory or safety-sensitive order, such as "dairy-free" combined with ordinary milk, might need a person to review it. The exact boundaries belong to the shop's policy, not to Jev.
Typed does not mean true
If the allowed drink values are ESPRESSO, LATTE, CAPPUCCINO, and TEA, a typed Choice cannot return an invented UNICORN_FRAPPUCCINO value. That protects the interface from 1 kind of error. It can still return CAPPUCCINO when the customer ordered TEA. Valid shape and correct meaning are different things. A model can also be confidently wrong or poorly calibrated on particular messages. Evaluate ambiguous and out-of-scope inputs, keep an uncertain route, and let people correct mistakes. Treat customer text as untrusted data; neither a typed answer nor a high score grants security authorization.
Why not just ask an LLM for JSON?
You can ask a generative LLM to return JSON such as {"team": "SHIFT_MANAGER", "refund_requested": false}. Modern structured output mechanisms can constrain the schema reliably, so malformed JSON is not the whole argument. If an existing solution is accurate and fast enough, changing it might bring no benefit. Jev gives up open-ended text generation and instead evaluates predefined questions against shared state, potentially several in 1 request. Its probabilities, speed and cost could help with repeated decisions.
TypeSafe publishes large advantages in its own workflow evaluations and also describes their limits and possible bias, for example that the reference answers come from other vendors' frontier models and that the workflows were built by its own team. Compare both systems on the same labeled examples, including correctness, full network latency, provider charges, error handling, and human review rates.
Is Jev a model, and can it run on vLLM?
Jev is an AI model, but TypeSafe describes it as a System One model rather than a large language model. The difference is visible at its interface. An LLM accepts tokens and generates a sequence of new tokens, which can become prose, code, or JSON. Jev receives application state and predefined Choice, Score, or Noul questions. It returns typed decisions and probabilities, not generated text. It therefore behaves more like a specialized semantic decision service than a chat or completion model.
As of September 21, 2026, TypeSafe describes Jev's architecture, parallel sampler, and training method only at a high level and has not published model weights or a parameter count. The official model is offered as a closed, managed API. You cannot download the official Jev model, package it in a container, or serve it on your own GPU, and it cannot be loaded into vLLM. vLLM can serve supported model architectures when the required weights and model configuration are available; neither is available for Jev.
By contrast, self-hosted alternatives for specialized inference are emerging through open weights and frameworks. Red Hat's optimized distribution of DiffusionGemma demonstrates an open model path that runs directly on vLLM. Because its model parameters and quantized artifacts are published openly, organizations can containerize the service, deploy it across local enterprise environments like Red Hat OpenShift, and maintain full data sovereignty. Where Jev relies on a proprietary hosted endpoint, DiffusionGemma shows how high-throughput, structured decision workloads can be served natively within a self-managed vLLM deployment.
Calling the hosted Jev API from an application running locally, on Red Hat OpenShift, or beside vLLM does not make Jev local. Your application sends the state and questions over the network to TypeSafe, whose service is currently based on the U.S. West Coast according to its launch post. For European teams, that means extra network latency and a data transfer review before customer data goes into the state. A hybrid architecture could still use Jev for bounded decisions while a self-hosted LLM on vLLM handles generation. If local processing, offline operation, EU-only data processing or full control of the weights is mandatory, the official Jev service does not currently meet that requirement. Community projects inspired by the same idea are not the official Jev model and should be evaluated separately.
The coffee shop makes the deployment boundary tangible. The till, order database, customer screen, and coffee machine can all run inside the shop. When the application needs a semantic judgment, it sends the relevant order state to the remote order desk and receives a typed assessment. The coffee machine never moves to the remote office, and the remote model never directly controls it. Code in the shop remains responsible for validating the decision and operating the machine.
Why Jev has that name
TypeSafe named Jev after William Stanley Jevons, the economist who observed that more efficient steam engines increased total coal consumption. This is now known as the Jevons paradox. The coffee version: 4 bought coffees at €5 cost €20 a day. With a cheap machine, 30 coffees at €0.20 cost €6. At larger scale, 200 coffees cost €40, twice the original spend. Cheaper cups can lead to more use and eventually higher total spending. TypeSafe's thesis is that cheaper semantic judgments could similarly make many more automated decisions economical. This is an analogy, not a forecast.
Defining the boundaries of System One AI
Specialized decision models give teams a focused, cost-effective tool for evaluating bounded questions against messy state. By understanding Jev's API mechanics, confidence metrics, and hosted deployment model, engineering teams can position semantic judgments precisely where they belong in the modern application architecture.
In part 2 of this series, we will move from theory to execution with a hands-on walkthrough—covering everything from sending your first curl request to architecting production-grade AI gateways with Apache Camel and Red Hat OpenShift.
