TypeSafe · Typed workflow decisions
An application routing a support ticket needs a destination it can use, rather than a paragraph about where the ticket might belong. Jev, from TypeSafe, accepts text and returns a defined kind of answer: Choice selects an option, Score evaluates a scale or rubric, and Noul returns a value between zero and one for a yes-or-no statement. Those typed outputs give software a predictable answer format. The interesting question is whether Jev chooses well when people describe similar problems in different ways. Ticket routing gives us a concrete way to explore that.
01Fit
02Requirements
The current model reference prices input tokens, the units used to measure submitted text, and lists output tokens as free. Check the chosen model version, rate and limits for your integration. A routing system also costs time when someone must correct a wrong destination or examine a ticket sent to triage, so include that work in your comparison.
Check current access and pricing03Setup
TypeSafe’s browser Playground lets you try the model without installing anything locally. Follow the official quickstart, sign in and begin with a synthetic ticket whose contents you can safely submit.
For ticket routing, use Choice with named queues and an explanation of what each one handles. Include triage for reports that are unclear or do not fit. Along with the selected queue, inspect the returned distribution, which describes how the model weighs the available options.
If the browser results are useful enough to justify an integration, create a Python project environment and install the official SDK below. Follow the quickstart’s authentication instructions, keeping credentials out of source files.
pip install typesafe-sdk04Using Jev
The starter has six synthetic support reports, four queue definitions and expected labels written before any model call. Use Jev’s Choice question to make recommendations, then inspect how mistakes differ. Sending an unclear report to a specialist is a different cost from sending a clear report to triage.
Included example files
Synthetic code, logs, a deliberately stale runbook, and six support tickets. The JavaScript uses Node.js 22+ with no packages or network calls. Product accounts and model access are separate.
node routing/evaluate.mjs routing/predictions.example.jsonnode routing/evaluate.mjs routing/predictions.json{
"state": "My account is locked after too many password attempts.",
"model": "jev-latest",
"questions": {
"queue": {
"type": "choice",
"instructions": "Route this synthetic support report. Use triage when detail is insufficient or no specialist fits.",
"criteria": {
"access": "Account lockout, sign-in credentials, or permission problems",
"application": "A specific application feature fails despite working access and connectivity",
"network": "An explicitly described DNS, connection, or network failure",
"triage": "Insufficient detail, conflicting evidence, or no fitting specialist"
}
}
}
}The artifact you are working toward
For the manual example only, the local checker must produce the counts below. Your model run may differ. Each prediction needs a unique ticket ID, a valid queue and the actual returned model ID.
{
"total": 6,
"exact": 4,
"wrongSpecialist": 0,
"unnecessaryTriage": 1,
"missedTriage": 1
}Inspect whether the triage definition is sufficiently distinct, and test that change against the same ambiguous reports. Do not fix the score by relabeling those reports after seeing the answers.
Six familiar examples cannot justify automatic routing. Add unseen, representative cases and measure the cost of wrong destinations before connecting the recommendation to real work.
You now have request definitions, actual responses and a repeatable comparison, enough to decide what a larger evaluation should test. Keep recommendations separate from execution until your own evidence supports a routing policy.
The included baseline tests and evaluation script were checked locally. The deliberately failing contract tests demonstrate the defects in the starter. No AI product was installed or run for these examples; model responses and reviews will vary.
05Next steps
Choosing “network” is only one part of routing. Your application still has to find the current destination for that queue, send the ticket and confirm delivery. The full Jev article follows those steps and compares the whole process with rules or an existing classifier, including cases where the label is sensible but the ticket never arrives.
Read the guidanceChoice and Score derive confidence from their output distributions. A high value does not provide a universal probability that this particular answer is correct. Compare confidence with reviewed outcomes from your own tickets before using a threshold for automatic handling. Record or pin the model version so the comparison remains meaningful when models change.
Read the guidance06Alternatives
07Evidence and scope
Product behavior is based on the linked official documentation. This walkthrough uses an authored synthetic starter project. Its baseline tests and local checker were checked; no installation, model response or product performance was independently tested for this guide.
Documentation checked