Jev Use Cases: 12 Things It Can Do, and 5 It Cannot

Jev use cases cluster around one job: turning messy input into a typed, confidence-scored decision that code can act on. That covers ticket routing, LLM guardrails, citation checking, RAG reranking, screening, and bulk classification. It does not cover writing text, counting, comparing dates, explaining itself, or picking from an open-ended set of answers.

Most “Jev use cases” roundups repeat the same twelve items lifted from TypeSafe’s own documentation, with no attempt to say where the model breaks. This post keeps the twelve, tags each one with its primitive so the list doubles as a design reference, and adds the five things Jev cannot do plus first-party test results from this publication’s own content.

New to the model itself? Start with what is Jev, TypeSafe’s System One model for the architecture. This post assumes you know what a Choice, Score and Noul question are and want to know where to point them.

What is Jev actually good at?

Jev is good at any decision with a closed set of outcomes and a cost to getting it wrong silently: which queue a ticket goes to, whether a tool call matches user intent, which passage answers a query best. The pattern behind all of them is confidence-gated routing.

High confidence lets code act automatically. Mid confidence escalates to a slower LLM or a rules engine. Low confidence goes to a human. That split is the real product, more than any single row below.

Routing and triage

Routing is the use case Jev shipped for first, and it is still the cleanest fit: a fixed set of destinations, a decision repeated thousands of times a day, and a cost to misrouting that compounds quietly.

Support ticket routing is the standard example: a Choice question assigns the queue, a Score question rates complexity, and code decides whether the ticket auto-replies, escalates, or goes to a specialist, classifying urgency and refund intent before any LLM sees it.

Model and tool routing works the same way one layer up: a Choice question decides whether a request needs a frontier model, a cheaper model, or no model at all. One widely cited example came from a Vercel engineer who reported replacing an OpenAI-based safety classifier with Jev and getting results 5 to 18 times faster with better accuracy, a third-party engineer’s own report, not an audited benchmark.

Guardrailing LLM output

Guardrailing checks an LLM’s input or output against a fixed list of hazards before anything executes, using Noul questions for yes/no risks and a Score question for severity.

TypeSafe’s own guardrails cookbook documents this for tool-call validation: does a proposed call match what the user asked for, and does the message try to get the model to ignore or reveal its instructions. Both checks run as one API call ahead of execution, since prompt injection is cheap to send and expensive to miss. The severity score can independently escalate a borderline pass into a block, keeping the threshold editable in code rather than buried in model weights.

Verifying citations and claims

Citation verification checks whether a claim is supported by the source it cites, a Noul question repeated per claim rather than one yes/no over a whole document.

In TypeSafe’s own citation-checking cookbook, four accurate citations scored 0.93 confidence or higher, clearing an 0.8 auto-accept threshold. Four planted failures, including a fabricated quote and a citation contradicting its own source, were all caught, two at low enough confidence (0.27 and 0.56) to force human review. This is a vendor demo, not an independent audit, sized to show the mechanism rather than a production error rate.

Reranking search and RAG results

Reranking rescores the shortlist a vector or keyword search already produced against the actual query, a Score question run per passage instead of one embedding comparison.

A community benchmark testing Jev as a reranker on legal document corpora is among the more closely watched independent tests here, and the developer running it was explicit that single-run gaps should not be over-read. One separately reported legal-document pass put top-1 accuracy moving from roughly 5 to 18 percent and top-10 from 38 to 62 percent. Treat that as a single, unreplicated trial, not a number for a procurement decision.

Scoring and screening at scale

Screening use cases share a shape: independent Score questions, one per dimension, combined afterward with weights the developer sets rather than one black-box verdict.

Resume and vendor screening is the clearest version: role-evidence, communication depth and specific experience each get a score, weighted in code where it can be audited. Insurance claims assessment and financial-crime alert prioritization follow the same shape at higher stakes, documented as triage layers ranking which claims need a human analyst, not systems that approve or deny alone. Marketplace and content moderation is the volume version, screening posts against named policies on every submission.

Bulk classification of archives

Bulk classification applies one Choice question to every row in a dataset, the use case where per-call cost matters most since the call count is large and fixed in advance.

Reported examples run from roughly 500,000 records up to tens of millions. TypeSafe’s list pricing (input tokens billed, output free) makes back-of-envelope math common: one illustrative community calculation puts 50 million rows at around $20. Treat that as a vendor-price estimate, not an audited case study, until you run your own volume through your own taxonomy. Semantic linting in CI is the developer-tooling cousin: a Choice or Noul question per changed file, catching what pattern-matching linters cannot, like an error message that gives the user nothing to act on.

Real-time decisions inside an app

Real-time use cases need a decision inside a millisecond latency budget, which rules out a full LLM call and is exactly the case System One models were built for.

TypeSafe reports latency in the 70-500ms range depending on question count and cardinality, and has demonstrated it driving in-game NPC decisions and UI state changes at that speed, choosing among up to 255 enumerated options per question. That ceiling is hard, not a guideline, and shapes how you design the answer space for anything inside a live loop. For the fuller speed and cost picture, see what Jev actually is and how System One models differ.

Which of these map to learning and development?

Three of the twelve map directly onto L&D operations: routing, bulk classification, and screening. We ran two tests against real content to check the theory, dated 22 September 2026.

In a catalogue-tagging test, we ran all 15 of this publication’s own published and drafted posts through Jev against a five-family content taxonomy (T3, n=15). Jev’s tags agreed with our human-assigned tags 73.3 percent of the time, at a mean confidence of 0.849. That is a real result on a genuinely small sample, and we state the n=15 every time we cite it so nobody mistakes it for a production benchmark.

In a publish-gate test, we compared five real OSHA public-domain safety fact sheets against five freshly AI-generated modules built with objectives, a scenario and a knowledge check (T7, n=10). We expected the widest gap on a fabricated-claim signal. It was not: the widest gap was “has_objectives,” at plus 0.844, meaning AI-authored modules scored far higher on stating measurable objectives. The caveat matters: the human half was reference material, not a structured module, so part of that gap is format, not authorship. Do not oversell it.

Both results, and the full methodology, live in Jev for learning and development, the next stop if content tagging or an AI publish gate is your problem. The same logic feeds LMS reporting on content quality, and pairs with any AI content-creation tooling you run, since one drafts and the other gates. See AI in the LMS for the broader case.

What can Jev not do?

Jev cannot generate text, code or a summary, cannot count reliably, cannot compare or reason about dates, cannot explain why it reached a decision, and cannot handle an answer space that is not fully enumerated in advance, since every Choice option must be listed up front and capped at 255.

The text-generation limit is structural: Jev is not built to produce prose, so forcing it gives poor output by design. The counting limit is subtler and catches people who assume a “scoring” model does arithmetic: it recognizes the shape of an answer rather than tallying items, so any real count needs to happen in code around the call. Dates fail the same way, since Jev reads a date as text rather than an ordered quantity, so “which comes first” is not a safe question to ask it directly.

No rationale ever comes back with a decision, so an audit trail must be built in code from the inputs and confidence score, not the model. The enumerated-answer-space limit means Jev is wrong once categories are open-ended, since every option must exist in the schema first. For the mechanics of calibrating around these limits, see Jev’s limitations and confidence calibration.

How do you pick a first use case?

Pick the decision that already has a fixed, enumerable set of outcomes, runs often enough that latency and cost matter, and currently goes to a slow LLM call or an untracked guess. That combination is where confidence-gated routing pays off fastest.

Look for a decision your team already makes by rule of thumb: which queue, which model, pass or block. If you can list every possible answer today, short enough for a schema, you have a Choice or Score candidate. If the honest answer is “it depends” and open-ended, that decision needs an LLM or a human instead. From there, question design is where most attempts go wrong; how to write Jev questions covers the wording that separates a calibrated question from one that misroutes edge cases.

Conclusion

The twelve use cases above are not a menu to pick from at random. They are twelve instances of one confidence-gated pattern, applied to whatever decision already has a closed answer set and a cost to getting it wrong.

Start smaller than you think. Run one use case against a real, small sample of your own data first, the way the 15-post and 10-document tests above ran against this site’s own content rather than a synthetic benchmark.

If your first candidate is content-related, tagging, gating or scoring training material, the L&D results and methodology above are the next stop. If it is a guardrail or routing decision, start with the question design guide before writing your first schema.