Most business software does not need an AI model to write another paragraph. It needs a useful answer to a narrow question: which queue should receive this request, which category fits this item, or does this document contain the evidence we need?
Jev, from TypeSafe AI, is designed for that part of the workflow. TypeSafe calls it a System One model: a model that evaluates supplied information and returns structured decisions rather than generating prose.
For an Australian business considering AI automation, the interesting question is where a decision model can remove a repetitive judgement without handing control of the whole process to an AI agent.
This guide explains Jev's interface, practical use cases, its limits and how to evaluate it. The business scenarios below are illustrative designs based on public documentation. They are not claims of ELASYN customer deployments or independently measured results.
What is Jev, and what does TypeSafe AI do?
TypeSafe introduced Jev in early access on 15 September 2026. Its approach centres on sending a model some state, such as a customer message or a product record, together with explicit questions about that state.
The response contains values that application code can use directly. For example, a support request can be assigned to one of a defined set of teams. The model can also evaluate whether a particular condition appears to be true or rate the input against a written rubric.
The application still owns permissions, validation, database access and the actions that follow. This is a useful fit for software that already has a clear workflow but needs help interpreting language at a particular step.
TypeSafe's introduction to the API explains the state-and-question approach. Its launch announcement describes performance and efficiency advantages on the company's chosen tasks. Those are vendor claims, rather than a substitute for measuring accuracy, cost and latency on your own workload.
Jev's question types: Choice, Score and Noul
The core text interface exposes three useful primitives.
| Question type | What it asks | What the answer contains | Example |
|---|---|---|---|
| Choice | Which defined option fits? | Selected option, probability distribution and confidence | Route a message to bookings, billing, warranty or review |
| Score | Where does the input sit on a described scale? | Score, probability distribution and confidence | Rate how directly a passage answers a question |
| Noul | Is a specific proposition true? | Probability that the answer is yes, from 0 to 1 | Does the message explicitly request a person? |
The underlying questions matter more than their names. A Choice needs options with clear boundaries. A Score needs levels that describe recognisable differences. A Noul needs a single proposition that can be judged from the supplied information.
Sources: TypeSafe's Choice documentation, Score documentation and Noul documentation.
Probability and confidence are different signals
A probability distribution describes how the model distributes its answer across the available outcomes. TypeSafe derives Choice and Score confidence from the shape of that distribution. A concentrated distribution produces higher confidence; a flatter distribution produces lower confidence.
Noul returns a yes probability and does not include the separate confidence field used by Choice and Score. Do not write an integration that assumes every answer has identical fields.
Neither a confident answer nor a well-formed response guarantees that the decision is correct. Test how the model behaves on your data, including cases where it is confidently wrong. Set action thresholds using the cost of mistakes and the results of that evaluation.
Reference: TypeSafe's explanation of confidence.
Where a decision model fits in a business application
A practical design is a sequence of small responsibilities:
- Ordinary code validates the incoming request and obtains only the information needed for the decision.
- Jev evaluates explicit semantic questions against that information.
- Code checks the response and applies the business's routing policy.
- A person handles uncertainty or actions that require approval.
- The application records the decision and its eventual outcome for evaluation.
Suppose a customer asks, "Can you move my fitting appointment and explain this extra charge?" A single exclusive category may conceal the fact that there are two requests. Separate booking and billing questions can expose both. The workflow can then open the appropriate tasks or send the combined request to a person.
This is an engineering design choice: define the decision before choosing the model. Our guide to AI automation for SME operations covers the broader task-selection problem.
Practical use case: route a shared inbox without losing exceptions
A workshop, retailer or professional services business may receive bookings, payment questions, complaints and supplier correspondence in the same inbox.
An illustrative Jev workflow would classify the message into a defined queue and separately check for an explicit request for human contact. The application could create a proposed task for the appropriate team, with ambiguous messages held for review.
For example, "I was charged twice and nobody has called me back" should not become a routine appointment request simply because it mentions a previous visit. Category descriptions should distinguish payment disputes, ordinary booking changes and unresolved complaints.
TypeSafe publishes a customer service intent-routing pattern that chooses between deterministic handlers, language models and people. That is a documented implementation pattern, rather than evidence that any particular business has deployed it.
The operational measure is how often requests reach the correct handler and how much work corrections create. Count missed complaints and inappropriate automatic actions as well as correct classifications.
Practical use case: triage invoices and supplier documents
Consider a small accounts team receiving invoices, credit notes, statements and unrelated attachments.
Jev could help classify the document and identify whether the text describes a credit or a charge. Parsing tools should extract candidate amounts and identifiers. Code should validate suppliers, calculate totals and compare the document with purchasing records.
A useful separation is:
- Language judgement: Which of these extracted amounts is described as the amount due?
- Deterministic checks: Does the arithmetic reconcile, does the supplier exist, and is the invoice identifier already recorded?
- Approval: May this payment proceed under the organisation's existing controls?
TypeSafe's pre-parsed extraction cookbook demonstrates selecting values from candidates found by regular expressions, then copying and normalising the selected value in code. This makes the model's job selection rather than inventing a new amount. It can still select the wrong candidate, and it cannot recover a value that the parser missed.
For a real implementation, retain a link to the source document, expose the selected text to the reviewer and keep payment approval separate from classification.
Practical use case: organise a product catalogue
A retailer or parts supplier may have inconsistent product descriptions from several vendors. A decision model could map a description to an approved catalogue category and flag records whose text lacks enough information.
For a tyre-related catalogue, for example, it could distinguish an accessory listing from a tyre listing. It should not infer vehicle fitment, load ratings or safety suitability from vague promotional text. Those decisions need verified product data and applicable business rules.
Use a defined taxonomy and an explicit review path. If a description could reasonably fit more than one category, separate the questions or improve the category definitions instead of forcing a confident-looking answer.
This scenario applies the fixed-option classification described in the Choice guide. It is an example of how a business could use that capability, not a claim of a deployed catalogue integration.
Practical use case: improve the evidence sent to an AI assistant
A retrieval-augmented generation system, or RAG system, looks up documents before a language model writes an answer. Retrieval can still return passages that mention the right words while answering a different question.
TypeSafe's RAG passage classification cookbook demonstrates checking retrieved passages for relevance, usable evidence, contradictions and attempts to instruct the model. Code then decides which passages reach the answering stage and how conflicts are presented.
In a business knowledge assistant, the practical goal would be to reduce answers based on the wrong policy or an irrelevant procedure. The workflow still needs document permissions, version information and an option to say that the available evidence is insufficient.
Jev does not replace the document store or make an outdated source authoritative. It supplies another judgement within the retrieval pipeline. Evaluate the resulting answers against approved source material, including questions for which no answer should be generated.
Practical use case: check citations before publishing an AI answer
An answer can include a genuine quotation that does not support its claim. A link alone does not establish that a statement is grounded in the source.
TypeSafe's citation-checking cookbook separates two jobs: ordinary string matching checks whether the quote occurs in the document, and a Choice question assesses whether its context supports the claim.
An internal reporting assistant could use this pattern to flag unsupported statements for an editor. The result should be treated as a review aid. A supported quotation can still come from an unreliable, outdated or inapplicable source.
For consequential material, retain editorial approval. A second model's agreement is useful evidence to examine, not a guarantee of factual accuracy.
Practical use case: add screening around an AI workflow
TypeSafe publishes a guardrails cookbook that screens inputs and outputs using narrow hazard questions and a severity rubric. Application policies determine whether to pass, block, review or route the result.
An illustrative customer support assistant could flag a message that appears to request disclosure of private account information or an answer that appears to contain prohibited content. The system could then withhold the proposed answer for review.
Keep access control in code. A classifier should not decide whether a user is authorised to read another customer's record. Likewise, a message classified as harmless should not acquire permission to execute tools or change records.
Test attempts to manipulate the screening step itself. A separate check can add a useful layer, but its presence does not establish that prompt injection or data leakage has been eliminated.
A small integration example
The following request follows the structure documented in TypeSafe's quick start. It uses a fictional workshop enquiry and asks independent questions about the same state.
{
"model": "jev-1.14.0",
"state": "Please move my fitting appointment. I also need a person to explain a charge on my invoice.",
"questions": {
"primary_queue": {
"type": "choice",
"instructions": "Which team should review this message first? Prioritise disputed charges over scheduling changes.",
"criteria": {
"bookings": "Appointment requests or changes without a billing question",
"billing": "Questions or disputes about invoices, charges or payments",
"review": "Another request or insufficient information"
}
},
"requests_person": {
"type": "noul",
"instructions": "Does the customer explicitly ask to speak with a person?"
}
}
}
Send this body to POST https://api.typesafe.ai/v1/systemone from a server-side integration using the provider's documented authentication. Keep the API key outside browser code. There is no measured response attached to this example; it shows how to express the task, rather than claiming an executed test.
The next step belongs in application code. Check that the expected answers are present, check that the selected queue is permitted and route uncertain results to a review queue. Handle timeouts and invalid responses explicitly. Creating an internal task is a smaller initial commitment than sending a customer reply or changing a booking automatically.
Model versions, pricing and performance
As reviewed on 22 October 2026, TypeSafe lists Jev 1.14 as available from 14 October 2026. Its model reference lists jev-1.14.0 and jev-1.13.0, and a price of $0.042 per million input tokens with no charge for output tokens. Consult the provider for current pricing, billing currency and commercial terms before estimating an Australian budget.
Pin an explicit model version for a repeatable evaluation. A moving alias such as jev-latest is convenient for experiments but may change the model used by a workflow.
Measure latency from the region where your application actually runs. Include network time, retries, the size of the supplied state and any review or fallback work. A vendor's benchmark does not establish your application's end-to-end response time or the cost of handling mistakes.
Where Jev needs care
TypeSafe documents known Jev 1.13 limitations, including literal interpretation, counting and arithmetic, date comparisons, multi-step indirection, irrelevant context and sensitivity to option ordering. Those notes apply to that model version; they are useful evaluation cases for a later version, rather than proof that every limitation persists unchanged.
Keep arithmetic and date comparisons in code. Supply focused context and write criteria that cover boundary cases. Check whether changing the order of Choice options changes results that should be stable.
Use a generative model for writing, open-ended synthesis or tasks that require producing new strings. A typed output interface reduces a class of integration problems. It does not establish that the underlying judgement is accurate, unbiased or suitable for every business decision.
How to evaluate a pilot before connecting live actions
Start with a workflow where the decision and the correction are both visible. Inbox routing is often easier to evaluate than an open-ended autonomous assistant because someone can label the correct queue and identify the cost of a mistake.
Build a representative evaluation set with permission to use the records. Include ambiguous messages, missing information, mixed requests, local terminology and examples that should go to a person. Keep evaluation examples separate from the examples used to refine the questions.
Measure the errors that matter: incorrect automatic routes, missed escalations, review volume and corrections. Compare the model with the existing process and with simple rules. Record the model version, question definitions and routing policy so results remain interpretable.
Run in shadow mode first. Generate proposed decisions without changing the live workflow, then compare them with the outcomes staff actually chose. Only introduce automatic actions after the evidence supports a specific, limited use.
Before sending business data to a hosted API, confirm the relevant contract, retention arrangements, processing locations and permitted data uses with the provider. Send the minimum context required. Do not assume a product's name or structured response format establishes its privacy or compliance properties.
Frequently asked questions
Is Jev a chatbot?
Its core interface returns typed decisions about supplied state. Use it for narrow classification, scoring and yes/no questions. Use a generative model when the task is to write an answer.
Does “type-safe” mean Jev cannot be wrong?
No. A response can fit the expected structure and still contain an incorrect judgement. Evaluate accuracy and the consequences of errors separately from output format.
Does every Jev answer include confidence?
No. Choice and Score include confidence and probability distributions. Noul returns the probability of yes without that separate confidence field. Follow the documentation for the primitive you use.
Can Jev calculate invoice totals or decide payments?
Use code for arithmetic, reconciliation and payment rules. Jev can help interpret document language or select a candidate value, with review where needed. Payment authority belongs in the existing approval process.
Do the use cases in this guide describe ELASYN customer results?
No. They are illustrative workflow designs and attributed public examples. This guide does not claim measured customer outcomes, independent benchmarks or a deployment of Jev by ELASYN.
What should an Australian SME test first?
Choose a repetitive, reversible decision with a clear review path, such as proposing a queue for incoming enquiries. Establish a labelled baseline and test in shadow mode before allowing the model to trigger live actions.
Turning a narrow AI decision into useful software
Jev is worth evaluating when the missing step in a workflow is a bounded language judgement. The application around it still determines whether the result becomes a useful operational improvement.
Define the question, keep the business rules explicit and make uncertainty visible to the people who own the process. The result should be a workflow your team can understand and correct.
ELASYN's AI and intelligent systems engineering and automation and workflow engineering work covers evaluating models and connecting decisions to business software. If you have a specific inbox, document or approval bottleneck, talk with ELASYN about a scoped technical review. Bring an example of the decision and what happens when it goes wrong.
Primary references
- TypeSafe AI: Introducing System One Models and Jev
- TypeSafe API introduction
- Choice questions
- Score questions
- Noul questions
- Confidence and probability distributions
- Intent-routing pattern
- Pre-parsed value extraction cookbook
- RAG passage classification cookbook
- Citation-checking cookbook
- LLM guardrails cookbook
- API quick start
- Models, versions and pricing
- Jev 1.13 known limitations
Last reviewed: 22 October 2026. Model availability, pricing and documented behaviour may change. Check current TypeSafe documentation before implementing an integration.