Many applications do not need AI to write a reply. They need a decision they can use: which team should handle an inquiry, whether a customer has mentioned a timeline, or how concrete an integration plan is.
JEV is TypeSafe's System One model for answering typed questions about supplied context. Through Sukidata, you can use it for classification, condition checks, and scoring, then connect the structured answers to your application. Its purpose here is to inform the next step, not to generate an article. Read TypeSafe's introduction to System One.
Start with one customer inquiry
Imagine this message arriving at a data product's inbox:
We're launching an analytics dashboard in October. We need to track 500 keywords across three markets every day. Can we discuss a suitable API plan?
There is more than one useful signal here. The customer is asking about a commercial plan, but also describing a use case, scale, and timeline. Labeling it only as a sales inquiry loses those details. Calling it high priority hides the criteria behind that judgment.
A clearer approach is to ask three separate questions: what kind of inquiry is this, does it include a timeline, and how concrete is the integration plan? The category supports routing, the timeline helps prepare the conversation, and plan readiness helps organize follow-up. Each answer has a distinct purpose.
Three question types, three different jobs
| Type | Example question | Answer |
|---|---|---|
choice | Is this about a plan, technical integration, or something else? | One selected option and option probabilities |
noul | Does the message specify a launch timeline? | A probability between 0 and 1 that the condition is true |
score | How concrete is the integration plan? | A value on your scale and a distribution across its levels |
Use choice when one category should win. If several labels can apply independently, such as “mentions a timeline” and “requests a trial,” ask separate noul questions instead. Choice reference.
A noul measures the probability of yes, not the intensity of a quality. “Is there a timeline?” fits this type; “How developed is the plan?” is better expressed as a score. Noul reference.
For score, define ordered levels. Three levels produce a scale from 0 to 2. The result can be fractional because it is a probability-weighted score, not necessarily a selected bucket. Score reference.
Separate the context from the criteria
The two central request fields are state, containing the material to evaluate, and questions, defining what to ask and how to judge it. This request applies all three questions to the same inquiry:
{
"model": "jev-latest",
"state": "We're launching an analytics dashboard in October. We need to track 500 keywords across three markets every day. Can we discuss a suitable API plan?",
"questions": {
"topic": {
"type": "choice",
"instructions": "What is the main purpose of this inquiry?",
"criteria": {
"sales": "Discussing API plans, purchasing, or a suitable usage package",
"integration": "Asking how to implement an integration or resolve a specific technical issue",
"other": "A message outside these two categories"
}
},
"has_timeline": {
"type": "noul",
"instructions": "Does the message explicitly specify a launch or integration timeline?",
"criteria": {
"true": "Gives a month, date, or specific relative timeframe",
"false": "Gives no timeframe or only suggests considering it someday"
}
},
"plan_readiness": {
"type": "score",
"instructions": "How concrete is the API integration plan described in the message?",
"criteria": [
"Exploring the product without describing a specific use case",
"Describes a specific use case without a clear timeline and scale",
"Describes a specific use case with a timeline and scale"
]
}
}
}
Send this JSON to POST https://api.sukidata.com/v1/systemone. For authentication and a complete request example, see the JEV API guide.
Question names identify returned answers; put the meaning the model needs in instructions and criteria. Questions in one request are evaluated independently and do not automatically read one another's answers.
A useful score starts with a useful rubric
“Low, medium, high” is concise, but does not identify the evidence to look for. The rubric above makes plan readiness observable: is there a use case, a timeline, and a scale?
It also makes results easier to inspect. Compare “I'd like to learn about your API” with “We're building a keyword dashboard, but have not set a launch date.” You can then check whether the model distinguishes the stages you care about. The illustration depicts the rubric, not an actual customer's measured score.
Keep the scale focused on one dimension. If commercial value matters too, ask a separate question. Mixing a large budget with a near-term launch in the same score makes changes harder to explain.
Read answers without parsing an explanation
The response's answers object uses your question names. Read answers.topic.choice for the category, answers.has_timeline.noul for the timeline condition, and answers.plan_readiness.score for the readiness score.
For example, level probabilities of 0.05, 0.20, 0.75 produce 0 × 0.05 + 1 × 0.20 + 2 × 0.75 = 1.7. These numbers illustrate the calculation; they are not a measured response to this article's request.
Choice and Score also return confidence, which summarizes the distribution's concentration. It is neither the winning option's probability nor a measured business accuracy rate. An ambiguous inquiry can remain pending clarification rather than trigger an action just because a category was returned. Confidence reference.
Where else can this help?
Organizing content. Assign a topic to a knowledge-base article and separately check whether it covers a particular feature. Keeping topic categories and feature labels separate can make the taxonomy easier to maintain.
Filtering search results. Supply a query and candidate content together, then evaluate candidates against your relevance rubric. This can support ranking after retrieval; it does not replace the search itself.
Choosing an agent's next step. Decide whether a request belongs in documentation search, a product page, or a human conversation. Your application still controls permissions and executes the action.
These tasks share a useful property: you know what types of answers are allowed and what you will do with them. Writing reports, creating images, and open-ended long-form analysis call for the corresponding generative models or tools instead.
Try JEV in Sukidata
Open the JEV Playground, put your content in State, and add questions. Inspect the categories, probabilities, and scores in the preview. Once the criteria work for your cases, export the API request for your application.
Sukidata supports jev-latest, jev-preview, and the pinned version jev-1.13.0. Use jev-latest to follow the current release, jev-preview to try the preview, or a versioned name when comparing results under a fixed model version.
JEV input costs $0.042 per million tokens, with free output on Sukidata. Billing follows actual input token usage, not a flat charge per question. See the JEV product page for model and pricing information.
Start with one place where someone currently reads text and assigns a category. Write down the criteria, check representative real examples, and use the results to decide which judgments are worth automating.