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).
80 lines
4.2 KiB
Markdown
80 lines
4.2 KiB
Markdown
# 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>`)
|
|
|
|
<CLAIMS>
|
|
|
|
## 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>"}
|
|
]}
|
|
```
|