Evidence review
Research verification with Jev: check claims against evidence
An independent guide by Jev AI · Reviewed · 阅读中文版
Research verification asks whether the evidence you have actually supports a particular claim. Jev can classify that relationship when you supply the claim, evidence and decision criteria. It does not browse the web, retrieve missing sources or authenticate a document in this request.
The research preset uses a synthetic refund-policy claim: an order arrived three days late, while the supplied policy requires five days for an expedited refund. This simple example illustrates why evidence should be checked before a claim becomes an answer or action.
What you will learn
- Supply the evidence; a URL alone is not retrieved by this call.
- Distinguish missing evidence from evidence against the claim.
- Use code for dates and arithmetic, and people or source checks for provenance.
On this page
- Build an evidence packet that can be reviewed
- Give each verdict an operational meaning
- Calculate exact facts before semantic review
- Test missing evidence and disagreement deliberately
- Request and code examples
- Interpret the result
- Troubleshoot a failed request
- Checks before integration
- Common questions
- Sources and next steps
Build an evidence packet that can be reviewed
The preset requires a nonempty claim string and an evidence array of strings. Include relevant excerpts with source identifiers, scope and the date you retrieved or verified them when those matter. source_quality and stakes provide context, but writing trusted source does not prove authenticity.
Keep each claim narrow. A sentence combining eligibility, legal compliance and payment timing is several claims with different evidence needs. Evaluate them separately, and retain the connection between each excerpt and its source so a reviewer can inspect the basis of the conclusion.
- State one proposition rather than a vague research goal.
- Supply supporting and conflicting evidence, not just favorable excerpts.
- Record what was not checked, including missing sources or unknown dates.
Give each verdict an operational meaning
sufficient means the supplied evidence adequately supports the claim at the stated stakes. insufficient means key support is missing or too weak. contradictory means the evidence conflicts with the claim or internally. stale means time-sensitive evidence is no longer current enough.
Some cases fit more than one concern. Define a priority when your application requires a single label, or use separate native questions for support, contradiction and recency. Do not interpret sufficient as a certification that the source is authentic or the statement is universally true.
| Verdict | Useful next step |
|---|---|
| sufficient | Review provenance and present the claim with its supporting evidence |
| insufficient | Identify the missing fact and retrieve more evidence |
| contradictory | Resolve the conflict or revise the claim |
| stale | Refresh the time-sensitive source |
Calculate exact facts before semantic review
In the worked example, three days is less than a five-day threshold. Your code should perform that comparison. Jev can help judge whether prose describes a qualifying exception or whether evidence addresses the claim, but it should not be your date calculator.
For recency, compute source age from validated timestamps using a documented cutoff. Feed that verified result into the state. Two identical excerpts with different timestamps can have different relevance; an undated source should not silently inherit today's date.
Test missing evidence and disagreement deliberately
Build cases with complete support, an absent policy section, conflicting excerpts, outdated policy and irrelevant text. Have a reviewer label what the supplied packet supports, without assuming facts from outside the packet. This keeps the evaluation aligned with the input the model actually sees.
Review false sufficient results carefully: they can cause unsupported claims to be published. An insufficient result should tell your workflow to collect a particular missing fact rather than repeat the same request indefinitely. Track the rate of abstention and human disagreement as well as overall label accuracy.
Illustrative example, not a live API result
// After validating the response, map verdicts to workflow states.
const nextStep = {
sufficient: "review_source_provenance",
insufficient: "collect_missing_evidence",
contradictory: "resolve_conflict",
stale: "refresh_sources",
}[result.answers.verdict.choice] ?? "human_review";
// This mapping does not perform a web search or publish a claim.Request and code examples
Create an API key in OmniaKey and set OMNIAKEY_API_KEY in your terminal or server environment. The curl example requires curl 7.76 or newer for --fail-with-body; the JavaScript example requires Node.js 20 or newer. Use synthetic inputs. Requests use your account balance; check OmniaKey for current pricing and availability.
Save the JavaScript as jev-example.mjs, then run node jev-example.mjs. Keep the key out of frontend code and Git. Example inputs stay in English to match the playground presets; evaluate other input languages separately.
curl
curl --fail-with-body --max-time 25 'https://api.omniakey.com/v1/alpha/search' \
-H "Authorization: Bearer ${OMNIAKEY_API_KEY}" \
-H 'Content-Type: application/json' \
--data '{
"model": "jev-latest",
"state": {
"claim": "This order qualifies for an expedited refund under the policy",
"evidence": [
"Order arrived three days late",
"Policy requires five days"
],
"source_quality": "mixed",
"stakes": "medium"
},
"questions": {
"verdict": {
"type": "choice",
"instructions": "Judge whether the supplied evidence supports the claim, considering coverage, contradictions, source quality, timeliness, and stakes. Do not invent missing sources or facts.",
"criteria": {
"sufficient": "The evidence adequately supports the claim at the stated stakes.",
"insufficient": "Evidence is missing, incomplete, or too weak to support the claim.",
"contradictory": "The evidence materially contradicts the claim or conflicts internally.",
"stale": "The evidence is too old for a time-sensitive claim."
}
}
}
}'Show the complete Node.js example
Node.js 20+
// Node.js 20+. Save as jev-example.mjs and run: node jev-example.mjs
// Set OMNIAKEY_API_KEY in the server/terminal environment first.
const key = process.env.OMNIAKEY_API_KEY;
if (!key) throw new Error("Set OMNIAKEY_API_KEY before running.");
const body = {
"model": "jev-latest",
"state": {
"claim": "This order qualifies for an expedited refund under the policy",
"evidence": [
"Order arrived three days late",
"Policy requires five days"
],
"source_quality": "mixed",
"stakes": "medium"
},
"questions": {
"verdict": {
"type": "choice",
"instructions": "Judge whether the supplied evidence supports the claim, considering coverage, contradictions, source quality, timeliness, and stakes. Do not invent missing sources or facts.",
"criteria": {
"sufficient": "The evidence adequately supports the claim at the stated stakes.",
"insufficient": "Evidence is missing, incomplete, or too weak to support the claim.",
"contradictory": "The evidence materially contradicts the claim or conflicts internally.",
"stale": "The evidence is too old for a time-sensitive claim."
}
}
}
};
const response = await fetch("https://api.omniakey.com/v1/alpha/search", {
method: "POST",
headers: {
Authorization: `Bearer ${key}`,
"Content-Type": "application/json",
},
body: JSON.stringify(body),
signal: AbortSignal.timeout(25_000),
});
if (!response.ok) {
const retryAfter = response.headers.get("retry-after");
throw new Error(`Jev HTTP ${response.status}; Retry-After: ${retryAfter ?? "not supplied"}`);
}
const result = await response.json();
console.log(JSON.stringify(result, null, 2));
// Inspect and validate the answer before connecting it to any external action.
The JSON below is the native API body. This guide's playground link selects the matching workflow preset; preset input and native request are different shapes. To use Custom Jev instead, paste this native JSON.
Copy native JSON for the playground
Native JSON
{
"model": "jev-latest",
"state": {
"claim": "This order qualifies for an expedited refund under the policy",
"evidence": [
"Order arrived three days late",
"Policy requires five days"
],
"source_quality": "mixed",
"stakes": "medium"
},
"questions": {
"verdict": {
"type": "choice",
"instructions": "Judge whether the supplied evidence supports the claim, considering coverage, contradictions, source quality, timeliness, and stakes. Do not invent missing sources or facts.",
"criteria": {
"sufficient": "The evidence adequately supports the claim at the stated stakes.",
"insufficient": "Evidence is missing, incomplete, or too weak to support the claim.",
"contradictory": "The evidence materially contradicts the claim or conflicts internally.",
"stale": "The evidence is too old for a time-sensitive claim."
}
}
}
}Interpret the result
Read answers.verdict.choice and probabilities. For the three-day/five-day example, the packet does not establish expedited-refund eligibility. Whether your rubric treats this as contradictory or insufficient should be made explicit and tested; the guide does not claim a captured Jev result.
The native response does not include newly found citations or a generated explanation. Keep your original source records and display the excerpts that informed the decision. A plausible probability distribution cannot repair a fabricated or misattributed source.
Troubleshoot a failed request
- Invalid request (for example, 400)
- Check model, state, questions and each question's type, options or range. Do not send a chat messages payload to this endpoint.
- Authentication or account rejection (such as 401, 402 or 403)
- Check the key, balance, model access and current provider policy. A status alone does not uniquely identify the cause. Inspect your OmniaKey account without pasting credentials into support text.
- Rate limit (429)
- Read Retry-After if supplied, reduce concurrency and use bounded backoff. These examples do not retry automatically; duplicate requests may add cost.
- 5xx, network failure or timeout
- Check service status and connectivity before deciding to retry. The 25-second timeout ends the client's wait; it does not guarantee upstream cancellation or avoid billing.
- HTTP success with an unusable answer
- Validate the response shape, question names and answer types. Missing answers or unknown options need a fallback or review, rather than coercion followed by execution.
Checks before integration
- A claim fully supported by an applicable, current policy excerpt.
- A claim whose decisive exception is absent from the evidence packet.
- Two excerpts that contradict each other.
- An otherwise relevant policy that has been superseded.
- Untrusted evidence that instructs the model to mark every claim sufficient.
Common questions
Can I paste a URL and have Jev fact-check it?
This request does not fetch the URL. Retrieve and verify the relevant content in your own workflow, then supply appropriate excerpts. Keep provenance checks outside the model.
Does sufficient mean the claim is true?
It is a judgment about the supplied evidence and criteria. It does not verify facts outside the packet, source authenticity or legal applicability. Higher-stakes uses need stronger independent review.
Sources and next steps
Protocol details were checked against OmniaKey's Jev guide and authentication documentation. Request examples pass local schema checks; this article does not claim a live performance evaluation of each workflow. This site is independent of the model developer and OmniaKey.
Try it with your own task
Start with a synthetic input and inspect the native request and model answer. Open OmniaKey key management with your account, or follow its sign-up flow if you are new.