Module 1 · 7 min read

Where Jev belongs in your product

By the end of this module you will have a map of your own product with the places where a judgment on unstructured data is unavoidable. Those places, and only those, get a Jev call.

Three ways to build software with a model in it

Traditional software. A decision tree made of reliable primitives. It breaks the moment an input is free text: a support message, a page, a spoken sentence.

An agent. An LLM reads instructions and picks its next step in a loop. It handles free text well and goes off the rails in a way that is hard to bound, because every loop iteration is another chance to misread.

AI-powered software. Code owns the workflow, the rules, the side effects. The model appears only where the system needs common sense over unstructured data, and each of those appearances is atomic and constrained. This is what Jev is built for.

The rule that follows, and that every later module applies:

Keep control flow, arithmetic, dates, counts and side effects in code. Give Jev one narrow judgment at a time, with only the context it needs, and combine the answers in code.

What this buys you

Structured. An answer cannot fall outside the options you supplied. Your code never recovers a value from prose.
Parallel. Every question in a request is evaluated on its own. One answer never leaks into another as hidden context. Add a question, latency barely moves.
Comparable. Probabilities sort, threshold and compare. A score of 1.6 on one ticket and 0.4 on another means something your code can act on.
Calibrated. Across many predictions, answers given 90 percent probability are right about 90 percent of the time. Calibration is a property of groups, never a guarantee on one answer, and that is exactly why confidence exists.
Fast and cheap enough for the request path. A decision inside a page load, a keystroke, a game tick.

Twelve places a typed decision pays for itself

Each of these is a full module or a playbook later. The pattern is the same everywhere: a state object, a handful of atomic questions, thresholds in code.

#	Place	State	Questions	Code acts on
1	Inbound form or email	message, sender	intent (Choice), urgent, budget, spam signals (Nouls)	route to sales, support, trash
2	Support triage	ticket, plan, open orders	department, refund requested, frustration, severity	queue, priority, escalation
3	Lead qualification	message, ICP definition	ICP fit (Score), intent, pain named, buying stage	composite score, SDR or nurture
4	LLM guardrail	user message or model reply	jailbreak, harmful, medical, self-harm (Nouls), severity (Score)	pass, review, block, support
5	Agent tool-call gate	command, arguments, last user request	destructive, exfiltration, beyond scope (Nouls), impact (Score)	run, confirm, refuse
6	Code review	diff hunk, tests	risk categories (Nouls), severity, test gap	assign reviewer, comment, block merge
7	Search and RAG	query, candidate passage	relevant, supports answer, contradicts, injection	rerank, keep, drop
8	Extraction	document, regex candidates	which candidate is the invoice total (Choice over spans)	copy the span verbatim
9	Classification into a taxonomy	item, children of current node	which branch (Choice per level)	walk the tree, beam on probabilities
10	Content moderation	post, policy	threat, spam, harassment (Choices with an uncertain outcome)	remove, review, keep
11	Voice or UI command	sentence, screen description	which function, which argument, was it stated (Choice, Noul)	call the function, ask to confirm
12	Model routing	request	intent (Choice), complexity (Score)	deterministic code, cheap model, strong model, human

If your product has none of these, it has a variant: any place where a rule says if (text looks like X) and the looks like is implemented with a regex that keeps growing.

Drawing your own map

Take one flow in your product. Write it as steps. For each step, ask: is this deterministic (dates, sums, lookups, permissions)? Then it stays in code. Is it a judgment on text a person would make in a second? Then it is a candidate.

Example, a contact form:

text

1. receive submission                       code
2. validate email, honeypot, rate limit     code
3. is it spam? which intent? urgent?        judgment  → Jev
4. look up the sender in the CRM           code
5. route to the right inbox                 code, using step 3
6. draft a reply                            LLM, only if step 5 says "sales" and confidence is high

Step 3 becomes one request with four to eight questions. Steps 5 and 6 read the answers. Nothing else changes.

The shape of every request in this course

json

{
  "state": { "message": "…", "sender": { "email": "…" }, "policy": "…" },
  "model": "jev-latest",
  "questions": {
    "intent": { "type": "choice", "instructions": "…", "criteria": { "…": "…" } },
    "urgent": { "type": "noul", "instructions": "…" },
    "frustration": { "type": "score", "instructions": "…", "criteria": ["…", "…", "…"] }
  }
}

Two habits from day one:

Name fields and point at them. A state with named keys, and instructions that reference them in backticks: Does `message` ask for a refund?. Jev is trained to follow those paths.
Ask everything at once. Every question your code might need goes in the same request, including ones that only matter for some inputs. The code ignores what does not apply. This is speculative fan-out, and it is why a Jev integration is usually one request per event.

What Jev will refuse to be good at

Say it early so nobody designs around it: Jev cannot count, do arithmetic, compare dates, follow double negatives, or generate text. It reads literally. A large state full of unrelated detail makes it worse. Module 4 has one real example of each and the fix.

Paste into your coding agent

The prompt below turns this module into a map of your own codebase. It works with the official TypeSafe skill installed (npx skills add typesafe-ai/skills --skill typesafe-ai, or the Claude Code plugin).

Paste into your coding agent

Use the TypeSafe skill. Explore this repository and list every place where code makes a judgment on free text or unstructured data: regex heuristics, keyword lists, hand-written classifiers, LLM calls whose output is parsed into a label or a boolean. For each, write: the file and line, what the judgment is, what state it would need (only the fields that matter), and whether it is a Choice, a Score or a Noul. Rank them by how often the code path runs times how costly a wrong answer is. Do not change code yet.

Checklist

You can name the three architectures and say which one Jev is designed for.
You have a list of two to five judgments in your own product, each with its state and its question type.
You know the two habits: named fields with backtick paths, and one request with every question.

Next: how to write a question that answers the way you meant.