TypeSafe makes units of AI intelligence usable like programming primitives: small judgments you can compose into larger capabilities. Its System One models return fast, focused judgments that software can consume directly. Jev is TypeSafe's flagship and first System One model. It understands natural language and returns typed answers and probabilities rather than generating text or reasoning explanations. Code owns the workflow; the model supplies programmable common sense where ordinary code needs semantic understanding.

The live TypeSafe docs are the source of truth. Read them as part of the task. This skill gives direction; the docs carry current concepts, prompting guidance, API contracts, SDK usage, models, limits, and worked examples.

Start from the behavior the user wants: what will the application show, select, change, or hand off? Work backward to the judgments it needs. Keep known rules, calculations, exact lookups, and execution in code. Preserve the user's chosen stack and scope; add TypeSafe where semantic understanding helps.

When brainstorming or choosing an architecture, consider more than classification. The patterns below are starting points: combine primitives around the user's goal, including ideas that do not fit an established recipe.

For open-ended requests, offer the few directions that best serve the user's goal and recommend a starting point. For a concrete request, choose the relevant pattern and build; a brainstorm is not a mandatory detour.

Choose by what the answer means, then read the relevant primitive page:

Give each question enough relevant state to answer: source text, identities, relationships, policies, and current facts. Prefer named JSON fields when context has several parts. Put the judgment in instructions and define its possible answers in criteria. Question IDs are for code and are not sent to the model; include complete meaning in the question. Reference nested state with backticked paths such as .

Ask one narrow, coherent judgment per question. Split independently useful dimensions, without destroying the relationship being judged. A bounded action selection or contextual interpretation is valid; atomic does not mean literal fact extraction or a one-sentence limit. Strings work for simple questions. Use structured objects or arrays when definitions, contrasts, exclusions, or examples clarify instructions or criteria. Score levels must describe concrete situations and stand on their own.

Keep the needed answers available. Include a no-match outcome when nothing may fit; use a separate presence judgment when it is independently useful. For source-value selection, check candidate coverage: the model cannot choose an omitted value.

Ask independent questions over the same state together, including useful speculative questions. They run in parallel and cannot see one another's answers. State each speculative premise explicitly; code consumes the applicable answers. A second request is warranted when an earlier answer is needed to fetch evidence, construct new state, or determine the next options. Extra questions still use tokens; measure actual request budgets, cost, and end-to-end latency.

Use probabilities and confidence to guide behavior, with thresholds evaluated on the user's data and consequences. Choice/Score confidence summarizes distribution concentration, not overall workflow correctness or permission to act. A Noul near 0.5 means similar probability for yes and no, not medium intensity. Several acceptable alternatives can also spread probability; low confidence need not invalidate a harmless preference choice. Ignore uncertainty on unused branches.

Keep policy explicit and raw judgments reusable. Weighted scores suit compensating preferences; an “any serious violation” rule needs separate conditions. Changing a weight or display filter need not rerun inference when evidence and question meanings are unchanged. Typed output guarantees the interface, not truth. System One models are trained for calibrated decisions; validate their performance in the target domain.

Test representative cases and the resulting application behavior. For failures, inspect the exact state, questions, candidates, answers, composition, and observed outcome. Separate missing evidence, model errors, code errors, and service failures. Treat cookbook thresholds and demo results as examples to evaluate, not universal rules or permanent model limitations. Keep API credentials server-side in web apps.