Jev and the Rise of Decision Models: What System One AI Means for Security Tools

On 25 September 2026, TypeSafe AI announced Jev, the first model in what it calls the "System One" category: not a chatbot, and not simply a bigger language model, but what the company describes as a decision model — something built to answer a bounded question with a typed, calibrated answer rather than a paragraph of prose. The announcement is dense with specific figures, so this piece goes through it exactly as claimed, marks plainly what we could and could not verify, and looks at why the underlying idea, deciding instead of generating, is worth taking seriously for security software in particular.

What TypeSafe actually announced

TypeSafe AI is founded by Diogo Almeida, who writes in the announcement that "At OpenAI, I helped build the methods that made language models useful at following instructions and talking with people." Jev, called the company's "first public model," is pitched as a different job entirely: producing what TypeSafe calls type-safe structured values with calibrated probabilities and confidence scores, generated through what it names a parallel sampler rather than the usual token-by-token decoding, and trained with a method the company calls Reinforcement Learning for Calibrated Decisions, or RLCD.

• TypeSafe reports an end-to-end response time of "70ms-500ms," against what it measured as "3 to 329 seconds" for the frontier language models it compared Jev to.
• TypeSafe prices input tokens at "$0.042 / MTok," with output tokens listed as free.
• On its own workflow evals, TypeSafe reports Jev running "193.6x faster, 444.6x cheaper" than the policies it was measured against.
• TypeSafe describes a type error in Jev's output as, in its words, "mathematically impossible."
• Jev is in early access; TypeSafe says it is bringing developers "off the waitlist as quickly as we can."

Generation versus decision

A large share of what gets called "AI in production" is quietly not a writing task at all. Allow or block a connection. Escalate or close a ticket. Flag or clear a transaction. Route a message to one queue or another. The desired output is not prose, it is a label pulled from a short, fixed list, sometimes with a score attached. Running that kind of question through a model built to produce fluent paragraphs is a mismatch: a JSON blob comes back that has to be parsed and hoped into validity, and any stated confidence tends to mean little in particular, because nothing forced it to track the model's real error rate.

Two claims are worth separating here, because they are not the same thing: typed, and calibrated. A typed output constrains the shape of the answer — a "choice" question returns one of the options on the list, a "score" returns a number inside a declared range, never a stray sentence or an invented field. Calibration is a much older and entirely separate idea. It is a statistical property, not a stylistic one: it means that when the system states a probability of 0.62, it is right about that often across many predictions like it, so a downstream program can actually threshold on that number instead of treating it as decoration.

TypeSafe's own naming borrows its vocabulary from psychology rather than statistics. Daniel Kahneman, who received the Nobel Memorial Prize in Economic Sciences in 2002 "for having integrated insights from psychological research into economic science, especially concerning human judgment and decision-making under uncertainty," popularized the terms in Thinking, Fast and Slow: "System 1" is "fast, automatic, frequent, emotional, stereotypic, unconscious," while "System 2" is "slow, effortful, infrequent, logical, calculating, conscious." The metaphor is evocative, but it describes human cognition, not a guarantee about a piece of software. A model can be fast the way System 1 is fast, without its stated confidence meaning anything at all — calibration has to be earned and measured, not implied by a name.

What "cannot hallucinate" can and cannot mean

TypeSafe's claim that a type error is "mathematically impossible" is describing constrained decoding, a technique that already exists elsewhere. OpenAI's own Structured Outputs guide makes a similar guarantee: the feature, it says, "ensures the model will always generate responses that adhere to your supplied JSON Schema, so you don't need to worry about the model omitting a required key, or hallucinating an invalid enum value." That guarantee is real and useful. It is also narrower than it sounds: it constrains the shape of the answer, not whether the answer is right. A "choice" question with three options will always return one of the three — including, if the model has misjudged the input, a confident, validly typed, wrong answer.

Calibration is the piece that has to be checked, not asserted. The standard tool is a reliability diagram: bucket predictions by their stated confidence, and for each bucket plot how often those predictions actually turned out to be right; the gap between the diagonal and the observed line is usually summarized as expected calibration error. This is not a new question for machine learning — Guo et al.'s 2017 paper "On Calibration of Modern Neural Networks" found that "modern neural networks... are poorly calibrated" by default, and that a simple, single-parameter fix called temperature scaling was "surprisingly effective" at repairing it. The lesson generalizes past that one paper: calibration is not a property a model gets to announce about itself. It is something you check, on your own labeled data, because it tends to degrade exactly where you need it most — on inputs that look nothing like whatever the model was tuned on.

A minimal eval harness (template)

Before routing a real decision through any decision model, Jev or otherwise, three questions matter more than any vendor figure: does the typed answer parse against your schema every single time, does a stated confidence track its real hit rate on a labeled sample of your own data, and does that calibration survive on inputs that differ from whatever the model has already seen. The sketch below is a template built around the request shape shown in TypeSafe's own quickstart documentation. It makes no claim about what running it against Jev would show — we have not run it, and this is illustrative pseudo-code, not a report.

# Illustrative pseudo-code. Mirrors the request shape shown in TypeSafe's own
# quickstart docs (POST /v1/systemone with state, model, and typed questions).
# Not run against Jev or any live API; no results are claimed here.
import requests

def ask(state: str, question_id: str, question: dict) -> dict:
    resp = requests.post(
        "https://api.typesafe.ai/v1/systemone",
        headers={"Authorization": f"Bearer {API_KEY}"},
        json={"state": state, "model": "jev-latest", "questions": {question_id: question}},
    )
    return resp.json()["answers"][question_id]

# 1. Shape check: does every response parse against the declared type, on your
#    own edge cases, not just a vendor demo set?
# 2. Calibration check: bucket the stated confidence and compare it to the
#    true label rate, on data the model has never seen.
buckets = {i: {"n": 0, "correct": 0} for i in range(10)}
for state, true_label in labeled_sample:          # your own traffic, labeled by hand
    answer = ask(state, "decision", {"type": "noul", "instructions": "Should this be allowed?"})
    bucket = min(int(answer["noul"] * 10), 9)
    buckets[bucket]["n"] += 1
    buckets[bucket]["correct"] += int(round(answer["noul"]) == true_label)

for b, s in buckets.items():
    if s["n"]:
        stated = (b + 0.5) / 10
        observed = s["correct"] / s["n"]
        print(f"stated~{stated:.2f}  observed={observed:.2f}  n={s['n']}")  # the gap here is your calibration error

• Whether the typed answer always parses, on inputs your own system produces, not only a vendor's demo set.
• Whether a stated 0.9 is right about nine times in ten on your own labeled traffic, not on someone else's eval set.
• Whether that calibration holds on inputs unlike anything it has seen before: a new app, a new protocol, a sender who has read the same announcement you just read.
• What the caller does on a timeout or an outage, since a decision system needs a safe default when the decision model is unreachable.

Why this matters for security tooling

A firewall, a spam filter, a fraud check, a triage queue: every one of these is a decision system, answering the same shape of question over and over — given this input, allow or block it, with how much confidence, and where the threshold sits. TypeSafe's own evals page draws its examples from exactly this territory: judging whether to close a security alert, escalate it to a person, or contain it immediately is a triage decision, not a writing task, and it is the kind of call a security tool makes constantly, at a volume no analyst could review by hand.

The privacy trade-off, honestly

Jev, as TypeSafe describes it, is a hosted API: a request carries "state," meaning whatever data the question is about, to TypeSafe's servers over the internet. For the security-incident and triage examples TypeSafe itself highlights, that state is exactly the kind of information many people would rather not hand to a third party by default — which app is talking to which address, how often, from which device. Sending it to any cloud model, however fast or cheap, means that data leaves the machine it came from.

FireAI, HisnLabs's own macOS firewall, made the opposite choice for the exact category of decision this article is about. FireAI runs on macOS 14 or later on Apple silicon, for a one-time €49, and is explicitly not an antivirus and not a VPN. When an app you have not seen before tries to reach the network, FireAI can run a small model on the device itself — an optional 1.5 GB download — to review that connection and prompt you with a plain-language reason attached; the traffic being reviewed is never sent anywhere. Every one of those AI-assisted decisions becomes a visible rule, tied to the app's code signature, that you can see and undo, sitting alongside threat feeds that are applied locally rather than queried against a remote server.

We are not claiming FireAI's on-device model matches Jev, or any other system-one model, in raw correctness, speed, or price — we have not run that comparison and have no evals of our own to publish here. What this announcement does support is a design direction: that a security decision is well served by a small, fast, bounded model running close to the data, rather than by routing it through a general-purpose chatbot somewhere else. TypeSafe is making that case from the API side; FireAI already builds on it from the on-device side, and for a different reason — because for a firewall specifically, the data in question should not have to leave the machine to be judged at all.

Open questions

• Independent evals: no outside party has yet published a reproduction of the speed or cost multiples in TypeSafe's announcement, on data TypeSafe did not choose.
• Calibration under distribution shift — the exact scenario Guo et al.'s paper is about, and the one that matters most against an adversary who adapts once a defense method is public.
• Whether the pricing holds at real production volume, and whether the stated latency holds under sustained load rather than a single demonstrated request.
• How the model behaves on adversarial or genuinely ambiguous inputs, where a confident typed answer can be less honest than an answer that says "unclear."
• When early access opens beyond the waitlist, to whom, and under what terms for the data sent as "state."

For now, Jev is a set of claims from a team with real credentials and no outside verification yet. The category it is trying to name, decision models rather than generation models, points at a real gap in how security software has been made to use AI so far. Whether or not Jev itself holds up under independent testing, it is a useful reminder that the interesting question for a firewall, a fraud filter, or a triage queue was never "can it write a convincing sentence" but "can it make a decision it can stand behind, fast enough to matter." That is the question we ask about the on-device model inside FireAI every time we change it — and it is why, for us, the answer stays on the device rather than becoming a request to somebody else's API.

How FireAI and HisnLabs fit in

We have not tested Jev and make no claim it works as described or that FireAI matches it in any way — but the idea that a security decision deserves a small, bounded, fast model instead of a paragraph from a chatbot is one we built FireAI around a year before TypeSafe wrote a blog post about it.

FireAI is HisnLabs’ own product: an on-device AI firewall for Mac. It shows every connection your apps make, in plain language, and lets you decide what leaves your Mac — its AI runs locally, so your traffic is never sent to us or anyone else. HisnLabs’ security research team is the group that keeps that decision-making accurate: cataloguing which domains are ordinary telemetry versus a real product, tracking the country and network behind a connection, and training the on-device model (its Autopilot feature) on real traffic patterns, all without any of it leaving your Mac.

You can read the technical decisions behind it, or try FireAI for 17 days, at FireAI, by HisnLabs.