jevJev is TypeSafe’s structured decision model for applications that need a small, inspectable choice. Instead of asking a general-purpose model to write a long answer, you describe the state of a task, ask one decision question, and provide the labels or ordered criteria that define an acceptable result. Jev can then classify a support request, score a candidate passage, or answer a yes/no proposition. That narrow contract makes the output easier to route, test, and explain to the rest of your application.
This homepage is an entry point for developers who want to build with the Jev AI API without treating a demo as a benchmark. The guides explain the request shape, the local Python examples show how to validate returned values, and the integration notes connect the same decision pattern to browser actions, retrieval, moderation, and agent workflows. Start with one bounded task, keep the expected answer visible, and only then decide whether Jev is the right component for a larger system.
What Jev is good at
Jev is a useful fit when the application already knows what kind of decision it needs. A Choice question can map an incoming message to a finite set of handlers such as shipping, billing, or review. A Score question can order candidates against a rubric, which is useful for reranking or triage. A Noul question can test a proposition when the product needs a clear yes or no. These primitives give the caller a stable place to put instructions and criteria instead of hiding the decision inside a paragraph of generated prose.
The useful boundary is deliberate. Jev does not replace application code, a database, a policy engine, or human review. Your code still decides what state to send, how to handle an uncertain answer, whether to retry, and what action is safe. The examples on this site use supplied answers and synthetic records where stated. Read each evidence note before interpreting a result, especially when a community project reports a speed, accuracy, or success rate that we have not reproduced.
How a Jev request fits into an application
- Describe the state. Give Jev the smallest useful snapshot: a customer message, a candidate passage, a browser observation, or a moderation item. Remove unrelated data so the decision is about the task you intend to measure.
- Ask one question. Write an instruction that names the decision, not the implementation. “Choose a support team” is easier to test than “figure out what to do with this message.” Keep the question stable while you compare inputs.
- Define the answer space. Choice uses named categories, Score uses ordered criteria, and Noul tests a proposition. Labels should be distinct, useful to the next function, and complete enough to include a review or unknown path when ambiguity matters.
- Inspect and route. Validate the returned shape before using it. Log the input, the selected label or score, and the fallback path during development. A Jev decision should narrow the next step; it should not silently trigger an irreversible action.
Build a reliable first experiment
Pick a task with a visible success condition. For example, collect a small set of support messages and write the expected handler for each one. Run the same examples through the Request Builder or the Python lab, then compare the predicted label with the expected label in the Evaluation Bench. Keep an error list rather than changing the prompt after every individual miss. You want to learn whether the categories are understandable, whether the state contains enough context, and whether a review category is needed.
When the first experiment is useful, add cases that are close to the boundary: short messages, conflicting clues, missing fields, and examples that belong in review. Measure those cases separately from the easy examples. This is where Jev can become a dependable application component, because the team can see exactly which decision is being made and which inputs still need policy or human judgment.
Jev, a text model, or rules?
Use deterministic rules when the condition is explicit and must always behave the same way. Use a traditional text model when you need a longer explanation, transformation, or open-ended draft. Use Jev when the application needs a compact decision over messy language and the possible outcomes can be described in advance. Many production systems combine them: a text model extracts or writes, Jev routes or checks, and ordinary code enforces permissions, limits, and side effects.
There is no benefit in adding Jev simply because a page contains AI. The right question is whether a structured decision makes your system easier to test and operate. If the answer space is not stable, start by clarifying the product contract. If the decision is safety-critical, keep a conservative fallback and human review even when the Jev response looks confident.
Questions developers ask about Jev
Does Fieldnotes call the live Jev API? The Request Builder and Evaluation Bench do not. They prepare requests and inspect records locally. The separate Jev Workbench can run a saved Decision Pack against Jev live; the provider key stays on its server, and no downstream tool action is executed.
Where should I start? Read the Jev quickstart, run the tool-routing example, and then use the Evaluation Bench with a small labeled set. When the categories and review rule are clear, move the same bounded task into the Workbench for a versioned mock or live run.
Can Jev make the final decision for my product? Treat Jev as one decision step. Your application owns validation, retries, authorization, logging, and the final side effect. Include an explicit review path when the cost of a wrong answer is higher than the cost of asking a person.
Where are the source boundaries? The official reading list links to TypeSafe’s documentation and published demonstrations. Community examples are labeled with their original repositories and limitations. We do not turn a recorded demo into a general performance claim.
Use this guide as a starting contract. Choose one task, write down the expected outcomes, run a small local evaluation, and only then connect Jev to the surrounding stack. That keeps the experiment focused while leaving room to change the implementation as the evidence improves.