What is Jev, and where does it fit?
Imagine running a small SaaS business with a few dozen support messages a day. A new ticket says, “My subscription was charged twice, and I cannot log in today. Please help.” You want a program to put it in the right queue. Part of that task involves interpreting language. Other parts involve business policy: which concerns matter, who handles a mixed request, and what happens when information is missing.
Jev is a TypeSafe model whose interface takes material to evaluate and typed questions, then returns structured answers for software to consume. Its useful output in this workflow is a value your code can inspect and act on. Official introduction
You can define the permitted queue names before making the request. You do not need a paragraph of analysis from which you later try to recover a department. A valid response shape, however, only solves the integration problem. Whether the selected department meets your business standard is a separate question for evaluation.
Follow one ticket through the workflow
Customer message and supporting material → state
Judgment dimensions and criteria → questions
Returned typed values → answers
Validation, review, and queue selection → application code
The state is the material available for this evaluation. A simple task can use a text string. When several sources matter, a JSON object can identify the customer message, known account facts, and relevant policy. State documentation
Here is an original teaching input:
{
"ticket_id": "T-101",
"customer_message": "I was charged twice and cannot log in today.",
"account_facts": "No verified payment records supplied."
}
This record supports a judgment about what the customer reports. It does not establish that two charges actually occurred. “Does the message report a duplicate charge?” and “Should this account receive a refund?” require different evidence. The second decision needs transaction records, a refund policy, and permission to perform an action. Better wording cannot manufacture those missing facts.
The questions describe the judgments you want. You could ask which queue fits, whether the customer reports a login failure, and whether the message names a deadline. Each question has a narrow job. The answers contain the corresponding results. Your application then saves a suggestion, sends it to review, or performs another deterministic check.
Choose the shape your application needs
| Application need | Type | Ticket example | Local use |
|---|---|---|---|
| One member of a finite set | Choice | billing, technical, mixed, other |
Select a queue |
| A position on ordered levels | Score | Reported business impact | Sort or compare a threshold |
| A specific yes/no proposition | Noul | The message explicitly requests action today | Mark a condition |
Choice and Score include probability distributions and confidence; Noul provides a noul value between 0 and 1. The official primitives reference describes the fields. For now, concentrate on whether your program needs a category, a degree, or a condition.
The examples keep enum values in English in both editions. A Chinese interface can display billing as a localized label while the saved data still says billing. Keeping display text separate from program values prevents a translation edit from silently changing a branch in the code.
Decide what deserves a model call
The following table expresses this book's design choices, not a performance ranking.
| Job | Starting point | Reason |
|---|---|---|
| Check whether input is empty | A Python condition | The standard is exact |
| Validate an order ID's format | String or regular-expression rules | Results can be reproduced precisely |
| Recognize a request for money back | Try a Noul question | Many phrasings can express the same intent |
| Route a ticket with several concerns | A Choice with an explicit mixed category | The destinations form a finite set |
| Write a customer reply | A template or generative model | The deliverable is new prose |
| Authorize access to an order | Application authorization rules | Access depends on trusted identity and records |
Do not delegate a step merely because you can phrase it as a question. If your system knows a subscription's expiration date, compare it with the current date. Asking a language model to reinterpret an exact fact adds another component to inspect without an obvious benefit.
On the other hand, a keyword does not always capture intent. “Please do not refund it; I only need an invoice” contains the word “refund” but asks for something else. That is a useful evaluation example. Keep a simple rule as a baseline and find out whether semantic judgment reduces errors on the cases you actually receive. The value should come from your measurements.
A bounded decision is one part of an agent
The routing case will make this division visible. The model proposes faq, order, or human. Code checks whether an order ID exists, whether the order belongs to the signed-in user, and whether the selected tool succeeds. Choosing a finite option does not also produce trustworthy tool arguments or establish permission to read a record.
The content checker has a similar boundary. It asks about observable material in the supplied draft, such as an executable step or a source attached to a claim. A positive answer to “Is a source present?” does not verify the source's authenticity, establish the claim's truth, or predict search traffic. Those tasks require additional evidence and a process designed to use it.
This division makes failures easier to investigate. You can inspect the input, the rubric, the answer, and the policy independently. TypeSafe's building guide likewise places control flow and side effects in application code.
Certainty is a signal to interpret
For Choice, an option's probability concerns that particular candidate. confidence summarizes the concentration of the whole distribution. Neither number is an accuracy measurement from your independently labeled dataset. Confidence documentation
Suppose an illustrative ticket produces similar support for billing and technical. Before lowering a threshold to force it through, inspect whether the ticket contains two concerns and whether your definitions allow a mixed outcome. A concentrated answer still needs valid input, appropriate permissions, and an acceptable consequence if it is wrong.
That is why the first workflow produces local suggestions. You can inspect them, change the rubric, and run again. Before integrating them into a real business process, use a held-out set to determine which suggestions can be adopted automatically and which need review. Review rate is itself a useful result. A system that asks a person about almost every item may provide less value than its classification accuracy suggests.
Pick a task you can finish this week
Write down one repetitive judgment you have made recently. Gather ten synthetic or authorized examples and label them yourself. For each one, record the expected answer and the part of your standard that supports it.
Then check three things. Can you list all permitted outputs? Would two colleagues applying your instructions usually agree? Does a mistake place an item in the wrong queue, or immediately trigger an irreversible action? These answers determine the scope of your first experiment.
If you cannot describe the output, narrow the task. “Automatically handle customer problems” could become “choose one of four proposed support queues.” If reviewers disagree, retain the disagreement as evidence. You may have found an unresolved policy question rather than a model limitation.
Evaluate Chinese inputs separately. The current official model notes say English performs best and other languages, including CJK text, are accepted with lower accuracy. This bilingual book does not establish equal model performance across languages. Models and language support
Continue with Quickstart: from a local demo to a live decision.