Jev Model Guide: Inputs, Outputs and Best Use Cases

The Jev model is TypeSafe AI's structured evaluation model for decisions inside software. A request contains shared state and one or more typed questions. The response contains bounded answers, distributions or probabilities and confidence values that code can inspect without asking the model to write prose.

Jev model request structure

Every Jev decision starts with two layers:

• State is the information being evaluated. It can be compact text, structured data or an array of relevant records.
• Questions define the judgments to make about that state. Each named question has a type, instructions and criteria.

Separating state from questions matters because several independent judgments can evaluate the same evidence in one model call. For example, a deployment review can ask for an action verdict, a risk score and the probability that human confirmation is necessary.

The three Jev model question types

Choice

Choice selects one answer from named criteria supplied by the caller. It fits routing, classification and action selection when the possible outcomes are known.

Examples include selecting a support queue, choosing an allowed AI model or mapping a tool call to allow, confirm, review or deny.

Noul

Noul represents a yes-or-unknown judgment and returns probability rather than open text. It fits questions such as “Does this need human review?” or “Is the evidence sufficient?”

Use the probability with an application-owned threshold. Do not treat a single threshold as universal; calibrate it on your data and choose stricter escalation rules for higher-impact actions.

Score

Score places the state on a caller-defined ordered rubric. It fits risk, urgency, quality or completeness ratings where a scale communicates more than a binary answer.

The rubric should describe each level clearly. Avoid labels such as “low” and “high” without defining what observations belong at each level.

Example Jev model request

AutoJev's generic Decisions API accepts the same state-plus-questions shape:

{
  "state": {
    "action": "Issue a USD 680 refund for a disputed duplicate charge",
    "customer_verified": true,
    "approval_limit_usd": 500
  },
  "questions": {
    "verdict": {
      "type": "choice",
      "instructions": "Choose the safest permitted next step.",
      "criteria": {
        "allow": "Proceed without another approval step.",
        "confirm": "Require explicit human confirmation.",
        "deny": "Do not perform this action."
      }
    },
    "needs_review": {
      "type": "noul",
      "instructions": "Estimate whether a human should review the action.",
      "criteria": {
        "true": "Human review is warranted.",
        "false": "Existing safeguards are sufficient."
      }
    },
    "risk": {
      "type": "score",
      "instructions": "Score the financial and policy risk.",
      "criteria": [
        "Low: isolated and easily reversible.",
        "Moderate: bounded impact with tested rollback.",
        "High: production impact or incomplete verification.",
        "Critical: unsafe until a blocker is resolved."
      ]
    }
  }
}

This structure keeps the action policy outside the Jev model. The application decides what a verdict or probability permits.

Reading Jev model output

An AutoJev response can include:

• The selected decision or score.
• Confidence associated with that answer.
• Probabilities for the available choices.
• The complete answer object for every question.
• Provider, model version, request ID and token usage.
• Deterministic preset guidance when a preset endpoint is used.

Probabilities are usually more useful than a label alone. An application can proceed above one threshold, request human review in an uncertain range and stop below another threshold. The thresholds belong to the application, not to the model.

Jev model versus JSON mode

JSON mode constrains how a generative LLM formats a response. Jev is designed around the decision task itself: bounded outputs and probabilities are the primary interface, not a text answer that happens to be serialized as JSON.

Both approaches still require good questions, representative evaluations and surrounding policy. Type-safe output prevents malformed response shapes; it does not eliminate semantic mistakes.

Best use cases for the Jev model

The Jev model is a strong fit when:

• The possible outputs can be defined before the request.
• A decision will be consumed by code rather than read as an essay.
• The workflow benefits from explicit uncertainty.
• Similar decisions occur repeatedly or at important agent boundaries.
• Deterministic code can enforce the final action policy.

Use a generative model instead when the task requires new text, code, a plan, long-form reasoning or tool arguments that cannot be enumerated in advance.

Jev model limitations

• Jev can select the wrong valid answer.
• Poor criteria create poor decision boundaries.
• Missing or misleading state can produce misleading probabilities.
• Public benchmarks cannot replace evaluation on your own workflow.
• A model verdict does not grant permission to execute an action.
• Secrets and unrelated private data should never be included in state.

Use the Jev model through AutoJev

AutoJev provides several ways to call the Jev model:

• Jev MCP for discoverable tools inside MCP-compatible agents.
• Jev Skills for repeatable trigger instructions and verdict handling.
• REST presets for model routing, task routing, tool guards, research checks and completion review.
• A generic Decisions API for custom Choice, Noul and Score questions.
• An online playground for interactive debugging.

For a less technical introduction, read What is Jev? or Jev AI for agents. For connection examples, continue to the AutoJev integration guide.