A number without a reason
A decision model gives you a calibrated probability and nothing that looks like an explanation. That is more honest than the alternative.
This translation was produced automatically using AI. The German version is the editorially reviewed original.
Jev returns a probability. It does not return a reason. For most software that is a feature, because a reason is something a machine has to parse and a probability is something it can act on directly.
For anything that touches a person's application, claim, invoice or employment, the missing reason looks at first like the whole design problem. It is not. It is a statement about where the record has to live.
01. The generated justification was never a record
A language model that classifies a case can be asked to justify itself, and the justification reads well. That has always been its own trap. The text is produced after the fact and is not a record of the computation that produced the decision. It is a plausible story about a decision, not the decision. Teams have been filing it as an audit trail anyway.
A decision model removes the illusion. You get a typed output and a calibrated probability, and nothing that resembles a reason. So the record has to be built around the model rather than requested from it.
02. What the record looks like
In practice the decision layer logs the state it was given, the exact question it was asked, the typed answer, the probability, the threshold in force at that moment, and the version of the question set. That is reproducible. Given the same state you can show what the system was asked and what it returned. A generated paragraph cannot make that claim.
The question set itself becomes a versioned artefact. Change a question and you change the basis of every later decision, and that has to be visible. In the systems we build, that set lives in the repository rather than in a configuration screen.
03. Calibration deserves one careful sentence
Calibration is a property of a distribution. If the model reports 0.8 across many cases, roughly eight in ten of those are correct. It says nothing about the case in front of you.
The threshold is therefore a policy decision about acceptable error, and it belongs in a document a person signed, not in a constant in a source file. Teams that take this seriously measure calibration on a held-out slice of their own data instead of assuming it.
04. Oversight needs boundaries, not prose
What the EU AI Act expects around human oversight for higher risk uses points the same way. Oversight is meaningful when the reviewer can see what the system was given, what it decided, and where the boundary sits. A confident sentence generated by the same system that made the call does not give them that. A logged state, question, score and threshold does.
There is a version of this that is worse than either option. A decision model produces a number, and a language model is asked afterwards to explain the number. It reads as thorough and it is not. The explanation is reconstructed from the output, never from the computation.
05. The shape we build toward
Typed decisions where the answer is a class, a score or a boolean. Generation only where a person genuinely needs prose. A decision record that sits outside both and does not depend on either being introspectable. Human review triggered by the probability band rather than by topic, so the cases nearest the threshold get the attention instead of the cases someone guessed would be sensitive.
None of that is new as a principle. What is new is that the decision layer became cheap enough for the architecture to be worth the trouble in ordinary B2B workloads, not only in the systems that already have a regulator attached.
