Many AI decisions are naturally choices among structured alternatives: select a tool, route a request or identify a suitable workflow. Serialising those alternatives into a prompt leaves a generative model to infer rules the application already knows. The ordering of a list should not change its meaning, and an inadequate menu should not force a selection.
Jeva treats those requirements as properties of the architecture. It independently represents requests and options, then uses a compact decision stack to compare them. This makes the paper relevant beyond the familiar question of whether a model is confident. It asks what a confidence score is actually describing.
Competition and coverage are different questions
Jeva, described in an October 13 paper, treats this as an architectural problem. It independently encodes requests and options, then uses a separate coverage estimate to support an explicit null outcome. Its authors report no decision flips under the option permutations they tested, alongside reuse of option representations across requests. Read the research paper.
A probability distribution over candidates tells the user which listed option wins relative to the others. It need not reveal whether any candidate satisfies the request. Jeva adds a separate coverage estimate so the system can distinguish competition among plausible options from absence of an appropriate answer.
That distinction has an operational consequence. Close competition may call for another observation that distinguishes two tools. Missing coverage may call for a new tool or escalation. A single scalar confidence cannot cleanly tell an operator which of those responses is appropriate, even when it is calibrated on its own chosen reference.
An option can be cached because the architecture makes it independent
Jeva’s option encodings and layer projections can be reused across newly assembled candidate sets. The justification is structural: that computation does not depend on the incoming request. It is a deliberately designed independence property, rather than an assumption that arbitrary internal model states are reusable whenever the underlying text matches.
This matters when interpreting latency improvements. Repeated choices over a stable catalogue offer more reuse than constantly changing options, and cache maintenance still has a cost. A tool whose description or capabilities changed must receive a new representation. The paper’s design brings scalability, stable ordering and reuse into the same architecture, but an application still needs to maintain the truth of its menu. Fast selection over an outdated option description is not a reliable decision, however consistently the model treats permutations of the list.
Symmetry is built into the comparison
The shared encoder represents each option independently, and symmetric aggregation supports permutation-equivariant probabilities. Reordering the alternatives should reorder the corresponding scores rather than change the decision. Shared scoring also allows the candidate set to grow without redefining a fixed output vocabulary.
The authors report no decision flips under tested permutations and strong null detection, including scaling to thousands of candidates. These results support the design on evaluated decisions. They do not guarantee that arbitrary option descriptions capture every capability or dependency a real tool might have. The representation of the menu remains a substantive input to the system.
Reusable computation can preserve a stable menu
Option representations and projections can be cached across requests because they do not depend on the current request. This is different from reusing context-conditioned document states: the architecture deliberately separates request-independent work. Latency savings follow from a stated independence property rather than an assumption that an arbitrary internal state can travel unchanged.
The wider opportunity is a cleaner interface between decision models and applications. The application can ask for a choice, a score or an explicit absence outcome, with predictable treatment of list order. Useful uncertainty begins by respecting the structure of the decision, rather than merely attaching a confidence number to generated text.
Questions, news tips or corrections? Contact [email protected].
