18 Practical JEV Use Cases for AI Agents: Routing, RAG, Guardrails, and Evaluation

What can you build with JEV? Start with a decision your software already makes repeatedly: choose a route, judge whether evidence supports a claim, score an issue, or decide whether a result needs review. JEV accepts a shared state and questions with bounded answers. Choice picks from named options, Noul returns a yes/no probability, and Score rates an ordered rubric. Your code still owns permissions, thresholds, side effects, and fallbacks.

Below are 18 use cases organized by the decision being made. Each includes the input to provide and the failure to test. These are implementation patterns, not claims that we deployed them for customers or measured their performance.

Agent and workflow decisions

1. Verify that an agent actually finished

Question: Does the observed result satisfy the task's acceptance criteria? Supply the goal, the latest artifact, and test or tool output as state. Use one Noul question per criterion or a carefully defined overall gate. If the evidence is absent or stale, keep the task open for inspection; the agent's “done” message alone is not proof.

2. Select a tool or function

Question: Which allowed tool fits the next step? Use Choice over a small set of tool purposes, plus an explicit none or review outcome. Let code check the user's permissions and required arguments before executing anything. Test inputs that fit no tool; a bounded model can still confidently pick the wrong allowed option.

3. Route to a model, code path, or person

Question: Does this request need an exact rule, a small model, a stronger model, or human review? Choice can propose a path, and Score can express task difficulty under a defined rubric. Compare total task success and cost against your existing router, including the overhead of the routing call. Sending a hard request down the cheap path can erase any saving.

4. Pick a skill or subagent

Question: Which capability description matches the current task? Give Choice a bounded roster of short skill descriptions; load or invoke only the selected candidate after a permission check. Keep a none outcome. Test look-alike descriptions and requests that need several capabilities rather than one.

5. Add a confidence gate to a workflow

Question: Is the decision strong enough for this specific next step? Use the probability from the relevant Choice or Noul answer, then apply thresholds in code. Route middle cases to confirmation and failed calls to a safe fallback. Thresholds must come from labeled examples and the cost of mistakes; a number copied from a tutorial is not a policy.

Retrieval and evidence decisions

6. Filter RAG passages before generation

Question: Does this passage answer the user's question, or is it merely keyword-adjacent? Use Noul on a query and one candidate passage after ordinary retrieval. Measure both useful passages missed and irrelevant passages kept. Do not treat this as permission to bypass source access controls or as a replacement for retrieval.

7. Rerank a short candidate set

Question: Which retrieved items are most relevant under a stated criterion? Score or judge candidates after a keyword or vector search has narrowed the set. Compare ranking quality with the existing retriever on labeled query–document pairs. Avoid sending a huge corpus as one Choice list simply because the interface allows many options.

8. Check a citation against a claim

Question: Does the cited passage support, contradict, or fail to address a specific claim? Choice can return those three labels. Code should separately verify that the quotation and URL actually refer to the supplied source. Test cases where a passage mentions the same topic but does not establish the claimed fact.

9. Align two entity records

Question: Do these records describe the same product, company, or person? First use exact identifiers and deterministic blocking to find plausible pairs, then use Noul or Score for ambiguous candidates. Keep borderline matches for review and measure false merges; one wrong merge can contaminate many downstream records.

Safety and quality decisions

10. Screen an LLM input or output

Question: Does the text match a defined risk category? Ask separate Noul questions for separate hazards, then map results to pass, review, or block in code. Evaluate false negatives and adversarial phrasing on your actual policy set. A model signal supplements hard rules and accountable review; it does not replace them.

11. Apply a fixed evaluation rubric

Question: Does a generated answer satisfy a narrow criterion, and how well? Use Choice or Score when the downstream system needs a typed verdict. Keep an LLM or human evaluator when a written critique is required. Compare disagreements with human labels and inspect whether a score such as 0.8 predicts acceptance in your workflow.

12. Flag semantic issues in code changes

Question: Does this diff appear to violate a natural-language project rule that a linter cannot express? Use Noul as a review signal, with the diff and rule as state. Never replace compilation, tests, static analysis, or security review. Track noisy warnings so reviewers do not learn to ignore the signal.

13. Check a document against a checklist

Question: Which of several explicit criteria are met, uncertain, or missing? Ask atomic Noul questions against a shared document state, and send uncertain items to a reviewer. Retain the source excerpt, question version, and model version for audit. Do not turn a probabilistic checklist into an automatic legal or compliance approval.

Data and operations decisions

14. Triage a support inbox

Question: Which queue owns the request, how urgent is it, and does it need escalation? Use Choice, Score, and Noul for separate questions over the same ticket state. Keep customer identifiers out unless needed and authorized. Check missed urgent tickets separately from harmless extra escalations.

15. Classify within a large taxonomy

Question: Which branch of the taxonomy fits this item? Ask a Choice question at each level instead of listing thousands of labels at once. Preserve candidate branches when probabilities are close. Test new or out-of-taxonomy items so the workflow can say “none of these.”

16. Select among extracted candidates

Question: Which candidate span answers a field question? Let a parser or regex first extract literal spans, then use Choice to pick among them. Copy the chosen span unchanged. JEV is not an open-ended extractor; do not let a selection label invent a value that was never in the source.

17. Combine several scored dimensions

Question: How do urgency, risk, value, and fit each rate under separate rubrics? Use multiple Score questions and combine them with explicit weights in code. Review whether the dimensions overlap and whether the weights produce sensible decisions for edge cases. This is easier to debug than hiding everything inside one vague “overall quality” score.

18. Add semantic features to a conventional model

Question: Do JEV probabilities add information beyond existing structured columns? Keep Noul or Score outputs as numeric features for a downstream classifier or regressor. Evaluate on held-out data, checking leakage, drift, calibration, and the cost of calling another model. If the baseline is already strong, the extra layer may not help.

Turn one idea into a testable first pilot

Do not attempt all 18 at once. Choose a repeated decision with four properties: its legal outcomes can be written down; you can label real examples; a wrong answer has a safe fallback; and the outcome can be observed later. Exact arithmetic and allowlist checks belong in code. Tasks that require new prose, plans, or code belong with a generative model.

For example, pilot agent completion verification. Suppose an agent says a pricing page is live. The state contains the goal, URL, deployment result, and actual page check. A Noul question asks whether the observed evidence satisfies the acceptance criterion. An illustrative request fragment is:

{
  "state": {
    "goal": "The pricing page is publicly reachable and displays the current plans.",
    "evidence": "Deployment succeeded. A subsequent page check returned 404."
  },
  "questions": {
    "complete": {
      "type": "noul",
      "instructions": "Does the observed evidence establish that the goal is complete? A deployment message alone is insufficient.",
      "criteria": {
        "true": "The live page is reachable and the requested plans were verified.",
        "false": "The page failed verification, evidence is missing, or the plans were not checked."
      }
    }
  }
}

The 404 is an intentionally simple example: deterministic code should already reject it. JEV is useful only where the remaining evidence needs semantic judgment. This illustrates a broader rule: run exact checks first, then ask the model a bounded question about the ambiguous remainder.

Run the pilot in shadow mode. Label complete, incomplete, ambiguous, stale-evidence, and adversarial cases. Measure costly false completions, unnecessary reviews, API failures, and the share of decisions that the exact checks handled without JEV. Set a threshold on development examples, then confirm it on held-out examples. A typed answer may be well formed and still factually wrong.

For Free JEV API access and more implementation patterns, start at jevapi.io. The site guides you to the free API; keep keys and API calls in your server-side application.

The 18 patterns are proposed uses, not measured deployments. The request fragment is illustrative; verify the current API contract and free access terms before a live integration.