Build with TypeSafe

Jev contributes small units of AI intelligence to ordinary software: application state and typed questions go in; answers and probabilities come out. Code owns control flow and actions. A generative model can write text or reason when needed.

Read the relevant guidance

The live documentation index is the source of truth for API contracts, SDKs, models, limits, and cookbooks. Follow its links; append .md for Markdown, or try the normal page if Markdown fetching fails. Before integrating, read the current API, chosen SDK, and closest cookbook. Preserve the existing stack and transport boundary. If live access fails, inspect installed types and local documentation and state which details remain unverified.

Read only the reference needed for the task:

• Question design: preparing state, decomposing judgments, choosing primitives, and fixing ambiguous instructions or criteria.
• Composition and evaluation: batching, extraction, retrieval, routing, confidence, regression cases, and agent economics.

Find the useful shape

Start with the desired application behavior. Identify where semantic understanding helps, and leave exact lookups, arithmetic, permission checks, and execution in code. For a concrete request, choose a suitable pattern and build. For exploration, offer a few possibilities suited to the user's goal. These patterns are starting points:

Design the judgments

Give each question the evidence and relationships it needs, preferably in named JSON fields. Put the judgment in instructions and define answers in criteria. Question IDs are not sent to the model: instructions must carry the full meaning. Use explicit paths such as ticket.messages[0].text when they clarify the target. Strings suit simple questions; objects and arrays suit definitions and examples.

Ask one coherent semantic judgment per question. Split independently useful dimensions; preserve relationships required to interpret meaning. Atomic does not mean context-free fact extraction: bounded action selection and contextual intent are valid. Include a no-match outcome when appropriate and check candidate coverage. Describe Score levels concretely so each stands on its own.

Compose and verify

Ask independent questions over the same state together, including useful speculative branches. They cannot see one another's answers; state conditional premises explicitly and let code consume only applicable answers. Use another request when an earlier answer changes the evidence, state, or candidates. Measure token cost and latency.

Keep probabilities and raw judgments reusable. Choice/Score confidence summarizes the answer distribution; it is not the probability that the workflow is correct. Thresholds belong to each question and action and must be evaluated on representative data. A weighted preference score is not a substitute for an explicit veto condition. Typed output guarantees shape, not truth or authorization.

For failures, inspect the exact state, questions, candidates, distributions, policy, and observed outcome. Separate missing evidence, question ambiguity, model errors, composition errors, and service failures. Add regression cases for demonstrated failures. Verify final application behavior as well as individual judgments. Pin an evaluated model version when thresholds matter and log the resolved model. Treat cookbook thresholds and performance numbers as dated examples. Keep API credentials server-side in web applications.