Ari’s Space*   est. 2026
Skip to content
ari*s space[ a. ]
← Librarytools and plugins / 2026-09-19

Jev: the decision model that doesn’t chat

Not a chatbot. State in, typed decisions out: what Jev is and how to wire it into software.

12 parts / Hover to explore. Click to read.

Not a chatbot. State in, typed decisions out: what Jev is and how to wire it into software.

       [CURATED STATE]
               |
     +---------+---------+
     |         |         |
  Choice     Score      Noul
     |         |         |
     +---------+---------+
               v
       application rules
act / gather evidence / escalate
Independent questions share state; application code combines their answers and controls side effects. Confidence is a signal to test, not authority to act or proof that an answer is correct.

Jev takes a state and some questions. It returns values your code can use.

That is the useful starting point. You are not asking it to write a paragraph and then hoping you can extract a decision from the prose. You specify the kind of answer, receive the assessment and decide what your application is allowed to do with it.

This essay began as a 19 September 2026 introduction. The core examples remain; the version and integration notes below were checked on 17 October 2026. Provider details change. Keep the date beside them.

Give the model a bounded judgement

TypeSafe calls Jev a System One model. Its launch explanation borrows Kahneman's fast-judgement idea and takes the name Jev from William Stanley Jevons. TypeSafe describes parallel sampling and Reinforcement Learning for Calibrated Decisions, or RLCD, as the basis for its decision outputs.

That is the vendor's account of the model. The practical question is simpler: where does a small judgement help your software?

Classify a support ticket. Assess severity. Decide whether a retrieved passage supports a claim. Screen a proposed tool call. The messy text goes to the model; the rules and side effects stay in your code.

In the September account, I was already using Jev-shaped decisions inside Imaginary Tools and CXN. That is the product context for my interest, not a new performance measurement.

Three question types to learn first

Choice selects from named options. It returns the choice, probabilities across the options and a confidence value. Use it for a category, an intent or a support/contradict/unrelated verdict.

Score returns a probability-weighted position along an ordered rubric, which can fall between levels. Its answer includes the score, legend, probabilities and confidence. Severity and frustration are examples: you define what each level means rather than asking for an unexplained number.

Noul asks whether a statement is true and returns a probability from 0 to 1. It has no separate confidence field. Refund intent, sufficient evidence and whether a skill is needed can each be their own Noul.

 Choice Score Noul
 +-----------------+ +-----------------+ +-----------------+
 | which option? | | which level? | | is this true? |
 | choice + probs | | score + legend | | noul 0-1 |
 | + confidence | | + probs + conf | | (no separate |
 | | | | | confidence) |
 +-----------------+ +-----------------+ +-----------------+
 \ | /
 \ | /
 +-------- same state, parallel ------+
Choice, Score and Noul shown as three System 7 cards
Choose an option, return a position on an ordered rubric or assess a yes/no statement.
Choice, Score and Noul boxes connected to one shared state
Shared state, independent questions. Your code combines the answers.

The September introduction covered text and these three primitives. Since the 14 October release, the image documentation describes experimental images for both 1.13 and 1.14, plus a Box question requiring 1.14. That path is off by default, needs the explicit image header and is not recommended by TypeSafe for production. It does not turn this into an audio/video model tutorial.

Put the rules in the application

The request has two jobs: give the model relevant facts, then ask precise questions about them.

POST /v1/systemone
+--------------------------------------+
| STATE |
| ticket · order · policy · passage |
+------------------+-------------------+
 |
 +-------------+-------------+
 v v v
 Choice Score Noul ...more
 | | |
 +-------------+-------------+
 |
 v
 typed answers + probabilities
 |
 v
 your thresholds -> act | caution | escalate
State, Questions and Answers windows across a System 7 notebook
State and questions in. Typed answers out.

State can be text, a JSON object or an array of text values. Curate it. An enormous object full of irrelevant fields gives the model more opportunities to answer the wrong question.

Point to a nested field with a backticked path, such as `ticket.messages[0].text`. Put the actual question in instructions. Question IDs are for your code and are not sent to the model. Put their meaning in the instructions.

Break a broad assessment into small questions. Ask independent ones together, then combine them with the weights and thresholds you have chosen. Only add another request when an answer really is an input to the next question. The patterns guide covers fan-out, confidence routing, composite scoring and intent routing.

Example: triage one support ticket

Imagine an app freezing during Export. The customer gives version details, sounds firm rather than furious and explicitly says they are not asking for a refund.

You can ask five things in one request:

  • Choice: which category does the ticket belong to?
  • Score: how severe is the reported bug?
  • Noul: are there enough steps to reproduce it?
  • Noul: is this a refund request?
  • Score: how frustrated does the customer sound?

For an illustrative result, suppose category selects bug, severity is high enough to matter, reproduction looks usable, refund intent is low and frustration is concerned. Your code can route to the bug branch and escalate using severity plus reproduction. It does not need to do anything with the refund result.

That is speculative fan-out: ask the independent questions while the state is already there. It is not a live result from this page.

TypeSafe's parallel-questions cookbook reports a specific experiment: thirteen questions over a GDPR page, using jev-1.12, cost 12.2 times less and ran 10.0 times faster together than as singles. The answers were mostly unchanged, not identical: one reported mean was 0.804 in the batch and 0.814 alone. Those are vendor measurements for that experiment, not promised savings for your app.

Confidence is a signal you still have to test

For Choice and Score, confidence summarises the answer's probability distribution. It is not simply the probability that the chosen answer is correct. Noul exposes its probability directly instead. The confidence reference explains the distinction and formulas.

Use those signals to build routes such as act, gather more information or escalate. Choose the thresholds against representative examples and the consequences of a mistake. A high value does not grant authority for an irreversible action, and a low value is a good reason to stop guessing.

Calibration concerns performance across groups of predictions. It does not promise that this particular call is right. Keep the application responsible for the decision, as in TypeSafe's confidence-routing pattern.

Example: check retrieved passages before generation

Search retrieves candidates. It does not certify them.

The RAG-passage recipe asks four Nouls about each passage: relevant, usable as evidence, contradictory to the query's premise, and attempting prompt injection.

Your thresholds then choose evidence, conflict or drop. In the example, an instruction-planted forum scrap should be dropped before generation. A relevant EU help-centre line can remain evidence; a US-only line may be excluded or carry an explicit scope caveat.

Those are intended routing outcomes. A model can miss the injection or misread the scope. The classifier is a filter, not a security boundary.

Example: verify the quote before judging it

If an agent supplies a quote, do the cheap deterministic check first. Does that exact text occur in the claimed source? If it does not, reject the quote without paying a model to interpret it.

For a surviving quote, ask a Choice whether its context supports the claim, contradicts it or is unrelated. Then apply your review rule. This separates a missing quotation from a misleading use of a real one. The citation-check recipe shows the two stages.

The same separation helps with other checks. The guardrails cookbook combines hazard Nouls and a severity Score around an LLM call. Your application chooses pass, review, block or support; a self-harm concern may need a supportive route instead of a blunt refusal.

For dates, let the model identify the named parts and let code resolve the calendar. That is the division in the date-extraction cookbook. Arithmetic and exactly-once side effects belong in deterministic code too.

Versions and cost: keep the date attached

Jev launched in early access on 15 September. The original research on 19 September saw a waitlist, jev-1.13.0 and two aliases pointing to it. That is historical context, not today's access instruction.

On 17 October, direct TypeSafe lists jev-1.13.0 and jev-1.14.0. jev-latest still points to 1.13; jev-preview points to 1.14. Both cost $0.042 per million input tokens, equivalent to $42 per billion, with no output-token charge. Pin a tested version when changing answers would affect your thresholds. Models, 1.14 release.

The launch material reported roughly 100 ms for many queries and a broader 70–500 ms end-to-end range, alongside large cost/speed multipliers. Those are vendor-reported measurements and positioning, not timings measured here or a guarantee for your workload. The original account also noted that published prices did not establish whether the service was subsidised.

A typed answer makes integration easier. It does not make an incorrect option correct. The September guide described a 255-option Choice limit before using a two-stage approach; consult the Choice reference before designing around a limit.

Integration names you can check

The common shape is still state plus questions. Do not assume every provider's alias, context limit or SDK surface is interchangeable.

SurfaceChecked reference, 17 October 2026
TypeSafePython typesafe-sdk, JavaScript @typesafe-ai/sdk, TYPESAFE_API_KEY, and the typesafe-ai/skills agent skill. Python, JavaScript, skill
Vercel AI Gatewaytypesafe-ai/jev; current AI SDK uses experimental_decide. The integration guide specifies ai 7.0.128+. September's evaluate name is not the current instruction. SDK reference, integration
Cloudflare Workers AIenv.AI.run with typesafe/jev; its catalogue lists a 32,000-token window. Model reference
OpenRouter~typesafe/jev-latest currently tracks 1.14. Its access route needs no waitlist or separate TypeSafe account. It offers decision endpoints; this is not evidence that direct TypeSafe has declared general availability. Guide
LangChainlangchain-typesafe, TypeSafeClassifier and experimental routing/tool-risk middleware. A middleware refusal is not a human-approval flow by itself. Provider reference
Pydantic AITypeSafeModel / typesafe:jev-latest; structured output fields become questions over the supplied state. Model reference

A surface may call a yes/no question boolean rather than Noul. Check that surface's response shape before sharing parsing code.

Give the model work it can answer

The direct service's default limits are 64k tokens for the whole request and 32k for state plus any one question. An opt-in long-context path raises both to 262k, with stated speed and accuracy trade-offs. Current rate limits are organisation-specific in the console; the September figures of 250,000 tokens per second and 1,200 requests per minute are not a current entitlement. Over-limit requests can return 429. Current limits.

Keep generation, multi-step reasoning, counting and date arithmetic elsewhere. Reduce irrelevant state and contradictory criteria. Test non-English workloads rather than assuming the English results transfer. A Noul and a Choice about a similar fact need not behave identically.

Adversarial state can still influence the answer. Constraining the schema limits the shape of the result; it does not provide injection immunity or truth.

TypeSafe's privacy policy says customer Input is not used for training or fine-tuning. Its legal documentation describes enterprise zero-data-retention arrangements, with enquiries currently directed to sales@typesafe.ai. These are the provider's published commitments, not an independent privacy audit.

Start with a decision you can inspect

Use plain code when the rule is already known. Use a generative model when you need writing or open-ended reasoning. Consider a decision model where messy input needs a bounded assessment your code can check and route.

In the docs and Playground, try one Choice and one Noul on a ticket or passage you understand. Write down the expected outcome first. Inspect the answers, the uncertainty and the failures. Then decide where a threshold helps and where a person still needs to look.

The important part is where the authority stays. The model supplies a judgement. Your application owns the action.

[ comments ]

guests welcome. members show first in the list

no comments yet. start the thread_

1 / 14