v157 · built-in ai · writing guardrails
Draft guardrail pre-check
Use case 3 from the explainer: a bug tracker that checks a draft before submission, on-device, so nobody learns about the missing repro steps — or the pasted API key — from a server round-trip. One schema, three questions, three question types: two boolean checks and one ordinal score whose expectedScore gives a severity estimate between the rubric points.
The check button makes the real DecisionModel calls, exactly as written in the payload below. On every released Chrome today that throws ReferenceError — shown verbatim, because that is the platform's current answer (CLs in review; flag steps on the surface probe; the WebAI extension polyfill makes it answer for real today). The page never grades your draft with hidden heuristics and never fakes a model verdict.
The draft
This sample deliberately contains repro steps AND a pasted credential, so both booleans have something to find.
has_repro_steps · boolean
“Does the draft include steps to reproduce the issue?”
not checked
contains_credentials · boolean
“Does the draft contain personal contact info, API keys, or passwords?”
not checked
severity · score (1–4)
“Rate the severity from 1 (cosmetic) to 4 (critical).” — read off expectedScore, the probability-weighted value between the rubric points.
not checked
The exact schema
why three types in one schema
A schema with several questions is encoded once and answered in parallel — one pass, all three answers. boolean questions come back as the strings "true"/"false" with a confidence, so the form can nudge only when confident (the explainer uses 0.8; so does this page). The score question defines its own rubric in the option descriptions, and expectedScore weights the numeric labels by probability — a draft the model reads as between “major” and “critical” scores, say, 3.4 rather than being forced to a bucket. Guardrail decisions stay advisory: the page would never block submission on model output alone.