Get fast, calibrated judgments from the Jev model at a decision point, instead of guessing in free text. Returns typed answers with probabilities. It never returns prose or reasoning, and it does not decide for you.

WHEN TO USE: you are about to pick between known options (which tool, route, plan, or file; allow/confirm/deny a risky action), check whether a condition holds (is the task complete, is there enough information to stop, does this need user confirmation), or grade something on a dimension you can describe (risk, relevance, severity). Do not use it for open-ended reasoning, arithmetic, exact lookups, or anything plain code or a tool can settle.

QUESTION TYPES:

• choice: exactly one of a set of options you define.

• noul: whether a condition holds. Use one noul per label when several labels may apply.

• score: a position on ordered levels you describe.

HOW TO READ THE RESULT:

• choice: "choice" is the top option, "probabilities" covers every option, "confidence" (0-1) says how concentrated that distribution is. Low confidence means no option clearly wins, which can also happen when two options are both acceptable.

• noul: "noul" is the probability that the answer is yes. Near 1 is a strong yes, near 0 a strong no. Near 0.5 means the model cannot tell. It does NOT mean "medium" or "partly". If you want a degree, ask a score question.

• score: "score" is the probability-weighted mean level, from 0 to "max_level", and can land between levels. Different distributions give the same score, so read "probabilities" and "confidence" with it.

• "certainty" (high/medium/low) and the noul "verdict" (yes/no/uncertain) apply the thresholds to those numbers. "needs_escalation" lists every question id whose answer is low certainty or uncertain.

WHEN AN ANSWER IS FLAGGED: do not act on it as if it were settled. Escalate in whatever way fits your situation: gather the missing evidence and ask again, reason the point through yourself, or ask the user. Medium certainty means proceed with caution, and verify first if the action is hard to undo. High confidence describes the model's answer, not a guarantee of truth or permission to act.

Rank 2-30 candidates (search results, candidate plans, next actions, models to route to) by grading each one on several described dimensions and combining the grades with your weights. Returns numbers only, never prose.

WHEN TO USE: you have a shortlist and the better choice depends on more than one factor (relevance and freshness; expected benefit, risk, and effort). For picking one option on a single question, use judge with a choice question instead.

WHAT TO PASS: "context" holds what every candidate is judged against (the query, the goal, constraints). Each candidate is graded in its own request, seeing only "context" and its own "content" as candidate, so grades are comparable and a candidate is never judged relative to the others. Dimensions must be independent; split "good and cheap" into two dimensions.

HOW TO READ THE RESULT:

• "ranking" is sorted best first. "composite" is the weighted mean of the normalized dimension scores, from 0 to 1.

• Each dimension reports "score" (probability-weighted level, can fall between levels), "normalized" (score divided by the top level), "confidence", and "certainty". The raw scores are returned so you can re-weight without calling again.

• "top_margin" is the composite gap between first and second place. "top_tied" is true when that gap is at or below "tie_margin": the ranking does not separate the two, so do not trust their order. Break the tie on something else or treat both as equal.

• Read the winner's "composite" as well as its rank. When every candidate is weak, the top one still has a low composite, and the right move may be to look for better candidates.

• "needs_escalation" lists each candidate/dimension pair graded with low certainty. That usually means the candidate's content does not say enough about that dimension, or the levels overlap. If a flagged pair involves a top candidate, get the missing information or verify before acting on the ranking.

Check whether supplied evidence actually supports claims you are about to state or act on. Returns a verdict and probabilities per claim, never prose.

WHEN TO USE: before reporting work as complete or a bug as fixed, before stating a root cause, before citing a source, or before building the next step on something you concluded earlier. Pass the claim and the raw evidence you believe backs it.

WHAT TO PASS: "evidence" is the actual material (test output, diff, log, document text), and "claims" are the specific statements to check against it. Several claims about the same evidence go in one call. Add "quote" when you attribute exact words to the evidence.

HOW TO READ THE RESULT, per claim:

• verified: the evidence states or directly implies the claim.

• contradicted: the evidence says the opposite. Retract or fix the claim.

• unsupported: the evidence does not address the claim either way. The claim may still be true, but this evidence does not show it; find evidence that does.

• fabricated: the "quote" is not in the evidence. Decided by string match with no model call, so "probabilities", "confidence", and "certainty" are null.

• "probabilities" covers supports / contradicts / says_nothing. "confidence" (0-1) says how concentrated that distribution is, and "certainty" (high/medium/low) applies the thresholds to it.

• "needs_escalation" lists claim ids whose verdict has low certainty. Do not treat those as settled, including a low-certainty "verified": get more direct evidence, check it yourself, or tell the user the claim is unconfirmed. A verdict only covers the evidence you passed; it cannot notice evidence you left out.

Run the staged Jev review over a diff you supply and return a structured report, never prose. The tool reads nothing from disk and runs no git: it judges exactly the patches you pass, so you and the tool are always looking at the same change.

WHEN TO USE: before committing, before opening or merging a pull request, or when asked to review a branch, once you have collected the diff. For a single judgment about one patch, use judge. To check a finding you wrote yourself, use verify_claim.

WHAT TO PASS: "files" holds one entry per changed source file, each with its own unified diff. Decide the scope yourself first (which base, whether uncommitted and untracked work is included) and leave out generated files, lock files, and anything that must not leave the machine: every patch is sent to the TypeSafe API. "test_files" holds the changed test files in the same shape. They are not reviewed; they are the evidence used when judging whether changed behavior lacks a test, so omitting them makes every test-gap screen fire.

COST: one request per file for screening (more for a patch over about 40,000 characters, which is split by hunk), then up to five profiling requests and about four requests for each of at most eight followed signals. Three files take a few seconds; a hundred take minutes.

HOW TO READ THE RESULT:

• "findings" is sorted by descending "severity" (0 to config.severity_max). Each one names a "file", a "line" (the first line of the evidence region, not the exact defect line), a "dimension" (correctness, security, reliability, compatibility, testGap), and a "mechanism". As a reference point, the jev-review workflow this pipeline comes from requests changes at severity 2 or above and comments below that. What to do with a finding is your decision.

• A finding is a lead, not a verdict. Open the file at the cited line and confirm it yourself before you repeat it. Pass the confirmed claim and the code to verify_claim if you want a second check.

• Each finding rests on three judgments: where the evidence is, which mechanism it shows, and how severe it is. "certainty" (high/medium/low) applies the thresholds to the least confident of the three, and "weakest_judgment" names it. A weak "location" often means the line is wrong even when the concern is real. "needs_escalation" lists the findings with low certainty: do not treat those as settled.

• "unresolved_signals" lists every screening signal at or above config.screen_threshold that produced no finding. "no_evidence_located" means it was followed, but no region was selected with enough confidence or the mechanism check found no concrete issue. "not_followed" means it fell past the config.max_follow_ups cap and was never examined. "request_failed" means the follow-up request itself failed. None of them means the file is fine: a screen fired and nothing confirmed or refuted it, so those files still need your own read, strongest probability first.

• "screening" holds, per file, the probability of every dimension that is not a clear no (at or above the lower bound of the noul band). A probability near 0.5 means the screen could not tell, not that the file is half broken. "quiet_files" counts the files where every dimension was a clear no; they are left out to keep the report small.

• "profiles" covers the config.max_profiles files with the strongest signals: a category and a "review_priority" from 0 (routine) to 3 (specialist review), with a "certainty" from the less confident of the two.

• "failed_requests" lists every request that still failed after retries, with its "file" and "stage". A file that failed at the "screen" stage was not judged at all: it is missing from "screening", is not counted in "quiet_files" or "workflow.screened_files", and needs either a second call with just that file or your own read. A "profile" failure only costs that file its profile. When every file fails to screen, the tool returns an error instead of a report.

• "owner" is set only for findings at severity 1.5 or above.

• An empty "findings" array does not mean the code is free of defects. Check "unresolved_signals" first. Jev reads only the text it is sent and does not compile, run tests, or follow calls into other files.

Run the staged Jev review over source files you supply and return a structured report, never prose. It asks whether an issue exists in the code as it stands, not whether a change introduced one. The tool reads nothing from disk: it judges exactly the text you pass, so you and the tool are always looking at the same code.

WHEN TO USE: to audit files you did not just change, or to find where to start reading unfamiliar code. To review work in progress or a branch, collect the diff and use review_changes, which sends far less text.

WHAT TO PASS: "files" holds the source files to review, each with its full content. Choose them yourself: the files at the center of the flow you care about, not a whole repository, because every file passes through your context and then goes to the TypeSafe API. Leave out generated code, vendored code, and anything that must not leave the machine. "test_files" holds related test files in the same shape. They are not reviewed; they are the evidence used when judging whether behavior lacks a test, so omitting them makes every test-gap screen fire.

COST: one screening request per 160 lines of each file, three files at a time, then up to five profiling requests and about four requests for each of at most eight followed signals.

HOW TO READ THE RESULT:

• "findings" is sorted by descending "severity" (0 to config.severity_max). Each one names a "file", a "line" (the first line of the evidence region, not the exact defect line), a "dimension" (correctness, security, reliability, compatibility, testGap), and a "mechanism". As a reference point, the jev-review workflow this pipeline comes from requests changes at severity 2 or above and comments below that. What to do with a finding is your decision.

• A finding is a lead, not a verdict. Open the file at the cited line and confirm it yourself before you repeat it. Pass the confirmed claim and the code to verify_claim if you want a second check.

• Each finding rests on three judgments: where the evidence is, which mechanism it shows, and how severe it is. "certainty" (high/medium/low) applies the thresholds to the least confident of the three, and "weakest_judgment" names it. A weak "location" often means the line is wrong even when the concern is real. "needs_escalation" lists the findings with low certainty: do not treat those as settled.

• "unresolved_signals" lists every screening signal at or above config.screen_threshold that produced no finding. "no_evidence_located" means it was followed, but no region was selected with enough confidence or the mechanism check found no concrete issue. "not_followed" means it fell past the config.max_follow_ups cap and was never examined. "request_failed" means the follow-up request itself failed. None of them means the file is fine: a screen fired and nothing confirmed or refuted it, so those files still need your own read, strongest probability first.

• "screening" holds, per file, the probability of every dimension that is not a clear no (at or above the lower bound of the noul band). A probability near 0.5 means the screen could not tell, not that the file is half broken. "quiet_files" counts the files where every dimension was a clear no; they are left out to keep the report small.

• "profiles" covers the config.max_profiles files with the strongest signals: a category and a "review_priority" from 0 (routine) to 3 (specialist review), with a "certainty" from the less confident of the two.

• "failed_requests" lists every request that still failed after retries, with its "file" and "stage". A file that failed at the "screen" stage was not judged at all: it is missing from "screening", is not counted in "quiet_files" or "workflow.screened_files", and needs either a second call with just that file or your own read. A "profile" failure only costs that file its profile. When every file fails to screen, the tool returns an error instead of a report.

• "owner" is set only for findings at severity 1.5 or above.

• An empty "findings" array does not mean the code is free of defects. Check "unresolved_signals" first. Jev reads only the text it is sent and does not compile, run tests, or follow calls into other files.