Jev is TypeSafe AI's System One model, built to return typed decisions with probabilities from supplied state and questions. Your application defines the possible answers and uses the results in its logic. Jev can supply a routing decision; your code determines whether to act on it.
Copy link to headingWhat does System One mean?
The name borrows Daniel Kahneman's distinction between fast, intuitive System 1 thinking and slower, deliberate System 2 reasoning. For developers, the relevant distinction is the interface: define a question with a bounded answer space, then decide how the application will use the result.
Copy link to headingWhat goes into a bounded decision?
Imagine an incident report that says checkout requests are failing after a configuration change. A responder has attached a log excerpt and noted that browsing still works. The team wants to assign the report to an owner without asking someone to read every incoming alert.
This is an editorial illustration, not an observed Jev result or a built-in incident-management feature. Start by separating the evidence from the question. The report and log excerpt are evidence. The question might ask which team should investigate, using a predefined list of team names. The application then has an answer it can compare with its routing policy.
Jev accepts text, JSON objects, and arrays. For this example, you might prepare a record with the report text and the responder's observations. Include the timestamp of each observation so a later report doesn't appear to describe the same moment. Keep the original wording of uncertain observations. A responder who suspects a configuration problem has supplied a hypothesis, not a confirmed cause.
A vague question such as "Handle this incident" leaves too much unspecified. Does handling mean assigning an owner, paging a responder, or changing production? Choosing an owner is a bounded decision because the intended answer has a defined place in the application. Keep the question narrow enough that two reviewers could agree on what a good answer would look like.
An array used as state remains one shared state. It doesn't turn the call into a batch of unrelated evaluations. In the incident example, a list of timestamped observations belongs together because each observation concerns the same event. Putting separate incidents in that list would blur which evidence the ownership question refers to. Give each unrelated incident its own evaluation context.
Copy link to headingHow should you define the possible answers?
Write category descriptions before collecting predictions. For our incident, suppose payments owns failures after a purchase reaches the payment service, while storefront owns failures that prevent the purchase request from leaving the page. That distinction gives reviewers something observable to check. Labels such as urgent and important would overlap and leave ownership unresolved.
Include an insufficient-evidence option if your workflow needs one. In this illustration, the report lacks any indication of whether the request reached the payment service. Forcing a choice between payments and storefront would conceal that gap. A review category gives the application a way to preserve it.
Keep the question's wording aligned with those categories. "Which team should investigate first?" permits a provisional assignment. "Which team caused the outage?" asks for a conclusion the evidence may not support. Those are different decisions even when both use team names as answers.
Copy link to headingWhat kinds of answers can you request?
AI Gateway uses Choice, Score, and Boolean.
The incident questions map to the following types:
The questions serve different purposes. An owner label identifies a destination. An impact rubric needs a definition of disruption, such as whether a customer can finish checkout. The failed-purchase question concerns a particular statement in the evidence. Avoid making one answer stand in for the others: a report assigned to the payments team doesn't establish that customers lost money.
Jev evaluates independent questions together.
In this illustration, you could ask about ownership and reported impact using the same evidence. Neither question needs the other's answer.
Copy link to headingWhat would an inspectable decision trace look like?
Continue the hypothetical incident with the same report and an added observation: a responder sees purchase requests reaching the payment service, followed by errors. The conceptual record below uses invented values to make a proposed result inspectable. It is separate from the API response format.
This record separates a plausible first assignment from a diagnosis. It also makes a later correction understandable. If the log excerpt turns out to concern an earlier deployment, a reviewer can identify the stale evidence that affected the assignment. Keep the evidence with the answer so an owner label doesn't become an unsupported fact when copied into another system.
Copy link to headingHow does this differ from structured language-model output?
AI SDK evaluation supports native TypeSafe evaluation and adapters for structured-output language models. The adapters put questions together in a prompt; they don't preserve TypeSafe's independent-question semantics.
The matching result shape therefore doesn't establish matching evaluation behavior. In our incident example, a team might keep the owner field unchanged while changing the model it points to.
That makes the application easier to compare, but reviewers still need to check the resulting assignments. An unchanged field name says nothing about whether the same ambiguous report will receive the same answer.
Copy link to headingDoes type safety mean the incident decision is correct?
TypeSafe says Jev's outputs conform to the defined schema. That guarantee concerns answer structure. Semantic correctness still needs evaluation.
Suppose the allowed owners are payments and storefront. An answer of payments satisfies the type constraint, but if a broken storefront script is the real cause, the investigation goes to the wrong team.
The distinction matters before you automate routing. In our example, evaluate owner assignments against incidents that responders have already resolved. Include reports with missing evidence and ambiguous ownership. Decide whether a mistaken assignment is an acceptable delay or whether those cases need someone to review them first. These are editorial recommendations for the example workflow.
Application code owns policy and execution. You might allow a proposed owner to appear in an internal queue while requiring a responder to approve any production change. Put that rule in the application. Selecting an owner should not quietly acquire the authority to roll back a deployment.
Copy link to headingWhat are Jev's boundaries?
Jev does not generate prose. Use a generative model for a written incident update, with the evidence and any approved decisions supplied separately. A routing answer alone gives the writer no basis to announce that an outage has ended.
You can call Jev through Vercel AI Gateway using AI SDK’s experimental evaluation API. The evaluation documentation explains how to send context, define questions, and read the results.
Copy link to headingFrequently asked questions
Copy link to headingWhat does System One mean?
System One is TypeSafe's name for models that make focused, typed decisions. It refers to the fast-thinking side of Kahneman's distinction between intuitive and deliberate thinking.
Copy link to headingDoes Jev write text or code?
No. Jev returns constrained answers, so use a generative model when the result needs to be a written explanation or source code.
Copy link to headingCan Jev analyze images or audio directly?
No. Jev's current inputs are text-based; prepare a text description or transcript before asking it questions about media content.
Copy link to headingDoes a typed answer guarantee a correct decision?
No. An answer can fit the allowed values and still misinterpret the evidence. Test the decisions against known outcomes before letting them trigger actions.