v157 · built-in ai · schema design
Schema playground
The schema is the API: context, expected inputs, and a list of typed questions whose options bound everything the model can ever answer. Build one here — the page validates it against the explainer's rules as you type, prints the exact JSON, and will hand it to a real DecisionModel.availability() so you can see what the platform says about your schema.
Validation on this page implements the explainer's documented constraints (choice requires options; 2–16 options is the practical single-pass band; score without options defaults to labels "1"–"5"; every question needs a unique id, a prompt, and a known type). It is a design aid, not a substitute for the platform's own errors — the availability button below asks the real API, which on today's released Chrome means the honest ReferenceError (flag steps on the surface probe).
Questions
One line of task framing the model sees alongside every question.
Verdict on this schema
design rules worth internalising
Keep option sets closed and small — single-pass scoring is what makes the API fast, and the explainer recommends staged filtering over cramming a 300-item catalogue into one question. Give ambiguous inputs somewhere to land (other/none catch-alls) so uncertainty shows up as a calibrated low-confidence catch-all instead of a forced wrong answer. Option order must not matter, descriptions carry most of the semantic weight, and numeric score labels are what expectedScore averages over — so label the rubric "1"…"4", not "low"…"critical", when you want the weighted value.