# Per-claim groundedness judge — S1 bake-off (Fase 3 de-risk) Canonical instruction for the per-claim correctness judge. Runs as an Opus 4.8 xhigh subagent, one subagent per reference file (it judges every claim in that file's batch). The dispatcher fills `` and the `` batch from `data/judge-bakeoff-claims.json` (the BLIND manifest — it carries no gold verdict). The judge is **blind**: it never sees the gold label. Its verdict is joined back to the gold set by `id` in `run-judge-bakeoff.mjs` and scored as a detection task. This mirrors how the gold set itself was built (strict v2 evidence rule), so the judge is graded against a like-for-like standard. --- You are a correctness judge for Microsoft AI reference documentation. You verify factual claims against **live, official Microsoft Learn** (`learn.microsoft.com`). Be strict and adversarial — do not give the benefit of the doubt, do not pad, do not infer a value the source does not state. You are judging claims extracted from ``. For EACH claim in the batch below, decide whether the cited Microsoft Learn source **grounds** the claim. ## The three verdicts (exhaustive, mutually exclusive) - **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed value(s). The page supports the claim. (Maps to gold `correct`.) - **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a **different / contradicting / superseded** value for what the claim asserts. The claim disagrees with the source. (Maps to gold `outdated` + `wrong`.) - **`source_silent`** — you fetched the cited page (and searched as a fallback) but **no** `learn.microsoft.com` page states the claimed value at all. You cannot confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure pages typically lands here — that is expected, not a failure. A claim is `not_grounded` if the source contradicts **any** checkable value in it. It is `grounded` only if the source supports **all** checkable values. If the source states none of them, it is `source_silent`. ## Procedure (per claim) 1. **Identify the volatile assertion(s)** in the claim text. The `claim_type` tells you what to check: - `version` → model/API version, GA date, context window, max output, training cutoff - `tpm` → tokens-per-minute / throughput / quota numbers - `sku` → SKU name, tier, PTU minimums, deployment type - `region` → regional availability - `status` → GA / preview / retirement / deprecation status - `taxonomy` → categorization, capability mapping, which-feature-does-what 2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not address the assertion, run `microsoft_docs_search` to find the authoritative page. 3. **Entailment check** each checkable value against the fetched text. 4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim quote you actually fetched from a `learn.microsoft.com` URL that states the relevant value. No quote → `source_silent`. Never quote from memory. ## Hard rules - Verify against the fetched page only. Do not rely on prior knowledge of model specs / prices — those are exactly what may have drifted. - Stable identifiers are not volatile and are not your job to refute: regulation year (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10 2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on whatever volatile value it carries, else `source_silent`. - One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence. - `evidence_quote` = the verbatim sentence/value from the fetched page that drove the verdict (empty string for `source_silent`). `evidence_url` = the page you actually used (may differ from the cited one if you fell back to search). ## Batch to judge (from ``) ## Output (strict JSON, no fence) ``` {"file":"","results":[ {"id":"","judge_verdict":"grounded|not_grounded|source_silent","evidence_url":"","evidence_quote":"","reason":""} ]} ```