Recipe 2: filter RAG evidence
Retrieve candidates first; distinguish relevance from factual support.
Where Jev fits
User question → authorized retriever selects candidates → Jev judges relevance → code retains passages → a generative model answers with sources.
Jev does not build your vector database or grant document permissions. Apply access control during retrieval, before sending content to any model.
Keep stable candidate identifiers
{
"query": "How long after delivery can I request a return?",
"passages": [
{"id": "returns-01", "text": "Insert verified return-policy text here"},
{"id": "shipping-02", "text": "Insert delivery-time information here"}
]
}
Ask a Noul question for each candidate, such as whether it contains information needed to answer the query. A clearly defined Score rubric is another option. Code maps identifiers back to source text, sorts results and applies limits.
Relevance is not claim support
A passage may mention returns without specifying a deadline. It can be relevant without supporting “returns are allowed within 30 days.” Check factual claims against their evidence separately. Missing evidence is not permission to invent a policy.
Build a small comparison set
Label relevant passages for a fixed collection of questions. Compare the original retriever, Jev-assisted ranking and an existing reranker. Inspect Recall@k, answer evidence, latency and cost, not just a few fluent responses.
Extend with care
Policy support, presales research and technical assistance can use this pattern. Revisit access control, outdated documents, citation traceability and insufficient-evidence behavior for every use case.
Sources and verification boundary
Reviewed September 19, 2026. Documentation-based guidance, not a live API or business-performance test.
TypeSafe · Classifying RAG passages →TypeSafe · Noul →TypeSafe · Score →TypeSafe · How to build →
