☕🤖 With great AI POWER come PREDEFINED RESPONSIBILITIES...

Return to site

☕🤖 With great AI POWER come PREDEFINED RESPONSIBILITIES: meet JEV

What if your AI didn't need to talk - only make the right decision?

· AI

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:

Here is a support ticket.

Analyze it and tell me:
- its category
- its severity
- what we should do

Return JSON.

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:

STATE:
"Production checkout is unavailable for every customer."

QUESTIONS:

category:
    technical
    billing
    security
    other

action:
    auto-route
    human-review
    escalate

severity:
    low
    medium
    high
    critical

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:

LLM → "What should I say?"

Jev → "Which predefined decision best fits this situation?"

🔸 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:

if (category.equals("security")) {
    escalate();
}

I don't particularly want an AI to answer:

This appears to be primarily a security-related matter,
although there may also be some technical implications...

🤣

I want:

security

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:

Browser
   │
   ▼
Spring Boot REST Controller
   │
   ▼
TriageService
   │
   ▼
TypeSafeClient
   │
   ▼
Codiv API
   │
   ▼
OpenJev
   │
   ▼
Typed decisions

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:

Choice.builder()
    .instructions(
        "Which team should handle this ticket?"
    )
    .option(
        "technical",
        "Bugs, outages, errors, integrations and technical problems"
    )
    .option(
        "billing",
        "Payments, invoices, charges and refunds"
    )
    .option(
        "security",
        "Credentials, suspicious access and security incidents"
    )
    .option(
        "other",
        "Anything that does not belong to the other categories"
    )
    .build();

Notice what we're doing.

We're not asking Jev to invent a category.

We're defining the application's vocabulary ourselves:

technical
billing
security
other

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:

.option("other", "Anything outside the defined categories")

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:

Low < Medium < High < Critical

That's where Score comes in.

Score.of(
    "How severe is the impact of this ticket?",
    "Low",
    "Medium",
    "High",
    "Critical"
);

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:

severity
risk
priority
relevance
quality
frustration

🔸 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:

Does this ticket describe a security incident?

Instead of generating:

Yes, I believe this is probably a security incident because...

the API can return something conceptually like:

0.93

That represents the probability of yes.

Then Java owns the policy:

if (securityProbability > 0.90) {
    escalate();
}

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.

String ticket =
    "Production checkout is down for all customers.";

We can then evaluate several questions about that same state:

SystemOneResponse response =
    typeSafeClient.systemOne(
        ticket,
        Map.of(
            "category", categoryChoice,
            "action", actionChoice,
            "severity", severityScore
        )
    );

Conceptually, that's:

┌──▶ CATEGORY
TICKET ──▶ OpenJev ──────┼──▶ ACTION
                         └──▶ SEVERITY

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.

https://youtu.be/Ai7oVfbFKts?si=P-KEhYkT4IwYGtbL

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:

{
  "category": "technical",
  "severity": "critical"
}

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.

Which queue?
Which team?
Which priority?
Which risk level?
Accept or review?
Fraud or legitimate?
Relevant or irrelevant?
Escalate or continue?

Traditionally we might encode them as increasingly complicated rules:

if (conditionA && conditionB && !conditionC) {
    ...
}

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:

"I've been charged twice and nobody has answered me for three days!"

and returning:

category = billing
priority = high
escalate = true

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👇

https://bit.ly/javaOCP

Spring👇

https://bit.ly/2v7222

SpringBook👇

https://bit.ly/springtify

JavaFullstackBook👇

https://bit.ly/jfstack27