What would a tiny, Jev-like judge look like? We built one that decides in about 2 ms

## Why Jev caught our eye
Half a second late, a near-perfect script hit nothing. That is the problem this note is about.

TypeSafe describes Jev as "a frontier-intelligence function call: unstructured state in, typed probabilistic decisions out." It is built for the places where software must "classify, route, score, extract, or branch where hand-written logic is too brittle."

We read the attention it got as a signal. Agents are moving into real work. In a survey of 1,340 respondents who build agents, 57% already run them in production. Real work means many small decisions, made fast, all day. Jev gave that need a clear name.

So we asked: what would a tiny judge look like, built for one narrow domain?

## The problem: gates are sure, but stiff
Most agent pipelines end in a fixed gate. It is a rule, a script check or a person who signs off. A gate gives the same answer to the same result, and that is exactly what you want before a step that cannot be undone.

But a gate only knows the cases it was written for. When the real question is "how likely?", a fixed rule either blocks good work or lets bad work through.

## The idea: a fast judge before the gate
We put a small, fast judge in front of the gate. It sees every case first and sorts it:
- Confident and low-cost: straight to the gate.
- Unsure or costly: to a person.
- A small random sample of the confident ones: to a person as well, so we can check that trust.

The gate and the person stay. The judge decides where their attention goes.

We call ours SimThink D. It is a hybrid design: a small local language model reads the task once, and small neural networks make the fast decisions. It speaks the same kind of contract as Jev. A state goes in; a typed choice with probabilities and a confidence comes out. Inside, it is simplified for one domain.

## What we saw
We tested it where time is very short: a fast shooting game (ViZDoom), where every decision must finish within one game step, 28.6 milliseconds. The task never changes there, so only the network part runs.

Speed matters most. When we delayed a strong hand-written script, its hits fell from 99.5% to 87.8% at just 30 ms late, and to zero at half a second.

Language models asked to make every decision alone could not keep up with the clock.

What we did not do: we did not beat the script, and true real-time play, without the game waiting, is our next problem.

What we did: our judge typically decides in about 2 ms, with no tokens and no outside calls. Over 58 different games, 98.2% of its shots hit, close to the script's 99.5%. It keeps that level of play inside the time budget.

## Where it sits: the gate layer
In SimThink Abyss, our design layer, an agent's work is laid out in rows: people, gates, work and records. SimThink D sits in the gate row, right before the central gate. Its threshold is one setting with a named owner, so tuning it is a design change.

## The other side
- A game is not a business. In business, results come late and people disagree on them.
- Confidence can mislead. A model can be very sure and still wrong.
- Ownership costs. A small model still needs data, watching and updates.

So the gate and the person stay, and the threshold has an owner.

## Open question
In your work, which decisions are narrow and frequent enough to deserve their own small judge, and who would own its threshold?