Smart if-statements: using Jev to route, score and sort work

A lot of business software is made of if-statements. If the invoice total is over a limit, send it to a manager. If the message mentions a refund, tag it as billing. The rules are easy to read, but they break on anything that does not match the pattern someone wrote down. A customer who writes “the parcel arrived broken and I want my money back” never uses the word refund, and the rule misses it.

Jev, from TypeSafe AI, answers that kind of condition instead. You ask a typed question, such as which team a message belongs to, and get back a field your code can branch on. Our earlier post on what Jev is covers the model and its claims. Here we look at where a fast, typed decision helps in a small business, and how we would design it.

What a smart if-statement looks like

TypeSafe AI lists “AI-powered workflows and ‘smart if-statements’” among Jev’s uses. The model answers the condition, and the rest of the code stays ordinary. The software asks a question, gets a choice, a score or a yes-or-no value, and branches on it.

This keeps the logic in your own code, where your team can read it. The model only supplies the answer to the condition. If the answer is wrong, you can see which branch the case went down, and you can change the question or the options without rewriting the workflow.

Routing tickets and inquiries

Routing is the easiest place to start. A support inbox or a website contact form receives mixed messages, and someone has to decide where each one goes. A choice question picks one option from a fixed list, such as billing, delivery, technical fault or sales. The answer is a field, not a paragraph, so the ticket is assigned before anyone reads it.

Before any routing goes live, we would pull a few hundred past tickets that already have the correct team recorded, run them through the question and look at the mistakes. The mistakes usually show which options are unclear to the model, and often which ones were unclear to the people who wrote the list. “Delivery” and “damaged item” may need to be one option, or two with clearer descriptions.

Scoring leads and triaging incidents

A score question rates the state against a rubric you write. For a sales inbox, the rubric might cover how specific the inquiry is, whether a budget or a deadline is mentioned, and whether the person names a problem the business solves. The score then decides which leads a salesperson sees first. It does not decide whether to reply, and it should never quietly discard anyone.

Incident triage works the same way. Security incidents is one of the four workflows in TypeSafe AI’s own evaluation, and a small operations team could ask a score question about severity before paging someone at night. Your rubric is not the company’s, though, so its results tell you little about yours until you test. The score is a ranking that helps a person act sooner, not a replacement for the on-call decision.

Checking invoices against purchase orders

Invoice processing is another workflow in the company’s evaluation. For a small business, a useful invoice check is often a set of yes-or-no questions, with the invoice and the matching purchase order both included in the state. Does the supplier name match the one on the order? Do the line items describe the same goods? Each is a check a person makes in seconds, which is why it suits a fast decision model.

We would leave anything exact to ordinary code. Whether two totals are equal is a sum, not a judgment. The model is worth asking about the fuzzy parts, such as “Acme Trading Corp.” against “ACME Trading Corporation”.

The docs give one piece of advice that shapes all of this. If a question “would require extended reasoning or weighs multiple independent factors, decompose it.” Each small question is easy to test on its own, and a failed check tells you which factor caused the problem. The docs also say that adding questions barely changes the response time, so splitting costs little in speed.

Setting thresholds and handing off

Choice and score answers come with a confidence value, and a yes-or-no answer is itself a value between 0 and 1. The threshold for acting on either should come from testing, not a guess. Take your past cases, see how often the answers are right at each level, and choose the cut-off where the errors become acceptable for that task. A routing decision and a payment hold will need different thresholds.

Cases below the threshold go somewhere else. A person is the safest destination, especially for money, complaints and anything that touches a customer’s account. A larger language model can summarise the case or draft a reply, with a person still deciding what happens next. The rule we would set is that nothing low-confidence is acted on silently, and every decision is logged with its input and confidence, because Jev does not explain its answers.

Naming that handoff is most of the design work. It is the part we spend longest on when we build AI agents into a client’s workflow: who owns each decision, and where the uncertain cases land.

What a case costs, and what to test first

TypeSafe AI reports a cost of $0.0004 per case on its four-workflow evaluation, and lists Jev’s input price at $0.042 per million tokens, with output free. Both are the company’s figures at the time of writing (late October 2026). At that per-case cost, 1,000 decisions would come to about $0.40. Your own cases will differ in length and in how many questions you ask.

Start with one decision that a person makes many times a week, such as routing the support inbox. That follows the advice in our post on starting with a familiar task. Build the question, test it on past cases, set the threshold and decide where low-confidence cases go. Then measure the cost and the time saved on your own volume before you add a second decision. Jev is in early access, so check its current terms before you plan around it.

Sources

• TypeSafe AI: introducing System One models and Jev
• TypeSafe AI documentation: introduction
• TypeSafe AI homepage
• TypeSafe AI workflow evaluation