typed/recipes

What Is Jev? Put AI Decisions to Work

By Keith Motte · September 24, 2026

A customer asks for a repair estimate. The request lands in a general inbox. Someone reads it, forwards it, and hopes the next person follows up.

I would use a workflow like this to evaluate Jev: can it get the request to the right person with less manual sorting?

Jev is TypeSafe AI’s model for returning structured decisions from information you provide. You define the question and the available answers. Your application uses the result to choose its next step. TypeSafe calls this a System One model. TypeSafe introduction

The answer depends on three things: how often Jev gets the route right, what happens when it is uncertain, and how much work the system saves after you count the mistakes.

What we tested: The JavaScript and Python routing policies linked below each passed 12 synthetic fixtures and three invalid-threshold checks. These exercise our code. We have not benchmarked Jev’s accuracy, latency, or cost.

Give each request somewhere to go

Consider a repair business receiving this message:

“One section of my fence came down. Can someone give me a price to replace it?”

This fictional request belongs in an estimating queue. Define the destinations before asking a model to choose:

  • Quote: A customer wants a price for new work.
  • Schedule: A customer wants to arrange or change an appointment.
  • Complaint: A customer reports dissatisfaction with previous work.
  • Other: The request does not fit, or needs clarification.

Keep other. A message that does not fit should reach a person who can resolve it.

Route the request to an estimator. Leave pricing, scheduling, and commitments to the people or systems authorized to make them.

How Jev represents a decision

Jev’s documented interface provides three question types:

  • Choice selects from named alternatives. Our repair-request categories fit here.
  • Score evaluates the input against an ordered rubric. You might define levels of follow-up urgency, with a clear description for each level.
  • Noul returns a value from zero to one for a true-or-false proposition. For example, you could ask whether a message explicitly requests a callback.

Choice and Score return probability distributions and a separate confidence value. Noul returns an estimated probability without that confidence field. Questions in the same request are evaluated independently against the supplied state; one answer does not become context for another. Interface documentation

If an action depends on two answers, combine them explicitly in your code.

For request syntax and authentication, start with the official quickstart. Its JSON response places named results under answers. If you name your Choice question intent, the object your routing policy needs is response.answers.intent.

Test the code that acts on the answer

Our routing policy recipe checks the returned label and confidence, sends invalid or uncertain answers to review, and routes eligible answers to a named queue. You can exercise the JavaScript version without an API key:

import { routeAnswer } from './route-policy.mjs';

// Synthetic fixtures, not responses from Jev.
const examples = [
  { choice: 'quote', confidence: 0.85 },
  { choice: 'quote', confidence: 0.849 },
  { choice: 'other', confidence: 1 }
];

for (const answer of examples) {
  console.log(routeAnswer(answer, 0.85));
}

Download route-policy.mjs, save the example beside it as demo.mjs, and run node demo.mjs.

The first fixture routes to quote. The second goes to review. The third also goes to review, even with maximum confidence, because other is not an automatic destination.

The 0.85 threshold is illustrative. It is not a recommended production setting. The test proves that the policy follows its rules; it does not prove that Jev will classify a real repair request correctly.

Send API failures and missing answers to review too. Give that queue an owner and a response target. Otherwise, you have replaced an unattended inbox with another unattended inbox.

Read confidence carefully

A confidence value of 0.85 does not establish that your workflow will be correct 85% of the time.

TypeSafe describes confidence as a statistic derived from the distribution of answers. It is separate from the probability assigned to the selected label. You need labeled examples from your own workload to establish how either measure relates to actual errors. Confidence documentation

I would examine confident mistakes first. An ambiguous request sent to review is visible. A wrong answer that clears the automatic-routing threshold can quietly create rework.

Be equally careful with the claim that Jev cannot hallucinate. TypeSafe’s launch discussion ties its guarantee to schema matching. Returning an allowed label does not establish that the label is the right one for the customer’s request. TypeSafe’s explanation

Count the rework in your cost estimate

TypeSafe’s September 15, 2026 launch post lists input pricing at $0.042 per million tokens, with output tokens free. That is 4.2 cents per million input tokens. Check the current offer before estimating a bill. Published launch pricing

For the repair business, I would track:

  • Cost per request that reaches the correct owner.
  • Percentage of requests requiring human review.
  • Time from arrival to the correct handoff.
  • Rework caused by incorrect routing.
  • API failures, retries, and any fallback-model charges.

A request routed incorrectly may need two people to read it before it reaches the estimator. Count that rework when comparing the new process with the old one.

Decide what would justify a rollout

Start with a labeled set of requests you are permitted to use. Include incomplete messages, overlapping categories, and requests that belong in other. Keep an untouched test set separate from the examples used to tune instructions and thresholds.

Record the model version returned by the API, the question wording, the category definitions, and the routing policy. Keep those records with the results so you can repeat the evaluation.

I would run the pilot in shadow mode first: record the proposed route while the existing process continues to handle the customer. Compare Jev with a simple rules-based baseline and the current workflow. If a language model is already available to you, include it as another candidate using its supported structured-output interface.

Before reviewing the final results, agree on the acceptable wrong-route rate, review workload, and handoff time. The person responsible for the queue should own that decision. If the pilot misses those limits, narrow the task or keep the existing process.

Use ordinary code where the rule is already explicit. An existing appointment ID, for example, may determine the destination without asking a model. Reserve semantic classification for the cases that need it.

Start with the tested routing policy and one queue. Expand only when the results show that customers reach the right person sooner without creating more work for the team.

About the author: Keith Motte is the founder of Topofmind.AI and previously worked in enterprise account engineering and enterprise service management at AWS. His work focuses on practical automation, cloud operations, and business workflows.

Research and testing: Prepared with AI assistance using the linked TypeSafe documentation and local policy-test results checked on September 24, 2026. No live Jev inference was run for this article. Typed Recipes is independent of TypeSafe AI.

Further reading: Thomas Reid’s An Introduction to Jev prompted this article. His file-classification experiment is separate from the routing-policy tests described here.