An answer is only useful if software knows what to do with it. That single sentence explains the Jev answer types. When Jev replies, it never returns an essay; it returns one of three shapes: Choice, Score or Noul.
Each shape is a contract. Choice picks from options you defined, while Score grades with a number. Noul is the typed empty answer, returned when nothing fits. The names come straight from the documentation, so you will see them in every SDK.
This guide walks through all three Jev answer types, with examples and design advice. You will see where each shines, how they combine, and how to phrase options that get good answers. No other setup is required, because the types are the whole interface.
In this guide
- The 30-second answer
- What you’ll learn
- Why Jev answer types exist at all
- The Choice type: one pick, every probability
- The Score type: grading instead of labeling
- The Noul type: the typed empty answer
- How the three Jev answer types work together
- Designing options that get good answers
- Frequently asked questions
- The bottom line
The 30-second answer
Here is the short version. Jev is non-generative: it assigns probabilities to predefined answer options and cannot answer outside them. So the Jev answer types must cover every case, because there is no free text to fall back on. The types are not packaging; they are the product.
Key takeaways
- Choice picks one of up to 255 options and returns every probability plus a confidence value.
- Score returns a number grade, which makes it the natural fit for ranking and sorting.
- Noul is the typed empty answer, the model’s way of saying nothing genuinely fit.
- Every answer is typed, so your code reads fields instead of parsing prose.
- Use Choice for categories, Score for degrees, and Noul for the honest empty case.
- The names come from the docs, so they match every SDK response.
What you’ll learn
The route through this guide
- Why answers have types at all
- The Choice type: one pick, every probability
- Score type: grading instead of labeling
- Noul type: the typed empty answer
- How the three types combine in one workflow
- Design tips for options that get good answers
Why Jev answer types exist at all
Start with the interface Jev replaces. A chat model answers in prose, so your code has to read sentences and guess the intent. That works for people, because people forgive ambiguity. Software does not forgive it, because a program needs a value it can branch on.
Here is the contrast that shows why the Jev answer types matter in practice. Ask a chat model the same routing question and you will get a sentence, maybe with a disclaimer attached. Someone has to read it, or something has to parse it. Ask Jev and the reply is already a value with odds attached.
Typed decisions close that gap. Pydantic’s docs describe Jev answering typed questions about a text, each with a probability or distribution over options. Because the shape is fixed, the calling code is ordinary branching logic instead of text wrangling. For the full pipeline view, our guide on how Jev works under the hood covers the whole call.
The Hugging Face listing calls the interface decision-oriented: text, JSON, or an array of texts describing the state. Because the state arrives structured, the same question works across one record or a thousand. That consistency is what makes the types feel less like an API and more like a vocabulary.
Programmers have seen this movie before. Databases got typed columns, APIs got typed schemas, and both changes made software more trustworthy. The Jev answer types bring the same discipline to model outputs.
It is worth naming what this replaces. Teams today glue regex, keyword lists and model parsing together to extract decisions from prose. Every layer adds latency, cost and a fresh way to fail. Typed outputs collapse that stack into one call.
The Choice type: one pick, every probability
The Choice type is the workhorse. You ask a typed question whose options are defined in advance, and Choice picks one of them. The answer returns the probability of each option, plus a single confidence value for the call overall.
A quick example shows the shape. Ask whether a message is urgent, routine or spam. Choice might return urgent at 0.74, routine at 0.21, and spam at 0.05. The confidence value might read 0.82, and your router has everything it needs.
Two details matter in practice. First, the option list can hold up to 255 entries, which covers most real taxonomies. Second, you get the full distribution, not just the winner. If billing scores 0.81 and technical scores 0.12, your code can see how close the call was.
What can you actually do with 255 options? Plenty of real taxonomies fit: issue categories, product lines, intents for a router, dispositions for a review. The limit is generous, though the advice later in this guide still applies: tighter sets, cleaner distributions.
That distribution is what separates the Choice type from an old classifier flag. A flag forces a binary path, while a distribution lets thresholds, escalations and logging all read the same answer. This is what people mean by typed decisions: the pick arrives as data, not prose.
Keep the winner, but keep the runner-up in mind too. Distributions are also a quality signal for your question design. When the top two options stay neck and neck across thousands of calls, the menu probably has overlapping options. Narrow the set and watch the spread sharpen.
The confidence value deserves its own sentence. It summarizes the call in one number, so dashboards and thresholds have a single figure to watch. Treat it as a routing signal, and calibrate what good looks like on your own data.
The Score type: grading instead of labeling
The Score type answers a different kind of question. Instead of picking a label, it returns a number grade for the record you sent. That makes it the natural fit for anything you would rank, weight or sort.
Teams often start here because sorting is the loudest pain. Records pile up faster than people grade them, and a number that arrives instantly changes the math. Picture the everyday jobs: scoring leads by fit, grading tickets by urgency, and rating search results by relevance.
So is flagging a risk number before a payment moves. Scores also combine well with thresholds. A number below one level can mean fully automatic handling, while a number above another means a human reviews first. The middle band gets logged, so the team can tune the cutoffs with evidence instead of vibes.
Relevance is the quiet one on that list. Search teams grade results constantly, and a number that arrives per record makes re-ranking practical. The same pattern works for deduping, prioritizing and any job where best-first beats first-in.
A practical pattern pairs two Jev answer types: Score first, then Choice. Grade everything first, then ask a Choice question only for the records that land in the interesting band. That keeps the option sets small and the calls cheap.
One warning keeps expectations honest. The Score type grades against the state and question you sent, so change the wording and the number can move. Pin your question definitions and version them like code.
What does a Score number mean? It means what your question says it means, which is both the power and the responsibility. Define the scale in the question itself, and the grade becomes comparable across records.
The Noul type: the typed empty answer
Noul is the type people underrate. When none of your options genuinely fit, Jev returns Noul instead of forcing a bad pick. In other words, it is a null value with probabilities attached. Noul completes the Jev answer types, because without it the model would have to guess.
That behavior is only possible because the model is non-generative. It cannot answer outside the options you define, so honesty arrives as an empty answer rather than invented prose. An old-fashioned classifier would have quietly picked whatever scored highest.
Treat Noul as a feature you design for. Decide before launch what the empty answer should trigger: a human queue, a retry, or a fallback model. Logs can count it, dashboards can alert on it, and spikes become an early sign of drift.
The name is unusual, and the spelling is part of the API surface. You will meet it in SDK responses, logs and dashboards, usually next to a confidence value. Wherever it appears, the meaning is the same: nothing on the menu fit.
There is a cultural shift here too. Teams that adopt the empty answer stop arguing about edge cases in design reviews. The question becomes empirical: what does the model return for the weird stuff? The answer is Noul, and the runbook handles the rest.
Noul also changes the economics of edge cases. Instead of reviewing everything, people review only what came back empty. The queue shrinks to the interesting part.
How the three Jev answer types work together
Real systems use all three Jev answer types in one pass. The state goes in once, and several typed questions come back with answers your code can chain.
One workflow, three shapes
The three types at a glance
| Question style | What you get | Use it for |
|---|---|---|
| Pick one from a fixed list | An option, every probability, a confidence value | Routing, tagging, safety checks |
| Grade on a scale | A number for the record you sent | Ranking, sorting, urgency, risk |
| Anything else | Noul, the typed empty answer | Escalation, retries, drift alerts |
A support desk shows the pattern. Choice routes the ticket, Score ranks the queue, and Noul catches the messages no one anticipated. Each answer is small, but together they run the workflow. Types do not fix every mismatch, so see our guide on when not to use Jev.
A payments review shows the same grammar. Choice picks a disposition, Score grades the risk, and Noul catches the cases that match no template. Three shapes, one pass, and an audit trail by default.
Batching works the same way. The Jev answer types also hold up in batch jobs, because the input can be an array of texts. One call covers a whole inbox, and answers come back typed for every item, so loops stay simple.
Notice what this implies about design effort. Most of the work happens before the first call, while the model itself stays boring at runtime. That is a fair trade, because boring at runtime is exactly what production systems want.
One question comes up often: do you need all three? A pure router might live on Choice alone for months. Still, the moment volume reveals weird inputs, Noul earns its place, and the moment ordering matters, Score joins.
Mapping this onto a bigger system? Our overview of what AI agents can do adds the wider context.
Designing options that get good answers
The three Jev answer types only work as well as the menu you provide. Vague options produce confident answers to the wrong question, which is garbage in, garbage out with better manners. The early use cases reported at launch were sorting requests, scoring records, and screening AI outputs for jailbreak attempts. Each one maps to a single shape, which is why the menus behind them were so concrete.
Write options as a person on the team would say them. Keep the set tight, because every extra option splits the probability mass again. If the list runs long, split one wide question into several narrow ones.
Consider the contrast between two menus. Bad: relevant, not relevant, maybe. Good: billing dispute, refund request, feature question, other. The second set tells you what to build, because the options match the routes your code can actually take.
- Write options the way your team actually phrases them in tickets and calls.
- Keep the option set tight, because extra options split the probability mass.
- Split one wide question into several narrow ones when the list runs long.
- Define what Noul should trigger before the workflow goes live.
- Version your question definitions, because changed wording changes numbers.
- Replay recorded cases through new versions before you promote them.
Test before you trust, and keep the test small. Community getting-started advice suggests limiting the first run to one task, using about 50 recorded responses from that workflow. Replay them through the same questions, then compare the picks with what your team would have done.
When a shape keeps misfiring, the fix is usually the question, not the model. Guides like the flaviocopes.com walkthrough make the same point with JavaScript examples: practical patterns beat clever prompts.
One more habit pays off: name the Noul path in your incident runbook. When the empty rate spikes, you want an owner, a threshold and a first step already written down.
Ready to try the types yourself? Our guide on how to set up Jev walks the first call in both SDKs.
Frequently asked questions
What are the three Jev answer types?
Choice picks one option from up to 255 and returns every probability plus a confidence value. Score returns a number grade. Noul is the typed empty answer for when nothing fits.
What does Noul mean?
It is the typed empty answer, returned when none of your options genuinely fit. Think of it as a null value with the model’s honesty attached. Your code decides what happens next.
Can Jev return free text?
No. Jev is non-generative and assigns probabilities to predefined options only. If nothing fits, you get Noul rather than an improvised answer.
How many options can a Choice question have?
Up to 255. Tighter sets usually produce cleaner distributions, because each extra option splits the probability mass. Split very long lists into several narrow questions.
When should a team use Score instead of Choice?
Use Score when the answer is a degree, not a category. Urgency, lead quality and relevance are Score-shaped questions. Sorting and ranking jobs fit Score too.
Do the answer types work in batch jobs?
They do, because the input can be an array of texts describing many states. Early use cases include sorting requests and scoring records in bulk. Answers stay typed either way.
The bottom line
The Jev answer types are the product’s whole interface, and that is the point. Choice handles categories, Score handles degrees, and Noul handles the honest empty case. Because every reply is typed, your software gets answers it can act on. Three shapes turn model output into ordinary data, and ordinary data is what software is built on.
Pick the shape that matches the question, and write options the way your team talks. Then test small, log everything, and let the probabilities earn trust. Log the distributions, not just the winners. The model can only answer from the menu, so the menu is the whole world.
If you want the wider story first, start with our Jev System One model overview. Then come back and design your first question set.
Sources
- TypeSafe AI, Jev product overview and answer type documentation — typesafe.ai
- Pydantic documentation, typed questions with Jev and probability distributions — pydantic.dev
- flaviocopes.com, guide to typed choices, scores and probabilities with JavaScript examples — flaviocopes.com
- semly.ai, getting-started advice for a first, single-task Jev test — semly.ai
- Hugging Face, Jev model listing with decision-oriented input description — huggingface.co