A decision model takes a state plus a typed question whose options are listed in advance, and one forward pass returns a probability for every option, with no free text and nothing to parse. Whether it fits classification, routing or a guardrail depends on where those probabilities come from and how much of the training is public.
Part 2 of the series | This part answers: how does a decision model give every listed option a probability in one pass, and how is it trained?
Why probabilities need no generation
A language model that has read the input can return a distribution over options you listed, without writing the answer token by token: score the options, then normalize. Reading the whole input before producing anything is called prefill. At the end of prefill, the last position holds a logit for every vocabulary token: a raw score, positive or negative, not yet a probability. Keep the logits of the listed options and apply softmax (exponentiate, then divide by the sum) to get probabilities that add to 1.
It is closer to counting the bubbles on an answer sheet than to asking for an essay. Structured output from a generative model still writes the answer token by token and relies on a format constraint or a parser to hold the shape; its confidence is usually a number the model writes. A decision model writes nothing and reads a probability for each option instead. This contrast follows the official documentation and prefill-only implementations such as LLM2Jev, with some of our own reading.
There are three question types: noul is yes/no and returns the probability that a statement is true; choice picks one named option; score is an ordered grade. "Typed" means the options and the answer shape are fixed before the question is asked. Jev's documentation caps choice at 255 options; splitting a longer list into two stages is our suggestion.
Because a schema bounds the output space, a type error cannot occur; that is what the documentation means by "no hallucination." Whether the chosen option is right is still a matter of probability, handled with calibration (reported probabilities matching how often things actually happen) and a confidence threshold. That last sentence is our reading.
Four ways to build one
Public material shows four constructions: read existing logits without changing weights; fine-tune a causal language model or add a decision head; put a decision head on a bidirectional encoder; or add a joint schema head to a backbone. The git projects in the table are summarized from their README and code, and we did not run them; the Clef row comes from the model card.
| Construction | Where the probability comes from | Examples |
|---|---|---|
| Read existing logits | One forward pass, no token-by-token answer | open-alternative-jev, LLM2Jev, SemIf |
| Train, then read scores | A decision head, or LoRA followed by candidate logits | NanoJev, Kev, Nimble |
| Encoder | A decision head on a bidirectional encoder | Laya |
| Joint schema head | One logit per option per question, softmax per question | Clef, Clef-flash |
Reading existing logits. open-alternative-jev sits on any open-weight language model, reads the logits of the option letters in one forward pass, answers several choice questions, and ships a temperature (a coefficient that rescales scores) calibration tool. LLM2Jev turns each candidate into its own yes/no question, reads only the next-token logits for yes and no, computes q = exp(yes)/(exp(yes)+exp(no)), and normalizes the q values into probabilities; confidence is computed by the program as (n × p_max − 1)/(n − 1), clipped to 0–1, where n is the number of options. The author states it is not endorsed by TypeSafe. SemIf, formerly OpenJev, allows 2 to 16 options and explicitly labels its output conditional/uncalibrated; it runs on torch or Apple's MLX.
The joint schema head. Clef adds a small transformer head on a Qwen backbone. It reads the backbone's final hidden states, routes evidence from the state to each question, and scores all questions' options together: one logit per option per question, a softmax per question, one forward pass. According to the model card, Clef is a 27B multimodal decision model post-trained from Qwen3.8-27B, and Clef-flash is a 9B model post-trained from Qwen3.5-9B. Both are Apache-2.0 with weights on Hugging Face, and both accept the same /v1/systemone request shape as Jev.
We have no Jev credentials and did not compare Jev with Clef head to head. The measurements in this series use the open weights of Clef-flash: on a Mac with MLX at 4-bit, and on an NVIDIA workstation with llama.cpp and the GGUF Q4_K_M build.
What Jev has and has not disclosed about training
Jev's published training information is the name RLCD, the goal of returning calibrated decision probabilities rather than generated text, data made in-house, and no training on user input; the architecture, parameter count, base model, training data, and the exact form of the reward and loss are not public. RLCD stands for Reinforcement Learning for Calibrated Decisions. The announcement also calls Jev "neither small nor an LLM" and says the data is "all ourselves." This series treats everything else as unknown.
The privacy policy says user input is not used to train or fine-tune the model, but input is still processed by the hosted service. That is a separate question from whether the weights can be downloaded.
The Clef and Clef-flash cards likewise say only that the models were post-trained from Qwen3.8-27B and Qwen3.5-9B, without the training data or details. Our reading: open weights do not let an outsider rerun the training.
How the open replicas are trained
These are third-party projects publishing their own readout, data or weights; none of it is a Jev training recipe published by TypeSafe. The summaries below follow each project's README and code; we did not run these projects. We condensed NanoJev, Kev and Nimble into five shared steps: prepare questions with gold answers, pick a backbone, add a decision head or LoRA, train against a scoring rule, and evaluate accuracy and calibration together; details differ by project.
NanoJev adds a decision head that reads option scores to Qwen3-0.6B, publishes data generation, training code and weights, and compares three objectives: cross-entropy, Brier, and a paired proper reward. The author does not claim it is the official Jev recipe.
Kev starts from Qwen3.5 Base with LoRA (training only small added low-rank weights) and a pointer head, builds a Jev-shaped local decision model, and implements /v1/systemone. A block-causal mask lets each question see the shared state but not the other questions. Weights come in 0.8B, 4B and 9B under Apache-2.0; the author reports new-source test accuracy of about 0.684, 0.837 and 0.852, which is not our measurement.
Nimble (Bespoke Labs) publishes data, a model and a recipe: contrastive data curation, LoRA fine-tuning of Qwen3.5-9B on answer tokens only, and candidate logits at inference. The author states it was not distilled from Jev. The repo holds 2,676 training rows and 324 evaluation rows.
Laya pairs a bidirectional ModernBERT encoder with decision heads; per its repo, 421M parameters for English and 322M for the multilingual version. The author of a third-party MLX port reports a short-question P50 of 13.42 ms (English) and 7.39 ms (multilingual) on an M3 Max. Cloudflare's Decision Index table (vendor-reported) lists Laya's median latency at 5.8 ms, with clearly lower accuracy on most tasks.
d1-3B (LiquidAI) is built on LFM2.5-VL-3B and returns typed answers in one forward pass with 0 output tokens; its card self-reports a Decision Index 0.2.1 score of 48.57 (vendor-reported). Per its model card (vendor-reported), its LFM Open License v1.0 excludes commercial use by organizations with annual revenue of $10 million or more. We have not run it.
Most of these projects install only from git, and PyPI hosts unrelated packages with the same names, such as openjev and llm2jev. Check the source before installing.
Why proper scoring rules lead to calibration
Log loss and the Brier score are strictly proper scoring rules: the expected score is best only when the reported probability equals the true one, so training on them pushes a model toward calibration on its training distribution. This is a standard result in statistics; see Brier (1950) and Gneiting and Raftery (2007), JASA 102:359–378.
A rain forecast should match how often it actually rains; a model's probabilities should likewise match how often events occur in its training data. A proper scoring rule governs that expected score. It does not guarantee the match holds on new data.
The "Calibrated" in RLCD and NanoJev's comparison of a proper reward with cross-entropy and Brier point to the same idea: use a proper scoring rule as the reward. TypeSafe has not published its reward, so this is our inference, not Jev's recipe.
One more point is easy to miss: the confidence field in a response need not equal the top-class probability. In our 2026-10-11 measurements, the same abstract on the NVIDIA workstation had confidence 0.884 and a top-class probability of 0.897. Part 3 explains the difference on 77 PubMed papers and links the calibration checker, which computes Brier, ECE and a reliability diagram in your browser without sending data anywhere.
A final point, also our inference: if each judgment is calibrated on its own, a pipeline that chains several judgments is not necessarily calibrated as a whole. A guardrail that asks several questions cannot treat per-question calibration as calibration of the whole chain.