Most AI systems on the market right now have one main job: creating stuff. They pump out text, summarize massive PDFs, or write code, token by token.

But it's the wrong tool for the countless micro-decisions that have to happen before any actual generation begins. Things like:

• Which files actually matter here?
• Where should we route this specific query?
• Do we really need to stuff this search result into the context window?
• Has the agent found enough proof to just stop digging?
• Is this webpage actually helpful, or just SEO spam?

TypeSafe’s Jev takes a completely different angle. Think of it as a "System One" decision engine. Rather than writing paragraphs of text, it evaluates typed questions in a single, parallel sweep—spitting out choices, scores, or probabilities instead.

Jev is not going to kill off generative AI, but is stepping up to be the ultra-fast decision-maker in front of it.

Generative AI isn't always the thing slowing you down

Picture a standard Retrieval-Augmented Generation (RAG) setup. A user asks a question, and the system pulls up 100 documents that might hold the answer.

Here's what your average pipeline normally looks like:

User asks a question --> Embed the text --> Grab 100 docs --> Rerank them --> Toss the top 10 to an LLM --> Get your generated answer

That final LLM? Probably fantastic at piecing together a response. But frankly, it’s a massive waste of computing power to force a giant, expensive model to make every tiny filtering choice along the way.

A purpose-built decision model can knock out those repetitive chores way more efficiently:

User asks a question --> Pull candidate docs --> Jev grades relevance and trashes the garbage --> The LLM gets only the 5–10 best docs --> Get your generated answer

This split gives both tools a job they actually excel at. Jev handles the routing, sorting, and confidence scoring. The generative LLM gets to focus on reasoning, synthesizing, and writing.

What exactly does Jev output?

Since Jev uses typed outputs, it thrives in situations where the answer space is strictly defined.

1. Making a Choice

Picking a single option from a hardcoded list. Let's say you need to categorize a search query. You could set it up to choose between:

informational | transactional | navigational | support

Once categorized, the search platform can automatically trigger the smartest retrieval strategy for that specific intent.

2. Assigning a Score

Dropping a value on a tight scale. For example, you want to grade a document's relevance from 0 to 4:

• 0 = totally off-topic
• 1 = barely related
• 2 = gets halfway there
• 3 = super relevant
• 4 = nails the answer directly

This is perfect for reranking search results before they ever touch your heavy-duty LLM.

3. Giving a Probability (Noul)

Spitting out a yes/no answer, but formatted as a probability.

• "Does this doc hold enough proof to answer the prompt?" → 0.91

Why a probability instead of a flat yes or no? Because it lets your app call the shots. A basic search tool might be totally fine with a 0.75 score, whereas a strict legal compliance bot wouldn't settle for anything under 0.95.

Why decision & Context matters

A quick decision layer buys you three massive perks.

1. Your costs drop because you aren't feeding as many tokens to the big model.
2. Latency shrinks because there's just less text to chew through.
3. And your grounding improves dramatically, since random, unhelpful documents aren't distracting the model from the real facts.

Jev doesn't replace embeddings or your generative tool—it just adds a much-needed quality control filter right in the middle.

Use Case 1: RAG that actually works (and works fast)

The main reason RAG setups fall flat is pretty straightforward: too much junk in the context window.

When an LLM gets flooded with noisy data, it wastes processing power trying to make sense of documents that should've been filtered out minutes ago. That means you pay more, wait longer, and run a higher risk of getting a hallucinated answer.

Imagine a dev asking:

“How do I rotate the production database credentials without causing downtime?”

Your standard retriever might drag back docs about local dev secrets, a totally unrelated auth outage, or some deprecated migration guide from three years ago. Jev steps in to score everything against the prompt, tossing out the weak links before the heavy-lifter LLM ever sees them:

Because the final LLM only looks at a slimmed-down, highly targeted context window, it can zero in on writing out the safe, correct procedure.

Use Case 2: Directing traffic across search domains

These days, search engines don't just do one thing. They handle product catalogs, technical docs, help desk tickets, and general web browsing all at once.

If someone searches "reset my MFA device," that needs to go straight to a security or support flow.

But if they type "best lightweight hiking shoes under $150," you need product filters, shopping links, and price comparisons.

Meanwhile, "containers vs virtual machines" is purely informational.

A classifier built like Jev can triage this traffic instantly:

From there, the engine knows exactly which index to hit, which ranking model to spin up, and how to format the screen. This is crucial because getting routing wrong gets expensive fast. Dumping a desperate support ticket into a standard web-search pipeline is just a terrible user experience, no matter how good the underlying index is.

Use Case 3: Knowing when to stop searching

AI agents usually have a bunch of tools and memory banks at their disposal. The hard part isn't teaching them how to search; it's teaching them when they've found enough.

If you don't give an agent a hard stopping rule, it'll just keep reading useless files, bloating its context window, and stalling the final output. Jev fixes this by looking at what the agent has found so far and deciding if it’s time to wrap up.

Take an infrastructure bot. A platform engineer asks, "Why did the deployment fail after the new ingress configuration was merged?"

The bot starts pulling pull requests, historical logs, and maybe a generic Kubernetes guide. After every pull, Jev can run a quick check:

• Is this doc actually related to the outage? → 0.93
• Do we have enough proof to explain the crash? → 0.88
• Should we keep searching? → 0.21

Once the evidence looks solid, the agent stops digging and hands the logs over to the generative model to write up a diagnosis. It’s a beautifully simple division of labor: Jev handles the brakes, while the LLM handles the explanation.

Use Case 4: Web-scale sorting

When you're operating at web search, you usually aren't trying to write paragraphs of text. You're trying to make one consistent judgment call across millions of pages.

Think SEO audits. You could categorize pages by intent, flag duplicate content, or score overall usefulness.

Or detecting low-quality "slop." You can figure out if a page is cheap, repetitive filler that won't actually help a human reader. By attaching a confidence score, the system can automatically ban the obvious trash and flag the borderline stuff for a human reviewer.

The playbook is identical across the board: churn through millions of items fast, and save your expensive reasoning models for the stuff that actually requires deep thought.

A stripped-down architecture

Here's a rough look at how you might actually wire this up:

Obviously, the real-world API would look a bit different depending on how Jev is deployed, but the blueprint holds up: make your cheap, fast choices first, and spend your generative compute budget where it actually counts.

What this means for web search

If this kind of architecture catches on, web search is going to get a lot more modular.

Instead of leaning on one monolithic model to do absolutely everything, search engines could stack specialized layers. You'd have one layer figuring out user intent, another picking the best data source, a third filtering out SEO spam, and a fourth scoring relevance. Only at the very end would a generative model step in to synthesize the final answer.

Not only does this make the whole process faster and cheaper, but it also totally shifts how we evaluate AI. Instead of just asking, "Did that final paragraph sound smart?", engineers can debug the pipeline step-by-step:

• Did it route right?
• Did it keep the useful docs?
• Did it ditch the junk?
• Did it stop searching at the right time?

That kind of transparency is infinitely easier to troubleshoot than a massive, opaque prompt chain.

Where Jev falls short

A decision model isn't a magic bullet. You wouldn't use Jev for drafting long essays, writing Python scripts, or doing complex math. If you need a nuanced narrative that weaves together a dozen sources, you absolutely still need a generative LLM.

It can also be confidently wrong, especially when it runs into weird edge cases. You have to treat its high probability scores as strong hints, not absolute facts. Plus, if you're feeding it unverified web text, you're always risking prompt injection. The system needs to treat those inputs as data to grade—never as instructions to execute.

To keep things safe, you have to calibrate those confidence scores, set strict thresholds, and keep authorization layers completely separate from the model's output.

TLDR: split up the work

The coolest part about Jev isn't just that it's fast. It's the whole philosophy of separating decision-making from content generation.

Right now, the industry trend is to force one generative model to do the whole song and dance:

classify → retrieve → filter → reason → write

A much smarter, leaner pipeline looks like this:

classify → retrieve → score → filter → stop → reason → write

Those first few steps are repetitive and structured. They scream out for a fast, predictable model. The last few steps are messy and require a strong grasp of language, which is exactly where generative models shine.

Ultimately, Jev is a high-speed decision layer built to clear the runway so your heavy-duty models can do what they do best. For search and RAG ecosystems, that means tighter context windows, fewer hallucinations, and much cheaper inference bills.

The future probably isn't one god-model doing everything—it's a tight crew of fast specialists teeing up the final shot.