Jev and System One, explained step by step

Text offset / decision

The document introductory page summarizes the problem in one sentence: the large language models are designed for produce text that humans read. As soon as you want a model to render a judgment that the code will consume ("is this ticket urgent?", "what service should treat it?"), you force a text generation system to exit a structured decision, then you re-spend the result to do something that the code may depend on.

Everyone has already written this kind of code: a prompt that begs the model to "respond only by a valid JSON", a regular expression to recover the value, a try/except for the day when the model adds a phrase of politeness. And even when the JSON is clean, one thing is missing: how safe the model is. A LLM can write "urgent" with the same aplomb, whether it is obvious or dice.

What Jev does instead

Jev is the flagship model of TypeSafe and the first model said System OneIt evaluates the questions typed against one state (the content to be judged) and returns structured results: no text generation, no parsing. The code receives typed values and probability distributions on which it can connect, sort, route. Choice and Score questions also refer to a "confidence", a number between 0 and 1 that the code uses to decide if it does, and how.

Three software architectures

Page How to build with TypeSafe Jev place in a three-box landscape. We must understand which Jev is aiming, because it is not not the agent's.

The name comes from Kahneman

Page System One explains: the name takes over the concept popularized by Daniel Kahneman in Thinking, Fast and Slow. System 1 is fast and intuitive; System 2 is slow and deliberate. Jev is firmly placed in the first: judgments rapid and targeted, the kind of thing that a competent person decides in a second when it is given the right context.

It is a design rule as well as a name. "Is this message urgent?" is a good question. "Analysing this message and determining the best course of action" is not one: it requires slow reasoning, and the documentation sees it as the signal that needs to be done. cut the task in small questions, then compose the answers in the code.

Like an LLM, a System One model includes natural language in the input. Unlike an LLM, it returns typed decisions and probabilities, not text. Two documented limits: Jev accepts only text (chains, JSON objects, text tables; neither image, audio, or video "for now"), and its main training language is English, with other languages being accepted with less precision.

Calibrated: what it means, and what it does not guarantee

The word comes back everywhere in the documentation: Jev is trained for calibrated decisions. Its probabilities are optimized against real results to reflect uncertainty. Specifically, on a large number of predictions of a well calibrated model:

• the outcomes to which it attributes a probability of 0.2 occur about 20% of the time;
• those to 0.8, about 80% of the time;
• those to 1.0100% of the time.

The documentation immediately adds the nuance that counts: these rates describe groups The calibration of predictions. does not guarantee a response taken in isolation. A confidence of 1.0 describes the model's response, not proof that it is fair.

Three post-training paths

L'AI primer TypeSafe bet: large-scale automation will be dominated by interactions IA-to-IA and IA-to-software, about 99% machine-to-machine and 1% human. The machine interface therefore counts more than the chat interface. TypeSafe calls this Machine Native Intelligence : an AI with software properties, structure, reliability, observability, testability, speed, consistency, low cost. The formula of the page: " Building prod, not God build for production, not a model that does everything.

The problem of the RLHF, seen by TypeSafe

The RLHF teaches a model to say what people prefer. This goal works well for a chatbot, but it can also reward the sycophancy and the hallucinations said with confidence. Optimizing preferences also causes what the page calls the mode dropping : the model learns to favor a style (follow instructions, for example) and reduces the probability of other possible outputs. It is an attenuated version of the mode collapse GAN, where a generator ends up always producing the same type of output because it continues to deceive the discriminator.

The conclusion of the page is measured: the RLHF remains a good choice for conversational models. But an output can be convincing for a person without being reliable enough for unsupervised automation. Human preference and machine reliability are two different optimization targets; automation in production requires, according to TypeSafe, an objective centered on constraints and calibrated uncertainty.

One request

Everything goes through a single point of entry, POST https://api.typesafe.ai/v1/systemone, with a header API key Authorization: BearerThe JSON body always has the same high-level shape:

• state : the content to be evaluated. A string, object or table (Chapter 4).
• model : the model that processes the request, for example "jev-latest" (chapter 17).
• questions : one map You choose each key; the answers return under the same keys.

Each question has a type (choice, score or noul), the instructions (the question asked) and, depending on the type, criteria (options, levels, or definition of yes and no).

Answer

The answer contains three fields: model, the versioned identifier of the model that responded (e.g. jev-1.13.0, even if you asked jev-latest) ; answers, one entry per question, under your identifiers; and usage, the number of tokens in and out. Each response has a type which corresponds to the type of the question, then to the fields specific to the type:

Two properties make these responses composing, and the literature highlights them:

• Each response is constrained by the options provided. The model returns a distribution on your options or levels, never a value outside. The code never has to recover a value in prose.
• Each response is independent. The answer to one question is not a hidden context for another. You can add or remove questions without changing the results of others.

Chain, object or table

The simplest state is a chain: "My card was charged twice.". But it can also be a JSON object or table containing context, examples, linked records. The image proposed by the page State : think of the status as the file you would present to a panel of experts before asking them for a judgment.

The Documentation Board: use an object for most queries, so that each part of the state has a descriptive name and its relationships remain clear. The chain is suitable when the case is simple and requires only one text. A query evaluates one against one or more questions; all questions see the same state and are assessed independently.

Separate the content of the questions

The state contains the content and the supporting facts; the questions define the judgements to be carried on. The example of the doc: keep the claim for reimbursement and the refund policy in the state, then ask on one side whether the client requests a refund, on the other side if the policy allows. Two Nols, only one state.

Refer to a specific field

When the state is a multi-party object, a question often relates to one of them. Primitives request to appoint her in the instructions with a "point and index" path to its key, including backticks : `ticket.messages[0].text`, `order.charges`. The model then knows what part of the state to judge.

When

A Choice serves when the answer is one of a fixed set of options : which team processes a ticket, which category of a product belongs to, in which language is written a code extract. If the answer is a position on a spectrum, it is a Score; if it is yes or no, a Noul. Examples of questions given by the page:

• « What programming language is this code written in » → python, javascript, typescript, go, rust, other
• « What type of meeting is this based on the title and description » → standup, planning, retrospective, one on one, brainstorm, none of the above
• « Which product category does this item belong to » → electronics, clothing, home garden, food and beverage

Note the options other and none of the above The doc recommends adding one when the list may not cover all entries, so that the model can say that none is appropriate.

The form

A Choice has three fields: type (always "choice"), instructions (the question) and criteria, a map whose each key is an option name and each value a description. Both names and descriptions are sent to the model : Write descriptions that separate the options from each other. A description may be null when the name is sufficient (example of the doc: {"calm": None, "frustrated": None, "angry": None}) A Choice accepts up to 255 options.

Read a shared answer

In the five-question example, department returns returns at 0.61, but billing a 0.35 due to a double rate mentioned in the ticket. The ticket belongs to two teams, and the confidence of 0.42 reflects this sharing. requested_resolution is even more indecisive: refund 0.40, replacement 0.34, exchange 0.24, confidence 0.20; the client does not say what he wants. The code of the doc has three consequences:

• under 0.3 confidence over department, we do not assign : a person sorted ;
• a second team that has more than 0.25 probability receives a copy;
• under 0.5 confidence over requested_resolution, on asks the customer Instead of guessing.

Structured descriptions

Start with one line of description per option. When two options are similar and the model confuses them, the doc advises to describe each one by one. object rather than a string: a field for what the option covers, one for what belongs to the next option, some examples. Field names (what, not_for, examples, question, focus...) are not part of the API and are not reserved: you choose them, the model sees them with values, so prefer short names that label the following. return_policy and return_status, two options that both talk about returns; with contrasting objects, the answer is return_status 1.0%.

When

A Score serves when the answer is a position on a spectrum that you can describe in steps : the severity of a bug, the satisfaction of a client, the Python experience of a candidate. criteria is a level, described in words. The number of a level is its position in the table from 0: three entries make levels 0, 1 and 2. It takes at least two levels; the API accepts up to 10.

Important detail given by the page: the model receives descriptions and nothing else, and each level is judged separately He sees neither the level number nor his neighbors. "Worse than the previous level" means nothing to him.

Write good levels

• Describe situations, not degrees. "Function broken or degraded, but a bypass exists" gives the model something to compare to the state. "Moderately serious" does not give anything.
• No numbers. With criteria: ["0", "1", "2"] and the "Rate severity from 0 to 2" statement, the report of the misaligned button gets 0.55 at confidence 0.33 (shared probability between 0 and 1). With the three descriptive levels, it gets 0.0 at confidence 1.0.
• As many levels as you can describe separately, up to 10. Three is good. Do not add a level that you can't distinguish.
• A dimension by Score. "Punctual and brilliant and experienced" measures three things; a high entry on one and bass on the other cannot be placed, confidence falls, the score loses meaning. Separate and combine in the code.
• Give your own level to a rare extreme case On which you have to act differently: a feeling scale that ends up "very angry" can add "undue or threatening".
• Test your data. Two formulations on the same scale can behave differently. Higher confidence alone does not prove that a description is better.

Cut a complex judgment into multiple Scores

A judgment that depends on several things breaks down into one Score per thing, sent in the same request (they are evaluated in parallel, it costs a few tokens of question). The code then combines the scores with weights that belong to it. The example of the doc: priority of a ticket from three Scores, gravity (3 levels), frustration (3 levels) and quality of the ratio (4 levels). normalizes each score by dividing it by its maximum level number, len(criteria) - 1, to bring everything back from 0 to 1.

Structured levels

When the model continues to place between two levels adjacent to the entries that you think are clear, give each level one object: one field for what the level covers, another with some example situations, the same field names on all levels. The doc's picture on the Safari report is eloquent:

The example that looks like real entries concentrates almost all probability on a level; the unconnected example does not change anything. And the caution of the page: a higher confidence does not establish what answer is correct. Choose examples of which you know the expected level, then test the revised descriptions on other entries before keeping them.

When

A Noul serves when the answer is yes or no: does this message require a refund, does this CV mention distributed systems, does this comment contain personal data. Fields: type ("noul"), instructions (the question, or a statement to be judged) and, as an option, criteria, an object with descriptions true and false what a yes and a no mean.

Read a Noul: the answer and the certainty in one number

Nearly 1, a frank yes. Nearly 0, a non-france. Nearly 0.5, the model gives the yes and the no a similar probability. no confidence separated, unlike Choice and Score : the distribution of a Noul has only two issues, so the only value noul The page gives six saved messages for the question "Is the customer asking for a human agent?"; the module below reproduces them.

A Noul is not a ladder

The value ranges from 0 to 1, but this is not a measure of the requested thing: it is the probability that the answer is yes. If the question is actually a question of degree, the value does not measure the degree. The doc compares, out of four candidates, the Noul "Is the candidate strong in Python?" and a Four Level Score (no experience, some familiarity, regular use at work, deep expertise):

One could, in the code, cut the 0–1 interval into slices ("0.3 to 0.7 = some experience"), but the model would not see them: nothing in its answer was judged against them. A median value may mean "average experience" or "miscellaneous case", and the spacing between candidates is not something you have chosen. With the Score, each candidate lands on or near a level you have written, and if you do not agree, you reformulate a level and restart.

Write a question Noul

• A question by Noul. "Is the client angry? and Does he ask for a refund?" forces the model to judge two things at a time. Two Nouls, combined in the code.
• A high value must mean yes. "Does the message contain personal data?" is clear. "Is the message free of personal data?" reverses the meaning and code that reads it will be wrong.
• A statement works as well. For "The customer is requesting a refund", a value close to 1 means that the statement is true. Try both on your data.
• Make the border clear. « Does this candidate have any Python experience?" does not leave a middle. When the border is subtle, add criteria with true and false ; otherwise, the instruction alone is often enough.

Structured instructions, code-generated questions

The instructions can be an object: the question in one field, reference data in the others. The example of the page compares a CV that has just arrived at records of a candidate database, one question Noul per sheet, all in a single request, with the card identifier in the key to the question. Answers reported: sheet 18 (name spelled differently, same city, same employer) gets 0.74; sheet 42 (same name, other city, other employer) 0.09; sheet 77 (near name, same place, other employer) 0.08.

The rule

• Choice when the answer is an option of a known set, without order between them. Give the complete list, more other if she can't cover it all.
• Score when the answer falls on a spectrum that you can describe each point.
• Noul for a net yes/no where the probability itself is the useful signal.

If two types seem to be suitable, prefer the one whose answer is used directly: a Choice between refund, rebook and information connects on three paths of code; a frustration score compares to a threshold; a Noul plugs in on a if.

Where the structure is accepted

Page Advanced: structure says System One models are trained to understand the structure, and lists the fields that accept it. EntryType : string, object, array or null.

When to use structure

Page How to build gives three situations: the question needs context or examples (a long sentence of context or a list of examples goes into fields named next to the question, which the code can modify without rewriting the question); part of the question comes from the code (a value read in the base goes into its own field rather than in a string template); several questions have neighbouring instructions (additional data make them separate). remains a chain.

A table also works, when the instruction is a list of things to check or compare:

Browse a taxonomy with Choices

To classify in a deep taxonomy, the doc proposes One Choice by Level, by browsing the tree in the code : at each step, the options are the children of the current node, and the value of each option is the subtree of the child. The model thus sees what lives under a branch before committing itself to it, which counts when the article belongs to a leaf whose name does not guess from the branch. The example : a gourd that can go under Sporting Goods > Cycling > Bike Bottles & Cages or Home & Kitchen > Drinkware > Water Bottles ; the probabilities If a subtree is too large, it is reduced to its direct children and to a sample of leaves.

Derivation of probabilities

Page Confidence Says it straight away: confidence is a statistics calculated from the distribution TypeSafe calculates it and returns it on each Choice and each Score, so the current case does not require anything more. For a Choice, the distribution is about your options; for a Score, about your levels. In both cases, the more flat it is, the lower the confidence: on a Choice, no option clearly outweighs it; on a Score, the levels are ambiguous, the question measures several things, or the state does not say enough.

"I don't know" is a useful signal

The sentence on the page is worth mentioning: if an intelligent system, human or machine, cannot express an honest uncertainty, it cannot be trusted. confidence is the integrated mechanism by which the model says "not safe for that one". This is what allows the code to have different behaviours depending on the degree of certainty, and it is, according to TypeSafe, the foundation of the systems on which we can really rely.

Keep the limit: a confidence of 1.0 means that the returned distribution puts all the probability on an exit. It describes the model's response, not a guarantee that it is fair.

Three paths

• High confidence: act automatically. The model has a clear reading.
• Medium confidence: proceed with caution. Request confirmation from the user, report for rereading, or collect more information before taking action.
• Low confidence: do not act. Route to a person, ask for clarification, or switch to another system. The model says that he lacks information or that the question is not right for him.

Where to trace these borders depends on the stakes. And in the same system, different actions must be kept at different levels. The page Confidence-gated routing the watch with a voice banking interface: consult a balance of 0.6 confidence, it is acceptable (at worst, the user hears a balance he has not requested); approve a transfer requests more than 0.85, otherwise we have confirmed.

The page adds a target: a report of intelligence / (speed and cost) greater than 100×, with the bet that cheaper intelligence will create much more demand.

Designing an eight-step flow

The complete example: sort a ticket

The flow triage_ticket.py of the page keeps determinism in the code (a closed ticket comes out immediately, without a model), only sends the useful structured context (message, sender, links, customer plan, open orders, list of sensitive identifiers), asks seven atomic questions in a single query (a Subject Choice, five Nouls, a Frustration Score), then composes the answers with explicit trusted doors. The following module isolates the part "Spam Risk": three Nouls weighted in the code.

Two details of the same file deserve attention. The questions are all there Structured : each Noul has an object instructions with question, compare or inspect, and focusand the criteria including true and false are objects with what, not_for, examples. And the paths to the state are quoted between serious accents (`ticket.message`, `policy.sensitive_credentials`), as in Chapter 4.

1 · Speculative fan-out

Because a request accepts a lot of questions, the doc recommends putting it all those that the system might need, then sort in the code. All are evaluated in parallel, so add little changes in response time. The example: sort a support ticket. Instead of asking the category, then gravity in a second call if it's a bug, you ask both at a time; if it's not a bug, you ignore gravity.

All that is needed for the full decision tree comes from a single call. Speculative questions are ignored when they are not serving, and save a round-trip when they are serving. Primitives returns to the cookbook Parallel questions : thirteen questions in one appeal against thirteen calls, about ten times cheaper and ten times faster, without changing the answers (both pages give slightly different multipliers, 11.5×/9.6× and 12.2×/10.0×, probably two executions).

2 · Confidence-gated routing

It's chapter 10: the answer says what, confidence says if you have to act, and every action has its threshold. Nothing to add here, if not the place of this pattern in the list: it's the one that brings reliability and security, not cost or speed.

3 · Composite scoring

We often want to classify elements according to several criteria at the same time. The pattern: to cut the judgment into independent dimensions, to note each separately (one Score per dimension, in a single query), to normalize between 0 and 1, then combine with weights that the control code. The example of the page: CVs of engineers rated on four dimensions (Python depth, leadership, system design, versatility), with two sets of weights depending on the position.

What the page points out: beyond the rankings, we see exactly how the final score is made. If the top ranked ones do not meet expectations, we adjust the weights, without losing the shade of individual scores.

4 · Intent routing

Not all requests deserve the same manager: some are settled by a basic request, others by a specialized LLM with its context, others by a human. TypeSafe stands ahead, as a fast and inexpensive classifier who decides which handler to invoke, instead of passing every message through an expensive LLM just to know what it's talking about.

Take the "Turn off all of the lights in the house" request. The code only needs four answers: the category of the request (domotic control), the target domain (the whole house), the type of device (lights), the action (off). The last question is written. assuming that the user is controlling lights, and it is asked before we know whether that is the case. It is a speculative question: it is evaluated in parallel with the others, and the code filters the results afterward. Each user request is thus evaluated against a long list of issues, many of which will not be applicable.

The wrong way, says the page, would be to cut into successive calls: the category first; then, once sure that it is a command, the domain and the device; then, once sure that they are lights, the action. This minimizes the number of questions, but it is much slower and more expensive than a single grouped call.

TypeSafe + LLM

The demo also shows two ways to associate Jev with a generic model, for a system that sometimes needs a text generation step:

• Cut a composite request. A Noul asks if the request requires more than one separate action. If so, an LLM cuts the sentence into a list of atomic commands, which TypeSafe then evaluates one by one.
• Switch to a conversational LLM. When TypeSafe determines that the request is a general information request or a conversation request, the system calls a LLM to generate a free response. Known deterministic behaviors are processed quickly and at low cost; the flexibility of a LLM remains available when needed. TypeSafe's initial response is so fast compared to that of the LLM that it adds negligible latency.

The page indicates that the demo is a Quick/React application whose full source code "will be available on GitHub at the output"; on the date of playback, only a video recording is offered. The course therefore does not describe its code.

By sector

Nineteen accords in the page. Each list of typical decisions; here is the content, condensed but faithful.

By form of decision

The point of entry

The API key is created in the console (console.typesafe.ai/keys) The body has the three fields seen in Chapter 3, all required: state (string | object | array), model (string) and questions (map<string, Question>). Question is one of the three types; all share type and instructions, each has its own criteria.

Errors and flow limits

On 429 and 529, the instruction is to try again with a exponential backoff, not immediately. SDKs do it by default and respect the header retry-after when it is present. One final API detail: GET /v1/models returns the list of names your account can send to model, with description and date of release; it currently lists aliases, but versioned identifiers as jev-1.13.0 are accepted whether or not they appear.

Python

Request Python 3.10 or more. The client reads TYPESAFE_API_KEY in the environment and calls for jev-latest by default. Two customers: TypeSafeClient (synchronous) and AsyncTypeSafeClient. The answer shows answers (all responses, by ID) and three typed views, nouls, choices, scores.

Typed answers with response_model

Since v0.7.0 (which replaced msgspec by pydantic), system_one accept one response_model : a subclass of SystemOneResponse which declares the expected answers, or even a pydantic model entirely to you. The result then exposes each answer as a typed attribute, and the query identifier via request_id.

Retries, errors, logging, environment

One RetryPolicy is done to the customer or by call (RetryPolicy(max_retries=3, backoff_max=0.2, timeout=1.0) in the example). API errors remove TypeSafeAPIError, status and request_id. The SDK logs on the logger typesafe_sdk ; TYPESAFE_LOG_LEVEL accepts debug, info, warning, error or off. In debug, headers and bodies are journaled; secret headers are masked, bodies are not..

Upward compatibility

The SDK continues to work when the API evolves: extra_body send query fields that the version of the SDK does not know yet; dictionaries of raw questions pass as they are; unknown types of answer are ignored with a warning, and raw_http_response The doc states that these are emergency exits and that it is better to update the SDK.

JavaScript / TypeScript

Request Node.js 20 or more. The package provides ESM, CommonJS and TypeScript declarations. Three helpers build the questions, choice(instructions, criteria), score(instructions, criteria) and noul(instructions?, criteria?), and the types of answers are inferred from the questions : answers.department.choice is typed as one of the keys to your options.

The manufacturer TypeSafeClient(config) accepts apiKey, baseURL, defaultModel, timeout (by default, 10 000 ms), retry, logLevel, logger, defaultHeaders, fetch, and dangerouslyAllowBrowser (false by default: using the SDK in a browser exposes the key to visitors). Explicit options override environment variables, which override SDK defaults. The default retry policy allows 2 additional attempts, with an initial 500 ms backoff doubling up to 5,000 ms and 25% jitter, for status codes 408, 429, and 500–599, respecting Retry-After up to 60 seconds. Errors are dedicated classes (AuthenticationError, RateLimitError, UnprocessableEntityError, APITimeoutError...), all derived from TypeSafeError.

Alias

An alias is a name that resolves to a versioned identifier. jev-latest points to jev-1.13.0 : the most recent stable version, the default of SDKs and the name used in the examples. jev-preview points to the most recent version, official or not; it passes ahead jev-latest when a preversion exists. On the read date, both point to the same model: there is no preversion available.

Practical consequence highlighted by the page: an alias moves at each exit, so the answers behind can change nothing at home. The field model of the answer gives the versioned identifier that responded, to log. And if you have set confidence thresholds on a specific version, pin his ID rather than the alias, and migrate at your own pace.

Customizing Jev

Jev is neither fine-tuned nor adapted by LoRA with customer data; the same weights serve all accounts. by the request : owner content, records and references in the state ; business rules and limit cases in instructions and criteria ; large judgments decomposed into atomic questions combined in the code ; and, to go further, a classical model trained on Jev probabilities (cookbook) AutoResearch).

Languages and data

English is the main language of training, the language where precision is the best. Other languages, including CJK scripts, are processed but less well: test your content before you rely on it, and monitor the confidence in routing. Jev is not trained on customer requests and answers; the page Legal refers to the data processing agreement, to the privacy policy, and offers zero retention (ZDR) to business customers.

Choose a single installation method to avoid duplicates. SKILL.md is readable on GitHub (typesafe-ai/skills) In a hurry, name the skill ("use the TypeSafe skill") works with any agent; with the Claude Code plugin, one can also invoke /typesafe:typesafe-ai.

Three prompts suggested

• Explorer : « Using the TypeSafe skill, explore the project and find opportunities for using intelligent judgement to stand in for complex parsing or other fragile code. »
• Experiment with a key exported in TYPESAFE_API_KEY "run some experiments... Proposes changes based on the most promising results."
• Refactor from the cookbooks: « analyze my code and see if there are any applicable cookbooks... »

Principles of vibe coding according to page

1. Discuss with the agent, starting from the above prompts.
2. Read the plan before implementing it.
3. Put constants (questions and thresholds) in one place, easy to read: agents are not very good at writing questions, expect to edit them with them.
4. Do not take statements for cash; push the agent to validate his assumptions.

Common problems

• The agent does not use the skill : explicitly invoke it, check that the installation targeted this agent well, restart.
• Routing does not behave as planned Check questions and thresholds. Too high, false negatives; too low, false positives.
• Confidence thresholds everywhere : if one wants only the best option, take the one of higher probability, without threshold; for a precise statistical algorithm, use the probabilities.
• TypeSafe code is hard to read What humans need to read again are the questions and threshold constants; group them into a single file.
• The agent invents fields of request or response : an outdated skill; update and try again.

Page Primitives adds one more reason to install the skill: code agents fall more than humans in the habit of "a question by call." The skill tells them to group a lot of questions by call, including those that only matter for some entries.

What the cookbooks teach, in five ideas

1. Find, then choose. Jev does not generate: when the answer is a text value, a regex or another model finds the candidates and a Choice chooses (Pre-parsed value extraction, Date extraction, Function callingThe returned value is copied as it is, never invented.
2. One request per document, as many questions as necessary. Parallel questions measures group gain: about ten times cheaper and faster on a 54,000-character document, with the same answers.
3. confidence separates easy cases from hard cases. Classification using confidence class 60 annual reports in 75 industrial groups: at the threshold 0.9, the confident half is just 90 %, the other 40 %; up one step in the hierarchy, this half increases to 70 %, without second call.
4. Check, cheaper than producing. SDE cascade extract with a small model, check each field with Nouls TypeSafe, and climb to the big model of reasoning only if a signal lights up. Citation check and Guardrails apply the same idea to quotes and messages from an LLM.
5. Stable answers. The two cookbooks Self-consistency play 15 times the same rubric and compare the dispersion of Jev's responses with those of LLM, including at temperature 0.

Glossary

• state : the content to be evaluated, sent in the field state.
• question : a typical judgment requested of the model; answer : the typed value returned under the same identifier.
• instructions : the question asked; criteria : options (Choice), levels (Score) or definition of yes and no (Noul).
• probabilities : distribution on options or levels, sum 1 ; legend : the levels of a Score recalled by number.
• confidence : summary of the concentration of the distribution (Choice and Score) from 0 to 1.
• speculative question : placed in advance, in the same call, before knowing if it will serve.
• context rot : loss of precision when the state contains matter unrelated to the question.
• RLCD : Reinforcement Learning for Calibrated Decisions, TypeSafe post-training.
• calibration - on a batch of predictions, a predicted probability of p is determined in a proportion close to p.
• jaggedness : "irregular edges", tasks on which the model is much less good than on others.

To go further

• The Playground : paste a text, add questions, see answers. This is the starting point recommended by the Quick start.
• The documentation, whose index llms.txt ; each page exists in Markdown by adding .md to his URL.
• The manifest TypeSafe, and the community Discord where the page Jaggedness calls for new methods of failure to be reported.