ms-ai-architect/scripts/kb-eval/judge-claim-prompt.md
Kjell Tore Guttormsen 3e39f2df6b feat(ms-ai-architect): S1 judge bake-off harness + forhåndsregistrert gate (TDD) [skip-docs]
Deterministisk de-risk-harness for Fase 3-judgen (kjøres på frosset 373-påstands gull-sett):
- lib/judge-bakeoff.mjs: P-filter (volatil+fetchbar, price ekskl.), confusion-matrix
  for 3 armer (staleness/judge/hybrid), Wilson-bånd, forhåndsregistrert gate. 14 tester.
- extract-judge-claims.mjs: blind manifest (255 påstander, 0 label-lekkasje — testet invariant).
- judge-claim-prompt.md: blind per-påstands groundedness-judge (Opus xhigh, microsoft_docs_fetch).
- run-judge-bakeoff.mjs: join gull+results på id, gate-rapport (.json/.md).

Gate FORHÅNDSREGISTRERT (operatørvalg, før fan-out): recall ≥0.80, presisjon ≥0.70,
OG slår staleness (0/38). Evalueringspop P = 240 verifiserbare, 38 positive.
Suite 551/551 (538 + 13 nye).
2026-06-26 20:10:58 +02:00

4.2 KiB

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 <FILE> and the <CLAIMS> 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 <FILE>. 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 <FILE>)

Output (strict JSON, no fence)

{"file":"<FILE>","results":[
  {"id":"<claim id>","judge_verdict":"grounded|not_grounded|source_silent","evidence_url":"<url actually used>","evidence_quote":"<verbatim quote or empty>","reason":"<one sentence: what the source said vs the claim>"}
]}