AWS Builder Center

Builder Center

Let the Model Decide, Let Your Code Act : My First Experiments with Jev-AI

Let the Model Decide, Let Your Code Act : My First Experiments with Jev-AI

I tried Jev-AI, a model that returns typed decisions instead of paragraphs. This article covers what I tested, what I saw, and what I still don't know.

Achmad Al Fauzi Dhiaulhaq

AWS Cloud & AI Enthusiast | Learning, Building & Sharing

The problem I wanted to solve

A lot of AI demos work like this: a user sends a message, and a chat model writes a long answer. But in many apps, I don't need a long answer. I need a decision.
For example, a customer message comes in. Is it about a refund? Is it urgent? Which service should look at it? After that, my own code should do the work.
The trouble is that a paragraph of text is hard for code to use. Code wants a clear value, like refund or true, that it can plug into an if or a lookup table.
So I wanted to try a model that is built for this one job: read some input, answer a question I defined, and return something my code can use right away. That is how I ended up trying Jev-AI.
In my own projects, two places came to mind: sending incoming messages to the right place before my RAG chatbot answers, and checking documents before a PII masking step. I'll come back to those later. I have not built either one yet.

What Jev-AI is

Jev-AI is a model from TypeSafe AI. TypeSafe calls it a "System One Model". It is a model made for decisions that software can use directly.
Here is the simple version. A chat model writes text. Jev does not write paragraphs. You give it some data and a question you defined, and it returns a typed answer, plus a probability and a confidence value.
I like to think of the split like this:
  • Jev answers: "From the options I defined, which one fits this input best?"
  • My app answers: "If the result is X, what should I do?"
So Jev makes the decision, but my app still controls the action. The routing logic stays in my code.

What a request looks like

A request has three parts:
PartWhat it is
stateThe data to analyze. This is whatever information my app has.
questionsThe judgments I want Jev to make.
modelThe model identifier, like jev-latest.

The three question types

  • Choice: pick one option, like A, B, or C.
  • Noul: a binary question. The answer is 0 or 1, like true or false.
  • Score: like Choice, but the output rules are looser. For example, I can ask for 1 to 10, or 0% to 100%.
That is all I needed to start testing.

Why a decision layer can be useful

These points come from TypeSafe's docs and my reading notes. They are TypeSafe's claims, not my own measurements.
  • Speed and cost. TypeSafe says Jev can answer in about 70 ms to 500 ms. It also says this is much cheaper than asking a chat model for JSON structured output.
  • Locked output. The answer has to fit the schema I define up front. TypeSafe says this means Jev cannot hallucinate. When I first read that, my reaction was "What??"
  • Parallel questions. If several questions use the same state, I can send them in one request. They are evaluated independently, in parallel, in one pass. Jev does not think step by step like a chat model.
Let me explain the "cannot hallucinate" claim the way I understand it. A normal chat model can make up an answer that goes outside the context. With Jev, the answer is locked to the typed schema I wrote. So the format is safe, and it should not break my system. That is not the same as saying every decision is correct. I'll show later why I read it that way.
The idea I find most useful is a division of work. Jev handles bounded decisions inside the software, like routing, classification, and structured judgments. A generative model is still the right tool for long reasoning and writing.

How the decision flow works

This is the flow I have in my head:
  1. Input arrives in my app, for example a customer message.
  2. My app puts the data into state and picks the questions to ask.
  3. My app sends one request to Jev.
  4. Jev returns a typed answer for each question, with probabilities.
  5. My own router reads the answers and decides what to do.
Step 5 is normal code. Here is the pseudocode from my notes:
1
2
3
4
5
route = (product, client, service, context)

tool = ROUTES[route]

result = tool(...)
Jev never calls the tool. It only gives the decision. My code owns the lookup table and the action. That is what I mean by "let the model decide, let your code act."

What I tested

I ran a small mini lab. The idea is simple: state is the information I want to analyze, and a question is the judgment I want from Jev. I used customer support messages for a payment app. I trimmed and cleaned up the JSON below so it is easier to read.

Test 1: One yes/no question (Noul)

State: "My card was charged twice for the same transaction. I want my money back."
1
2
3
4
5
6
7
8
9
10
{
"duplicate_charge": {
"type": "noul",
"instructions": "Does the customer report that the same transaction was charged more than once?",
"criteria": {
"true": "The customer explicitly reports that the same transaction was charged multiple times.",
"false": "The customer does not report a duplicate charge"
}
}
}
Response:
1
2
3
4
5
6
{
"model": "jev-1.13.0",
"answers": {
"duplicate_charge": { "type": "noul", "noul": 0.99, "stats": {} }
}
}

Test 2: Pick one option (Choice)

Same state. This time I asked for the customer's main intent, with four options: refund, duplicate_charge, transaction_status, and account_issue. Each option has a short description (the criteria).
Response (inner answer only):
1
2
3
4
5
6
7
8
9
10
11
{
"type": "choice",
"choice": "refund",
"confidence": 0.68,
"probabilities": {
"duplicate_charge": 0.24,
"account_issue": 0,
"transaction_status": 0,
"refund": 0.76
}
}

Test 3: A level instead of a label (Score)

State: "My payment has failed three times. I need to complete the payment today because the deadline is approaching."
Question: "How urgent is the customer's request?" with three levels: not urgent, moderately urgent, and highly urgent.
Response (inner answer only, shortened):
1
2
3
4
5
6
{
"type": "score",
"score": 2,
"confidence": 1,
"probabilities": { "0": 0, "1": 0, "2": 1 }
}

Test 4: Many questions in one request

State: "My card was charged twice for the same transaction. I need the extra charge refunded today because I need the money for an important payment."
I sent four questions in one request. They all look at the same state and are evaluated independently:
QuestionTypeWhat it asks
intentchoiceWhat is the main intent? (refund, duplicate_charge, transaction_status, account_issue, other)
refund_requestednoulDoes the message explicitly ask for a refund?
duplicate_chargenoulDoes it report the same transaction charged more than once?
urgencyscoreHow urgent is the request? (three levels)
Response:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
{
"model": "jev-1.13.0",
"answers": {
"intent": {
"type": "choice",
"choice": "refund",
"confidence": 0.81,
"probabilities": {
"transaction_status": 0,
"duplicate_charge": 0.15,
"refund": 0.85,
"other": 0,
"account_issue": 0
}
},
"refund_requested": { "type": "noul", "noul": 0.99 },
"duplicate_charge": { "type": "noul", "noul": 0.99 },
"urgency": { "type": "score", "score": 2, "confidence": 1 }
},
"usage": { "input_tokens": 555, "output_tokens": 104 }
}

Test 5: Structured state

The state does not have to be a string. Jev accepts strings, objects, and arrays. I wrote a ticket as JSON and pointed the questions at specific fields:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
{
"ticket": {
"id": "T-001",
"customer": { "name": "Alex", "tier": "premium" },
"message": "My card was charged twice for the same transaction. I want the extra charge refunded."
},
"transaction": {
"id": "TX-83921",
"amount": 49.99,
"currency": "USD",
"status": "completed"
},
"channel": "chat"
}
The questions use field paths in their instructions, like these:
  • "What is the customer's main intent based on ticket.message?"
  • "What customer tier is specified by ticket.customer.tier?"
  • "Is transaction.status completed?"
  • For arrays: "Does ticket.messages[2].text indicate that the customer needs the issue fixed urgently?"
My notes keep the questions but not the outputs for this test, so I won't claim any results here.

A design sketch: an intent router (not run)

I also drew a routing idea with dummy data. This is a sketch only. I did not record a live run, and the output shape below is simplified, not a real Jev response.
The dummy services look like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
card_management
├── bank_abc
│ └── api-core
└── bank_xyz
├── api-atm
└── api-cms

payment
├── fauzipay
│ ├── api-payment
│ ├── api-gateway
│ ├── api-fraud
│ └── api-settlement
└── arsyipay
└── (same four services)
The idea: for a message like "Please check the API gateway logs for FauziPay, because many payment transactions are failing," Jev answers four questions: product, client, service, and context. For multiple labels, I use several questions. My router then joins the answers into one path:
1
2
3
4
5
6
product = payment (0.98)
client = fauzipay (0.97)
service = api-gateway (0.95)
context = logs (0.96)

→ route: payment/fauzipay/api-gateway/logs
The numbers above are illustrative.

What I observed

These are things I saw in the outputs from Tests 1 to 4.
  • The shape never changed. Every answer had a type, a value, and probabilities. That is easy for code to read. There was no text to parse.
  • Clear cases got high numbers. Both yes/no questions in Test 4 came back at 0.99. The urgency score was 2 with a confidence of 1.
  • Mixed messages got a split. The message talks about a duplicate charge and a refund. Jev picked refund, but it still gave duplicate_charge 0.24 in Test 2 and 0.15 in Test 4.
  • Many questions, one response. Four questions came back together. The usage showed 555 input tokens and 104 output tokens.
One thing I did not do: I did not time any request. So I have no latency numbers of my own.

What I learned

This part comes from my reading notes on Jev's speed claims and benchmarks.
The speed numbers are real, but not apples-to-apples. Jev only returns a Choice, a Score, or a yes/no, plus probabilities. It does not write prose or code. The "20 to 200 times faster" claim is against chat models that are forced to output probability distributions. That is a different job from normal chat.
An independent test showed a trade-off. In a test by Every, Jev took 0.35 seconds per passage and caught 6 of 7 defects. Fable, a large language model, took 8.83 seconds and caught 7 of 7. So Jev was faster and cheaper, but recall went down.
The official benchmark has limits. It uses a workflow built by the TypeSafe team. Its reference is the average of frontier models, not ground truth.
My conclusion for now: Jev looks like a good fit for bounded decisions inside software, like routing, classification, and structured judgments. It is not for long reasoning. So I see it as a division of work, not a replacement for generative AI.
Two smaller things I learned:
  • On "cannot hallucinate": in my tests the format never broke, which matches the idea of a locked schema. But the Every result shows that a fast decision can still miss things. This is my own reading.
  • For multiple labels, I use several questions. For data that lives in different fields, I can send structured state and point to fields by path.

Possible use cases

These are ideas I think could work. I have not built or tested any of them yet.
  • Route messages before RAG. In my chatbot Tanyain Bangkep, a decision layer could sort incoming messages before they go into the RAG step.
  • Classify documents before PII masking. Before documents enter my Presidio masking pipeline, I could ask "Does this document contain PII?" as a Noul question, and "What category is this document?" as a Choice question.
  • Support ticket triage. This is what my mini lab looked like: intent, refund requested, duplicate charge, and urgency.
  • Service and log routing. The dummy tree from my sketch, where the answers join into a path like payment/fauzipay/api-gateway/logs.
  • Handling unsure cases. Because Jev returns probabilities, I think my app could treat close calls differently from clear ones. I have not tried this.

Limitations and open questions

This was a small experiment, so there is a lot I can't say yet.
  • I did not measure speed or cost. The 70 ms to 500 ms range and the "cheaper than JSON structured output" claim come from TypeSafe.
  • The benchmarks are not mine. TypeSafe's own numbers use its own workflow and no ground truth. The independent test I read about showed lower recall.
  • Only a few examples. I ran short English messages about payments. That is not enough to judge accuracy. I have not tested other languages, other topics, or inputs that fit none of the options.
  • Some results are missing. I did not record outputs for the structured state test, and I did not run the router sketch.
  • Confidence is unclear to me. In Test 2, the top probability was 0.76 but the confidence was 0.68. My notes don't explain how the two differ.
  • Not for every job. Jev does not write text or reason over long steps. For that, I still need a generative model.

What I want to try next

  1. Use Jev as a first step in Tanyain Bangkep, to route incoming messages before the RAG step.
  2. Try the PII yes/no question and the document category question before my Presidio masking pipeline.
  3. Run the intent router sketch for real, and see if product, client, service, and context work as I imagined.
  4. Time the requests myself and compare them with JSON structured output from a chat model.
  5. Look at the alternatives I noted down. Laya AI is an open-source Jev alternative that can be self-hosted on a GPU VPS (LumaDock tutorial ). There is also von  on GitHub. I have not tried either one.
I'm still learning, and this is only my first look. If you have tried a decision layer like this in your own apps, I would like to hear what worked and what didn't.
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article