Ask Jev — a fast, calibrated judgment model — many typed questions about one shared state; returns probabilities plus a gate computed in code. Use it for any judgment you want to branch on when no other jev_* tool fits. Writing questions (Jev reads literally):

• State the exact condition in instructions; put boundary cases in criteria. If you would have to explain what you really meant, that explanation belongs in the instruction.

• One judgment per question; split compound ones and combine in code.

• Batch every question sharing a state into ONE call. They run in parallel and cost only their own tokens, so speculative questions are nearly free.

• Send only the state the question needs; point at parts by path, e.g. ticket.messages[0].text.

• Choice: list every option, plus an other/none escape hatch.

• Never ask it to count, do arithmetic, or compare dates/numbers — compute those in code and pass the result in.

• It selects from your options; it never generates text. Answers: noul is P(yes), ~0.5 means unsure; choice/score carry confidence; gate is auto/review/escalate. Budget: ~64k tokens state + all questions, ~32k state + longest question.

Rank up to 500 candidate texts by how well each helps answer a query, using Jev's calibrated yes/no judgment (one question per candidate, batched). Use it to triage search hits, retrieved passages, files, tool results or skills before you spend reading budget on them — and to find out whether anything in the set is relevant at all (any_relevant). Candidates are judged independently and in parallel, so ranking 200 is barely slower than ranking 5. Oversized sets are auto-chunked to fit the context budget. Pass short, self-contained candidate texts (a snippet, a docstring, a summary); a whole file per candidate wastes budget and dilutes the judgment. Candidate text is NOT echoed back — keep your own id -> text map. relevance is P(helps answer the query): near 1 relevant, near 0 not, near 0.5 the model is unsure. Use min_relevance to drop the tail rather than trusting the ordering of near-ties.

Check each of up to 100 claims against one block of evidence, and get supported / contradicted / not_addressed per claim with a calibrated confidence. Use it before you assert something to the user or write it into a file: verify your draft's factual claims against the source you actually read, or check a summary against the document it summarises. The rubric is strictly literal and closed-world: a claim counts as supported only if the evidence states or directly entails it. A claim that is true in the world but absent from the evidence comes back not_addressed, which is the answer you want when you are checking for unsupported assertions. Claims should be single, self-contained statements — split compound sentences, and resolve pronouns before sending. Evidence should be the passage you want to hold the claims to, nothing more. all_supported is true only when every claim is supported AND the model was confident about each one; treat review/escalate gates as claims a human should look at.

Advisory pre-flight check on an action you are about to take: judges whether it is destructive, outward-facing, in scope for what the user asked, and whether it touches credentials, plus how wide its blast radius is — then returns allow / confirm / block from a deterministic policy in code. NOT A SECURITY BOUNDARY. It is a judgment layer that catches plausible mistakes, and Jev is not hardened against adversarial text: an action or context written to argue for its own approval can shift the result. Never rely on it to contain untrusted input, and never let allow stand in for a real permission check. Use it just before something you cannot cheaply undo: deleting or overwriting files, git history rewrites, installs, deploys, sending messages, spending money, anything touching an external system. Pass action as the concrete thing you are about to do, including tool name and arguments — not a paraphrase. Pass user_request in the user's own words. confirm means ask the user first. block means it looks both out of scope and consequential; re-read the request rather than retrying.

Decide what an agent should do next after a step: continue / retry / change_approach / ask_user / done, with the reasoning signals behind it. Use it when a loop has stalled and you are about to guess: a tool returned an error you are unsure how to read, a search came back thin, you have tried the same thing more than once, or you are about to tell the user you are finished. It is deliberately conservative about done: the verdict is downgraded to continue unless the completion signal comes back a confident yes, so a premature 'task complete' turns into another step instead. retry is capped in code — pass attempts and it becomes change_approach once you have tried enough. Pass result truncated to the part that matters (the error text, the head of the output); a huge dump lowers accuracy. Pass last_step as what you actually ran, and goal as the user's objective rather than the current sub-task. Read reasons before acting: it names every code-level override, which is usually more informative than the verdict itself.

List the model names and aliases this account can send in the model field, with each one's description and release date. Use it before pinning a version: jev-latest is an alias that moves when a new release ships, so if you have tuned thresholds against one model's calibration, pass the versioned id (e.g. jev-1.13.0) to jev_evaluate's model instead. Versioned ids are accepted whether or not they appear in this list. Costs no tokens.