TL;DR
LLMs are excellent when we want AI to generate something.
But many applications don't need an essay, an explanation, or even a sentence.
They need a decision.
Is this ticket technical or billing? How severe is this incident? Should we escalate it?
That's the problem Jev approaches differently.
Instead of generating arbitrary text token by token, Jev is a System One model (fast, automatic, intuitive, low-effort): you provide a state and predefined questions, and it returns typed decisions and probabilities that your application can directly consume. GitHub
I built a small Spring Boot + OpenJev application to see what this programming model actually feels like.
🔸 WHAT IS JEV? 🧠
Jev is TypeSafe AI's flagship System One model.
The idea behind System One is different from the usual chatbot interaction.
With an LLM, we might write:
The model then generates an answer.
We can constrain that generation with structured output, JSON schemas, tool calling, etc., but generation remains at the heart of the interaction.
With Jev, the application instead defines the decision space beforehand.
Conceptually:
Jev evaluates those questions against the state and returns typed answers with probabilities rather than composing a natural-language response.
That's the first big mental shift:
🔸 AN ESSAY vs A MULTIPLE-CHOICE TEST 📝
Here's the analogy I find easiest.
Imagine asking two students the same question.
The first gets:
Explain what should happen with this customer request.
That's the LLM.
The second gets:
Choose one: Technical / Billing / Security / Other.
That's much closer to Jev.
The second student still has to understand the problem and make a judgment.
But they don't have to invent the output.
The possible answers already exist.
And that's important for software.
If my Java code expects:
I don't particularly want an AI to answer:
🤣
I want:
And preferably I also want to know how confident the model is in that decision.
Jev's Choice responses therefore include the selected option, probabilities for the available options and a confidence value.
🔸 WHAT JEV BRINGS vs AN LLM ⚔️
This doesn't make Jev a "better LLM."
It solves a different problem.
Use an LLM when you need:
▪️ Generated text
▪️ Explanations
▪️ Code
▪️ Summaries
▪️ Conversations
▪️ Creative or open-ended answers
Jev becomes interesting when you need:
▪️ Classification
▪️ Routing
▪️ Scoring
▪️ Prioritization
▪️ Gating
▪️ Risk evaluation
▪️ Decisions from a finite set
Its three core question primitives are Choice, Score and Noul.
Choice selects from predefined alternatives;
Score evaluates against an ordered scale; and
Noul gives a yes/no probability.
So instead of asking AI to control your application, an interesting design principle emerges:
Code owns the workflow. AI makes narrow judgments inside
🔸 THE SPRING BOOT DEMO ☕🍃
To experiment with this, I built a deliberately small support-ticket triage application.
The architecture is:
I use OpenJev, the open System One model hosted by Codiv, rather than running the model locally.
Codiv exposes the System One-compatible /v1/systemone API and currently supports openjev-latest.
The complete source code is here:
https://github.com/vinny59200/jev-springboot
🔸 THE IMPORTANT PART: Choice 🎯
The interesting code lives in TriageService.
For example:
Notice what we're doing.
We're not asking Jev to invent a category.
We're defining the application's vocabulary ourselves:
Jev's job is to decide which option best corresponds to the supplied state.
A Choice can contain up to 255 options in the current System One API.
This is also why including something like:
can be important.
Otherwise, your predefined world may be narrower than the real one.
🔸 Score: NOT EVERYTHING IS A CATEGORY 📊
Severity is different.
There is an order:
That's where Score comes in.
A score isn't simply another classification.
Jev knows these levels form an ordered scale.
The API returns a probability distribution across those levels and an expected numerical score, meaning the result can represent uncertainty between adjacent levels.
That's useful for things such as:
🔸 AND THERE IS ALSO Noul ✅❌
My demo mainly focuses on Choice and Score, but Jev has a third primitive worth knowing:
Noul.
Think of it as a probabilistic yes/no question.
For example:
Instead of generating:
the API can return something conceptually like:
That represents the probability of yes.
Then Java owns the policy:
That's an interesting separation of responsibilities.
AI judges.
Code decides what to do with that judgment.
🔸 ONE STATE, MULTIPLE DECISIONS ⚡
Our ticket is the state.
We can then evaluate several questions about that same state:
Conceptually, that's:
The System One API accepts multiple questions in the same request and returns one typed answer per question.
That fits the ticket-triage problem extremely well.
🔸 WATCH THE DEMO 🎥
I test the application with different situations, from an ordinary individual request to something requiring immediate escalation.
The UI itself is intentionally minimal.
That's because the interesting part isn't the frontend.
It's seeing how little AI-oriented code is required once the application's decision space is clearly defined.
🔸 WHY NOT JUST USE STRUCTURED OUTPUT WITH AN LLM? 🤔
That's probably the most interesting question.
Modern LLM APIs can absolutely produce structured output.
You can define a JSON schema and constrain an LLM to something like:
So structured output alone isn't the reason to use Jev.
The distinction is deeper.
An LLM remains fundamentally useful for generation and open-ended reasoning.
A System One model is specifically designed around fast, structured judgments and calibrated probabilities.
That makes Jev especially interesting when your problem is fundamentally:
Given X, which of these known outcomes is most appropriate?
If you already know every valid answer, generating arbitrary text may simply be solving a larger problem than you actually have.
🔸 WHY SHOULD A JAVA DEVELOPER CARE? ☕
Because enterprise applications are full of decisions like these.
Traditionally we might encode them as increasingly complicated rules:
Rules are fantastic when the business logic is deterministic.
But some judgments depend on the meaning of messy natural-language data.
That's where a decision model becomes interesting.
You don't necessarily need a chatbot.
You may just need something capable of understanding:
and returning:
while keeping the application's actual workflow in Java.
🔸 WHEN I WOULD NOT USE JEV 🚫
Jev isn't a replacement for every LLM use case.
I wouldn't choose it to:
▪️ Write an email
▪️ Generate Java code
▪️ Explain an exception
▪️ Summarize a long document into prose
▪️ Build a conversational assistant
▪️ Produce creative content
Those are generative problems.
But if I catch myself asking an LLM:
"Return only one of these four values..."
then I would at least ask:
Do I really need generation here?
Maybe I need a decision model.
🔸 TAKEAWAYS 🎯
▪️ Jev is a System One model, not a conventional chatbot.
▪️ You provide state + typed questions, rather than asking for arbitrary generated text.
▪️ Choice selects among predefined alternatives.
▪️ Score evaluates against an ordered scale.
▪️ Noul evaluates a yes/no proposition probabilistically.
▪️ Responses can include probabilities and confidence, making uncertainty usable by your code.
▪️ Your Java application keeps control of the workflow.
▪️ LLMs remain the better tool when you actually need generation.
▪️ And sometimes, with great AI power...
come PREDEFINED responsibilities. 🤣🕷️
#Java #SpringBoot #SpringAI #Jev #OpenJev #AI #ArtificialIntelligence #MachineLearning #JavaDeveloper #SoftwareArchitecture #SoftwareEngineering #GenerativeAI
Go further with Java certification:
Java👇
Spring👇
SpringBook👇
JavaFullstackBook👇