What is Jev Engineering?

Jev engineering is the discipline of decomposing a task into closed questions a decision model can answer well. It's the skill that separates the builds in this directory that work from the ones that flip coins, and after cataloging 400+ of them, we can say it plainly: the model is rarely the difference. The questions are.

The name is new; the craft borrows from older ones. Writing acceptance criteria, designing survey instruments, drafting policy that a new hire could apply consistently: jev engineering is that lineage, pointed at a model that only rules.

Jev engineering vs prompt engineering

Prompt engineering persuades a generalist: you shape instructions, examples, and context so a chat model produces the output you want, and the output is prose you then trust or parse. Jev engineering specifies a judgment: you design the question, its answer set, and its edge cases, and the model's only freedom is which allowed answer to pick.

The practical difference shows up in where effort goes. Prompt engineers iterate on phrasing and context; jev engineers iterate on decomposition and boundaries. "Make the model understand" versus "make the question undeniable." You don't prompt Jev into being smarter; you question it into being useful.

The five principles

1. Operational questions only. The test: could a new hire answer this consistently on day one? "Is this urgent?" fails; "does this email state that a customer-facing system is currently down?" passes. Vague in, coin flip out, on any model ever built.

2. Decompose ruthlessly. One judgment per question. A "good lead" is really three questions (problem fit, budget language, authority); a post's quality is, per one cataloged build, 61 separate questions. At reported verdict prices, decomposition is free, and every answer becomes independently debuggable.

3. Close the answer set, honestly. Fixed labels, plus a legal "unclear." Deny the escape hatch and the model launders uncertainty into your categories silently, which is worse than not knowing.

4. Legislate the edges inside the question. Most wrong verdicts live at boundaries you never defined. "Does the review mention a defect? (Cosmetic damage counts; disliking the color does not.)" Two parentheses, half the ambiguity gone.

5. Calibrate, then version. Run 50-100 cases you already know the answers to; measure agreement; fix the questions before blaming the model. Then version question text like an API, because a reworded question is a new instrument and your metrics fork silently otherwise.

A worked example

Task: route inbound support email. The un-engineered version asks "categorize this email" and gets vibes. The engineered version asks a battery: Which of [billing, bug, how-to, sales, other] best matches the sender's request? Does the sender state that something is currently broken or blocked (yes / no / unclear)? Does the message contain cancellation or refund language (yes / no)? Could a documentation link fully resolve this without human action (yes / no / unclear)? Four rulings, each checkable, each wired to a routing action, and the reported economics (500 emails for 3.5 cents) make the battery cost a rounding error. That's the whole discipline in miniature.

The architecture principle: cascade what you can't specify

Some cases resist even good questions: sarcasm, deep context, genuine ambiguity. Jev engineering's answer isn't a cleverer question; it's routing. Confidence gates send the hard slice to a bigger model or a human, per the cascade pattern; the fraud build's reported 96/100 at ~$0.07 is what that looks like executed. Knowing what not to ask the fast model is as much the craft as asking well.

Go deeper: how to write judge questions (the failure modes and probes), the getting-started tutorial (your first calibrated pipeline), and TypeSafe's official material at docs.typesafe.ai for the mechanics of actually calling the model.

Frequently asked questions

What is jev engineering in one sentence?

The craft of turning tasks into closed, operational questions (with legislated edge cases and honest escape hatches) that a decision model can answer consistently, then calibrating and versioning those questions like production code.

How is jev engineering different from prompt engineering?

Prompting shapes a generalist's open-ended output; jev engineering specifies a judgment's question, answer set, and boundaries. Iteration targets decomposition and edges, not phrasing and persuasion.

Do I need ML expertise to do it?

No. The prerequisite skill is writing criteria a stranger could apply consistently, closer to good spec-writing than to machine learning. The craft guide teaches the patterns.

What's the most common jev engineering mistake?

Vague questions, followed closely by skipping calibration: trusting verdicts before scoring them against 50-100 known cases. Both are fixed in an afternoon and both cause most "the model is inaccurate" reports we can trace.

Where does jev engineering not help?

Tasks needing generation or open-ended reasoning: no question design makes a decision model write or deduce, per the limitations. The craft includes recognizing those and routing them elsewhere.