Find the decision before choosing the model
A useful starting task has a bounded question, enough evidence to answer it, and a clear next step. For a customer message, those might be the requested service, the relevant account record, and a suggested queue. For a document, they might be a reader’s query, the text, and a location to inspect.
The workflows here are design suggestions unless explicitly labeled as official examples or community reports. We have made live calls to check this website’s functionality, but have not independently reproduced the third-party cases or published quality or performance benchmarks. A working demo and an individual model result do not establish accuracy for these applications.
Community cases: how builders use Jev
These public reports show specific decisions that builders have tested. Each summary links to its author. Inclusion does not imply endorsement by TypeSafe or the featured teams.
Vercel: review commands before automatic execution
Author-reported experiment · Not reproduced by this website
Guillermo Rauch shared Vercel’s evaluation of Jev for the safety reviewer in fx auto mode. Commands are the items being checked; the judgment helps decide whether a command is suitable for automatic execution. The post describes a candidate change to the reviewer, not a confirmed Jev rollout. It does not provide the complete review policy. A model judgment alone is not an execution permission.
Every: check writing against explicit questions
Author-reported experiment · Not reproduced by this website
Mike Taylor at Every tested article text against questions about writing patterns. Jev returned judgments for the checks, helping the writer decide which articles and checks need another review. This was an experiment in reviewing prose, not an established way to prove who wrote it. The author reported missed issues; the writer still needs to inspect the text and decide what to change.
Good Start Labs: check answers against a rubric
Author-reported experiment · Not reproduced by this website
Alex Duffy described early-access experiments grading game tasks and financial-research answers against supplied criteria. The inputs include the answer and the rubric; the judgments indicate whether particular checks pass. The team uses disagreements to guide further review. This is a reported evaluation, not proof that a model verdict is correct or that an autonomous grading product has been deployed.
Try a writing check in the official Playground
Original fictional teaching example; no recorded model results. This is a separate exercise inspired by the writing-review use case, not Every’s prompt or a reproduction of its experiment. Orbit Notes is fictional. The English input and questions stay identical across languages for copying.
An external TypeSafe page. Sign in with your own account and the required access; joining the waitlist does not itself grant access.
-
Paste the sample below into the state field.
-
Add three Noul questions using the names and instructions below. The official quickstart explains how to enter a state and questions.
-
Run the request in the official Playground. Read each returned probability alongside its question, then edit the sample and run it again if useful.
Fictional input
Explore the technical details
Orbit Notes saves your drafts locally.
Your drafts are stored on your device.
Click Export to download a copy.Questions to enter
Explore the technical details
repetition (Noul)
Does the text repeat a claim without adding new information?
clear_action (Noul)
Does the text explain what happens when the reader clicks Export?
guaranteed_safety (Noul)
Does the text claim that a draft can never be lost?Inspect whether the first two sentences add different information, whether the Export action is explained, and whether the text promises that drafts cannot be lost. The questions are independent; their probabilities do not need to sum to one. Use the judgments as prompts for human review. This exercise supplies no expected scores or automatic decision threshold.
Four roles, four starting points
Developers: review a semantic rule
Try a narrowly written convention that ordinary linting misses: does a change introduce a user-facing error without explaining how to recover? Supply the relevant diff and the rule, and return a review signal. The official use-case map includes semantic code linting; this particular check is our illustrative proposal.
Keep the compiler, test suite, and exact lint rules. Let a reviewer inspect the flagged lines and decide whether the concern is valid. Begin with advisory comments so you can learn the cost of false alarms before making the check a merge requirement. This is a suggested integration, not an available PR bot supplied by this website.
Support teams: separate ownership from urgency
A frustrated customer may need billing rather than engineering. An apparently calm message may describe an urgent outage. Ask separately about the destination and time sensitivity, then apply a queue policy. The official quickstart provides the ticket example below.
Your application still has to retrieve account facts, deduplicate tickets, and enforce the rules for refunds or account changes. A classification does not confirm that a reported failure happened.
Search and RAG teams: choose evidence before writing
Retrieval-augmented generation (RAG) supplies retrieved material to a text generator. Jev can be evaluated between retrieval and generation. TypeSafe’s RAG passage cookbook checks relevance, usable evidence, contradictions, and attempted instructions separately, then uses code to include, flag, or exclude a passage.
Keep the source identifier with the judgment. Contradictory evidence may deserve a visible warning rather than silent deletion. Evaluate whether your filter removes the only passage needed to answer a difficult query. A generator is still responsible for the final wording; neither stage should override document access permissions.
Security teams: prioritize analyst attention
TypeSafe’s guardrails cookbook demonstrates checking incoming messages and generated replies, with probabilities for hazards and an ordered severity assessment. Code then applies the response policy.
For an initial integration, retain your existing detection path and compare the proposed review queue with analyst decisions. Track missed incidents and unnecessary escalations separately. A low model score should not grant a tool permission, disable an existing control, or establish that an attachment is harmless. See the adversarial-input limitations.
Complete example: find an answer in a document
1. Task and input
Search the cookbook’s GitHub Terms of Service text: 218 lines tagged with IDs, using jev-1.12. The cookbook and full script link the complete input and explain replay.
2. Questions
One request asks where (Choice over line IDs) and exists (Noul: does the document contain an answer?).
3. Published output excerpt
These are selected values, not a complete API response:
Explore the technical details
query: who owns the code I upload?
exists: 0.98
L052: 0.95The matched source line begins: L052 | You own Your Content.
4. Postprocessing
The cookbook sorts line probabilities and joins IDs back to source text. Its existence policy marks values at least 0.7 as answered, below 0.35 as absent, and the interval between them as partial. This example therefore points to L052 and passes the answer-existence check.
5. Limits and source
The thresholds and earlier model version belong to this example. Replay is not a new measurement. It demonstrates retrieval, not legal interpretation or accuracy on other documents. Original case and displayed output
Why use two signals?
Choice distributes probability over the supplied options, which together sum to one. A leading option is therefore a relative winner; it is not an independent guarantee that an appropriate option exists. TypeSafe documents a maximum of 255 Choice options. Choice semantics and limits
Our implementation advice is to preserve both the location and the existence judgment in a result record. Do not turn the top line into an unconditional answer. Show the source text for inspection, handle missing or partial evidence explicitly, and retain the document version so later edits do not silently change what an ID means.
When adapting this design, include documents with no answer in your review set. Also include answers spanning several lines and questions whose wording contains a false assumption. Those cases test the retrieval policy you actually need, beyond whether the first-ranked line looks plausible.
Complete example: triage a support ticket
Input, questions, and documented output
The sample customer describes a failed Stripe connection over three days, lost sales, and a need for urgent help. The request asks for a department, frustration level, and urgency. The message is paraphrased here.
| Question | Definition, summarized | Published result |
|---|---|---|
department — Choice |
Pick billing, technical, or sales | technical; probabilities: 0.159, 0.84, 0.001, respectively; confidence 0.596 |
frustration — Score |
Place tone on three levels from calm to very angry | Score 1.035 on a 0–2 scale; confidence 0.842 |
is_urgent — Noul |
Assess time sensitivity | 0.999 |
Source: quickstart request and response.
Turn the result into a proposal
The following is our explanatory code. Its thresholds are illustrative policy choices, not validated settings:
Explore the technical details
function proposeRoute(response) {
const department = response.answers.department;
const urgency = response.answers.is_urgent.noul;
return {
queue: department.confidence >= 0.7
? department.choice
: "manual-triage",
priority: urgency >= 0.9 ? "urgent" : "normal",
suggestedTeam: department.choice,
};
}For the published values, this function proposes urgent manual triage and suggests technical support. The leading department does not clear our chosen confidence threshold. No ticket is actually assigned by this example.
Probability and confidence are different fields. TypeSafe derives Choice and Score confidence from the distribution; Noul has no separate confidence field. Confidence documentation
Before connecting such a proposal to a ticketing system, validate the response, define how conflicts are resolved, and make failures observable. Evaluate wrong routes and missed urgent tickets separately. The sample does not establish the customer’s account state or resolve the integration problem.
Community report: exploring phishing-email triage
A Discord participant described an early Python SDK experiment on September 17, 2026, at 14:24–14:27 UTC, hoping to assist security operations and later connect to a SOAR workflow. They described encouraging early results and sensitivity to the wording and detail of criteria. Experiment introduction, follow-up observations
This is a community self-report. It does not establish detection accuracy, false-positive rates, speed, savings, deterministic behavior, or production integration. We have not reproduced it. No verified official response was observed in the captured exchange; the research covered selected discussions, not the complete community history. The links may require community access.
Pick one next step
Choose one decision with an inspectable outcome and a manageable review process. Start with getting access and sending a request, budget the path with the pricing guide, and read the limitations before connecting the output to automatic actions.
Sources & further reading
Official documentation and linked community reports support this guide. Community observations are attributed to their authors.
- Official line-by-line semantic search cookbook
- Official support-ticket quickstart
- TypeSafe use-case map
- Classifying RAG passages cookbook
- Guardrails for LLMs cookbook
- Choice outputs and options
- Confidence and probability
- Community phishing experiment: introduction
- Community phishing experiment: follow-up
- Vercel command-safety experiment: Guillermo Rauch
- Every writing-check experiment: Mike Taylor
- Good Start Labs rubric-check experiment: Alex Duffy
- Official TypeSafe Playground