Jev Choice, Score, and Noul: build a confidence-aware fallback workflow

Quick answer

Build a Jev workflow in three layers. First, ask atomic typed questions: Choice for one option from a fixed set, Score for a position on an ordered rubric, and Noul for the probability that a yes/no statement is true. Second, translate uncertainty into code-owned states such as auto_route, ask, review, and deny. Third, keep permissions, irreversible actions, and fallback behavior outside the model.

Choice and Score return probability distributions plus a separate confidence statistic. Noul does not return confidence; its 0–1 value is the probability of yes. Do not apply one threshold to all three primitives. The thresholds below are placeholders; calibrate them on your labeled cases.

Jev remains in early access. On September 26, 2026, TypeSafe listed jev-1.13.0 and mapped jev-latest to it. Pin the version after tuning thresholds because aliases can move.

Who this is for

This guide is for developers who have already decided that a narrow judgment fits Jev and now need a production contract. If you are still deciding between Jev, an LLM, and a hybrid, start with the Jev workload-selection guide.

Support triage exposes the necessary boundaries: a fixed route, ordered impact, binary request, uncertainty, and a possible refund. The pattern also fits moderation, lead routing, incident triage, or document review over text or JSON.

Start with one typed request

The API endpoint is POST https://api.typesafe.ai/v1/systemone. TypeSafe's Python package is typesafe-sdk, whose documented client defaults to jev-latest. One request can mix all three primitives against the same state.

{
  "model": "jev-1.13.0",
  "state": {
    "message": "I was charged twice and cannot use the product.",
    "account_status": "active",
    "duplicate_charge_verified": false
  },
  "questions": {
    "route": {
      "type": "choice",
      "instructions": "Which team should own the next response?",
      "criteria": {
        "billing": "Charges, invoices, or refunds",
        "technical": "Product failures or integration bugs",
        "account": "Login, access, or plan administration",
        "other": "None of the listed teams clearly fits"
      }
    },
    "impact": {
      "type": "score",
      "instructions": "How much is the customer currently blocked?",
      "criteria": [
        "Question or inconvenience; core use still works",
        "Important function is degraded; workaround exists",
        "Core use is blocked; no verified workaround"
      ]
    },
    "refund_requested": {
      "type": "noul",
      "instructions": "Does the customer explicitly request a refund?",
      "criteria": {
        "true": "Directly asks to receive money back",
        "false": "Reports a charge or problem without asking for money back"
      }
    }
  }
}

The route result supplies a selected option, probabilities, and confidence. The impact result supplies a probability-weighted score, its level distribution, legend, and confidence. refund_requested.noul supplies only the yes probability. Those different shapes should remain visible in your application types.

Convert answers into a policy, not an action

Use an explicit gate after schema validation:

def decide(a):
    if missing_required_answer(a):
        return "review"

    route = a["route"]
    impact = a["impact"]
    refund_p = a["refund_requested"].noul

    if route.choice == "other" or route.confidence < 0.75:
        return "ask_or_review"
    if 0.15 < refund_p < 0.85:
        return "ask_or_review"
    if impact.probabilities[2] >= 0.20:
        return "priority_review"
    if refund_p >= 0.85:
        return "refund_review"  # never issue money here
    return f"route:{route.choice}"

The important detail is the state machine: an ambiguous answer needs a named destination. A high-impact answer may recommend a queue but cannot bypass identity, authorization, policy, balance, or confirmation. For irreversible actions, use the approval-and-confidence boundary and require a terminal receipt from the action owner.

For Choice, consider both confidence and the distribution: a second option with meaningful probability may deserve notification or review. For Score, do not rely only on the expected score; inspect probability mass on the critical level. For Noul, define a middle band rather than forcing every value into yes or no.

Record a versioned decision receipt

Store enough evidence to replay a decision without storing secrets:

requested_model: jev-1.13.0
resolved_model: jev-1.13.0
state_schema: support-triage-v3
question_set: triage-2026-09-26
threshold_policy: support-risk-v1
answer_types: [choice, score, noul]
decision: priority_review
external_action: none

TypeSafe currently documents $0.042 per million input tokens, free output tokens, a 64k request budget, and dynamic rate limits. Treat those as current first-party terms, not a permanent guarantee. Log input usage, HTTP status, retry count, and the resolved model so cost and alias drift can be audited.

Test the fallback before live traffic

Run this minimum matrix with de-identified fixtures:

Case	Expected evidence
Clear route	Choice is accepted only above the task's measured threshold
Two plausible routes	Second-option probability triggers review or notification
Missing context	Workflow asks for data instead of guessing
Score boundary	Critical-level probability is checked, not only the mean
Ambiguous Noul	Middle band goes to clarification or review
High-impact request	Model output cannot execute refund, deletion, or publication
401, 422, 429, timeout, or 5xx	Retry is bounded; final behavior fails closed
Alias or policy change	Shadow replay runs before thresholds move

Promotion should require labeled quality, review load, latency, retries, and accepted-result cost together. A lower review rate is not a win if wrong automatic actions increase.

Common mistakes

• Reading Noul as a degree scale or expecting a separate confidence field.
• Using a Choice without other when the set may be incomplete.
• Treating a Score's decimal mean as the whole uncertainty story.
• Copying example thresholds into production without calibration.
• Letting jev-latest move after thresholds were tuned to a pinned version.
• Retrying indefinitely or defaulting to approval when the API is unavailable.
• Allowing confidence alone to authorize money, deletion, deployment, or publication.

Make your Mac notch useful with SuperNotch—22 native tools for music, clipboard, focus, screenshots, system controls, and more.

FAQ

Does every Jev answer have confidence?

No. Choice and Score have confidence plus distributions. Noul returns the probability of yes, which completely represents its two-outcome distribution.

Should I use TypeSafe's example thresholds?

Only as illustrations. Thresholds depend on error cost, data, action reversibility, and the review capacity of your workflow. Measure them on a fixed labeled set and recheck them when the model, question set, state schema, or policy changes.

Can high confidence approve a refund automatically?

It should not be the sole authority. A model can recommend a path; deterministic checks and explicit confirmation should own high-impact actions.

Sources

• TypeSafe AI: Introducing System One Models & Jev
• TypeSafe AI docs: Quick start
• TypeSafe AI docs: Choice
• TypeSafe AI docs: Score
• TypeSafe AI docs: Noul
• TypeSafe AI docs: Confidence
• TypeSafe AI docs: Models and pricing
• TypeSafe AI: OpenAPI schema
• TypeSafe AI: Workflow evals

Originally published on IndieSeek.