Typesafe AI

Build with TypeSafe

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.

Read the live docs

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 with the documentation index to discover relevant pages and cookbooks. Use targeted reads rather than loading the entire site.
• Mintlify serves Markdown by appending .md to a page path, for example how to build with TypeSafe. Follow links from the index; convert extensionless documentation page links to .md when useful. Resolve relative links against https://docs.typesafe.ai.
• Before writing an integration, read the current API or chosen SDK page and the question guidance relevant to the design. For a new workflow, also inspect the closest cookbook: it often shows a better decomposition than a generic classifier.
• If the index is unavailable, use the direct links below or the site's navigation. If Markdown fetching fails, try the normal page. If live access is unavailable, use available local docs or installed SDK types, state that limitation, and avoid inventing version-dependent details.

Find the useful shape

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.

• Route and fill known arguments. A request can select a handler and its typed parameters. Ask useful branch-specific questions up front and consume only the relevant answers. Explore function calling and speculative fan-out.
• Select instead of generate. Find candidate values or source spans in code, use a judgment to select the intended one, then copy or normalize it. Code can also assemble source text into a formatted document or reading guide. Explore value extraction and structure recovery.
• Find and judge evidence. Retrieve candidates, compare their relevance to a query, and select useful context. Explore reranking and hierarchical classification.
• Turn judgments into reusable data. Score dimensions once, then let code or user controls change weights, thresholds, rankings, and views. With labeled outcomes, those signals can become classical ML features. Explore composite scoring and feature discovery.
• Verify and escalate. Check specific claims or fields against their evidence; send uncertain or failing cases to a person or reasoning model. Explore citation checks and extraction cascades.
• Respond to changing state. Code can retain goals and observations while fresh judgments guide the next bounded step. Keep inferred state distinct from observed facts, and check freshness before applying a result to a changed situation.

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.