Oracle APEX and Jev: Somewhere Between Valid and Wrong

I like to play with technology.

I was all over the Raspberry Pi and ESP32 craze when it happened. For years, I had a crappy NAS built from one. I even learned assembly just because I saw a tutorial on how to write Hello World from scratch.

When machine learning became a thing, I spent ungodly amounts of time implementing it in various languages just for the heck of it.

And, of course, now that we're in the age of LLMs, the gaming GPU in my gaming PC spends more time predicting the next token than running Cyberpunk 2077.

Naturally, the YouTube algorithm knows that very well. So when Jev came out, my feed was full of it.

So, what is Jev?

Jev is a new type of AI focused on making small, structured decisions.

In its simplest form, you give it a question and it predicts the probability that the answer is Yes.

That's it.

Thanks to the simplicity of the task, it doesn't take 7.5 million years and the resources of an entire civilization to respond.

Actually, it's quite the opposite.

A single answer takes less than a second, and Jev is priced at around $0.042 per million input tokens , and outputs are free.

There are also some additional modes, such as choosing from a list of possibilities or scoring multiple options.

The wider internet has already started using it for all kinds of cool things: driving a simulated car, predicting the stock market, and even playing Doom.

So naturally, I thought I would do something even more exciting:

Implement it in APEX!!!

Jev in APEX

I won't go into too much technical detail here. I was more interested in the potential use cases than in how to integrate it.

The only real technical hurdle we have to solve is that the standard Oracle AI packages don't understand the terrifyingly complex JSON schema Jev uses.

So we have to use apex_web_service.make_rest_request and parse the response ourselves.

For the actual experiment, I used Oracle APEX's built-in Customer Management application.

On the customer create/edit page, I added a Jev-based validation layer that can raise flags after the user saves the record.

The interesting part is that the validations themselves are not hardcoded into the page.

Instead, an application administrator can configure them on a separate page.

For each validation, the admin can specify:

• which field should be checked,

• what question Jev should answer,

• any additional static context that should be included,

• the warning threshold,

• and the warning message shown to the user.

In the example below, the customer is called Illumina Biotech test and is classified as Healthcare, but its description says that the company operates mostly in the oil industry.

Jev raises two flags.

One is attached directly to the customer name because it looks like placeholder or test data.

The other applies to the whole record because several fields appear to describe different companies.

I intentionally display these in an Information region, not as warnings or errors, because Jev is making a prediction.

I don't want it deciding whether the user is allowed to save the record, and I don't want it to be overly nagging either.

The user can still continue. The system is simply saying:

Hey, this looks a bit suspicious. Maybe check it again.

But why, Jev?

There is also one extra piece.

Jev itself only gives us the decision, so when it flags something, the user might reasonably ask:

Why?

For that, I added a separate call to a normal LLM.

The LLM is not used for every validation.

It is only called when Jev flags a potential problem and the user actually asks for an explanation.

That way, Jev handles the fast and cheap decision, while the larger model is only used when some actual reasoning needs to be presented to the user.

So the flow looks roughly like this:

1. Jev checks the configured rule.

2. If everything looks fine, nothing happens.

3. If Jev flags something, APEX displays it in the Information region.

4. If the user wants more detail, they can ask for an explanation.

5. Only then do we call the regular LLM to explain why the value may have triggered the check.

This keeps the LLM out of the critical path.

Most validations stay fast and inexpensive, while the more expensive model is used only when it provides some additional value.

Once the explanation is shown, the user can also rate the whole interaction.

That feedback is stored so the application administrator can review cases where the flag or explanation wasn't useful.

From there, the admin can adjust either side of the system:

• the question being sent to Jev,

• the static context,

• or the prompt being used by the LLM to generate the explanation.

So instead of treating the AI configuration as something you get right once and never touch again, the application gives you a small feedback loop for improving it over time.

The whole thing ends up looking something like this:

Jev decision → flag → optional LLM explanation → user feedback → admin tuning

Jev reviewing Jev

There is also a slightly ridiculous recursive part to this.

If administrators are going to create Jev questions themselves, those questions can also be bad.

A question might be ambiguous, combine multiple independent checks, require information that isn't actually available on the page, or even have its Yes/No logic backwards.

So I added another Jev review for the Jev configuration itself.

Before a check is used to judge customer data, Jev can judge whether the check makes sense.

For example, it can ask whether:

• the question is ambiguous about what counts as Yes,

• it combines multiple independent problems into one question,

• answering it requires information that isn't available,

• a Yes actually represents a problem rather than acceptable data,

• the warning message claims more than Jev actually established,

• or the check contradicts the context of the page it belongs to.

Yes, I am using Jev to check whether my questions for Jev are good questions for Jev.

We may have gone too deep.

From fuzzy checks to real validations

What I like most about this solution is that the business doesn't need to come up with every possible validation rule on day one.

Those questions can grow over time.

Something goes wrong.

A bad value gets through.

Someone eventually asks:

How the hell did we not catch this?

Instead of only fixing that one record, the business can add another question to the system so the same kind of mistake is more likely to be caught next time.

Over time, the list of questions starts to reflect actual problems the business has encountered rather than some theoretical list of everything that could possibly go wrong.

So you end up with another small feedback loop:

something goes wrong → add or improve a question → Jev starts checking for it → users rate the result → admin tunes it further

It's not a system that magically learns by itself.

But it does give the business a way to gradually turn past oopsies into additional checks, without having to build another hardcoded validation every single time.

And some of those questions may not stay AI-based forever.

If a particular check keeps proving useful, and the business eventually understands the rule well enough to express it deterministically, it can be promoted into a normal validation.

At that point, Jev has done its job.

It helped the business discover and refine a useful rule before anyone had to sit down and define the perfect validation logic upfront.

So the system can gradually evolve from:

AI-assisted checks → proven patterns → standard validations

I think that's the interesting part of this whole experiment.

The goal isn't to replace normal validations with AI.

Normal validations are still better whenever you actually know the rule.

The interesting space is everything in between.

The cases where someone looks at the data and says:

This looks wrong.

…but can't immediately turn that feeling into a neat IF statement.

That feels like a pretty good place for something like Jev.

And to answer the question from the beginning:

So yes, Jev — Jev can be used in Oracle APEX.