A recipe is one decision, worked end to end: the state you send, the typed questions you ask about it, the code in Python and TypeScript, and the decision policy that turns the answer into an action. The model returns a label and a number; the thresholds stay in your code, which is the part how to build with System One models goes into properly.
Every recipe names the official cookbook or pattern it is derived from, and lists the SDK documentation pages its code was checked against. Numbers in the thresholds are starting points from the vendor's own worked examples, not values tuned for your data.
An LLM cites a document for a claim. This recipe checks the citation in two steps: a plain string match that catches quotes missing from the source, then one noul question that returns the probability the quoted section actually supports the claim. Your code turns that probability into a verdict.
A single Choice question sorts an inbound support ticket into one of four queues and returns a probability for every option. The model supplies the label and the certainty; your router applies the thresholds, holds the doubtful tickets for a human, and keeps every side effect in your code rather than in the prompt.
A support ticket needs a category, a severity, and two yes/no facts that only matter for one category each. Asking in sequence costs four round trips and four copies of the ticket. This recipe sends all four questions in one call, including the speculative ones, and lets the routing code ignore what it does not need.
One Choice names the action the user is asking for and one Noul says whether the message confirms it. Two numbers come back, and a table of per-action thresholds in your code decides the rest: a read runs at moderate confidence, a refund needs more, and anything below the floor goes to a person.
A keyword search hands you thirty plausible passages in no useful order. One Score question rates each query-passage pair against a written five-level rubric, and your code sorts by the returned score, keeps the top few above a cutoff, and passes nothing along when the best candidate is still weak.
Asking a model how good a lead is gives you a number nobody can argue with or adjust. This recipe asks four narrow score questions instead, one per dimension, normalises each answer to a 0 to 1 range and combines them with weights kept in your code, so changing what qualifies means editing a constant.
Four yes/no questions go to Jev in one request and come back as four probabilities between 0 and 1, one per injection hazard. Nothing is refused by the model. Your code reads the numbers, applies two thresholds you picked, and decides whether the turn passes, gets stripped of pasted orders, goes to review, or stops.
A taxonomy with hundreds of leaves does not fit in one question. This recipe walks the tree instead: one choice question per level, each asking only about the direct children of the node you are standing on. Multiply the winning probabilities, normalise for depth, and stop early when an edge looks weak.