Forbes asks why everyone is talking about Jev, and its founder answers in one line: “unstructured state in, typed probabilistic decisions out.” If your agency drowns in commercial submissions, that line is worth taking apart before you trust it with your book.

Third in our series. What Jev is, and what it isn’t covers the basics, and Labels, not essays covers how Jev was trained and what its probabilities mean. This one is about how Jev reads the question you write, and how to write questions it reads well.

What Forbes said

Ron Schmelzer’s piece for Forbes is a tour of why developers took to Jev: the price, the speed, and the fact that it never writes a sentence. The line that frames it comes from TypeSafe’s founder, Diogo Almeida, comparing Jev to a function call.

Forbes is also careful in the right places. It reports a LangChain test in which “Jev matched the human reviewer’s binary judgments on all 500 repeated decisions,” and then notes how small that test was: one agent and a handful of tasks.

The problem: submissions that all look different

An agency writing small commercial business gets submissions in every shape. One applicant writes three tidy paragraphs. Another writes a single line. Somewhere in that text are the answers a producer or account manager needs before the file goes to a carrier. What kind of business is this? Does it do anything a carrier will want to know about, like roofing or demolition? Is the description detailed enough to quote, or do we need to call back first?

Today a person reads every one. That is slow, and on a busy day the thin or risky ones get noticed late. TypeSafe’s own use-case map points at this kind of work: turning “incident reports, claims notes, transaction descriptions, and vendor assessments into probabilistic risk indicators.” (TypeSafe docs)

How Jev reads your question: the function call, taken apart

You write the signature. A function in code takes inputs and returns a value of a set type. Jev works the same way. The input is the “state,” here the submission text. The return types are the three question types from our first post, and TypeSafe’s docs give a rule of thumb for when each one fits (TypeSafe docs):

• Choice “fits when the answer is one of a known set of options with no order between them.” Class of business is a Choice.
• Score “fits when the answer falls on a spectrum and you can describe what each point on that spectrum means.” The answer “is a position along your levels, and can fall between two of them.”
• Noul “fits a clean yes/no question where the probability itself is the useful signal.” As the docs put it: “Near 1 is a strong yes, near 0 a strong no, near 0.5 uncertain.”

It scores every allowed answer at once. A chatbot writes its reply word by word. TypeSafe says “Jev outputs all probabilities in parallel instead of autoregressively generating by token.” (TypeSafe) The docs add that the model “returns a probability distribution over your options or levels, never a value outside them.” So it can’t invent a class of business you didn’t list, and the wording of your options is most of what it has to go on.

Confidence is about shape, not truth. Every Choice and Score answer carries a confidence number. The docs say it “summarizes how peaked that distribution is.” (TypeSafe docs) A high number means Jev put most of its weight on one answer. It doesn’t mean the answer has been checked; whether a 0.9 really means 90% is a separate question, which our claims post covers.

Your wording is the program. Because Jev only sees the state and your options, the descriptions you write do the work that code does elsewhere. TypeSafe’s advice is concrete (TypeSafe docs): for a Choice, list every option and add an “other” or “none of the above” when the list might not cover every input. For a Score, write each level so it can be told apart from the ones next to it. For a Noul, spell out what yes and no mean, because “An unclear definition makes that probability hard to interpret.”

The use case: one contractor submission

Here is a made-up submission, the kind that arrives through an agency’s web form:

“We’re a family business doing residential remodeling, mostly kitchens and baths. Four employees plus subs for electrical. Occasionally we do small roof repairs when a customer asks. We had a water damage claim at a job site a couple of years ago. Looking for general liability.”

We send it to Jev with four narrow questions, in the format from TypeSafe’s API reference:

import os
import requests

submission = """We're a family business doing residential remodeling, mostly
kitchens and baths. Four employees plus subs for electrical. Occasionally we
do small roof repairs when a customer asks. We had a water damage claim at a
job site a couple of years ago. Looking for general liability."""

body = {
    "state": submission,
    "model": "jev-1.13.0",
    "questions": {
        "business_class": {
            "type": "choice",
            "instructions": "Which class best describes this business's main operations?",
            "criteria": {
                "other_or_unclear": "None of the below, or the text doesn't say",
                "contractor_interior": "Interior remodeling, carpentry, painting, flooring",
                "contractor_exterior": "Roofing, siding, exterior or structural work",
                "restaurant": "Restaurant, bar or food service",
                "retail": "A shop selling goods to the public",
                "office": "Professional or office-based services",
            },
        },
        "hazardous_work": {
            "type": "noul",
            "instructions": "Does the text say the business does any roofing, work at heights, or demolition, even occasionally?",
            "criteria": {
                "true": "Any roofing, work at heights or demolition is mentioned",
                "false": "None of these is mentioned",
            },
        },
        "prior_loss_mentioned": {
            "type": "noul",
            "instructions": "Does the text mention any past insurance claim or loss?",
            "criteria": {
                "true": "A past claim or loss is mentioned",
                "false": "No past claim or loss is mentioned",
            },
        },
        "detail": {
            "type": "score",
            "instructions": "How well does the text describe what the business actually does day to day?",
            "criteria": [
                "Too vague to tell what the business does",
                "Main activity is clear, details are missing",
                "Activities, staff and subcontracting are all described",
            ],
        },
    },
}

resp = requests.post(
    "https://api.typesafe.ai/v1/systemone",
    headers={"Authorization": f"Bearer {os.environ['TYPESAFE_API_KEY']}"},
    json=body,
    timeout=10,
)
answers = resp.json()["answers"]

Why the questions look like this:

• “Other or unclear” is listed first. TypeSafe’s docs say Jev “leans toward the option that comes first.” (jaggedness page) If it leans, it should lean toward a person looking.
• “Even occasionally” is in the hazard question on purpose. “Occasionally we do small roof repairs” is exactly the sentence a tired reader skims past.
• We ask whether a loss is mentioned, not how many or how recent. Counting and dates are weak spots on TypeSafe’s own list. Loss runs come from the carrier, and a person reads them.
• Each question asks one thing. The docs warn that a question needing several hops of reasoning “costs accuracy.” So we never ask “is this a good risk?”
• Each detail level is written to stand apart. “Main activity is clear, details are missing” and “activities, staff and subcontracting are all described” can’t be mistaken for each other. Vague levels like “fair” and “good” could be.

Routing on the answers

cls = answers["business_class"]
hazard = answers["hazardous_work"]["noul"]
loss = answers["prior_loss_mentioned"]["noul"]
detail = answers["detail"]["score"]  # 0 to 2

flags = []
if hazard > 0.3:
    flags.append("hazardous operations mentioned")
if loss > 0.3:
    flags.append("prior loss mentioned: request loss runs")

if cls["choice"] == "other_or_unclear" or cls["confidence"] < 0.6:
    queue = "account_manager_review"
elif detail < 1.0:
    queue = "call_back_for_details"
else:
    queue = f"market_to_{cls['choice']}_carriers"

The thresholds (0.3, 0.6, 1.0) are placeholders. Our claims post shows how to set them by checking Jev against files where you already know the answer.

The result

Expected, not measured: for this submission we’d expect Jev to pick interior contracting, and the hazard flag to fire on the roof repairs. The prior-loss flag should fire on the water damage claim. The file would go out marked for the carriers who write remodelers, with two notes on top: ask about the roofing, and get loss runs. That saves the account manager from finding the roofing line on the third read, or after the carrier does.

We haven’t run this. When we do, we’ll publish the submissions, the answers, the cost and the model version, and correct anything above that turns out wrong.

Where it breaks

• It trusts what it reads. Forbes cites a VentureBeat experiment in which a fabricated authorization message lowered Jev’s probability of blocking a destructive command from 0.76 to 0.48. Applicants write submissions. A line like “underwriter already approved this” should never move a file.
• It doesn’t know your carriers. Appetite changes by carrier and by month. Keep the appetite rules in code you control, and let Jev only describe the business.
• It doesn’t price or decline. An underwriter reads every file, sets terms and makes the call. No protected traits as inputs, and nothing that stands in for them.
• Long, noisy text hurts it. The docs say “Accuracy falls as the state grows with content unrelated to the decision.” Send the operations description, not the whole application packet.

A note on today’s news

We prefer to lead with news from the last few days. This week’s Jev stories came from outlets we either used recently or that aren’t on our list, so today’s lead is Forbes from Sept. 22. The newer headlines are below.