Between a model's answer and an action in your systems there is a step. Zarel is a governance runtime for that step, a different layer from a guardrail on the model's text, an evaluation framework or a model router: the AI proposes, a contract declares what may execute and for whom, and the runtime enforces it.

When deciding gets cheap

On 15 September 2026, TypeSafe AI opened early access to Jev, behind a waitlist, and called it its first "System One model" (DataCamp). Jev takes program state and typed questions and returns typed decisions, with no generated text: a Choice from a list of options, a Score against ordered levels, or a Noul, the probability that a statement is true. Each answer comes with a probability that TypeSafe describes as calibrated, and the model is trained with a method TypeSafe calls Reinforcement Learning for Calibrated Decisions (MarkTechPost). The weights and the architecture are not published.

The speed and price figures come from TypeSafe's own benchmarks. DataCamp notes that nobody has reproduced them independently yet, and that TypeSafe says it cannot prove the price is not subsidized. The direction matters more than the multiplier: a decision that used to take a call to a frontier model becomes cheap enough to sit in every branch of a program. Flavio Copes describes Jev as "a smart if statement" and shows it deciding whether an email gets a rate card or goes to a person.

Cheap decisions get automated in volume. Once they do, the question stops being only whether the model is right, and becomes who authorized each decision to execute, under which policy, and how that can be shown afterwards.

What a typed output guarantees

DataCamp's summary says Jev "cannot hallucinate or produce type errors, because valid outputs are defined in the schema in advance." Read closely, that is a statement about shape: every answer is one of the values you declared. Copes states the other half: the answers can still be wrong, Jev needs literal and specific questions, and indirect phrasing degrades its accuracy.

A wrong answer inside the schema is a perfectly valid value, and code that branches on it acts on it. The schema removed the invalid options; which valid option comes back is still the model's. Tom's Hardware states the limits plainly: Jev "can still misclassify information, fall victim to adversarial attacks, or answer literal wording rather than meaning." A narrower output does not change who wrote the input. That is the same exposure every classifier has, which is why a classifier's verdict makes a poor safety gate (You can't fight probabilism with probabilism).

Calibration is a different question from authorization

Vanessa Barroeta, PMO Team Manager at Telefónica Tech, put Jev to the test instead of taking the benchmarks on trust. The tool Barroeta built for it, judge-audit, does not measure whether a judge is right; it measures whether its "I'm 96% sure" is true, because in production being wrong while convinced is worse than being wrong. The run covers four datasets, six judges and 3,800 decisions, and it starts from a question worth keeping (translated from the Spanish): and if your agent delegates decisions to it… who watches the one that decides?

Barroeta sets aside the first result, 200 out of 200 on clean emails, as too perfect for an easy, synthetic dataset. The ones that matter come after. On 200 emails with traps (prompt injection, homoglyphs, social engineering, personal data), Jev was right 95.5% of the time, and when an injection fooled it its confidence usually fell with it, from 0.996 to 0.71. Claude Sonnet 4.5 was right slightly more often, 96.5%, and stayed confident when it was wrong. Barroeta turns that difference into a threshold: below it, the decision goes to a person, which in that run of 200 emails let Jev automate 73% of the decisions with no observed error, against 2% for Claude. Used as a router, Jev sent every task to the cheap model with 96% confidence until each option carried a one-line description, a failure in how the question was asked that nothing in the accuracy revealed. Barroeta also points out that the confidence field Jev's API returns is a rescaled maximum probability rather than a measure of uncertainty, which is why judge-audit checks the probability against human labels.

That is the right way to use a model's confidence: measured against your own decisions, and used to send the doubtful ones to a person.

The threshold then decides which decisions skip a reviewer. It says nothing about whether the action a decision triggers may execute, for this actor, on this record, and a well-calibrated 0.9 is still wrong about one time in ten. Which actions a decision can trigger, and where a person is required whatever the confidence, is a question of authority, settled by a rule declared before the model answered. A threshold can add a reviewer, and keeping it from removing one that such a rule requires is the job of the next layer.

Where the gate goes

A model like Jev is, if anything, a good proposer. Its output is narrow and typed, so it enters the system as data that is easy to check, and it remains untrusted input.

In Zarel, what may execute is declared in a contract, and the runtime enforces it. The contract lists the actions, the roles and what each role may do. A write goes through the gate: permission, the phase of the process and the declared preconditions, then the value bindings, which set a field from the actor's identity or check the proposed value against stored records instead of taking the model's word for it. An action the actor's role was never granted is refused. Where a write has to wait for a person's confirmation, the contract declares it as a guard on the write or on the state transition (effect: confirm); the guard asks the acting user and, when it names roles, only a user who holds one of them. The model's confidence plays no part in it. Each gate verdict is recorded with the version of the contract it was decided under, in a table outside the hash chain. The chain covers state-machine transitions and flow events, with signed checkpoints, so an edit to them is detectable by anyone holding the published key; verifying that without trusting the operator requires a deployment the customer runs, with keys the customer holds.

A model's probability does have one place in Zarel, where it can only add caution: a declared flow does not start when the model's confidence in the intent falls below the floor the contract declares (or a default, when the contract declares none), or when the model reports no confidence at all. Nothing works the other way round: a high probability does not waive a permission, a precondition or a required confirmation.

One pattern would connect Barroeta's layer to this one: recording the probability a model reported next to the verdict on the action it proposed, so that calibration can later be audited against what actually happened. Zarel does not record it today.

Two layers

A system that automates cheap decisions needs both layers: a measurement of whether the model's confidence holds on your data, and a declared rule for what may execute whatever that confidence says.

This is the typed-decision case of a broader line: communication and proposal may be probabilistic; authority, consequence, and compliance must be deterministic and declared. The general argument is in You can't fight probabilism with probabilism.

Nicolás Moreno builds Zarel: governed AI operations, where the AI proposes and the contract decides.