Jev + RAG swaps reranker for per-passage probability gate

The article frames Jev + RAG as a change to one stage of a well-known pipeline rather than a new architecture. In a standard setup, documents are chunked, embedded, and stored in a vector DB; a query is embedded and the top-k closest chunks are pulled, often followed by a reranker that reorders those passages before they go into the context window. The newsletter's point is that this ordering step answers a different question from whether the evidence actually supports an answer.

The proposed alternative keeps retrieval exactly as it is and turns the query into shared state while the retrieved passages become candidates judged together. Each candidate gets a probability, application code applies a threshold, and passages above it continue while those below are dropped. The same request can also assess whether what remains is enough to answer at all.

The ceiling, as the article stresses, belongs to retrieval: Jev cannot recover a passage that never entered the candidate set. The practical stakes therefore hinge on where the threshold is set and on how much the existing embedding model and vector database are already surfacing — the pieces Jev explicitly does not replace.