Jev and Laya Explained: How Non-Autoregressive “System One” Decision Models Work

You have a routing step in an agent pipeline. Four possible destinations. The LLM call costs a full generation, 1–2 seconds, and a token bill. The answer is one of four strings.

That mismatch is the whole story behind Jev and Laya. In September 2026, TypeSafe AI launched Jev, a hosted "System One" model, alongside a $40 million seed round. Three days later, Convai Innovations open-sourced Laya, and the community immediately labeled it "the open-source Jev." The headline framing — faster, cheaper LLMs — is the weak model. The sharper one: these are not language models at all. They are typed decision functions, and the interesting consequence is not speed. It is that the output space is closed by construction.

Here is the invariant this article will prove: no generation, no hallucination, no free-form answers — and no ability to answer a question you failed to ask.

The Mechanism: One Forward Pass, No Tokens

Autoregressive decoding produces one token at a time, each conditioned on every token before it. That sequential dependency is why generation is slow and why format drift is possible: the model is always choosing the next token from a vocabulary of tens of thousands, and nothing structurally prevents it from choosing wrong.

A non-autoregressive decision model removes the loop. It runs a single bidirectional encoder pass over the input state and emits scores over a fixed answer space. There is no token stream, no sampling step, no decoding.

The call contract is the mechanism:

{
  "state": "refund not received after 30 days",
  "questions": [
    { "type": "choice", "options": ["billing", "support", "sales"] }
  ]
}

State in — a string, a JSON object, or an array of text values. Typed questions in, with every candidate answer declared by the caller. Numbers and probabilities out. No prose, no reasoning chain, no explanation.

Laya's concrete shape: roughly 421M parameters, a ModernBERT-large backbone plus a decision head with an option-marker scorer and an act/escalate output. English and multilingual (mmBERT) checkpoints ship under Apache-2.0. Jev is proprietary, hosted, and described by its vendor as a function mapping unstructured state to typed probabilistic decisions, trained with a method it calls Reinforcement Learning for Calibrated Decisions (RLCD).

"System One" is a useful label for single-pass, low-deliberation inference. It is not a cognitive theory, and it stops being exact the moment someone reads it as a claim about how minds work.

The Three Question Primitives: choice, score, noul

Both implementations share the same interface vocabulary. Learn it once and you can read model cards, API docs, and eval results without guessing.

Type	Meaning	Answer shape	Typical use
choice	pick one of N options	{ choice, probabilities }	routing, classification, triage
score	level on an ordered rubric	{ score, probabilities, choice }	severity, priority, quality
noul	calibrated yes/no	{ noul: P(true) }	gating, filtering, approval

All three carry a confidence value — the probability of the returned answer. That is what makes programmatic gating possible: a --min-confidence 0.7 threshold, or an explicit escalate path when the model is unsure.

The decomposition pattern matters more than the primitives. Instead of asking "is this message malicious," ask several atomic typed questions — does the sender domain match, does the body request credentials, does it create urgency, do links conceal redirects — and let ordinary control flow combine the probabilities. Software owns the business rule. The model owns the narrow ambiguous judgment.

From Scores to a Decision: One Trace

The interface description above tells you what goes in and what comes out. It does not show the transition that matters: how a probability distribution becomes an action, an escalation, or a rejection. That transition is where most integration bugs live, so walk through one.

Suppose you are routing inbound support messages. You declare three options and a confidence floor of 0.70. The model returns a distribution over the declared set:

{
  "choice": "billing",
  "probabilities": { "billing": 0.81, "support": 0.14, "sales": 0.05 },
  "confidence": 0.81
}

The application logic is not inside the model. It is a policy you write:

result = decide(state, questions)
top = result["choice"]
conf = result["confidence"]

if conf >= 0.70:
    route_to(top)              # act
else:
    escalate_to_human(state)   # defer

The values above are illustrative, not measured. The point is structural: the model produces a distribution, and your threshold converts that distribution into a branch. Change the threshold and you change the system's behavior without retraining anything. Lower it and you automate more, at the cost of more wrong actions. Raise it and you escalate more, at the cost of human load.

This is also where calibration stops being academic. If the model reports 0.81 but is right only 60% of the time at that confidence level, your threshold is a lie you told yourself. The distribution is the model's output; the threshold is your risk policy; calibration is the bridge that makes the two agree.

The model never decides to escalate. It returns a number. Your code decides what that number means. Keep the threshold, the coverage floor, and the escalation path in application code where you can test and version them.

Why the Output Space Is Closed — and What That Costs

Type safety here is enforced by the interface, not learned during training. The model cannot emit a value outside the declared candidate set, and it cannot produce an invalid format. Hallucination in the generative sense is not suppressed; it is unavailable. There is no token stream to drift.

The cost is symmetric, and it is the part people forget. The model can only answer the question it was given. It cannot volunteer a fourth option the caller failed to consider. It cannot explain itself. If your option set is wrong, the model will confidently pick the least-wrong member of a wrong set.

This is also the boundary against agent reasoning architectures. A decision model is a component inside a control loop, not a planner. Do not read "System One" as a replacement for tool-calling or multi-step reasoning. It answers one bounded question per call, and the loop around it is yours to write.

One practical failure mode: high-cardinality option sets degrade quality. Keep option sets small. More than 20 options per choice is a known weak spot, and Banking77-style classification is not the target workload.

Calibration Is the Product, Not a Nice-to-Have

A model can be 95% accurate and still unroutable. If confidence scores are unreliable, the system cannot tell which 95% to trust.

The reported numbers are starting points, not guarantees. Laya's model card reports mean expected calibration error (ECE) around 0.466 before calibration versus 0.081 after. Base checkpoints are near chance on unseen tasks — roughly 0.362 zero-shot accuracy on the typed-decisions checkpoint. These models ship over-confident.

The engineering workflow is unglamorous and short: collect ~50+ labeled examples, fit a temperature per (question type, option count), then re-evaluate. Calibration should apply on every call, with an explicit opt-out for debugging.

Test for option-ordering instability. Reordering the candidate list can shift assigned probabilities materially — reports put the swing as high as 20%. Shuffle the candidate list in your eval harness rather than trusting a single ordering.

Gate, do not guess. Route low-confidence decisions to a human or to a generative model instead of forcing a choice. The probability is the point; a decision model without a threshold is just a slower classifier.

Jev vs Laya: The Decision Axis Is Data and Deployment, Not Benchmarks

Define the axis before listing differences, or you will end up arguing about a leaderboard that does not exist.

Axis 1 — zero-shot generalization. Jev is positioned as a ready-to-use generalist reachable through a hosted API. Laya's base weights are weak zero-shot and need domain data plus fine-tuning to become useful.

Axis 2 — sovereignty and cost structure. Jev is closed, network-bound, and billed per call. Laya is open-weight, runs locally (roughly 1–2 GB of memory, viable on CPU or a single modest GPU), and shifts cost to engineering and data work.

Axis 3 — context and option-space limits. Reported context windows differ substantially between the two, and long context plus large option spaces favor the hosted generalist.

Latency is a deployment property, not a model constant. Measured figures range from ~22–27 ms per decision on a warm GPU to 75–270 ms when the GPU has dropped to idle clocks. Hosted p50/p99 numbers include network time. Lock clocks, warm the server, and measure your own path.

The honest conclusion: Jev is a generalist in the cloud; Laya is a local specialist you fine-tune. Neither claim survives as "the open-source version of the other."

What the Evidence Actually Supports

Separate the layers before you trust any of them.

Confirmed and checkable. Laya's architecture, parameter count, license, and weights are public. The three question primitives are shared across implementations. The API contract is documented.

Vendor claims. Jev's stated 70–500 ms end-to-end range and the "40–200x faster than LLMs" framing come from the vendor. Read them as claims, not measurements.

Independent measurement, narrow scope. One testbed characterization reports Jev warm p50 around 281 ms and cold around 726 ms, and Laya p99 around 25.8 ms at roughly 1.10 J per decision. Useful — but scoped to that testbed's hardware and task set.

Open questions. How much of the speed advantage survives realistic network and cold-start conditions. Whether calibration holds across domains without refitting. How much of the reported quality depends on synthetic training data.

The class-level claim that does hold up: moving deterministic decisions out of the decoding loop removes real latency and cost, and it returns evaluation to standard statistical measurement — accuracy, calibration, coverage — instead of prose grading.

When to Use a Decision Model — and When Not To

Use it when the decision is bounded, the options are enumerable, the answer must be machine-checkable, and you need per-decision confidence you can gate on.

Do not use it when the output is open-ended prose, when the task requires multi-step reasoning or tool orchestration, or when you cannot enumerate the answer space in advance.

Do not treat it as a drop-in replacement for a fine-tuned classifier you already trust. The difference is where the task is defined: caller-declared options at inference time versus a fixed trained label set. That flexibility is the actual gain.

Keep the boundary honest. The model recommends; your permissions and policy layer authorizes. "A refund is requested" is not "a refund is allowed."

If you can enumerate the answers and need a gateable probability, a typed decision model belongs in front of your LLM, not instead of it. Pick one routing or triage decision in your current pipeline. Define three to five options. Collect ~50 labeled examples. Calibrate. Then compare accuracy, calibration, and p99 latency against the LLM call it would replace. The adjacent concept worth studying next is how calibration and coverage thresholds interact with escalation policy in a production control loop — because that interaction, not the model weights, is what determines whether your automation is safe to expand.