Explainable by design, without pretending the model explains itself

Jev does not tell you why it answered. That is a feature. Explanations you can defend come from the structure around the model, not from the model narrating itself.

Asking a large language model to explain its answer produces fluent text. It does not give you a faithful trace of how the answer was produced. Treating that text as an audit trail is a mistake that will surface the first time someone challenges a decision.

Jev doesn't generate explanations at all. It returns a typed answer and a probability. So the explanation has to come from somewhere else, and that turns out to be the more honest route.

Where the explanation actually lives

The question, written in plain English and versioned. "Does the request ask for standing admin rights?" is something a reviewer can read and check.
The state: exactly which evidence fields were sent, and how fresh they were.
The answer and its distribution, so you can see a close call from a clear one.
The policy rule that turned the answer into an action, with its version.
The reason code, generated by policy, not by the model.
The human outcome: who reviewed it, what they did, and whether they agreed.

Keep the prediction and the final action as separate records. Together they let you rebuild any decision after the fact, and compare groups of decisions over time.

Explaining to the person affected

When someone asks why their request was routed or held, the honest answer is the reason code, the evidence it rested on and a named contact who can review it. "Held because the justification didn't state a duration; your approver can release it" is clearer and more accurate than a paragraph of generated reasoning.

Explaining to the organisation

Calibration checks whether groups of predictions behave as their probabilities suggest. It doesn't guarantee any single answer, but it tells you whether thresholds are working. Report it per question and per release, with the number of cases behind each figure.

This is less black box, but it isn't magic transparency. The model's internals stay opaque. What becomes visible is every point where a decision could go wrong: the question, the evidence, the threshold and the rule. Those are the points you can test and fix.