Imagine your incident bot has read docker pull failed: 401 Unauthorized from registry. The tests never ran. You need to route the failure to the registry owner. The bot replies with three paragraphs about Docker, credentials, networking, and possible next steps. Somewhere in paragraph two, it says what your program needed all along: registry authentication.
That's a strange way to get one branch condition.
A decision model accepts the incident as state, receives an explicit question and legal answers, and returns a choice or scores for those answers. TypeSafe's Jev brought this idea into view with an API for typed decisions: choices, rubric scores, and 0–1 truth scores (Noul). TypeSafe says Jev produces the decisions in parallel and trains for calibrated probabilities. It hasn't published enough of Jev's internals to reconstruct the model, so the open implementations below are useful explanations of the design space, not copies of Jev.[1][2]
A sentence and a decision are different products
Suppose the application allows three routes for the same log: test_regression, registry_auth, and needs_review. A chat model can be prompted to write a JSON object with one of those values. Grammar-guided decoding can enforce the syntax. The model still generates tokens until the object is complete, and legal syntax alone doesn't show that the chosen route is right.
A direct decision readout instead scores those three named alternatives. It can return the winner and the distribution without drafting an explanation. The win is a narrower interface, not free reasoning or free compute: the model still has to read the log and process the question.
💡 The useful mental model: A decision model is a learned branch condition over a bounded answer set. The application still owns the allowed answers and what happens after selection.
The boundary is valuable in software. A returned value can be validated against an enum. It doesn't authorize a credential rotation or prove that the label was correct. Treat the log itself as untrusted data, including any line that asks the model to ignore the caller's question.
Jev is the headline, but its internals aren't public
TypeSafe describes Jev as a System One model with a new architecture, a parallel sampler, and Reinforcement Learning for Calibrated Decisions (RLCD). Its launch reports strong speed and price results on TypeSafe's workflow evaluations and also discusses where its examples and reference answers may favor the system. Those are provider-reported results, not an open recipe or a controlled benchmark against every alternative.[1]
The honest question is: what can we inspect today? Three public projects expose different ways to turn language understanding into a bounded answer. They share an interface goal, not a model architecture.
| Route | Actual readout | Training for the decision task | What remains to check |
|---|---|---|---|
| Kev | Learned pointer head compares option-marker states to a decision-marker state | LoRA adapter plus pointer head; base Qwen frozen | Accuracy, calibration, option order, and domain transfer |
| SemIf | Reads fixed answer-letter logits from a frozen Qwen language model | None in its baseline | Whether letter-logit preferences work for your prompt and task |
| Tev1-style fine-tune | Generates one answer letter, then client maps it to JSON | Supervised LoRA on labeled answer-letter completions | Format failures, decision quality, and confidence calibration |
Kev is the clearest open example of a purpose-trained readout. Its Qwen backbone processes state, question, and options with special markers. The learned head compares each option's representation with a final decision representation, then a softmax produces a distribution over the choices. The Qwen base stays frozen while the adapter and head train on labeled decisions. Kev's maintainers say no Jev outputs were used to train it.[3]
SemIf asks how far you can get without that training. It presents the state and alternatives to a frozen model, reads the next-position logits for fixed answer letters, and normalizes those candidate scores. There's no need to sample a letter just to inspect its logit. SemIf explicitly says its method isn't Jev's undisclosed architecture.[4]
Together's Tev1 recipe takes another path: supervised fine-tuning makes Qwen3.5 complete one answer letter, and application code turns the letter into a structured response. That's a short language-model completion, not Jev's private RLCD procedure. The public recipe uses a versioned set of 37,840 training records for one epoch; its source is more precise than the original blog prose, which gives a conflicting total.[5]
The invisible denominator under every score
Return to the three incident routes. Imagine the model assigns logits 2.0 to test_regression, 1.0 to registry_auth, and 0.0 to needs_review. Softmax converts them to about 0.665, 0.245, and 0.090. These are invented values for the example. The model is wrong: the registry response arrived before any test ran.
That 0.245 doesn't mean there's a 24.5% chance that the incident truly belongs to registry authentication. It is a normalized share of the three offered scores. Remove needs_review, and the share changes even if the registry logit doesn't. Change the option descriptions or order, and the model may change its scores too. SemIf's method documentation calls out this conditional-score limit.[4]
The training signal for a labeled record is straightforward: if the reviewed answer is registry_auth, minimize the negative log probability of that option. Kev updates its adapter and pointer head with that loss. A letter-completion trainer applies its loss to the answer letter. Different parameters move, but both require examples whose labels mean what the product needs.[3][5]
The data is often harder than the optimizer. Split by incident ID rather than by individual log line, or near-duplicate failures leak into the test set. Add records where none of the named teams fits. Rotate option order. Hold out a new source system. Compare the model with a simple rule for obvious signatures such as 401 Unauthorized. The model earns its place on cases where semantic interpretation improves the workflow, not on a benchmark engineered around its favorite prompt.
Keep the final test set sealed while fitting the model and any calibration temperature. This is the short path from labeled incidents to a release decision:
When one input needs three answers
The incident collector may ask: which team owns this, is customer impact reported, and how urgent is the evidence? Those questions can share the same state. A useful runtime can fan them out, score each legal answer set, and return a typed bundle. TypeSafe says Jev samples its questions in parallel; don't assume every open implementation uses the same scheduling. Kev's current Qwen3.5 path evaluates questions in separate rows while reusing cached state.[1][3]
That gate is where probabilities become product behavior. A route can automate only when its error rate at the selected threshold meets your budget on held-out cases. Fit a calibration temperature on a separate development set, inspect a reliability plot, then measure selective risk at the exact operating point. Temperature scaling can improve reliability on some neural networks without changing the top choice, but it can't repair bad labels or guarantee transfer to another incident source.[6]
⚠️ A confident wrong answer is still wrong. A typed enum prevents unexpected shapes. It doesn't prevent a model from choosing the wrong legal value. Keep
needs_reviewand an application-owned approval path for consequential actions.
One more trap matters for frozen-letter baselines. The first-token probability for A, B, or C needn't match what an instruction-tuned model would say after writing a full answer. Wang and colleagues found substantial mismatch in their tested tasks and models. Score the exact readout you plan to deploy; don't substitute a chat transcript as if it were the same measurement.[7]
Try the branch, then measure the workflow
For a first experiment, label a few hundred real incidents with the intended route and a needs_review option. Freeze incident groups into development and final test splits. Measure a deterministic rule, a short generated-label baseline, and an open decision readout on the same examples. Record accuracy, option-order flips, Brier score, coverage at your acceptable error rate, and end-to-end latency. Revisit the labels behind every confident error before fine-tuning.
You can inspect open Kev and SemIf readouts in the Kevala browser playground. For the complete training objective, worked loss, and release checklist, continue with the decision-model curriculum lesson.
The appealing part of this story isn't that an AI says registry_auth faster than it writes an essay. It's that software can ask for a bounded judgment, see the uncertainty, and decide what to do next. The model supplies a score. The system earns trust by checking when that score deserves action.