Where Jev fits in a regulated system. And where it doesn’t.

A new kind of model answers yes, no, or a pick from your list. Here is where it belongs in a clinic, a bank or a law firm, and where it doesn’t, from its maker’s own documentation.

Tyler Gibbs. . 6 minute read.

Parallel railway tracks under a concrete signal gantry, one blue signal over the chosen track, a person watching from the cabin as a car approaches

A referral lands at a clinic. Before anyone can schedule it, somebody has to answer six questions. Is the insurance listed? Is the ordering physician named? Does the diagnosis match the service requested? Is there a prior authorization on file? Is it urgent? Is anything missing that would send it back? None of those answers is a paragraph. Each is a yes, a no, or a pick from a short list.

A lot of the work in a clinic, a bank or a law firm looks like that. A fraud alert gets cleared, escalated or sent to an analyst. A contract has the indemnity clause or it doesn’t. A document is privileged, or it might be, or it isn’t. Chat models can make these calls, but they write the answer out as text, and software then has to parse the text, check that it is one of the allowed answers, and decide what to do when it isn’t.

A decision model belongs in the decision layer.

Jev, released in September by TypeSafe AI, was built for that layer. You give it a case and a set of typed questions, and it answers each one with a pick from options you wrote, a score on levels you defined, or a yes-or-no probability. It cannot return an answer outside the options. TypeSafe describes its purpose plainly: it is for building “AI-powered software, not agents,” where code owns the workflow and the model handles narrow judgments.

That division is the useful idea, whichever model fills the layer. The steps a regulator will ask about stay in code you can read. The model answers the questions a person used to answer by reading, and nothing else.

Ask many questions of the same case at once.

TypeSafe’s documentation says every question in a request sees the same case and is evaluated independently. Its own test backs that up: it asked 13 compliance questions about one long document, once in a single request and once as 13 separate requests, and got the same answers both ways. The single request was 12.2 times cheaper and 10 times faster. Those are TypeSafe’s numbers, on its test.

For regulated work, that means a referral’s six questions, or a loan file’s checklist, can go out as one request without one answer leaning on another. It also means each check can carry its own line: the urgency question and the missing-field question do not have to share a threshold.

A fixed set of answers is not a security boundary.

Because the model can only return one of your options, it cannot be talked into writing arbitrary text. TypeSafe’s guardrails example shows the upside: an “ignore your instructions” message scores as a jailbreak instead of working as one. But the same company’s list of known weak spots says that content written to steer the model, including an injected instruction, “can move the answer.” A fixed answer set stops the model from saying anything. It does not stop it from saying the wrong allowed thing.

So a decision model makes a good screen in front of other AI and a poor lock. Who may approve a transfer, release a record or file a document stays in code and permissions, where a clever sentence in the input cannot reach it.

Keep numbers, dates and counting in code.

TypeSafe is direct about this. Its documentation says Jev “does not count reliably,” reads dates “as text, not as ordered quantities,” and that its score levels are “weak in numerical calibration.” Regulated work runs on exactly those things: a Reg E dispute window, a filing deadline, a dosage, a debt-to-income ratio.

The pattern TypeSafe recommends is the right one. Let the model find the date, the amount or the dose in the text, which is a judgment. Let code compare, add and check it against the rule, which is arithmetic. The model reads. The code counts.

Send only what the question needs.

TypeSafe reports that accuracy falls as the input fills with material unrelated to the decision, and recommends filtering first and sending only the fields a question needs. In healthcare that habit has a second reason behind it. HIPAA’s minimum necessary standard asks covered entities to limit uses and disclosures of protected health information to the minimum necessary for the purpose. A referral check does not need the whole chart, and sending less makes the answer better and the disclosure smaller at the same time.

Draw each line by what a mistake costs, then check it.

TypeSafe’s routing example is a voice banking assistant. Anything below 0.6 confidence goes to a person. Checking a balance can run at 0.6, because a wrong read costs the customer a few seconds. Approving a transfer needs more than 0.85, because a wrong read moves money. That is the right way to think about thresholds in any regulated setting: one line per action, set by the cost of being wrong.

Two cautions carry over from our last post. Jev’s confidence field describes how concentrated its probabilities are, which is how sure it sounds, not how often it is right. And the only way to know whether a line at 0.85 means anything is to run the model on a few hundred of your own past cases with known answers and count. The first independent test on medical text found answers at full confidence that still disagreed with the labels.

Where it doesn’t belong.

TypeSafe’s own list is a good guide. Writing anything, from a clinical summary to a brief to a member letter, belongs to a generative model. To that I would add long analysis that has to connect page 4 of a contract to page 40, and any open-ended conversation. Questions that take several hops, or that hinge on a double negative, lose accuracy, so split them into plain questions and combine the answers in code. And the model reads literally: it answers the question you wrote, not the one you meant, so the criteria have to carry the edge cases.

Put together, the design is simple to describe. Code owns the workflow and the arithmetic. The decision model answers the narrow questions a person used to answer by reading. A generative model writes whatever has to be written. And a person owns every line where a wrong answer costs a customer, a patient or a client something real.