Start with one decision and one example input. The goal of a first integration is to learn whether the question fits your workflow, not to connect every action in the application at once.
The examples in this directory are source-reviewed and checked against TypeSafe SDK types. They are not live-model benchmarks. Running them yourself requires a provider account, an API key, and any applicable API charges.
Pick a decision you can inspect
Choose a task with a short input and an outcome a person can judge. Routing a support request is a manageable starting point because you can inspect the message, possible destinations, and selected label together.
Download its TypeScript example. Read the question and criteria before running it. The input is illustrative; replace it with non-sensitive examples from the type of work you intend to handle.
Keep the source and license notices when reusing extracted code.
Set up the server-side example
Our downloadable examples use Node.js 24 and TypeSafe JavaScript SDK 0.6.0. Install that SDK version, set TYPESAFE_API_KEY in your environment, and run the downloaded decision.ts file with Node.js.
The official SDK guide describes the current client interface. Keep the key on your server or local development machine. The public directory itself never needs your key and does not run inference in the browser.
If setup fails, first check the runtime, installed package version, credentials, and provider response. Avoid editing the question to solve an authentication problem.
Inspect the raw answer before acting
Read the label, probabilities, and confidence for a Choice question. For Noul, read the probability of yes. For Score, read the rubric and expected score.
The examples log a decision or recommendation. Replace that logging with a real handler only after you understand the failure cases and any permissions required by the action.
A route to a billing handler should not immediately authorize a refund. A suggestion to trim context should not immediately delete the only copy of a transcript.
Replace the demo policy
Some examples contain a numeric threshold so the control flow is concrete. That value is not evidence of the right cutoff for your application.
Try clear positives, clear negatives, incomplete requests, and out-of-scope inputs. Record the expected outcome before reading the model answer. Compare incorrect actions and fallback frequency, then adjust the question or policy using a separate development set.
The urgency example is useful when you want to collect a signal before choosing a cutoff.
Pin what you evaluate
The examples use jev-latest for convenient exploration. Before a repeatable evaluation, select an available explicit model identifier from the model documentation. Save it alongside the question version, SDK version, labeled inputs, and application policy.
Re-run that set when one of those parts changes. Track total workflow latency and cost, including retries and fallback work, rather than assuming the first model call tells the whole story.
Your first successful integration is a small, inspectable loop: input, question, answer, policy, and a measured decision about what to automate next.
Sources & review
Reviewed against the following TypeSafe documentation on Sep 18, 2026. Model behavior and API details can change; check the current docs before shipping.
Found a mistake? Suggest a correction on GitHub.