Jev: A Different Kind of Condition in Software

I’ve been looking at Jev from TypeSafe recently. The easiest way I’ve found to understand it is through a very ordinary programming problem.

Suppose we have a table of restaurants.

If the requirement is:

Find all cuisines starting with I.

That is trivial.

SELECT *
FROM restaurants
WHERE cuisine LIKE 'I%';

Now change the requirement slightly:

Find all restaurants serving Italian cuisine.

If the data already has a clean cuisine = 'italian' field, this is still trivial.

But real data is often not that clean.

You might have:

restaurant: Bella Napoli
description: Wood-fired Neapolitan pizza, handmade pasta and tiramisu.

restaurant: Corner Cafe
description: Coffee, sandwiches, pasta and pastries.

restaurant: Mediterranean House
description: Fresh pasta, grilled seafood, olives and seasonal dishes.

Now what exactly makes a restaurant Italian?

We can start writing rules around words like pizza, pasta, risotto, or tiramisu, but those rules are only approximations. A cafe can sell pasta without being Italian. An Italian restaurant may have a description that never contains the word Italian.

The condition itself is easy to state:

Does this restaurant primarily serve Italian cuisine?

The implementation is the difficult part.

That is the gap Jev is trying to fill.

Conditions that are easy to describe but hard to encode

A lot of software is built around exact conditions.

if price > 100:
    ...

if status == "paid":
    ...

if name.startswith("N"):
    ...

These are good conditions because the meaning and implementation line up cleanly.

Things get less pleasant when the requirement contains words like:

relevant
similar
suspicious
appropriate
likely
useful
about

Developers usually end up translating these into measurable proxies.

For the restaurant example, maybe we check whether the description contains enough Italian dish names.

For user behaviour, maybe we decide that three failed actions means the user is struggling.

For support tickets, maybe the presence of the word refund means someone wants their money back.

Sometimes those heuristics are completely fine. I would still use them whenever the rule is clear enough.

The problem is when the heuristic starts becoming the implementation simply because we don’t have a good way to express the actual condition.

Jev lets you ask the condition directly.

Conceptually:

is_italian = jev(
    restaurant,
    "Does this restaurant primarily serve Italian cuisine?"
)

and get back a probabilistic answer rather than generated text.

That changes what kinds of conditions are practical to put inside normal software.

This gets more interesting in retrieval

The restaurant example is deliberately simple. The same problem shows up constantly in information retrieval.

Suppose someone asks:

Can I cancel my subscription and still use the product until the end of the month?

A retrieval system may return passages about:

cancellation
refunds
billing cycles
access after cancellation
account closure

An embedding model is useful here because it can find text that is semantically related to the query.

But related is not quite the condition we care about.

What I really want to know is:

Does this passage contain information that helps answer the question?

Those two things overlap, but they are not the same.

A passage can be very similar to the query and still be useless as evidence.

So one possible retrieval pipeline becomes:

query
  ↓
BM25 / vector search
  ↓
candidate passages
  ↓
Jev: "Does this passage help answer the query?"
  ↓
filtered or reranked results

This is where Jev starts to feel less like a classifier API and more like something you can compose with existing systems.

I would not replace retrieval with it.

BM25 and embeddings are very good at cheaply reducing a large search space.

But after retrieval, there are many places where we currently rely on weak proxies for what we actually care about:

Is this passage relevant?

Does this passage support the claim?

Are these two records referring to the same entity?

Does this document contradict what we already found?

Is this result useful enough to show to the user?

Those are judgment problems.

A different style of software

This is the part of Jev I find most interesting.

Most software today contains conditions that are easy for machines to evaluate:

if order.total > 500:
    ...

if country == "NP":
    ...

if retry_count >= 3:
    ...

With something like Jev, you can start imagining conditions such as:

if restaurant_is_probably_italian(...):
    ...

if passage_supports_the_claim(...):
    ...

if these_two_products_are_the_same(...):
    ...

if user_seems_stuck(...):
    ...

if this_output_needs_human_review(...):
    ...

That does not mean these should all become model calls.

I would be suspicious of any design that turns every if statement into AI.

Exact rules should stay exact. SQL should stay SQL. Regex should stay regex. A proper trained model may still be the right answer for a stable, high-volume problem.

But there is a useful middle ground where the business condition is clear and the implementation is mostly a pile of proxies.

That is where Jev looks useful.

Why not just ask an LLM?

At this point the obvious question is whether we already have this with GPT, Claude, or any other LLM.

In terms of capability, often yes.

You could ask an LLM:

Does this restaurant primarily serve Italian cuisine?
Return true or false.

or:

Does this passage help answer the user's question?

People already do this.

The difference is that an LLM is still a generative model. We ask it to generate output even when our program only needs a small decision.

That comes with a few things we then have to manage:

output format
parsing
validation
generation latency
token cost

Jev is designed around the narrower case where the output space is already known.

That makes sense to me architecturally.

If I need a model to write an answer, I want an LLM.

If I already know the possible outcomes and only need help deciding between them, a decision model is a more natural fit.

Whether Jev is actually accurate, calibrated, and cheap enough to deserve that role is something I would still want to test on my own data. It is new, and most of the strong performance claims today come from TypeSafe itself.

But the abstraction is interesting even before those questions are settled.

The useful question is not:

Can Jev do something an LLM cannot?

It is:

Are there places in my software where the condition I actually care about is being replaced by a bad proxy because expressing the real condition was too expensive or inconvenient?

For me, that is the most useful way to think about Jev.