Where does Jev fit in your product? Five decision points

What is a decision point?

A decision point is a place in your software where a question with a fixed set of answers comes up. Which team gets this ticket? Is this message about a payment? May this agent run this command? The answers are known in advance, and your code knows what to do next for each one.

In many products that spot now holds an LLM prompt that returns text, followed by code that tries to parse it. Or a stack of if statements that breaks with every new phrasing. Jev, TypeSafe's decision model, returns a typed answer with probabilities instead: a chosen option, a level or a yes probability.

The idea predates Jev. In 2024, Anthropic described routing as a standard AI workflow: classify an input and send it to a specialised follow up task. According to Anthropic, that classification can be done by a language model or by a more traditional classification model. Jev is such a classification model, with probabilities attached.

How do you spot decision points in your own product?

Look for places where your code waits for a judgement about text and then takes a fixed branch. A spot is a good candidate when most of this list holds:

• The outcome is a label, a level or a yes or no, not a sentence.
• You can write the options down in advance, including one for none of these.
• The state is text or JSON, and you are allowed to send it to an outside provider.
• Nothing needs calculating, counting or sorting by date.
• A mistake costs something, but you can catch it with a fallback, a repair step or a person.
• The judgement comes up often, so speed and price per decision matter.

A useful search in your own codebase: prompts that may only answer "yes" or "no", and prompts whose output you then check with string matching. The fixed set of answers is already there, just not typed.

Routing: which model, which team, which ARC?

Routing is a Choice over a list of destinations, with an option for no match. Jev picks the destination; your code decides what happens with that pick and whether it is allowed at all.

The best known form is the LLM router: easy questions go to a small, cheap model and hard ones to a larger model. Anthropic gives exactly that example. The researchers behind RouteLLM⁠↗ trained such a router on preference data in 2024 and report cutting costs by more than half in some cases without losing quality. If model routing is all you need, there is a ready made option: Jev Router⁠↗ on OpenRouter picks a model and reasoning effort for each request, and runs on Jev itself.

For routing inside your own product, such as which team, which queue or which tool, you build the Choice yourself. We do this in ARCS, our platform for agentic work. A deterministic planner assigns the first ARC, a specialised system that takes on the task. Next to it, Jev picks from the same list and we compare the two. The code says it plainly: the result "never changes routing or grants execution authority". Jev runs in shadow mode.

Around it sit several guardrails. Jev only sees the task and whether a repository is attached, not its path. The option descriptions are deliberately generic, so no internal names reach the provider. The question itself tells Jev to ignore requests inside the task to change the rules. External classification is off by default, a task may be at most 2,000 characters, a timeout follows after 6 seconds, the probabilities must add up to roughly 1 and the model that answers must actually be typesafe/jev-1.13. On any failure the system falls back to the planner, and it never approves anything automatically. How often Jev and the planner agree, we do not know yet.

Classification and tagging

Classification is the most direct use of Jev: one question per dimension, and several dimensions as separate questions over the same state. Your code combines the answers.

In Plens, our rain advice app for cyclists, that is exactly the role Jev plays. Our own documentation puts it this way: Jev decides one thing per question, which destination, which intent, whether to show a map or not. Arithmetic, planning and the decision rule (decide) stay in code.

For large volumes, OpenRouter describes a cookbook for classifying and tagging: one category plus any number of tags per item, with per tag thresholds set from a small labelled sample. Two lessons from Plens apply there as well. Think about the order of your options, because jev-1.13 leans towards the first one. In Plens, dry is listed first for that reason. And ask the question in English if in doubt: Plens has done so since 10 October, because Dutch works less well according to TypeSafe.

Verifying and approving agent actions

Jev can judge a proposed step before it runs: routine goes through, what does not fit is stopped, and doubtful cases go to a person. The authority to act stays with your code and with people. This is where Jev works as one of your LLM guardrails.

Verifying

For verification you ask a Noul: is this claim supported by this source? It resembles LLM as a judge, but with a typed verdict instead of a written assessment. OpenRouter describes a cascade built on that pattern. A cheap model writes a draft, Jev checks it against the retrieved context, and only if that check fails does a stronger model take over.

Approving

Two other OpenRouter cookbooks are about agents. The first checks risky tool calls against what the user asked for: safe calls run, unsupported ones are blocked and only unclear cases go to a person. The second answers permission prompts from coding agents such as Claude Code, Codex, Cursor and OpenCode with a reversibility check. Routine commands go through, risky ones still ask the user.

That is how we see human in the loop as well: Jev decides which cases need a person, not the final yes on anything that matters. In ARCS, money, contracts and commitments to customers always require a visible final action by a person. Our internal flight search tool follows the same line: it never books by itself and queues every result for review.

Ranking and scoring

For how much, use Score; for which one is best, use a Choice over a pre filtered list. In both cases code does the counting.

With Score you describe an ordered set of levels yourself, and Jev places the state between them. That works for judgements such as urgency, relevance or tone. TypeSafe does warn that the levels are weakly calibrated in numerical terms: read a score of 2.4 as somewhere between level 2 and 3, not as an exact measure.

For selection, the flight tool shows how the work is split. Code first checks price, currency, route, date, freshness (less than two hours old) and budget. Only then does Jev pick from at most twenty offers, or choose no_match. That last option matters, because a Choice is relative: if every option is bad, Jev points at the least bad one.

What Jev should not decide

Jev should not decide anything that is arithmetic, planning, a hard rule or final responsibility. The Plens documentation says Jev should not pick a departure time, weigh minutes of rain or decide what counts as dry enough. It adds that a high probability may never override a rule the sentence parser read with certainty.

The same line holds in other products. Amounts, dates and counts belong in code, because according to TypeSafe Jev is not a calculator and reads dates as text. Rules about permissions, age or budget belong in code, because a high probability is not proof. And where you need to explain afterwards why something happened, Jev will not help: it returns no reasoning.

Sometimes the best choice is for the product not to ask anything. In Plens we built a button asking whether you wanted to arrive dry, for cases where the advice was uncertain, and then removed it again. Alan Abdulla, one of our founders, decided that Plens does not ask questions back.

How do you measure whether it works?

Run Jev in shadow mode next to your current solution first, on examples you labelled yourself, and compare by type of error. Only then choose thresholds at which Jev may act on its own.

1. Write down the current path and what each mistake costs: a wrong label, a wrongful block, an unnecessary question to a person.
2. Label a set of examples without looking at Jev's answers. Include hard, ambiguous and adversarial cases.
3. Run Jev in shadow mode next to your current prompt or rules, as ARCS does.
4. Compare by error type, not just the average. Also measure response time, the cost from the usage block and the cost per accepted decision.
5. Choose thresholds based on what mistakes cost. Pin the version and measure again when you switch.

TypeSafe divides confidence into three bands. High: act. Medium: proceed with care, for example by asking for confirmation or flagging for review. Low: do not act, but route to a person, ask for clarification or fall back to another system. The example values TypeSafe gives, 0.5 as a floor and 0.9 for a risky step, are explicitly illustrative.

Also decide what happens when Jev does not answer. In ARCS, timeouts and missing permission fall back to the deterministic planner, never to automatic approval. And check every answer: is the label in your list, do the probabilities add up, was the right model used?

For more on how we let agents work with checks, read ARCS: agents that build with checks and AI code review by a council. How we develop knowledge and evaluations outside the product is described under strategy and data. Want to know which decision points in your product qualify? Get in touch.