Designing questions for Jev
"Jev engineering" is a community term, not TypeSafe's: it means designing the state you send Jev, the typed questions you ask about it, and the confidence thresholds your code acts on. TypeSafe's docs do not use the phrase, but they cover the practice in detail under state, primitives, confidence and patterns (How to build with TypeSafe).
Is "Jev engineering" an official term?
No. We searched TypeSafe's full documentation and its launch post and found no use of "Jev engineering". The nearest phrase is "Harness Engineering", a use-case card about using Jev inside an LLM harness for routing, retrieval and guardrails (Example use cases). That is a different idea. This guide uses TypeSafe's own wording and calls the practice designing questions. For the basics of the model, start with what is Jev.
Design the state
The state is the content Jev evaluates. It can be a string, a JSON object or an array of text, and the docs recommend an object for most requests so each part has a descriptive name (State). Keep the content in the state and the judgments in the questions.
- Include only the context the current questions need. The docs say this helps the model avoid distraction and "context rot" (How to build with TypeSafe).
- Don't rely on what the model already knows when you can supply current facts from your own data (How to build with TypeSafe).
- Point a question at one part of the state with a backticked path such as
support.tickets[0].message(Primitives).
Design the questions
TypeSafe's rule of thumb is "one snap judgment per question": something a knowledgeable person could decide in a second with the right context (Primitives). The how-to-build guide calls decomposing questions "probably the most important concept" (How to build with TypeSafe).
| Type | Use it when | Returns |
|---|---|---|
| Choice | The answer is one of a known, unordered set | choice, probabilities, confidence |
| Score | The answer sits on a spectrum you can describe level by level | score, probabilities, confidence |
| Noul | A clean yes/no where the probability itself is useful | noul (0 to 1) |
- Write the full question in
instructions. Question IDs are for your code and are not sent to the model (Primitives). - A Choice accepts up to 255 options. Give the full list and add an
otheroption when it might not cover every input (Choice). - Split a multi-factor judgment into one question per factor, then weight the answers in code (Primitives).
- Ask every question you might need in one request, including speculative ones. Questions run in parallel and independently, so extra ones add little time (Speculative fan-out). Make a second request only when your code needs the first answer to build it (Primitives).
Set thresholds on confidence
Choice and Score answers include confidence, a number computed from the probability distribution; flatter distributions mean lower confidence. Noul has no separate confidence, so you threshold the probability itself (Confidence, Primitives).
The docs suggest three ranges to start with: act automatically when confidence is high, confirm or flag for review in the middle, and route to a person or another system when it is low. Thresholds should scale with risk, so a destructive action needs a higher bar than a read-only one (Confidence, Confidence-gated routing). Start conservative, plot confidence against accuracy on your own data, and adjust (How to build with TypeSafe). If you tune thresholds against one model version, pin that version's ID (Models).
Compose answers with patterns
TypeSafe documents four patterns for combining answers in code (Patterns):
- Speculative fan-out: ask many questions at once and let code pick what matters.
- Confidence-gated routing: use confidence as a second axis for whether to act.
- Composite scoring: combine several atomic scores with weights you control.
- Intent routing: classify a request and send it to code, a specialist LLM or a person.
Worked examples are in how to use Jev and the guides and docs section. For why this differs from prompting a chat model, see Jev vs. LLMs.
Projects doing this
Questions
What is Jev engineering?
A community term for designing what you send Jev: the state, the typed questions and their criteria, and the confidence thresholds your code uses to act. TypeSafe's docs describe the same practice but do not use the phrase.
Is Jev engineering the same as prompt engineering?
It overlaps, but the output is different. Jev returns typed answers and probabilities, not text, so the work is mostly choosing question types, defining options and levels, splitting judgments, and setting thresholds in code.
How many questions should one Jev request contain?
As many as share the same state. TypeSafe recommends batching every question in one request, including speculative ones, because questions run in parallel and extra ones add little time.
What confidence threshold should I use?
TypeSafe gives no single number. Its docs suggest high, medium and low ranges, stricter bars for riskier actions, conservative starting values, and tuning on your own data.
Does Noul return a confidence value?
No. Noul returns one probability that the answer is yes. Values near 0.5 mean the model is uncertain, so threshold the probability itself.
More guides: What is Jev?Jev pricing and API costJev vs LLMs: when to use whichHow to use Jev: a quickstartJev and MCP: using Jev as a Model Context Protocol toolHow to use Jev with Claude CodeJev in an agentic harness: where it fits in an agent loopJev for orchestration: routing requests, models and skillsJev as a judge: evaluating LLM and agent outputsJev for SEO and GEOJev for ads and ad reviewJev for marketing and lead scoringIs there an open source Jev?Can you fine-tune Jev?What is RLCD?Jev statistics