Jev

Jev is TypeSafeAI's System One model: it does not generate text. Instead it answers a set of typed questions about the state you give it, returning one structured answer per question that your code can branch on directly — nothing to parse.

It is served through the TypeSafeAI System One endpoint. The official SDKs (typesafe-sdk, @typesafe-ai/sdk) work as-is — just point the base URL here.

Model#

Three question types#

Every question has type and instructions, plus a criteria whose shape depends on the type. You can mix them in one request; all questions are evaluated in parallel and independently against the same state, so adding questions barely changes latency.

noul: yes / no#

Answers with the probability that the statement holds: 0 is no, 1 is yes.

"is_urgent": {
  "type": "noul",
  "instructions": "Does this convey urgency?",
  "criteria": { "true": "Explicitly time-sensitive", "false": "No urgency expressed" }
}

choice: pick one#

Picks exactly one of the options you define, with a probability for every option.

"department": {
  "type": "choice",
  "instructions": "Which team should handle this?",
  "criteria": {
    "billing": "Payments, invoicing, refunds",
    "technical": "Bugs, outages, integrations",
    "sales": null
  }
}

score: ordered rating#

Rates the state on levels ordered lowest first. The result is probability-weighted and can land between two levels.

"frustration": {
  "type": "score",
  "instructions": "How frustrated is the customer?",
  "criteria": ["Calm", "Frustrated", "Very angry"]
}

Structured instructions and criteria#

instructions, choice option descriptions, score levels, and noul criteria all accept JSON. Put the question in one field and the data it needs in others, and refer to those fields by name in backticks:

"instructions": {
  "potential_duplicate": { "name": "John Smith", "location": "Oakland, California" },
  "question": "Is the resume for the same person as `potential_duplicate`?"
}

Fields in state are referenced the same way: send state as { "message": "…" } and write `message` in the question.

Answers#

answers uses the same keys as questions, and every answer carries the same type as its question:

The response's model is the versioned ID that actually answered (for example jev-1.13.0), and we do not rewrite it — aliases move with new releases, and logging it is how you know which release produced a batch of answers.

Confidence#

Choice and score answers carry a confidence (0–1) derived from how concentrated the distribution is: all mass on one option is 1, evenly spread is 0. Noul answers have no such field — the answer is already a probability.

A useful starting point is three bands: high — act automatically; medium — ask for confirmation or flag for review; low — don't act, route to a human or a reasoning model. Gate destructive actions at a higher threshold than read-only ones. If you have tuned thresholds, pin jev-1.13.0 and recalibrate on your own schedule when moving to a new version.

Known weak spots#

Ask atomic questions and compose them in code. Jev 1.13 is unreliable in these situations:

English works best. Other languages, Chinese included, work too, but test on your own data first and watch confidence more closely.

How the body is forwarded#

Only model, state and questions reach the upstream. Every other top-level field is removed and listed in amux.droppedParams and the x-amux-dropped-params header — the upstream rejects unknown top-level fields with an error that does not name them. Fields inside a question are forwarded as-is.

Errors#

Errors come back in OpenAI's error shape ({ "error": { "type", "message", … } }), which the official SDKs recognize.

For every type value and its retry semantics, see Errors and retries.