Most AI systems are asked to produce an answer: a summary, a reply, a plan, a block of code. A great deal of business software needs something much smaller. It needs a decision that another piece of software can inspect and act on.
A support platform needs to choose a queue. A fraud workflow needs to decide whether a case goes to review. A coding agent needs a signal that the command it is about to run is risky. A municipal service desk needs to know whether a report is about a pothole or a burst pipe, and whether it can wait until Monday. None of these needs a paragraph. Each needs one bounded judgement, in a shape the code can read without guessing.
Jev is a model built for that middle layer. It accepts state, evaluates one or more typed questions about it, and returns structured answers with probabilities. It does not take the action. The application around it stays responsible for permissions, business rules, audit records, fallbacks and human approval.
In plain language:
Jev is a specialist judge. You give it the facts, define the allowed form of the answer, and let your own software decide what to do with the result.
This ten-part series explains the pattern from first principles, tests where it stops being useful, and shows how it can work with coding agents, with the BMAD Method and in South African delivery.
Who makes Jev, and who we are
There are two names to keep apart. TypeSafe builds the underlying Jev model and offers it through its own API. Jev AI is a separate service that offers the same model, alongside other decision models, through a common interface. Jev AI's own pages say it "is an independently operated product and is not affiliated with, operated by, or endorsed by TypeSafe." Which one you use determines the contract, the endpoint, the support you get and the terms you sign, and Part 8 shows why that matters before production.
This is an independent CloudNala analysis. CloudNala has no commercial relationship with Jev AI or TypeSafe, and nothing here is an endorsement. Product details were checked against the public documentation on 13 October 2026. They change, so recheck them before you build or buy anything.
The council that brought us here
Kloofvale Local Municipality is fictional, and its systems and figures are illustrative. Kloofvale is a mid-sized municipality in the Eastern Cape. Residents report service problems through Kloofvale Fix-It, a WhatsApp and web channel the municipality's eight-person digital services team built and runs. Fix-It receives about 1,400 reports a week, in English, isiXhosa and Afrikaans, often switching between them mid-sentence, and often without a usable location.
Today two call-centre staff read every report and route it by hand to roads, water, electricity or "other", which covers refuse, parks and everything else. On a quiet week they keep up. After a storm they do not. In one illustrative weekend in March, a report of a burst water main sat for 31 hours behind dozens of reports about uncollected refuse, because the queue was first in, first out and nobody had read that far down.
The team's question was not "how do we add AI to Fix-It?" It was narrower and more useful: could software read each report, suggest where it belongs and how urgent it is, and hand anything uncertain to a person? That is a decision problem, not a writing problem. Kloofvale's emergencies already go to a separate 24-hour control room, and the team was clear from the start that Fix-It must never present itself as an emergency line.
The missing layer between language and software
A conventional large language model is very good at producing text. Ask it to explain an incident or draft a reply and it responds in language meant for a person, or for another model, to interpret.
Production software usually needs a smaller answer:
- Which approved queue?
- How severe is this case?
- Does this action need a person?
- Is the evidence sufficient?
- Should the workflow continue, pause or escalate?
You can ask a general-purpose model to answer in JSON, and many teams do. The task is still text generation, squeezed into a shape after the fact, and the application then has to check that what came back is one of the answers it can handle. Jev approaches the problem the other way round. The caller defines the decision before sending it: the question, the allowed answers and what each one means. The model returns an answer within that space, with a probability distribution across it.
The taxi-rank analogy
Think of a busy taxi rank.
A general-purpose assistant is like an experienced rank marshal who can listen to a passenger, talk through several routes and give a detailed recommendation. Useful, but you get a conversation.
Jev is closer to the routing board. It takes the passenger's destination and the current conditions and points to one of the approved routes, with an honest indication of how sure it is. The rank still decides whether that route is running, whether the taxi is licensed for it and whether a supervisor needs to step in.
The narrower role is the point. A component that can only answer a defined question is far easier to test, monitor and reason about than one that can say anything.
What a request looks like
A request has three parts:
| Element | Meaning | Kloofvale example |
|---|---|---|
state | The information the decision needs | The report text, the ward, whether a location pin was shared |
questions | The bounded judgements to make, each with its own identifier | route, urgency, needs_human |
model | The decision model to call | typesafe/jev-1.13 on Jev AI, or jev-latest on TypeSafe's own API |
The response comes back under the same question identifiers. Depending on the question type, an answer can be a selected option with a probability for every option, a probability-weighted position on a scale, or a probability that a statement is true. Part 2 covers the three types in detail.
On what it can read, Jev AI's documentation is specific: state can be "text, a JSON object, or an array of text items. Image, audio, and video inputs are not supported yet." Kloofvale receives voice notes and photos on WhatsApp too. Those would need an upstream step, such as speech-to-text or a person adding a description, before Jev could see them. That step becomes another component to evaluate, because a decision can only be as good as the state it was given.
What "System One" means here
TypeSafe calls Jev "the first System One model", and describes System One as "a class of AI models built to make fast, structured decisions that software can use directly." The name borrows from the psychologist Daniel Kahneman's distinction between fast, intuitive thinking (System 1) and slow, deliberate reasoning (System 2).
Do not stretch the metaphor. In an architecture, System One is a product category, not evidence that the service thinks like a person. TypeSafe itself says these models "do not write replies, produce code, or generate explanations of their reasoning." The engineering distinction that matters is the one you can measure:
- The answer space is defined before the call.
- The output is typed.
- Probabilities come back with every answer.
- Several independent questions can read the same state.
- The model does not perform the action that follows.
What Jev does not do
Jev does not write the reply to the resident. It does not generate code, run commands, call a payment API, grant permissions or replace rules that can be written down. It cannot prove that any single answer is right, and it does not remove the need for people to review the cases that matter.
That boundary is what makes the component easy to reason about. It is also why Jev on its own achieves nothing. It only becomes useful inside an application that has been designed to use it properly: one that prepares the state carefully, decides in its own code what each answer allows, and gives uncertain cases somewhere safe to go. Parts 3 and 4 are about that design.
The CloudNala view
We treat Jev as a probabilistic decision service behind a deterministic control boundary. It earns its place when the same question comes up again and again, the allowed outcomes are known, uncertainty matters to what happens next, and the application can safely handle every possible answer, including "I'm not sure".
Kloofvale's routing problem fits that description. Fourteen hundred reports a week, four known destinations, a real cost to getting urgency wrong and a human team already in place for the hard cases. Whether Jev is good enough for that job is a separate question, and one only evaluation on Kloofvale's own reports can answer. Part 7 shows how.
Key points
Jev returns decisions, not prose. It answers typed questions about the state you send, with probabilities.
The caller defines the answer space. Questions, options and their meanings are set before the call, not parsed afterwards.
It never takes the action. Rules, permissions, review and audit stay in your application.
Jev AI and TypeSafe are different providers. Know which contract, endpoint and terms you are using.
Fit comes before features. Repeated, bounded judgements with a safe fallback are where the pattern pays off.
Next: Part 2, Choice, Score and Noul. All parts are on the series page.
How CloudNala can help
We help teams find the repeated judgements hiding inside their workflows, the queue choices, triage calls and review triggers that people make hundreds of times a week, and work out which belong in a rule, which belong with a person and which could use a decision model with a safe fallback. We start from one real decision and a sample of real cases, so the conversation is about evidence rather than about a product.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Decision Review or write to us at consult@cloudnala.co.za