Jev Model's Three Primitives: Judgment, Choice, Scoring

Everything the Jev model does reduces to three question primitives: judgment, choice and scoring. TypeSafe AI built the model around them, and once you internalize the mapping from problem to primitive, most integration decisions make themselves. This guide shows the request shape and response shape for each primitive, how to pick between them, and how they compose in real pipelines. All examples run through OpenRouter’s OpenAI-compatible endpoint.

TL;DR: Judgment questions return yes/no/unclear; choice questions return one of the options you enumerate; scoring questions return a number on a scale you define. Every response carries a confidence score and a rationale. Pick the primitive whose answer space matches your decision, and chain them when a workflow needs more than one decision.

The three primitives side by side

One rule of thumb covers most cases: if the answer is a yes/no, use judgment; if it is a which, use choice; if it is a how much, use scoring.

Primitive 1: judgment

Judgment is a bounded yes/no with an escape hatch — unclear is a legitimate answer when the input does not give enough information.

# Confirm the exact model slug on the OpenRouter model page
curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "typesafe/jev-1.13",
    "messages": [
      {
        "role": "user",
        "content": "Judgment question: is this refund request covered by the 30-day policy? Request: \"...\""
      }
    ]
  }'

A standard chat completions request; the judgment semantics are carried by phrasing the content as a judgment question.

Response — example fixture, confirm exact field names in the official documentation:

{
  "answer": "yes",
  "confidence": 0.97,
  "rationale": "The purchase date is within 30 days and the item is unopened."
}

Use judgment for moderation flags, policy checks, duplicate detection and any gate that either opens or does not.

Primitive 2: choice

Choice requires you to enumerate the options. That constraint is the feature: the answer is guaranteed to be one of them, so your switch statement is safe.

import json, os, requests

prompt = (
    "Choice question: which team should own this email? "
    "Options: sales, billing, support. Email: \"...\""
)
resp = requests.post(
    "https://openrouter.ai/api/v1/chat/completions",
    headers={"Authorization": f"Bearer {os.environ['OPENROUTER_API_KEY']}"},
    json={
        # Confirm the exact model slug on the OpenRouter model page
        "model": "typesafe/jev-1.13",
        "messages": [{"role": "user", "content": prompt}],
    },
    timeout=30,
)
route = json.loads(resp.json()["choices"][0]["message"]["content"])

The request enumerates the options inside the question text; confirm the exact model slug on the OpenRouter model page before shipping.

Response — example fixture, confirm exact field names in the official documentation:

{
  "answer": "billing",
  "confidence": 0.94,
  "rationale": "The email disputes a charge amount rather than asking about a product feature."
}

Use choice for ticket routing, intent classification and any “pick one from this list” decision. The email routing case shows a three-team setup end to end.

Primitive 3: scoring

Scoring returns a number on a scale you define, plus the scale echoed back so it is never ambiguous.

import json, os, requests

prompt = "Scoring question (1-10): how well does this FAQ entry answer the user question? Entry: \"...\""
resp = requests.post(
    "https://openrouter.ai/api/v1/chat/completions",
    headers={"Authorization": f"Bearer {os.environ['OPENROUTER_API_KEY']}"},
    json={
        # Confirm the exact model slug on the OpenRouter model page
        "model": "typesafe/jev-1.13",
        "messages": [{"role": "user", "content": prompt}],
    },
    timeout=30,
)
score = json.loads(resp.json()["choices"][0]["message"]["content"])

The scale lives in the question phrasing; keep it consistent across calls so scores are comparable.

Response — example fixture, confirm exact field names in the official documentation:

{
  "answer": 8,
  "scale": [1, 10],
  "confidence": 0.86,
  "rationale": "The entry answers the core question but skips the edge case mentioned in the question."
}

Use scoring for quality bars, reranking candidates and prioritizing queues.

Composing the primitives

Real workflows chain them. A support pipeline might judge “is this actionable by a bot?”, then choose the owning team, then score the drafted reply before sending. A useful way to think about composition:

1. Judgment as the gate. Cheap yes/no first; unclear or “no” exits early to a human.
2. Choice as the fork. Once past the gate, route to the right owner.
3. Scoring as the quality bar. At the output end, score the result and hold anything under threshold.

Keep each call to one primitive — mixing a choice and a score in one question muddies the answer space and makes confidence harder to interpret. Question wording, option enumeration and few-shot examples are covered in depth in the state-and-questions guide.

This guide applies to Jev 1.13.