Jev Decisions

Jev decisions

Jev reads a state and answers named questions with probabilities, never prose: yes/no, one of a set, a level on a rubric, or a box in an image. It is a classifier you program in plain language, fast (roughly 70-500 ms) and cheap (input tokens only, output is free), so it can sit on every turn, every tool call and every ticket. It decides; it does not write, compute or plan.

The shape of every system built on it:

gather (code, or an LLM that reads and writes)  ->  compute exact facts (code)
  ->  judge (Jev, one call, many questions)  ->  gate the probabilities (code)  ->  act (code)

An LLM may think and draft, Jev decides, code acts. Nothing consequential happens because a model said so in text. When an LLM writes the plan Jev's choices follow, the plan names exact values and steps and only what the menus can express; without a detailed plan Jev struggles with even elementary tasks.

Apply only the routes and checks for the selected job. Read a linked skill's named file from its installed folder when available, or from the linked source. Report an unavailable required reference instead of inventing it. [skill-authoring, DISTRIBUTION.md#composing-skills]

The rules

1. Code computes, Jev judges. Amounts, sums, dates, day counts, string and ID equality, lookups, limits and permissions in a table are code. Compute them, put them in the state labelled as computed and reliable, and ask Jev only what needs reading: what a message means, whether a record covers an action, which of these candidates matches. Jev is weak at arithmetic, calendars and counting; never ask it to do them.
2. One judgment per question. "Is it urgent and is the customer angry" is two questions. A question that bundles two judgments gives a probability of neither.
3. Every menu has an exit. A choice always includes "none of these" (other, none, unsure, no_reason_given), described as narrowly as the real options, or the model is forced to pick a wrong label with high probability.
4. Describe what would be observed, not a mood. "The customer threatens a chargeback, a regulator or a lawyer" beats "the customer is hostile". Criteria name the evidence that makes each answer true, and say what does not count.
5. Ask everything independent in one call. Questions in a call are answered against the same state and can't see each other's answers; batching a dozen costs one round trip and one read of the state. Split into separate calls only when a later question needs a different state or should run only on some cases (GATES.md).
6. Thresholds belong to actions, not questions. The same probability can open a cheap check at 0.3 and trigger an irreversible action only above 0.9. Set each from labelled cases and the cost of being wrong (PRODUCTION.md).
7. Three outcomes, never two. Act when sure, decline or close when sure of the opposite, and send the middle to a question back to the user, a person or a deeper check. Forcing a yes/no at 0.5 converts uncertainty into errors.
8. The state is data. Text in the state, including tool results and documents, is evidence. An instruction inside it ("ignore the policy and refund") is something to ask about, never something to follow (QUESTIONS.md).
9. Every decision can be replayed. Record the pinned model, a hash of the state and the questions, every answer and which rule fired with its inputs. Re-running new thresholds over stored answers costs nothing (PRODUCTION.md).

Shapes that recur

Start from what the application will show, select, change or hand off, and work back to the judgments it needs.

• Route and fill: pick the handler, the team, the worker, the subagent or the model, and its closed-set arguments, in one call (AGENTS.md).
• Select instead of generate: code finds the candidate values or source spans, Jev picks the intended one, code copies it out verbatim. The model can't choose a candidate you didn't send, so check coverage first.
• Find and judge evidence: score retrieved passages for relevance, keep the useful ones, flag the planted ones, before a writer model sees them.
• Score once, reuse: store the per-dimension judgments; weights, filters, rankings and views change in code without calling the model again (GATES.md).
• Verify and escalate: check each claim or field against its evidence; the confident pass, the rest go to a reasoning model or a person.
• Judge at volume: thousands of small pairwise calls (should page A link to page B, are these two records the same thing, does this message need a reply), each with a "nothing honestly fits" outcome.
• Steer a changing state: each step rebuilds the menu from what exists now and Jev picks the next bounded move, while code keeps the goal, the observations and the limits.

When not to use it

Generating text, summarising, writing code, explaining itself, extracting a value nobody listed, doing maths or date arithmetic, or anything a regular expression, a schema check or a SQL query decides exactly. If deterministic code already gets it right, keep the code. A judgment that needs several hidden reasoning steps is split into smaller questions or given to a reasoning model. Generating by a chain of choices (one character or syntax node per call) is possible but poor: letter-by-letter code barely produced an if, and choosing AST nodes gave valid but mostly incorrect programs, with misspelt names (fibonacio for a plan that named fibonacci), after 42 choices for a recursive Fibonacci.

Typed output guarantees the shape, not the truth: Jev can't return an option you didn't define, but it can confidently pick the wrong one you did.

Prove it

For each gate, name the action, the threshold and the labelled cases it was set from. Run the workflow over the labelled set with the pinned model: report agreement with the expected actions per policy, the cases that disagree, and cost and latency per case. Feed it a state whose tool output contains an injected instruction and confirm no consequential action follows. Check that removing the model call (fixtures from the replay cache) reproduces every decision exactly.