ms-ai-architect/scripts/kb-eval/data/r72-payloads.json

[
  {
    "file": "skills/ms-ai-engineering/references/agent-orchestration/agent-365-governance-and-deployment.md",
    "claim_count": 16,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/agent-orchestration/agent-365-governance-and-deployment.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/agent-orchestration/agent-365-governance-and-deployment.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-365-governance-and-deployment.md#1\",\n    \"claim\": \"Microsoft Agent 365 ble generelt tilgjengelig (GA) 1. mai 2026.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/copilot/microsoft-365/agent-essentials/m365-agents-blueprint\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-365-governance-and-deployment.md#2\",\n    \"claim\": \"Agent Inventory i Agent Registry viser fire agentkategorier: Microsoft-bygde | partner-bygde | user-shared | org-published.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/microsoft-365/admin/manage/agent-registry\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-365-governance-and-deployment.md#3\",\n    \"claim\": \"Risks Column (aggregerte high-severity risks fra Entra, Defender og Purview per agent) er kun tilgjengelig med Microsoft 365 E7-lisens.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/microsoft-365/admin/manage/agent-registry\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-365-governance-and-deployment.md#4\",\n    \"claim\": \"Admin Center tilbyr 11 lifecycle management actions: Publish | Activate | Deploy | Pin | Block | Remove | Delete | Approve Updates | Manage Ownerless Agents | Reassign | Export Inventory.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/microsoft-365/admin/manage/agent-registry\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-365-governance-and-deployment.md#5\",\n    \"claim\": \"Maksimalt 3 administrator-pinned agenter per tenant, og kun deployed agenter kan pinnes.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/microsoft-365/admin/manage/agent-registry\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-365-governance-and-deployment.md#6\",\n    \"claim\": \"Microsoft Entra Agent ID gir fem agent-capabilities: Agent Blueprint | Agent Sponsorship | Conditional Access for Agents | Identity Protection for Agents | Lifecycle Workflows.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/microsoft-agent-365/admin/capabilities-entra\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-365-governance-and-deployment.md#7\",\n    \"claim\": \"Agent 365 støtter tre installasjons-/deployment-modeller: Microsoft-installed | Admin-installed | User-installed.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/copilot/microsoft-365/copilot-agent-install\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-365-governance-and-deployment.md#8\",\n    \"claim\": \"Agent 365 Policy Templates finnes i to typer: Default Template | Custom Template.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/copilot/microsoft-365/copilot-control-system/management-controls\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-365-governance-and-deployment.md#9\",\n    \"claim\": \"Default Template inkluderer policyene: Entra Identity Protection | Network visibility | Lifecycle management | SharePoint external sharing restrictions | Purview Audit/DLP | AI compliance assessment.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/copilot/microsoft-365/copilot-control-system/management-controls\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-365-governance-and-deployment.md#10\",\n    \"claim\": \"Microsoft anbefaler en trefaset deployment-blueprint for Agent 365: Prepare → Deploy → Manage.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/copilot/microsoft-365/agent-essentials/m365-agents-blueprint\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-365-governance-and-deployment.md#11\",\n    \"claim\": \"Programmatisk agentadministrasjon skjer via Microsoft Graph beta-endepunkt /beta/copilot/admin/catalog/packages (Graph API for Agent Registry er i preview).\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/microsoft-365/admin/manage/agent-registry\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-365-governance-and-deployment.md#12\",\n    \"claim\": \"Microsoft Agent 365 er en separat, betalt SKU og er ikke inkludert i Microsoft 365 Copilot-lisensen.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/copilot/microsoft-365/agent-essentials/m365-agents-blueprint\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-365-governance-and-deployment.md#13\",\n    \"claim\": \"Microsoft 365 E7 («Frontier Suite») bundler Microsoft 365 E5 + Microsoft 365 Copilot + Agent 365 + Entra Suite.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/copilot/microsoft-365/agent-essentials/m365-agents-blueprint\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-365-governance-and-deployment.md#14\",\n    \"claim\": \"Standalone Agent 365-lisens krever en kvalifiserende baselinjelisens: Microsoft 365 E5 | Defender + Purview Suite FLW | Business Premium.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/copilot/microsoft-365/agent-essentials/m365-agents-blueprint\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-365-governance-and-deployment.md#15\",\n    \"claim\": \"Agent Builder krever Microsoft 365 Copilot-lisens for å opprette agenter.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/copilot/microsoft-365/agent-essentials/m365-agents-blueprint\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-365-governance-and-deployment.md#16\",\n    \"claim\": \"Copilot Studio Agents krever Power Apps/Power Automate premiumlisens ELLER Pay-as-you-go.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/copilot/microsoft-365/agent-essentials/m365-agents-blueprint\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/agent-orchestration/agent-365-governance-and-deployment.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/agent-orchestration/agent-autonomy-and-control-governance.md",
    "claim_count": 17,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/agent-orchestration/agent-autonomy-and-control-governance.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/agent-orchestration/agent-autonomy-and-control-governance.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-autonomy-and-control-governance.md#1\",\n    \"claim\": \"Deterministisk kontrollnivå i Microsoft Agent-stakken bruker verktøyene: Foundry Workflows | Microsoft Agent Framework Workflows | Copilot Studio Topics.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/generative-orchestration\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-autonomy-and-control-governance.md#2\",\n    \"claim\": \"Hybrid (intercept) kontrollnivå bruker verktøyene: HITL i Agent Framework | Foundry Agent Service approval policies | Copilot Studio confirmation nodes.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/generative-orchestration\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-autonomy-and-control-governance.md#3\",\n    \"claim\": \"AI orchestrator-kontrollnivå bruker: Generative Orchestration | Tool approval modes | System message constraints.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/generative-orchestration\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-autonomy-and-control-governance.md#4\",\n    \"claim\": \"Approval modes i Agent Framework (Python @tool-dekoratør): always_require | never_require | conditional.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/agent-framework/user-guide/workflows/orchestrations/human-in-the-loop\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-autonomy-and-control-governance.md#5\",\n    \"claim\": \"Guardrails opererer ved fire intervention points i agent execution lifecycle: User input (prompt) | Tool call (preview) | Tool response (preview) | Output (completion).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/foundry/guardrails/guardrails-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-autonomy-and-control-governance.md#6\",\n    \"claim\": \"Risk categories som guardrails detekterer: Hate | Sexual | Self-harm | Violence | User prompt attacks | Indirect attacks | Protected material (code + text) | Personally identifiable information (PII) | Groundedness | Spotlighting (preview) | Task Adherence (preview).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/foundry/guardrails/guardrails-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-autonomy-and-control-governance.md#7\",\n    \"claim\": \"Guardrail-actions: Annotate (logg risikodeteksjon uten å blokkere, kun modeller) | Annotate and block (blokker og logg, modeller + agenter).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/foundry/guardrails/guardrails-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-autonomy-and-control-governance.md#8\",\n    \"claim\": \"Microsoft Foundrys standard-guardrail er Microsoft.DefaultV2.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/foundry/guardrails/guardrails-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-autonomy-and-control-governance.md#9\",\n    \"claim\": \"Tool call/response intervention points i Foundry er i preview og kun tilgjengelig for agenter (ikke modeller).\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/foundry/guardrails/guardrails-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-autonomy-and-control-governance.md#10\",\n    \"claim\": \"Foundry Agent Service lagrer memory/conversation state i Azure Cosmos DB for NoSQL.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/guardrails/guardrails-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-autonomy-and-control-governance.md#11\",\n    \"claim\": \"Microsoft Agent Framework Workflows tilbyr orchestrations: Sequential | Concurrent | Group Chat | Magentic.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/agent-framework/user-guide/workflows/orchestrations/human-in-the-loop\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-autonomy-and-control-governance.md#12\",\n    \"claim\": \"AG-UI Protocol approval-implementering: C# via ApprovalRequiredAIFunction-klasse | Python via @tool(approval_mode=\\\"always_require\\\")-dekoratør og AgentFrameworkAgent(require_confirmation=True).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/agent-framework/integrations/ag-ui/human-in-the-loop\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-autonomy-and-control-governance.md#13\",\n    \"claim\": \"Azure har regioner i Norge — Norway East og Norway West — for dataresidens.\",\n    \"claim_type\": \"region\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/guardrails/guardrails-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-autonomy-and-control-governance.md#14\",\n    \"claim\": \"Azure API Management (AI Gateway) tilbys i tiers: Developer | Standard.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/guardrails/guardrails-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-autonomy-and-control-governance.md#15\",\n    \"claim\": \"Microsoft Entra ID P1 og P2 kreves for Conditional Access på agenter.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/security/security-for-ai/agent-365-security\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-autonomy-and-control-governance.md#16\",\n    \"claim\": \"Microsoft Agent Framework er open source under MIT-lisens.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/guardrails/guardrails-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-autonomy-and-control-governance.md#17\",\n    \"claim\": \"Copilot Studio er inkludert i Microsoft 365 Copilot-lisensen eller tilgjengelig standalone.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/generative-orchestration\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/agent-orchestration/agent-autonomy-and-control-governance.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/agent-orchestration/agent-evaluation-testing-frameworks.md",
    "claim_count": 16,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/agent-orchestration/agent-evaluation-testing-frameworks.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/agent-orchestration/agent-evaluation-testing-frameworks.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-evaluation-testing-frameworks.md#1\",\n    \"claim\": \"Azure AI Evaluation SDK er GA, mens de agent-spesifikke evaluatorene er i Preview.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/foundry-classic/how-to/develop/agent-evaluate-sdk?view=foundry-classic\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-evaluation-testing-frameworks.md#2\",\n    \"claim\": \"Azure AI Evaluation SDK-evaluatorene omfatter: IntentResolutionEvaluator | TaskAdherenceEvaluator | ToolCallAccuracyEvaluator | ResponseCompletenessEvaluator | GroundednessEvaluator | RelevanceEvaluator | CoherenceEvaluator | FluencyEvaluator | ContentSafetyEvaluator | IndirectAttackEvaluator | CodeVulnerabilityEvaluator | TaskCompletionEvaluator | CustomerSatisfactionEvaluator | ToolSelectionEvaluator | ToolInputAccuracyEvaluator | ToolOutputUtilizationEvaluator | ToolCallSuccessEvaluator | TaskNavigationEfficiencyEvaluator.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/foundry/concepts/evaluation-evaluators/agent-evaluators?view=foundry\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-evaluation-testing-frameworks.md#3\",\n    \"claim\": \"ContentSafetyEvaluator detekterer harmful content i kategoriene violence | hate | sexual | self-harm, med score-range 0-7 severity.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/concepts/observability\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-evaluation-testing-frameworks.md#4\",\n    \"claim\": \"TaskCompletionEvaluator og CustomerSatisfactionEvaluator er merket som preview.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/foundry/concepts/evaluation-evaluators/agent-evaluators?view=foundry\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-evaluation-testing-frameworks.md#5\",\n    \"claim\": \"FoundryEvals kjører som standard evaluatorene relevance | coherence | task_adherence, og legger automatisk til tool_call_accuracy når tool-definisjoner finnes.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/concepts/observability\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-evaluation-testing-frameworks.md#6\",\n    \"claim\": \"Microsoft anbefaler gpt-4.1-mini som judge-modell for kompleks evaluering.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/foundry-classic/how-to/develop/agent-evaluate-sdk?view=foundry-classic\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-evaluation-testing-frameworks.md#7\",\n    \"claim\": \"Støttede agent-rammeverk for evaluering: Foundry Agent Service (AIAgentConverter) | Semantic Kernel (AIAgentConverter) | Custom agents (ingen converter, krever OpenAI-style message schema).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/foundry-classic/how-to/develop/agent-evaluate-sdk?view=foundry-classic\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-evaluation-testing-frameworks.md#8\",\n    \"claim\": \"ToolCallAccuracyEvaluator støtter disse tool-typene i Foundry Agent Service: File Search | Azure AI Search | Bing Grounding | Bing Custom Search | SharePoint Grounding | Code Interpreter | Fabric Data Agent | OpenAPI | Function Tool.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/foundry/concepts/evaluation-evaluators/agent-evaluators?view=foundry\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-evaluation-testing-frameworks.md#9\",\n    \"claim\": \"Continuous evaluation støtter sampling fra 0-100 %, med maks 1000 evalueringer per time.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/foundry-classic/how-to/continuous-evaluation-agents?view=foundry-classic\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-evaluation-testing-frameworks.md#10\",\n    \"claim\": \"Judge-modeller for LLM-evaluatorer: gpt-4o (standard) | gpt-4.1 (bedre reasoning) | o3-mini / o-series (kompleks evaluering).\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/foundry-classic/how-to/develop/agent-evaluate-sdk?view=foundry-classic\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-evaluation-testing-frameworks.md#11\",\n    \"claim\": \"Azure OpenAI api_version for reasoning-modell-konfigurasjon er 2024-08-01-preview.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/foundry-classic/how-to/develop/agent-evaluate-sdk?view=foundry-classic\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-evaluation-testing-frameworks.md#12\",\n    \"claim\": \"MLflow 3 GenAI-evaluering tilbyr: Built-in LLM judges | Custom scorers | Eval harness | Conversation evaluation | Conversation simulation | Production monitoring | Review App.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/databricks/mlflow3/genai/eval-monitor/\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-evaluation-testing-frameworks.md#13\",\n    \"claim\": \"MLflow 3 production monitoring (scorers og judges på produksjons-traces) er i Beta.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/databricks/mlflow3/genai/eval-monitor/\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-evaluation-testing-frameworks.md#14\",\n    \"claim\": \"Prompt Flow evaluation flows er en deprecated tilnærming; Microsoft anbefaler Azure AI Evaluation SDK i stedet.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/concepts/observability\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-evaluation-testing-frameworks.md#15\",\n    \"claim\": \"For EU-datalagring kan Azure OpenAI judge-modell (gpt-4.1) deployes i EU-regionene France Central | Sweden Central.\",\n    \"claim_type\": \"region\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/concepts/observability\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-evaluation-testing-frameworks.md#16\",\n    \"claim\": \"Copilot Studios automated tests for agent quality/reliability er i 2025 preview.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/power-platform/release-plan/2025wave1/microsoft-copilot-studio/run-automated-tests-agent-quality-reliability\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/agent-orchestration/agent-evaluation-testing-frameworks.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/agent-orchestration/agent-memory-and-context-management.md",
    "claim_count": 15,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/agent-orchestration/agent-memory-and-context-management.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/agent-orchestration/agent-memory-and-context-management.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-memory-and-context-management.md#1\",\n    \"claim\": \"Referansen er merket Status: GA totalt, mens Managed Memory i Foundry Agent Service er i Preview.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/concepts/what-is-memory\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-memory-and-context-management.md#2\",\n    \"claim\": \"Microsoft-stakken tilbyr tre hovedtilnærminger til agentminne: chat history management (alle agenttyper) | vector-basert semantic memory (Semantic Kernel) | managed memory extraction (Foundry Agent Service, preview).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/concepts/what-is-memory\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-memory-and-context-management.md#3\",\n    \"claim\": \"Memory-typer i Microsoft AI-stakken: Short-term (Session) via ChatHistory/AgentThread | Working Memory via WhiteboardProvider (SK) | Long-term (User Profile) via Mem0Provider (SK)/Foundry Memory Store | Long-term (Chat Summary) via Foundry Memory Store (preview) | Semantic Memory (Vector) via Vector Store connectors.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/concepts/what-is-memory\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-memory-and-context-management.md#4\",\n    \"claim\": \"Minnearkitekturer per plattform: Semantic Kernel Agents (ChatHistoryAgentThread; Mem0Provider, Vector Stores) | Foundry Agent Service (managed session context; Managed Memory Store preview) | Microsoft Agent Framework (ChatHistoryProvider in-memory/Cosmos; ChatHistoryMemoryProvider, Mem0Provider, Redis) | Copilot Studio (session-variabler; Conversation history opt-in Cosmos DB) | M365 Copilot (Microsoft-managed).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/concepts/what-is-memory\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-memory-and-context-management.md#5\",\n    \"claim\": \"Semantic Kernels Legacy Memory Stores (IMemoryStore) er deprecated; Microsoft migrerer bort fra IMemoryStore til Vector Store-abstraksjoner.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/semantic-kernel/concepts/vector-store-connectors/memory-stores\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-memory-and-context-management.md#6\",\n    \"claim\": \"Legacy Memory Stores i Semantic Kernel: InMemoryMemoryStore | Azure AI Search | Cosmos DB (NoSQL/MongoDB) | PostgreSQL | SQL Server.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/semantic-kernel/concepts/vector-store-connectors/memory-stores\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-memory-and-context-management.md#7\",\n    \"claim\": \"Foundry Agent Service ekstraherer tre typer long-term memory: User profile memory | Chat summary memory | Procedural memory (aktivert by default).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/concepts/what-is-memory\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-memory-and-context-management.md#8\",\n    \"claim\": \"Foundry-minne (siste preview) tilbyr item-level memory CRUD (create/read/update/list/delete), store-nivå default TTL (default_ttl_seconds, 0 = ingen utløp), remember/forget-kommandoer og styring via user_profile_details.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/concepts/what-is-memory\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-memory-and-context-management.md#9\",\n    \"claim\": \"Foundry Managed Memory (preview) har kvoter: 100 scopes og 10 000 memories per scope.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/concepts/what-is-memory\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-memory-and-context-management.md#10\",\n    \"claim\": \"Cosmos DB Chat History er GA, og BYOS (Bring Your Own Storage) for Azure Copilot er GA.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/copilot/bring-your-own-storage\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-memory-and-context-management.md#11\",\n    \"claim\": \"Memory vs. Foundry IQ: user-specific context dekkes av Memory | organizational knowledge base av Foundry IQ | user-uploaded documents (session) av File search tool.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/concepts/what-is-memory\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-memory-and-context-management.md#12\",\n    \"claim\": \"Foundry Memory (preview) har en region-liste som inkluderer Norway East, Sweden Central og France Central m.fl.; VNet-integrasjon støttes ikke for memory stores.\",\n    \"claim_type\": \"region\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/concepts/what-is-memory\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-memory-and-context-management.md#13\",\n    \"claim\": \"Foundry Managed Memory (preview) har kvote på 1000 requests/min (search + update).\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/concepts/what-is-memory\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-memory-and-context-management.md#14\",\n    \"claim\": \"Azure AI Search tilbys i Basic-tier og Standard S1-tier, der S1 støtter 50M vektorer for produksjon.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/concepts/what-is-memory\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-memory-and-context-management.md#15\",\n    \"claim\": \"GPT-4o har 128K context window og GPT-4o-mini har 128K context window.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/concepts/what-is-memory\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/agent-orchestration/agent-memory-and-context-management.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/agent-orchestration/agent-to-agent-a2a-protocol.md",
    "claim_count": 12,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/agent-orchestration/agent-to-agent-a2a-protocol.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/agent-orchestration/agent-to-agent-a2a-protocol.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-to-agent-a2a-protocol.md#1\",\n    \"claim\": \"A2A-protokollspesifikasjonen er stabil (v1.0), mens Microsofts A2A-SDK og Agent Framework A2A-pakker fortsatt er i Preview.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/agent-framework/integrations/a2a\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-to-agent-a2a-protocol.md#2\",\n    \"claim\": \"Microsoft har implementert A2A-støtte i Foundry Agent Service | Copilot Studio | Semantic Kernel | Teams AI Library, og Azure API Management kan fronte som A2A-gateway.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/concepts/agent-to-agent-authentication\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-to-agent-a2a-protocol.md#3\",\n    \"claim\": \"A2A protokollversjon v1.0 er den første stabile, produksjonsklare versjonen (2026); v0.3 er fortsatt støttet via versjonsforhandling.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/concepts/agent-to-agent-authentication\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-to-agent-a2a-protocol.md#4\",\n    \"claim\": \"A2A v1.0 har fire hovednyheter: Signed Agent Cards | multi-tenancy | multi-protocol bindings (JSON-RPC og gRPC) | versjonsforhandling (v0.3→v1.0).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/concepts/agent-to-agent-authentication\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-to-agent-a2a-protocol.md#5\",\n    \"claim\": \"Microsofts A2A-SDK og Agent Framework A2A-pakker (agent-framework-a2a, Microsoft.Agents.AI.Hosting.A2A / .AspNetCore) er i preview, ikke GA i Microsoft Agent Framework.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/agent-framework/integrations/a2a\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-to-agent-a2a-protocol.md#6\",\n    \"claim\": \"Foundry støtter A2A via SDK-ene Python | C# | TypeScript | REST API; Java er ikke støttet per februar 2026.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/how-to/tools/agent-to-agent\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-to-agent-a2a-protocol.md#7\",\n    \"claim\": \"Copilot Studio tilbyr autentiseringsmetodene None | API key | OAuth 2.0 ved tilkobling til en ekstern A2A-agent.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/microsoft-copilot-studio/add-agent-agent-to-agent\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-to-agent-a2a-protocol.md#8\",\n    \"claim\": \"Copilot Studio integrasjonstyper og anbefalt valg: eksterne rammeverk/host → A2A | enkle API/HTTP-tjenester → Custom connectors | MCP-verktøy og ressurser → MCP-servere | Microsoft 365 Agents SDK-agenter → Activity Protocol.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/microsoft-copilot-studio/add-agent-agent-to-agent\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-to-agent-a2a-protocol.md#9\",\n    \"claim\": \"Semantic Kernel orchestration-mønstre som støtter A2A: Concurrent | Sequential | Handoff | Group Chat | Magentic.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/semantic-kernel/frameworks/agent/agent-orchestration/\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-to-agent-a2a-protocol.md#10\",\n    \"claim\": \"Azure API Management som A2A-gateway tilbyr: mediering av JSON-RPC til A2A-backend | governance/trafikkstyring via policies | OpenTelemetry GenAI-samsvar (genai.agent.id, genai.agent.name) | Agent Card-transformasjon.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/agent-to-agent-api\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-to-agent-a2a-protocol.md#11\",\n    \"claim\": \"Foundry autentiseringsmetoder for A2A: Ingen autentisering | Nøkkelbasert (API key) | Microsoft Entra ID – agent identity | Microsoft Entra ID – project managed identity | OAuth identity passthrough (kun sistnevnte bevarer brukerkontekst).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/concepts/agent-to-agent-authentication\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-to-agent-a2a-protocol.md#12\",\n    \"claim\": \"A2A SDK-pakker: agent-framework-a2a (--pre/preview) | azure-ai-projects[agents] | @microsoft/teams.a2a (npm) | microsoft-teams-a2a (pip).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/agent-framework/integrations/a2a\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/agent-orchestration/agent-to-agent-a2a-protocol.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/agent-orchestration/agent-to-agent-communication.md",
    "claim_count": 14,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/agent-orchestration/agent-to-agent-communication.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/agent-orchestration/agent-to-agent-communication.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-to-agent-communication.md#1\",\n    \"claim\": \"Microsoft tilbyr to primære protokoller for agent-til-agent-kommunikasjon: A2A (Agent-to-Agent), en åpen rammeverksagnostisk protokoll | Agent Registry API via Microsoft Entra for enterprise-sikkerhet, identitet og governance.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/semantic-kernel/frameworks/agent/agent-orchestration\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-to-agent-communication.md#2\",\n    \"claim\": \"A2A-arkitekturens kjernekomponenter: A2A Protocol | Agent Card | Client Agent | Remote Agent | Agent Registry API | Message Broker.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/semantic-kernel/frameworks/agent/agent-orchestration\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-to-agent-communication.md#3\",\n    \"claim\": \"Agent Card (JSON-manifest) beskriver agentens Identity (navn, versjon, beskrivelse) | Capabilities (streaming, push notifications, skills) | Endpoint (base URL) | Authentication (OAuth scopes, token requirements).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/agent-framework/user-guide/hosting/agent-to-agent-integration\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-to-agent-communication.md#4\",\n    \"claim\": \"Microsoft Entra Agent Registry tilbyr funksjonene: Agent Identity (agentIdentityId i Entra) | Discovery Policies (secure-by-default + custom) | Audit Trails (logging med traceId) | Authorization (OAuth 2.0, RBAC).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/entra/agent-id/identity-platform/registry-agent-to-agent-protocol\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-to-agent-communication.md#5\",\n    \"claim\": \"Agent Card hentes for discovery via well-known-endepunktet GET /.well-known/agent-card.json.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/agent-framework/user-guide/hosting/agent-to-agent-integration\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-to-agent-communication.md#6\",\n    \"claim\": \"Agent Registry eksponeres via Microsoft Graph på beta-endepunktet graph.microsoft.com/beta/agentRegistry (ressurser agentCardManifests og agentInstances).\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/entra/agent-id/identity-platform/registry-agent-to-agent-protocol\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-to-agent-communication.md#7\",\n    \"claim\": \"Message brokers for asynkron agent-kommunikasjon: Azure Service Bus (reliable queuing, topic pub/sub) | Azure Event Grid (real-time event routing) | Azure Event Hubs (high-throughput event streaming for IoT).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-to-agent-communication.md#8\",\n    \"claim\": \"Azure Event Grid støtter real-time event routing på 10 millioner events per sekund.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-to-agent-communication.md#9\",\n    \"claim\": \"Event-driven topologier: Broker Topology (agenter broadcaster events, andre reagerer eller ignorerer) | Mediator Topology (en mediator styrer event flow og state og dispatcher commands).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-to-agent-communication.md#10\",\n    \"claim\": \"A2A-agenter kan brukes i Semantic Kernel orchestration-mønstre: Group Chat | Sequential | Handoff.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/semantic-kernel/frameworks/agent/agent-orchestration/\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-to-agent-communication.md#11\",\n    \"claim\": \"A2A-verktøyet i Microsoft Foundry er i Preview (representert ved klassen A2APreviewTool).\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/agent-framework/user-guide/hosting/agent-to-agent-integration\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-to-agent-communication.md#12\",\n    \"claim\": \"For hosting av lokale agenter i Norge anbefales Azure-regionene Norway East og Norway West.\",\n    \"claim_type\": \"region\",\n    \"evidence_url\": \"https://learn.microsoft.com/semantic-kernel/frameworks/agent/agent-orchestration\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-to-agent-communication.md#13\",\n    \"claim\": \"Microsoft Entra ID P2 kreves for å bruke Agent Registry.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/entra/agent-id/identity-platform/registry-agent-to-agent-protocol\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/agent-to-agent-communication.md#14\",\n    \"claim\": \"Entra ID P2 audit logs har 90 dagers retention.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/entra/agent-id/identity-platform/registry-agent-to-agent-protocol\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/agent-orchestration/agent-to-agent-communication.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/agent-orchestration/autonomous-workflow-automation-patterns.md",
    "claim_count": 12,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/agent-orchestration/autonomous-workflow-automation-patterns.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/agent-orchestration/autonomous-workflow-automation-patterns.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/autonomous-workflow-automation-patterns.md#1\",\n    \"claim\": \"Kjerneteknologien Durable Functions er merket GA (generelt tilgjengelig).\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/azure-functions/durable/durable-functions-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/autonomous-workflow-automation-patterns.md#2\",\n    \"claim\": \"Microsoft-stakken tilbyr tre primære tilnærminger til autonomous workflow automation: Durable Functions | Power Automate med AI Builder | Azure Logic Apps.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/azure-functions/durable/durable-functions-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/autonomous-workflow-automation-patterns.md#3\",\n    \"claim\": \"Power Automate har 1400+ connectors.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/power-platform/release-plan/2025wave1/power-automate/cloud-flows\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/autonomous-workflow-automation-patterns.md#4\",\n    \"claim\": \"Durable Functions-arkitekturmønstre dekket i filen: Function Chaining | Fan-out/Fan-in | Human-in-the-Loop | Monitor | Aggregator (Stateful Entities).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-overview#application-patterns\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/autonomous-workflow-automation-patterns.md#5\",\n    \"claim\": \"Durable Functions støtter kode-først utvikling i språkene C# | Python | JavaScript | Java | PowerShell.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/azure-functions/durable/durable-functions-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/autonomous-workflow-automation-patterns.md#6\",\n    \"claim\": \"Power Automate cloud flows har maksimal kjøretid på 30 dager.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/power-platform/release-plan/2025wave1/power-automate/cloud-flows\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/autonomous-workflow-automation-patterns.md#7\",\n    \"claim\": \"Azure Logic Apps Standard tier har maksimal kjøretid på 90 dager.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/azure-functions/durable/durable-functions-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/autonomous-workflow-automation-patterns.md#8\",\n    \"claim\": \"Azure Functions Durable Functions tilbys i hosting-planene Consumption | Premium (VNet, ubegrenset kjøretid) | Dedicated (App Service).\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/azure-functions/durable/durable-functions-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/autonomous-workflow-automation-patterns.md#9\",\n    \"claim\": \"Power Automate lisenstyper: Per user | Per flow | Process (RPA desktop flows, unattended automation).\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/power-platform/release-plan/2025wave1/power-automate/cloud-flows\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/autonomous-workflow-automation-patterns.md#10\",\n    \"claim\": \"Power Automate Per user-lisens inkluderer 40 000 AI Builder credits per måned.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/power-platform/release-plan/2025wave1/power-automate/cloud-flows\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/autonomous-workflow-automation-patterns.md#11\",\n    \"claim\": \"Power Automate Per flow-lisens inkluderer 15 000 cloud flow runs per måned og 250 000 API requests.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/power-platform/release-plan/2025wave1/power-automate/cloud-flows\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/autonomous-workflow-automation-patterns.md#12\",\n    \"claim\": \"Azure Logic Apps tilbys i tierne Consumption | Standard.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/azure-functions/durable/durable-functions-overview\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/agent-orchestration/autonomous-workflow-automation-patterns.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/agent-orchestration/computer-using-agents-cua.md",
    "claim_count": 15,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/agent-orchestration/computer-using-agents-cua.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/agent-orchestration/computer-using-agents-cua.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/computer-using-agents-cua.md#1\",\n    \"claim\": \"Foundry Agent Service tilbyr CUA via computer-use-preview-modellen i Azure OpenAI, i (public) preview siden sep 2025.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/how-to/tools/computer-use\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/computer-using-agents-cua.md#2\",\n    \"claim\": \"Copilot Studio Computer Use (som verktøy i agenter) var public preview fra 2025-05-27 og ble GA 2026-05-07.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/microsoft-copilot-studio/computer-use\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/computer-using-agents-cua.md#3\",\n    \"claim\": \"CUA kombinerer tre kapabiliteter: Computer Vision | Resonnering | Kontrollgenerering.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/microsoft-copilot-studio/faqs-computer-use\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/computer-using-agents-cua.md#4\",\n    \"claim\": \"I Copilot Studio (GA) kan CUA-verktøyet velge mellom modellene: OpenAI Computer-Using Agent (GA, standard) | Anthropic Claude Sonnet 4.5 (GA, standard) | Anthropic Claude Sonnet 4.6 (Experimental, standard) | Anthropic Claude Opus 4.6 (Experimental, premium).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/microsoft-copilot-studio/computer-use\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/computer-using-agents-cua.md#5\",\n    \"claim\": \"CUA støtter handlingstypene: screenshot | click | double_click | type | key | scroll | drag | navigate.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/microsoft-copilot-studio/computer-use\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/computer-using-agents-cua.md#6\",\n    \"claim\": \"Machine-alternativer for hvor Copilot Studio CUA kjøres: Hosted browser (preview) | Cloud PC pool (preview) | Bring-your-own-machine.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/microsoft-copilot-studio/configure-where-computer-use-runs\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/computer-using-agents-cua.md#7\",\n    \"claim\": \"Credential-/tilgangskonfigurasjoner i Copilot Studio CUA: Maker-provided credentials | End user credentials | Intern Power Platform-lagring | Azure Key Vault | Access control.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/microsoft-copilot-studio/computer-use\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/computer-using-agents-cua.md#8\",\n    \"claim\": \"Fakturering i Copilot Studio (GA): standardmodeller (OpenAI CUA, Claude Sonnet 4.5/4.6) koster 5 Copilot Credits per steg, premiummodell (Claude Opus 4.6) koster 15 Copilot Credits per steg.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/microsoft-copilot-studio/computer-use\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/computer-using-agents-cua.md#9\",\n    \"claim\": \"Foundry Agent Service computer-use-preview er tilgjengelig i regionene: eastus2 | swedencentral | southindia.\",\n    \"claim_type\": \"region\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/how-to/tools/computer-use\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/computer-using-agents-cua.md#10\",\n    \"claim\": \"Foundry-modellen returnerer pending_safety_checks av typene: malicious_instructions | irrelevant_domain | sensitive_domain.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/how-to/tools/computer-use\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/computer-using-agents-cua.md#11\",\n    \"claim\": \"Browser Automation Tool i Foundry Agent Service er i public preview (august 2025).\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/how-to/tools/browser-automation\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/computer-using-agents-cua.md#12\",\n    \"claim\": \"Modellstøtte: Browser Automation støtter alle GPT-modeller, mens Computer Use Tool kun støtter computer-use-preview.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/how-to/tools/browser-automation\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/computer-using-agents-cua.md#13\",\n    \"claim\": \"Browser Automation-oppsett i Foundry krever azure-ai-agents >= 1.2.0b2.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/how-to/tools/browser-automation\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/computer-using-agents-cua.md#14\",\n    \"claim\": \"CUA-begrensninger: multi-skjerm ikke støttet | hosted machine groups ikke støttet | begrenset støtte for Electron, Java Swing, Unity, spill, CLI, Citrix.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/microsoft-copilot-studio/faqs-computer-use\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/computer-using-agents-cua.md#15\",\n    \"claim\": \"For Copilot Studio CUA (GA) er det tidligere preview-kravet om United States-region ikke lenger oppført i GA-dokumentasjonen.\",\n    \"claim_type\": \"region\",\n    \"evidence_url\": \"https://learn.microsoft.com/microsoft-copilot-studio/computer-use\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/agent-orchestration/computer-using-agents-cua.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/agent-orchestration/foundry-agent-service-ga.md",
    "claim_count": 30,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/agent-orchestration/foundry-agent-service-ga.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/agent-orchestration/foundry-agent-service-ga.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/foundry-agent-service-ga.md#1\",\n    \"claim\": \"Connected Agents tilhører Foundry (classic), er deprecated og pensjoneres 31. mars 2027; multi-agent erstattes av Workflows + A2A-tool i ny Foundry Agent Service.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry-classic/agents/how-to/connected-agents?view=foundry-classic\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/foundry-agent-service-ga.md#2\",\n    \"claim\": \"Foundry Agent Service nådde General Availability (GA) 19. mai 2025.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry-classic/agents/whats-new?view=foundry-classic\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/foundry-agent-service-ga.md#3\",\n    \"claim\": \"Foundry Agent Service støtter modellene GPT-4o | o3 | Llama | Grok | DeepSeek m.fl.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/foundry-agent-service-ga.md#4\",\n    \"claim\": \"Prompt agents (konfig-definert, fullt administrert runtime) er GA.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry-classic/agents/whats-new?view=foundry-classic\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/foundry-agent-service-ga.md#5\",\n    \"claim\": \"Responses API er GA og fungerer som single entry point for alle agenttyper (modell-inferens + tool-orkestrering).\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/foundry-agent-service-ga.md#6\",\n    \"claim\": \"Hosted agents (din egen kode/container) er i Public Preview.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/foundry-agent-service-ga.md#7\",\n    \"claim\": \"Workflows (multi-agent orkestrering) er i Preview.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/foundry-agent-service-ga.md#8\",\n    \"claim\": \"Workflows (multi-agent orkestrering) bruker API-versjon 2025-11-15-preview.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/foundry-agent-service-ga.md#9\",\n    \"claim\": \"A2A-tool (agent-to-agent) er i Preview.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/foundry-agent-service-ga.md#10\",\n    \"claim\": \"Agent tracing og debugging er GA.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry-classic/agents/whats-new?view=foundry-classic\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/foundry-agent-service-ga.md#11\",\n    \"claim\": \"Logic Apps-triggerintegrasjon er GA.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry-classic/agents/whats-new?view=foundry-classic\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/foundry-agent-service-ga.md#12\",\n    \"claim\": \"Memory Store API er i Preview.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/foundry-agent-service-ga.md#13\",\n    \"claim\": \"Innebygde verktøy i Foundry Agent Service: Code Interpreter | File Search | Grounding with Bing Search | Bing Custom Search | SharePoint | Azure Functions | Azure Logic Apps | OpenAPI tool | MCP tool | Deep Research tool | Fabric Data Agent | Morningstar tool.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/foundry-agent-service-ga.md#14\",\n    \"claim\": \"File Search-verktøyet er ikke tilgjengelig i regionene Italy North og Brazil South.\",\n    \"claim_type\": \"region\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/concepts/tool-best-practice?view=foundry#tool-support-by-region-and-model\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/foundry-agent-service-ga.md#15\",\n    \"claim\": \"SharePoint-verktøyet er i Preview (de øvrige innebygde verktøyene er GA).\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/foundry-agent-service-ga.md#16\",\n    \"claim\": \"MCP tool (koble til remote MCP-servere) er GA (juni 2025).\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry-classic/agents/how-to/tools-classic/model-context-protocol-samples?view=foundry-classic\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/foundry-agent-service-ga.md#17\",\n    \"claim\": \"Deep Research tool (o3-deep-research + Bing) er GA (juni 2025).\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/foundry-agent-service-ga.md#18\",\n    \"claim\": \"Hosted agents-rammeverkstøtte: Microsoft Agent Framework (Python + C#) | LangGraph (kun Python) | Custom code (Python + C#).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/foundry-agent-service-ga.md#19\",\n    \"claim\": \"Connected Agents finnes kun i Foundry (classic) og bruker API-versjon 2025-05-15-preview.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry-classic/agents/how-to/connected-agents?view=foundry-classic\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/foundry-agent-service-ga.md#20\",\n    \"claim\": \"Semantic Kernel-integrasjon på .NET krever minimum SK 1.53.1 og pakken Azure.AI.Agents.Persistent 1.0.0.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/semantic-kernel/support/migration/azureagent-foundry-ga-migration-guide\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/foundry-agent-service-ga.md#21\",\n    \"claim\": \"Semantic Kernel-integrasjon på Python krever minimum SK 1.31.0 og pakken azure-ai-agents 1.0.0+.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/semantic-kernel/support/migration/azureagent-foundry-ga-migration-guide\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/foundry-agent-service-ga.md#22\",\n    \"claim\": \"Foundry Agent Service er tilgjengelig i 19 regioner totalt, inkludert Norway East | Sweden Central | West Europe | Germany West Central | France Central | Switzerland North | UK South | East US / East US 2.\",\n    \"claim_type\": \"region\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/concepts/limits-quotas-regions?view=foundry\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/foundry-agent-service-ga.md#23\",\n    \"claim\": \"Maks antall filer per agent/thread er 10 000.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/concepts/limits-quotas-regions?view=foundry\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/foundry-agent-service-ga.md#24\",\n    \"claim\": \"Maks filstørrelse er 512 MB.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/concepts/limits-quotas-regions?view=foundry\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/foundry-agent-service-ga.md#25\",\n    \"claim\": \"Total opplastet filstørrelse er 300 GB.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/concepts/limits-quotas-regions?view=foundry\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/foundry-agent-service-ga.md#26\",\n    \"claim\": \"Maks tokens for vector store-tilknytning er 2 000 000 tokens.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/concepts/limits-quotas-regions?view=foundry\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/foundry-agent-service-ga.md#27\",\n    \"claim\": \"Maks antall meldinger per thread er 100 000.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/concepts/limits-quotas-regions?view=foundry\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/foundry-agent-service-ga.md#28\",\n    \"claim\": \"Maks antall tegn per melding er 1 500 000.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/concepts/limits-quotas-regions?view=foundry\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/foundry-agent-service-ga.md#29\",\n    \"claim\": \"Maks antall verktøy per agent er 128.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/concepts/limits-quotas-regions?view=foundry\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/foundry-agent-service-ga.md#30\",\n    \"claim\": \"Connected agent maks dybde er 2 nivåer.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/agents/concepts/limits-quotas-regions?view=foundry\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/agent-orchestration/foundry-agent-service-ga.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/agent-orchestration/multi-agent-orchestration-patterns.md",
    "claim_count": 7,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/agent-orchestration/multi-agent-orchestration-patterns.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/agent-orchestration/multi-agent-orchestration-patterns.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/multi-agent-orchestration-patterns.md#1\",\n    \"claim\": \"Microsoft Agent Framework sine workflow-orkestreringer (multi-agent orchestration) har status GA.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/agent-framework/user-guide/workflows/orchestrations/overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/multi-agent-orchestration-patterns.md#2\",\n    \"claim\": \"Microsoft tilbyr fem kjerne-orkestreringsmønstre gjennom Microsoft Agent Framework og Semantic Kernel: Sequential | Concurrent | Group Chat | Handoff | Magentic.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/agent-framework/user-guide/workflows/orchestrations/overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/multi-agent-orchestration-patterns.md#3\",\n    \"claim\": \"Semantic Kernel sine orkestreringsmønstre er på experimental-stadiet (under aktiv utvikling).\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/semantic-kernel/frameworks/agent/agent-orchestration/\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/multi-agent-orchestration-patterns.md#4\",\n    \"claim\": \"Durable Agents (Agent Framework + Durable Functions) gir deterministiske multi-agent-orkestreringer med: deterministisk replay etter failure | automatisk conversation state management | checkpoint mellom agent-kall | human-in-the-loop-mønstre med venting (dager/uker uten compute-kostnad).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/agent-framework/user-guide/agents/agent-types/durable-agent/features\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/multi-agent-orchestration-patterns.md#5\",\n    \"claim\": \"Connected Agents (Foundry classic) er DEPRECATED og pensjoneres 2027-03-31.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/architecture/multi-agent-patterns\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/multi-agent-orchestration-patterns.md#6\",\n    \"claim\": \"I ny Foundry Agent Service brukes Workflows med API-versjon 2025-11-15-preview (i tillegg til A2A).\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/architecture/multi-agent-patterns\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/multi-agent-orchestration-patterns.md#7\",\n    \"claim\": \"Copilot Studio Agents er inkludert i Power Apps per-user plan og Microsoft 365 Copilot (med messages/day-grenser).\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/agent-framework/user-guide/workflows/orchestrations/overview\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/agent-orchestration/multi-agent-orchestration-patterns.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/agent-orchestration/tool-use-and-function-calling-patterns.md",
    "claim_count": 13,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/agent-orchestration/tool-use-and-function-calling-patterns.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/agent-orchestration/tool-use-and-function-calling-patterns.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/tool-use-and-function-calling-patterns.md#1\",\n    \"claim\": \"Tool Choice styrer om modellen må, kan eller ikke skal kalle funksjoner, med verdiene: auto | required | none | spesifikk funksjon.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/function-calling\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/tool-use-and-function-calling-patterns.md#2\",\n    \"claim\": \"Tool Choice er støttet i Azure OpenAI API fra og med versjon 2023-12-01.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/function-calling\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/tool-use-and-function-calling-patterns.md#3\",\n    \"claim\": \"Parallell funksjonskalling (flere funksjoner i én respons) støttes av modellene: GPT-4 | GPT-4o | GPT-5-serien | o1/o3-mini.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/function-calling\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/tool-use-and-function-calling-patterns.md#4\",\n    \"claim\": \"Automatisk funksjonsinvokasjon er tilgjengelig i Semantic Kernel (FunctionChoiceBehavior.Auto) og Microsoft Agent Framework.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/semantic-kernel/frameworks/agent/agent-functions\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/tool-use-and-function-calling-patterns.md#5\",\n    \"claim\": \"Structured Outputs (Pydantic-basert skjemavalidering for funksjonsargumenter) er tilgjengelig i Azure OpenAI fra og med gpt-4o 2024-08-06.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/structured-outputs\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/tool-use-and-function-calling-patterns.md#6\",\n    \"claim\": \"Agent-as-Tool eksponerer en agent som funksjon i Agent Framework via AsAIFunction() (C#) og as_tool() (Python).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/agent-framework/tutorials/agents/agent-as-function-tool\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/tool-use-and-function-calling-patterns.md#7\",\n    \"claim\": \"AG-UI backend tool events som streames til klient i sanntid: TOOL_CALL_START | TOOL_CALL_ARGS | TOOL_CALL_END | TOOL_CALL_RESULT.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/agent-framework/integrations/ag-ui/backend-tool-rendering\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/tool-use-and-function-calling-patterns.md#8\",\n    \"claim\": \"Foundry Agent Service støtter function calling via OpenAPI-endepunkter og auto-invocation som managed service, med agent-as-tool via tool composition.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/semantic-kernel/frameworks/agent/agent-functions\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/tool-use-and-function-calling-patterns.md#9\",\n    \"claim\": \"Copilot Studio støtter function calling via Actions og Plugins og automatisk invocation, men støtter ikke structured outputs.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/semantic-kernel/frameworks/agent/agent-functions\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/tool-use-and-function-calling-patterns.md#10\",\n    \"claim\": \"Function calling i Azure OpenAI krever Azure-abonnement og en OpenAI-deployment.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/function-calling\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/tool-use-and-function-calling-patterns.md#11\",\n    \"claim\": \"Semantic Kernel (plugins, auto-invocation) er open source under MIT-lisens.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/semantic-kernel/frameworks/agent/agent-functions\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/tool-use-and-function-calling-patterns.md#12\",\n    \"claim\": \"Foundry Agent Service (managed agents, built-in tools) krever Microsoft Foundry-lisens.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/semantic-kernel/frameworks/agent/agent-functions\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/agent-orchestration/tool-use-and-function-calling-patterns.md#13\",\n    \"claim\": \"Copilot Studio (Actions, Plugins) krever Power Apps/Power Automate Premium eller Copilot Studio-lisens.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/semantic-kernel/frameworks/agent/agent-functions\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/agent-orchestration/tool-use-and-function-calling-patterns.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/api-management/apim-azure-front-door-ai.md",
    "claim_count": 9,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/api-management/apim-azure-front-door-ai.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/api-management/apim-azure-front-door-ai.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/api-management/apim-azure-front-door-ai.md#1\",\n    \"claim\": \"Kapabiliteten som beskrives (Azure Front Door foran APIM for global AI-distribusjon) har status GA (generelt tilgjengelig).\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/frontdoor/front-door-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/apim-azure-front-door-ai.md#2\",\n    \"claim\": \"Bicep-eksemplene bruker ARM API-versjon 2024-02-01 for Microsoft.Cdn/profiles (Azure Front Door) og relaterte ressurstyper (afdEndpoints | originGroups | origins | routes).\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/frontdoor/front-door-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/apim-azure-front-door-ai.md#3\",\n    \"claim\": \"Azure Front Door innebygd DDoS-beskyttelse dekker: L3/L4 DDoS (automatisk for alle Front Door-profiler) | L7 DDoS (via WAF-policyer) | volumetriske angrep (absorberes av det globale nettverket) | protokoll-angrep (filtreres på edge) | applikasjonslag (WAF rate limiting + bot protection).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/frontdoor/front-door-ddos\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/apim-azure-front-door-ai.md#4\",\n    \"claim\": \"Bicep-eksempelet bruker ARM API-versjon 2023-11-01 for Microsoft.Network/ddosProtectionPlans (Azure DDoS Protection Plan).\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/frontdoor/front-door-ddos\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/apim-azure-front-door-ai.md#5\",\n    \"claim\": \"Bicep-eksempelet bruker ARM API-versjon 2024-02-01 for Microsoft.Network/FrontDoorWebApplicationFirewallPolicies (Front Door WAF-policy).\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/afds-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/apim-azure-front-door-ai.md#6\",\n    \"claim\": \"Front Door WAF bruker det managed rule set Microsoft_DefaultRuleSet versjon 2.1.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/afds-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/apim-azure-front-door-ai.md#7\",\n    \"claim\": \"Front Door WAF bruker det managed rule set Microsoft_BotManagerRuleSet versjon 1.1.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/afds-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/apim-azure-front-door-ai.md#8\",\n    \"claim\": \"Kostnadsoversikten angir APIM-nivået Standard v2 som SKU/prisnivå for Azure API Management.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/front-door-api-management\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/apim-azure-front-door-ai.md#9\",\n    \"claim\": \"Front Door Premium er nødvendig for Private Link til APIM og WAF Managed Rules; Front Door Standard-tier mangler Private Link og WAF Managed Rules.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/frontdoor/front-door-overview\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/api-management/apim-azure-front-door-ai.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/api-management/apim-vs-direct-access-comparison.md",
    "claim_count": 8,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/api-management/apim-vs-direct-access-comparison.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/api-management/apim-vs-direct-access-comparison.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/api-management/apim-vs-direct-access-comparison.md#1\",\n    \"claim\": \"Azure API Management tilbys i tier-ene Standard v2 og Premium, der Premium støtter multi-region deployment (flere scale units).\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/genai-gateway-capabilities\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/apim-vs-direct-access-comparison.md#2\",\n    \"claim\": \"Azure API Management tilbyr innebygde sikkerhetspolicyer for AI-gateway: OAuth 2.0-validering | IP-filtrering | Content Safety | Prompt Shield | mTLS | managed identity | nøkkelrotasjon via Key Vault.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/genai-gateway-capabilities\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/apim-vs-direct-access-comparison.md#3\",\n    \"claim\": \"Azure API Management har en policy kalt llm-token-limit for å håndheve token-kvoter per team.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/genai-gateway-capabilities\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/apim-vs-direct-access-comparison.md#4\",\n    \"claim\": \"Azure API Management styrer modell-tilgangskontroll via Products og subscriptions.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/genai-gateway-capabilities\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/apim-vs-direct-access-comparison.md#5\",\n    \"claim\": \"Azure API Management har en policy kalt llm-emit-token-metric for å sende token-metrikker med dimensjoner (f.eks. API og Subscription).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/genai-gateway-capabilities\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/apim-vs-direct-access-comparison.md#6\",\n    \"claim\": \"Azure OpenAI tilbyr deployment-typen Global Standard, som ruter automatisk til regioner med tilgjengelig kapasitet.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/genai-gateway-capabilities\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/apim-vs-direct-access-comparison.md#7\",\n    \"claim\": \"Azure API Management tilbyr innebygde reliability-kapabiliteter for Azure OpenAI: backend pools | circuit breaker | multi-region routing.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/genai-gateway-capabilities\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/apim-vs-direct-access-comparison.md#8\",\n    \"claim\": \"Azure API Management støtter semantic caching for Azure OpenAI som ytelses- og kostnadsoptimalisering.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/genai-gateway-capabilities\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/api-management/apim-vs-direct-access-comparison.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/api-management/caching-strategies-apim-ai.md",
    "claim_count": 10,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/api-management/caching-strategies-apim-ai.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/api-management/caching-strategies-apim-ai.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/api-management/caching-strategies-apim-ai.md#1\",\n    \"claim\": \"Semantisk caching for AI-svar i Azure API Management er GA (generelt tilgjengelig).\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/caching-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/caching-strategies-apim-ai.md#2\",\n    \"claim\": \"Azure API Management stotter to hovedtyper caching: intern (innebygd) | ekstern (Redis-basert).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/caching-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/caching-strategies-apim-ai.md#3\",\n    \"claim\": \"Semantisk caching av AI-svar i APIM krever ekstern cache via Azure Managed Redis med RediSearch-modulen aktivert.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/azure-openai-enable-semantic-caching\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/caching-strategies-apim-ai.md#4\",\n    \"claim\": \"Semantisk caching krever en embeddings-deployment med modellen text-embedding-ada-002 eller nyere.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/azure-openai-enable-semantic-caching\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/caching-strategies-apim-ai.md#5\",\n    \"claim\": \"Alle APIM-tiers stotter semantisk caching nar ekstern cache brukes.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/azure-openai-enable-semantic-caching\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/caching-strategies-apim-ai.md#6\",\n    \"claim\": \"APIM tilbyr semantiske caching-policyer: azure-openai-semantic-cache-lookup | azure-openai-semantic-cache-store | llm-semantic-cache-lookup | llm-semantic-cache-store.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/llm-semantic-cache-lookup-policy\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/caching-strategies-apim-ai.md#7\",\n    \"claim\": \"Azure Managed Redis tilbys i SKU-en Balanced B1.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/caching-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/caching-strategies-apim-ai.md#8\",\n    \"claim\": \"Semantisk caching stottes kun av ekstern (Redis) cache, ikke av intern cache i APIM.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-cache-external\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/caching-strategies-apim-ai.md#9\",\n    \"claim\": \"Intern cache er ikke tilgjengelig i Consumption-tier; ekstern (Redis) cache er tilgjengelig i alle tiers.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/caching-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/caching-strategies-apim-ai.md#10\",\n    \"claim\": \"Intern cache har persistent lagring i v2-tier, men ikke i classic; ekstern (Redis) cache har persistent lagring.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/caching-overview\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/api-management/caching-strategies-apim-ai.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/api-management/cost-tracking-apim-policies.md",
    "claim_count": 6,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/api-management/cost-tracking-apim-policies.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/api-management/cost-tracking-apim-policies.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/api-management/cost-tracking-apim-policies.md#1\",\n    \"claim\": \"APIM-policyen `llm-emit-token-metric` tillater maks 5 custom dimensions per policy (Azure Monitor-grense; 5 default-dimensjoner brukes allerede av tjenesten).\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/llm-emit-token-metric-policy\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/cost-tracking-apim-policies.md#2\",\n    \"claim\": \"`llm-emit-token-metric` virker for OpenAI Chat Completions/Responses | Anthropic Messages API | Google Vertex AI.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/llm-emit-token-metric-policy\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/cost-tracking-apim-policies.md#3\",\n    \"claim\": \"Støtte for Anthropic Messages API i `llm-emit-token-metric` krever API Management v2-tiers.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/llm-emit-token-metric-policy\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/cost-tracking-apim-policies.md#4\",\n    \"claim\": \"Token-kategoriene i `llm-emit-token-metric` omfatter prompt | completion | total | cached | reasoning | thinking.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/llm-emit-token-metric-policy\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/cost-tracking-apim-policies.md#5\",\n    \"claim\": \"Cached-, reasoning- og thinking-tokens i `llm-emit-token-metric` er i preview.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/llm-emit-token-metric-policy\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/cost-tracking-apim-policies.md#6\",\n    \"claim\": \"PTU (Provisioned Throughput) faktureres per time uavhengig av faktisk bruk.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/cost-management-billing/costs/overview-cost-management\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/api-management/cost-tracking-apim-policies.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/api-management/developer-portal-ai-apis.md",
    "claim_count": 8,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/api-management/developer-portal-ai-apis.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/api-management/developer-portal-ai-apis.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/api-management/developer-portal-ai-apis.md#1\",\n    \"claim\": \"Azure API Management Developer Portal er GA (generelt tilgjengelig).\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/developer-portal-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/developer-portal-ai-apis.md#2\",\n    \"claim\": \"Developer Portal tilbyr ut av boksen: API-dokumentasjon med OpenAPI-spesifikasjoner | interaktiv testkonsoll | brukerregistrering | API-nøkkelhåndtering | bruksanalyse.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/developer-portal-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/developer-portal-ai-apis.md#3\",\n    \"claim\": \"Developer Portal kan tilpasses på områdene: Visuelt design | Sidelayout | Egendefinert innhold | Widgets | Custom HTML/CSS | Self-hosting (åpen kildekode-kodebase).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-developer-portal-customize\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/developer-portal-ai-apis.md#4\",\n    \"claim\": \"Bicep/ARM-ressurstypen Microsoft.ApiManagement/service/products bruker API-versjon 2023-09-01-preview.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/developer-portal-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/developer-portal-ai-apis.md#5\",\n    \"claim\": \"Et APIM-abonnement gir to API-nøkler: primær og sekundær.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/api-management-subscriptions\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/developer-portal-ai-apis.md#6\",\n    \"claim\": \"Developer Portal støtter identitetsleverandørene Username and Password | Azure Active Directory (Microsoft Entra ID).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-developer-portal-customize\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/developer-portal-ai-apis.md#7\",\n    \"claim\": \"I motsetning til Developer Portal støtter Azure API Center MCP-server-registrering | Copilot Studio-connector | omfattende governance-metadata | automatisk synkronisering fra APIM.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-center/register-discover-mcp-server\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/developer-portal-ai-apis.md#8\",\n    \"claim\": \"Developer Portal er tilgjengelig i alle APIM-tiers unntatt Consumption: Developer | Basic | Standard | Premium (classic) | Basic v2 | Standard v2 | Premium v2.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/developer-portal-overview\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/api-management/developer-portal-ai-apis.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/api-management/genai-gateway-policies.md",
    "claim_count": 12,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/api-management/genai-gateway-policies.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/api-management/genai-gateway-policies.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/api-management/genai-gateway-policies.md#1\",\n    \"claim\": \"GenAI-spesifikke APIM AI gateway-policyer er GA (generelt tilgjengelig).\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/ai-services/content-safety/concepts/jailbreak-detection\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/genai-gateway-policies.md#2\",\n    \"claim\": \"llm-content-safety policy-attributter: backend-id | shield-prompt | enforce-on-completions.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/llm-content-safety-policy\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/genai-gateway-policies.md#3\",\n    \"claim\": \"Azure AI Content Safety harm-kategorier brukt i llm-content-safety: Hate | Violence | SelfHarm | Sexual.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/llm-content-safety-policy\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/genai-gateway-policies.md#4\",\n    \"claim\": \"Content Safety severity output-types: FourSeverityLevels (nivåer 0, 2, 4, 6) | EightSeverityLevels (nivåer 0-7).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/llm-content-safety-policy\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/genai-gateway-policies.md#5\",\n    \"claim\": \"llm-token-limit token-quota-period støtter periodene Daily | Weekly | Monthly (dag | uke | måned).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/llm-token-limit-policy\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/genai-gateway-policies.md#6\",\n    \"claim\": \"I multi-region deployments teller llm-token-limit og rate-limit separat per regional gateway, mens quota og quota-by-key er globale (én teller per instans).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/genai-gateway-capabilities\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/genai-gateway-policies.md#7\",\n    \"claim\": \"LLM-logging i APIM kan logge prompts og completions med inntil 32768 bytes hver.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-llm-logs\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/genai-gateway-policies.md#8\",\n    \"claim\": \"ApiManagementGatewayLlmLog-skjemaet inneholder feltene TimeGenerated | CorrelationId | OperationName | DeploymentName | ModelName | PromptTokens | CompletionTokens | TotalTokens | RequestMessages | ResponseMessages.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-llm-logs\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/genai-gateway-policies.md#9\",\n    \"claim\": \"GenAI-spesifikke APIM-policyer: llm-content-safety (Inbound) | llm-token-limit (Inbound) | llm-semantic-cache-lookup (Inbound) | llm-semantic-cache-store (Outbound) | llm-emit-token-metric (Outbound).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/genai-gateway-capabilities\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/genai-gateway-policies.md#10\",\n    \"claim\": \"APIM-tiers/SKU-er for GenAI-policy-kompatibilitet: Classic | V2 | Consumption | Self-hosted | Workspace.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/genai-gateway-capabilities\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/genai-gateway-policies.md#11\",\n    \"claim\": \"llm-token-limit støttes på Classic, V2, Self-hosted og Workspace, men ikke på Consumption-tier.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/llm-token-limit-policy\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/genai-gateway-policies.md#12\",\n    \"claim\": \"llm-semantic-cache-lookup og llm-semantic-cache-store støttes ikke på Workspace-tier (støttes på Classic, V2, Consumption og Self-hosted).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/llm-semantic-cache-lookup-policy\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/api-management/genai-gateway-policies.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/api-management/logging-analytics-ai-traffic.md",
    "claim_count": 12,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/api-management/logging-analytics-ai-traffic.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/api-management/logging-analytics-ai-traffic.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/api-management/logging-analytics-ai-traffic.md#1\",\n    \"claim\": \"APIM sine logging- og analysekapabiliteter for AI-trafikk (AI gateway) er GA (generelt tilgjengelig).\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/genai-gateway-capabilities\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/logging-analytics-ai-traffic.md#2\",\n    \"claim\": \"Bicep-/ARM-resurstypene Microsoft.ApiManagement/service/loggers og service/apis/diagnostics bruker API-versjon 2023-09-01-preview.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/genai-gateway-capabilities\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/logging-analytics-ai-traffic.md#3\",\n    \"claim\": \"APIM tilbyr policyene azure-openai-emit-token-metric (for Azure OpenAI-API-er) | llm-emit-token-metric (for generiske LLM-API-er) for å sende token-metrikker til Application Insights.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/llm-emit-token-metric-policy\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/logging-analytics-ai-traffic.md#4\",\n    \"claim\": \"APIM tilbyr emit-metric-policyen for å sende egendefinerte metrikker med dimensjoner til Application Insights.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/emit-metric-policy\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/logging-analytics-ai-traffic.md#5\",\n    \"claim\": \"En custom metric kan ha maksimalt 10 dimensjoner (5 default + 5 custom).\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/emit-metric-policy\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/logging-analytics-ai-traffic.md#6\",\n    \"claim\": \"Maksimalt 50 000 aktive tidsserier per region innen en 12-timers periode for custom metrics.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/emit-metric-policy\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/logging-analytics-ai-traffic.md#7\",\n    \"claim\": \"Default-dimensjonene (5 stk) for custom metrics er Region | Service ID | Service Name | Service Type | + 1 reservert.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/emit-metric-policy\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/logging-analytics-ai-traffic.md#8\",\n    \"claim\": \"APIM diagnostic settings tilbyr kategorien 'Logs related to generative AI gateway' som kan sendes til et Log Analytics workspace.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-llm-logs\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/logging-analytics-ai-traffic.md#9\",\n    \"claim\": \"LLM-meldinger opp til 32 KB logges i én oppføring; større meldinger splittes i 32 KB-biter med sekvensnummer; maks 2 MB per request/response.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-llm-logs\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/logging-analytics-ai-traffic.md#10\",\n    \"claim\": \"Log Analytics-tabellen ApiManagementGatewayLlmLog har kolonnene CorrelationId | OperationName | DeploymentName | PromptTokens | CompletionTokens | TotalTokens | RequestMessages | ResponseMessages.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/apimanagementgatewayllmlog\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/logging-analytics-ai-traffic.md#11\",\n    \"claim\": \"ApiManagementGatewayLlmLog har ingen subscription-kolonne; abonnements-ID (ApimSubscriptionId) ligger i ApiManagementGatewayLogs og må joines på CorrelationId.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/apimanagementgatewayllmlog\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/logging-analytics-ai-traffic.md#12\",\n    \"claim\": \"APIM har et innebygd Azure Monitor-dashboard under Monitoring > Analytics > Language models med token-forbruk over tid | fordeling per modell | request-volum og feilrate | gjennomsnittlig responstid.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/genai-gateway-capabilities#observability-and-governance\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/api-management/logging-analytics-ai-traffic.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/api-management/multi-region-ai-gateway-design.md",
    "claim_count": 9,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/api-management/multi-region-ai-gateway-design.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/api-management/multi-region-ai-gateway-design.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/api-management/multi-region-ai-gateway-design.md#1\",\n    \"claim\": \"APIM Premium (classic)-tier støtter multi-region gateway-deployment med én kontrollplan; den nyere Premium v2-tieren støtter availability zones, men IKKE multi-region deployment.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-deploy-multi-region\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/multi-region-ai-gateway-design.md#2\",\n    \"claim\": \"I APIM multi-region-deployment ligger management plane og developer portal kun i primærregionen, mens gateway-komponenten replikeres til alle konfigurerte regioner, og policy-konfigurasjon propageres automatisk til alle regioner (< 10 sek).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-deploy-multi-region\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/multi-region-ai-gateway-design.md#3\",\n    \"claim\": \"Bicep/ARM-ressursen Microsoft.ApiManagement/service bruker API-versjon 2023-09-01-preview.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/foundry-models/concepts/deployment-types\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/multi-region-ai-gateway-design.md#4\",\n    \"claim\": \"Azure Traffic Manager routing-metoder som kan brukes med APIM regionale endepunkter: Geographic | Performance | Priority | Weighted.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/foundry-models/concepts/deployment-types\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/multi-region-ai-gateway-design.md#5\",\n    \"claim\": \"APIM AI gateway tilbyr semantisk caching via policyene llm-semantic-cache-lookup og llm-semantic-cache-store (med Azure Managed Redis som backend).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/genai-gateway-capabilities\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/multi-region-ai-gateway-design.md#6\",\n    \"claim\": \"APIM AI gateway tilbyr policyen llm-emit-token-metric for å emittere token-metrikker med egendefinerte dimensjoner.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/genai-gateway-capabilities\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/multi-region-ai-gateway-design.md#7\",\n    \"claim\": \"Azure OpenAI deployment types og dataresidens: Standard (data i angitt region) | Provisioned/PTU (data i angitt region) | Data Zone Standard (data innenfor Azure/europeisk data zone) | Global Standard (data kan prosesseres i enhver region).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/deployment-types\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/multi-region-ai-gateway-design.md#8\",\n    \"claim\": \"APIM i VNet krever NSG-porter: 3443 inbound (management traffic), 443 inbound (klienttrafikk/HTTPS), 1433 outbound (Azure SQL i primærregion, påkrevd fra alle regioner) og 443 outbound (Azure Storage, Azure Monitor, Key Vault).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry/foundry-models/concepts/deployment-types\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/multi-region-ai-gateway-design.md#9\",\n    \"claim\": \"Rate-limiting-policyer (rate-limit, llm-token-limit) i APIM teller separat per regional gateway, slik at en TPM-grense gjelder per region og ikke totalt på tvers av regioner.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/genai-gateway-capabilities\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/api-management/multi-region-ai-gateway-design.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/api-management/request-response-transformation-ai.md",
    "claim_count": 8,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/api-management/request-response-transformation-ai.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/api-management/request-response-transformation-ai.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/api-management/request-response-transformation-ai.md#1\",\n    \"claim\": \"APIM request/response-transformasjon for AI-API-er (AI gateway-kapabiliteter) har status GA.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/genai-gateway-capabilities\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/request-response-transformation-ai.md#2\",\n    \"claim\": \"Azure API Management (APIM) tilbyr over 75 innebygde policies for transformasjon av forespørsler og svar.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/genai-gateway-capabilities\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/request-response-transformation-ai.md#3\",\n    \"claim\": \"Transformasjonspolicies i APIM opererer i fire faser: inbound | backend | outbound | on-error.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/genai-gateway-capabilities\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/request-response-transformation-ai.md#4\",\n    \"claim\": \"Azure OpenAI bruker endepunkt-format /openai/deployments/{id}/chat/completions (auth: API Key / Entra ID), og Microsoft Foundry bruker /models/chat/completions (auth: Managed Identity).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/genai-gateway-capabilities\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/request-response-transformation-ai.md#5\",\n    \"claim\": \"APIM tilbyr en unified model API som foreløpig er i Preview, tilgjengelig i classic-tiers via AI Gateway early-release-kanal.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/unified-model-api\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/request-response-transformation-ai.md#6\",\n    \"claim\": \"APIM unified model API eksponerer flere LLM-backends (OpenAI Chat Completions | Anthropic Messages) bak ett OpenAI-kompatibelt endepunkt, med automatisk format-translasjon, modell-aliaser, failover på tvers av leverandører og felles policy-governance.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/unified-model-api\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/request-response-transformation-ai.md#7\",\n    \"claim\": \"api-version for Azure OpenAI chat completions settes til 2024-08-01-preview.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/genai-gateway-capabilities\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/request-response-transformation-ai.md#8\",\n    \"claim\": \"Bicep-eksempelet bruker ARM API-versjon 2023-09-01-preview for Microsoft.ApiManagement/service, /apis og /operations.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/genai-gateway-capabilities\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/api-management/request-response-transformation-ai.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/api-management/security-hardening-ai-gateway.md",
    "claim_count": 8,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/api-management/security-hardening-ai-gateway.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/api-management/security-hardening-ai-gateway.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/api-management/security-hardening-ai-gateway.md#1\",\n    \"claim\": \"Sikkerhetsherding for AI-gateways i Azure API Management (genAI-gateway-kapabiliteter) er merket som GA (generelt tilgjengelig).\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/genai-gateway-capabilities\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/security-hardening-ai-gateway.md#2\",\n    \"claim\": \"Azure API Management som AI gateway tilbyr over 20 sikkerhetspolicies, fra IP-filtrering og sertifikatvalidering til AI-spesifikk innholdsmoderasjon og prompt injection-forebygging.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/genai-gateway-capabilities#security-and-safety\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/security-hardening-ai-gateway.md#3\",\n    \"claim\": \"APIM VNet-moduser: External (internett-tilgang via gateway, VNet-tilgang) | Internal (ingen internett-tilgang, kun VNet-tilgang) | VNet Integration (utgående til VNet, anbefalt for Standard v2-tier).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/genai-gateway-capabilities\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/security-hardening-ai-gateway.md#4\",\n    \"claim\": \"Bicep-eksemplet bruker ARM API-versjon 2023-09-01-preview for ressurstypen Microsoft.ApiManagement/service.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/genai-gateway-capabilities\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/security-hardening-ai-gateway.md#5\",\n    \"claim\": \"APIM Premium-tier støtter Internal VNet-modus (virtualNetworkType 'Internal') for VNet-injeksjon.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/genai-gateway-capabilities\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/security-hardening-ai-gateway.md#6\",\n    \"claim\": \"APIM llm-content-safety policy (shield-prompt) integrerer Azure AI Content Safety med moderasjonskategoriene Hate | Violence | SelfHarm | Sexual.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/llm-content-safety-policy\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/security-hardening-ai-gateway.md#7\",\n    \"claim\": \"Microsoft Prompt Shields (levert via Microsoft Entra Global Secure Access) tilbyr: Jailbreak-deteksjon | Indirect injection-deteksjon | Data exfiltration-blokkering | nettverksnivå-enforcement (uavhengig av applikasjonskode).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/entra/global-secure-access/how-to-ai-prompt-shield\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/security-hardening-ai-gateway.md#8\",\n    \"claim\": \"APIM validate-client-certificate policy støtter attributtene validate-revocation, validate-trust, validate-not-before og validate-not-after for validering av klientsertifikat.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-mutual-certificates-for-clients\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/api-management/security-hardening-ai-gateway.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/api-management/streaming-support-apim.md",
    "claim_count": 5,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/api-management/streaming-support-apim.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/api-management/streaming-support-apim.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/api-management/streaming-support-apim.md#1\",\n    \"claim\": \"Streaming-støtte i APIM for AI-responser (AI gateway-kapabilitet) har status GA (generelt tilgjengelig).\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/genai-gateway-capabilities\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/streaming-support-apim.md#2\",\n    \"claim\": \"APIM støtter SSE-streaming på Classic- og v2-tiers, men Consumption-tier støttes IKKE.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/how-to-server-sent-events\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/streaming-support-apim.md#3\",\n    \"claim\": \"Azure Load Balancer, som brukes i APIM-infrastrukturen, har en standard idle timeout på 4 minutter (240 sekunder) som ikke er konfigurerbar i APIM.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/genai-gateway-capabilities\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/streaming-support-apim.md#4\",\n    \"claim\": \"Standardverdien for forward-request-policyens timeout-attributt er 300 sekunder.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/forward-request-policy\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/streaming-support-apim.md#5\",\n    \"claim\": \"Azure OpenAI chat completions kalles med api-version 2024-10-21.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/foundry/openai/reference#chat-completions\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/api-management/streaming-support-apim.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/api-management/versioning-ai-api-endpoints.md",
    "claim_count": 5,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/api-management/versioning-ai-api-endpoints.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/api-management/versioning-ai-api-endpoints.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/api-management/versioning-ai-api-endpoints.md#1\",\n    \"claim\": \"Azure API Management tilbyr tre versjoneringsstrategier: URL-path | header | query string, i tillegg til revisjonsstyring for ikke-brytende endringer.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/api-management-versions\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/versioning-ai-api-endpoints.md#2\",\n    \"claim\": \"ARM-ressursene Microsoft.ApiManagement/service/apiVersionSets og Microsoft.ApiManagement/service/apis bruker API-versjon 2023-09-01-preview.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/genai-gateway-capabilities\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/versioning-ai-api-endpoints.md#3\",\n    \"claim\": \"APIM-egenskapen versioningScheme på apiVersionSets støtter verdiene Segment (URL-path) | Header | Query.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/api-management/api-management-versions\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/versioning-ai-api-endpoints.md#4\",\n    \"claim\": \"Azure OpenAI-modellen gpt-4o har modellversjoner (snapshots) 2024-05-13 | 2024-08-06 | 2024-11-20.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/genai-gateway-capabilities\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/api-management/versioning-ai-api-endpoints.md#5\",\n    \"claim\": \"Azure OpenAI-modellen gpt-4o-mini har modellversjon (snapshot) 2024-07-18.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/api-management/genai-gateway-capabilities\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/api-management/versioning-ai-api-endpoints.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/data-engineering/cross-cloud-data-integration.md",
    "claim_count": 6,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/data-engineering/cross-cloud-data-integration.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/data-engineering/cross-cloud-data-integration.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/cross-cloud-data-integration.md#1\",\n    \"claim\": \"OneLake shortcuts og external data sharing for krysssky-dataintegrasjon i Microsoft Fabric er GA (generelt tilgjengelig).\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/governance/external-data-sharing-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/cross-cloud-data-integration.md#2\",\n    \"claim\": \"OneLake shortcut-kilder med shortcut-type og autentisering: Azure Data Lake Gen2 (ADLS shortcut, service principal/account key) | Amazon S3 (S3 shortcut, IAM access key/secret) | Google Cloud Storage (GCS shortcut, service account JSON) | S3-kompatibel (S3-compatible shortcut, access key/secret) | On-premises (via On-premises Data Gateway/OPDG) | Annen Fabric-tenant (OneLake shortcut, data sharing invitation).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/onelake/onelake-shortcuts\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/cross-cloud-data-integration.md#3\",\n    \"claim\": \"Shortcut-caching er tilgjengelig for eksterne krysssky-kilder (Amazon S3, Google Cloud Storage, S3-kompatibel, on-premises), men ikke for samme-sky Azure Data Lake Gen2 eller cross-tenant OneLake shortcuts.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/onelake/onelake-shortcuts\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/cross-cloud-data-integration.md#4\",\n    \"claim\": \"Fabric multi-cloud connector-katalog (via Pipeline/Dataflow Gen2): AWS S3 | AWS Redshift | Google BigQuery | Google Cloud Storage | Snowflake | Oracle (via OPDG) | SAP HANA | MongoDB Atlas; OneLake shortcut støttes kun for AWS S3 og Google Cloud Storage, øvrige integreres via JDBC/connector.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/cicd/partners/partner-integration\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/cross-cloud-data-integration.md#5\",\n    \"claim\": \"Shortcut-caching-retensjon i OneLake er konfigurerbar fra 1 til 28 dager.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/onelake/onelake-shortcuts\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/cross-cloud-data-integration.md#6\",\n    \"claim\": \"Maksimal filstørrelse for shortcut-caching i OneLake er 1 GB.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/onelake/onelake-shortcuts\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/data-engineering/cross-cloud-data-integration.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/data-engineering/data-anonymization-privacy.md",
    "claim_count": 5,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/data-engineering/data-anonymization-privacy.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/data-engineering/data-anonymization-privacy.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-anonymization-privacy.md#1\",\n    \"claim\": \"Microsoft tilbyr for personvernbeskyttelse: Azure Language PII-deteksjon | Microsoft Purview | SmartNoise (differensiell personvern).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/concept-responsible-ai\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-anonymization-privacy.md#2\",\n    \"claim\": \"Azure Language PII-deteksjon stotter 50+ PII-kategorier.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/ai-services/language-service/personally-identifiable-information/concepts/entity-categories\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-anonymization-privacy.md#3\",\n    \"claim\": \"Azure Language PII-entitetskategorier (Azure-koder): NorwayIdentityNumber | Person | Address | PhoneNumber | Email | InternationalBankingAccountNumber | Organization | HealthcareEntities.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/ai-services/language-service/personally-identifiable-information/concepts/entity-categories\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-anonymization-privacy.md#4\",\n    \"claim\": \"Microsoft Purview Data Map brukes til a identifisere/kartlegge persondata (produktkomponent i Microsoft Purview).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/purview/data-governance-master-data-management\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-anonymization-privacy.md#5\",\n    \"claim\": \"Azure Language PII-deteksjon stotter norsk sprak (language=\\\"no\\\").\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/ai-services/language-service/personally-identifiable-information/overview\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/data-engineering/data-anonymization-privacy.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/data-engineering/data-cataloging-discovery.md",
    "claim_count": 11,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/data-engineering/data-cataloging-discovery.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/data-engineering/data-cataloging-discovery.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-cataloging-discovery.md#1\",\n    \"claim\": \"Microsoft Purview Unified Catalog (datastyring / data governance) er generelt tilgjengelig (GA).\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/purview/unified-catalog\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-cataloging-discovery.md#2\",\n    \"claim\": \"Purview kan skanne/registrere datakilder i kategoriene: Microsoft Fabric | Azure Data (SQL Database, ADLS Gen2, Cosmos DB, Synapse) | On-premises (SQL Server, Oracle, file shares via Self-hosted Integration Runtime) | SaaS (Dataverse, Salesforce, SAP) | Multi-cloud (AWS S3, Google BigQuery via cross-cloud connectors).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/purview/data-governance-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-cataloging-discovery.md#3\",\n    \"claim\": \"Ved Fabric-tenant-skanning inventerer Purview følgende elementer per Fabric-opplevelse: Data Engineering (Lakehouse, Notebook, Spark Job Definition, SQL Endpoint) | Data Factory (Data Pipeline, Dataflow Gen2) | Data Science (Experiment, ML Model) | Data Warehouse (Warehouse) | Real-Time Analytics (KQL Database, KQL Queryset) | Power BI (Semantic Model, Report, Dashboard, Dataflow, Datamart).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/governance/microsoft-purview-fabric\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-cataloging-discovery.md#4\",\n    \"claim\": \"Purview har innebygde klassifiseringer identifisert som: MICROSOFT.GOVERNMENT.NORWAY.NATIONAL.ID.NUMBER | MICROSOFT.FINANCIAL.CREDIT_CARD_NUMBER | MICROSOFT.PERSONAL.EMAIL | MICROSOFT.PERSONAL.PHONE_NUMBER.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/purview/data-governance-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-cataloging-discovery.md#5\",\n    \"claim\": \"Naturlig språk-søk (AI-drevet søk med forretningskontekst) i Purview Unified Catalog er i preview.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/purview/unified-catalog\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-cataloging-discovery.md#6\",\n    \"claim\": \"Unified Catalog tilbyr oppdagelsesmetodene: Nøkkelordsøk | Naturlig språk (preview) | Governance domain-browsing | Data product-søk | Filtreringsbasert (fasettert) søk.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/purview/unified-catalog\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-cataloging-discovery.md#7\",\n    \"claim\": \"Business glossary i Unified Catalog består av komponentene: Glossary Terms | Synonymer | Akronymer | Hierarki (Parent/child) | Custom Attributes | Ressurser.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/purview/unified-catalog-glossary-terms\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-cataloging-discovery.md#8\",\n    \"claim\": \"Purview Unified Catalog definerer rollene: Unified Catalog Reader (Global Catalog Reader) | Local Catalog Reader | Governance Domain Creator | Data Product Owner | Data Steward | Data Health Reader | Data Profile Reader.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/purview/data-governance-roles-permissions\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-cataloging-discovery.md#9\",\n    \"claim\": \"Unified Catalog støtter OKR-er (OKRs) som styringsartefakt for datastyring.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/purview/unified-catalog-okrs\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-cataloging-discovery.md#10\",\n    \"claim\": \"Purview Data Estate Health tilbyr Health Controls (automatisk evaluering), Health Actions (forbedringsaksjoner) og en samlet Health Score.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/purview/data-governance-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-cataloging-discovery.md#11\",\n    \"claim\": \"Purview Analytics in OneLake gir tilgang til katalog-metadata i Fabric/OneLake for videre bruksanalyse.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/governance/microsoft-purview-fabric\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/data-engineering/data-cataloging-discovery.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/data-engineering/data-mesh-patterns.md",
    "claim_count": 10,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/data-engineering/data-mesh-patterns.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/data-engineering/data-mesh-patterns.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-mesh-patterns.md#1\",\n    \"claim\": \"Microsoft Fabric støtter data mesh-arkitektur gjennom domener | OneLake shortcuts | foderert governance.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/governance/onelake-catalog-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-mesh-patterns.md#2\",\n    \"claim\": \"Roller i Fabric domenestyring: Fabric Admin | Domain Admin | Domain Contributor | Data Producer | Data Consumer.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/governance/onelake-catalog-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-mesh-patterns.md#3\",\n    \"claim\": \"Fabric-domener opprettes via admin-portalen eller Fabric REST API.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/governance/onelake-catalog-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-mesh-patterns.md#4\",\n    \"claim\": \"OneLake bruker Delta Lake / Parquet som standard delingsformat for interoperable dataprodukter.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/governance/onelake-catalog-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-mesh-patterns.md#5\",\n    \"claim\": \"OneLake shortcuts er den primære mekanismen for datadeling mellom domener uten å kopiere data.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/governance/onelake-catalog-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-mesh-patterns.md#6\",\n    \"claim\": \"Cross-tenant datadeling krever at Fabric admin aktiverer External Data Sharing i begge tenants, og data forblir read-only for mottaker.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/governance/onelake-catalog-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-mesh-patterns.md#7\",\n    \"claim\": \"Fabric lar tenant-administratorer delegere innstillinger per domene: egne sertifiseringsregler | egne sensitivitetsetiketter (default label) | egne godkjennere for dataprodukt-sertifisering.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/governance/onelake-catalog-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-mesh-patterns.md#8\",\n    \"claim\": \"OneLake Catalog-funksjoner: Explore-fane | Domenefilter | Endorsements | Govern-fane | Secure-fane.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/governance/onelake-catalog-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-mesh-patterns.md#9\",\n    \"claim\": \"Medallion-lag per domene i Fabric-arbeidsområder: bronze (inntak) | silver (transformasjon) | gold (servering).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/governance/onelake-catalog-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-mesh-patterns.md#10\",\n    \"claim\": \"Default domains kan automatisk tilordne nye arbeidsomrader til riktig domene basert på hvem som oppretter dem.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/governance/onelake-catalog-overview\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/data-engineering/data-mesh-patterns.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/data-engineering/data-pipeline-orchestration.md",
    "claim_count": 8,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/data-engineering/data-pipeline-orchestration.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/data-engineering/data-pipeline-orchestration.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-pipeline-orchestration.md#1\",\n    \"claim\": \"Microsoft tilbyr to hovedplattformer for datapipeline-orkestrering: Fabric Data Factory | Azure Data Factory.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/data-factory/data-factory-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-pipeline-orchestration.md#2\",\n    \"claim\": \"Fabric Data Factory har native integrasjon mot OneLake | Lakehouse | Warehouse | notebooks.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/data-factory/data-factory-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-pipeline-orchestration.md#3\",\n    \"claim\": \"Azure Data Factory (klassisk) gir hybrid-stotte og bredere tilkobling via self-hosted integration runtime.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/architecture/data-guide/technology-choices/pipeline-orchestration-data-movement\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-pipeline-orchestration.md#4\",\n    \"claim\": \"Fabric Data Factory har fire trigger-typer: Schedule | Tumbling Window | Event-based | On-demand.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/data-factory/pipeline-runs\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-pipeline-orchestration.md#5\",\n    \"claim\": \"Fabric-pipelines kjores/planlegges via Fabric REST API v1-endepunktet /workspaces/{id}/items/{id}/jobs/instances?jobType=Pipeline.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/data-factory/pipeline-rest-api-capabilities\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-pipeline-orchestration.md#6\",\n    \"claim\": \"Fabric Data Factory stotter fire typer aktivitetsavhengigheter: Succeeded | Failed | Completed | Skipped.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/data-factory/pipeline-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-pipeline-orchestration.md#7\",\n    \"claim\": \"Standardverdier for aktivitets-retry-policy: retry = 0, retryIntervalInSeconds = 30 sekunder, timeout = 7 dager.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/data-factory/data-factory-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-pipeline-orchestration.md#8\",\n    \"claim\": \"Fabric Data Factory stotter Apache Airflow-jobber for komplekse DAG-baserte arbeidsflyter.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/data-factory/create-apache-airflow-jobs\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/data-engineering/data-pipeline-orchestration.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/data-engineering/data-quality-ai-frameworks.md",
    "claim_count": 18,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/data-engineering/data-quality-ai-frameworks.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/data-engineering/data-quality-ai-frameworks.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-quality-ai-frameworks.md#1\",\n    \"claim\": \"Microsoft-stacken tilbyr fire hovedspor for data quality management i AI: Microsoft Purview Data Quality | Azure Machine Learning Model Monitoring | Microsoft Fabric data quality | Azure Databricks expectations (Delta Live Tables/DLT).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/machine-learning/concept-model-monitoring\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-quality-ai-frameworks.md#2\",\n    \"claim\": \"Det finnes seks industristandard datakvalitetsdimensjoner: Completeness | Accuracy | Consistency | Timeliness | Uniqueness | Conformity.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/cloud-scale-analytics/govern-data-quality\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-quality-ai-frameworks.md#3\",\n    \"claim\": \"Microsoft Purview Data Quality tilbyr kapabilitetene: AI-powered profiling | No-code/low-code rules (out-of-box + AI-generated + custom) | Data quality scoring (column → data asset → data product → governance domain) | Alerts (email ved threshold breaches) | Actions center (diagnostic queries).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/purview/data-quality-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-quality-ai-frameworks.md#4\",\n    \"claim\": \"Microsoft Purview Data Quality støtter multi-cloud datakilder: Azure (Blob Storage | ADLS Gen2 | Azure SQL DB | Synapse | Fabric Lakehouse i Delta/Iceberg-format) | AWS (S3 med Parquet/CSV/Delta | RDS) | GCP (BigQuery).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/purview/data-quality-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-quality-ai-frameworks.md#5\",\n    \"claim\": \"Microsoft Purview Data Quality støtter Managed Identity som eneste autentiseringsmetode.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/purview/data-quality-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-quality-ai-frameworks.md#6\",\n    \"claim\": \"Azure ML Model Monitoring 'Data drift'-signalet bruker metrikkene: Jensen-Shannon Distance | PSI | Normalized Wasserstein | KS test | Chi-squared.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/concept-model-monitoring\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-quality-ai-frameworks.md#7\",\n    \"claim\": \"Azure ML Model Monitoring 'Prediction drift'-signalet bruker metrikkene: Jensen-Shannon Distance | PSI | Normalized Wasserstein | Chebyshev Distance | KS test | Chi-squared.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/concept-model-monitoring\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-quality-ai-frameworks.md#8\",\n    \"claim\": \"Azure ML Model Monitoring 'Data quality'-signalet bruker metrikkene: Null value rate | Data type error rate | Out-of-bounds rate.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/concept-model-monitoring\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-quality-ai-frameworks.md#9\",\n    \"claim\": \"Azure ML Model Monitoring 'Feature attribution drift'-signalet bruker metrikken Normalized Discounted Cumulative Gain (NDCG).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/concept-model-monitoring\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-quality-ai-frameworks.md#10\",\n    \"claim\": \"Azure ML Model Monitoring 'Model performance'-signalet bruker metrikkene: Accuracy | Precision | Recall | F1 | AUC | MAE | RMSE.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/concept-model-monitoring\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-quality-ai-frameworks.md#11\",\n    \"claim\": \"Fabric Materialized Lake Views constraints støtter to on-mismatch-actions: FAIL (stopper refresh ved første constraint-violation, default) | DROP (fjerner records som ikke møter constraint og gir count i lineage view).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/data-engineering/materialized-lake-views/data-quality\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-quality-ai-frameworks.md#12\",\n    \"claim\": \"I Fabric MLV-constraints støttes innebygde Spark/SQL-funksjoner (UPPER, TRIM, COALESCE, SUBSTRING), UDF-er (spark.udf.register()), Pandas-UDF-er og Fabric User Data Functions; ren regex/LIKE er ikke et eget constraint-konstrukt.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/data-engineering/materialized-lake-views/data-quality\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-quality-ai-frameworks.md#13\",\n    \"claim\": \"Delta Live Tables (DLT) er rebrandet til Lakeflow Spark Declarative Pipelines (SDP); import dlt/@dlt.* fungerer fortsatt, men anbefalt syntaks er nå 'from pyspark import pipelines as dp' + @dp.*.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/databricks/lakehouse-architecture/data-governance/best-practices\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-quality-ai-frameworks.md#14\",\n    \"claim\": \"Databricks/Lakeflow expectations-dekoratorer: @dp.expect (spor violations, la records passere) | @dp.expect_or_drop (drop violating records) | @dp.expect_or_fail (fail pipeline ved violations).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/databricks/lakehouse-architecture/data-governance/best-practices\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-quality-ai-frameworks.md#15\",\n    \"claim\": \"Det finnes ingen native integrasjon mellom Azure ML og Microsoft Purview (per 2026-02).\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/concept-model-monitoring\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-quality-ai-frameworks.md#16\",\n    \"claim\": \"Microsoft Fabric krever F2-kapasitet som minimum, med F64 anbefalt for produksjon.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/data-engineering/materialized-lake-views/data-quality\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-quality-ai-frameworks.md#17\",\n    \"claim\": \"Azure Databricks Premium tier kreves for Unity Catalog, og Delta Live Tables (DLT) er inkludert i Premium tier.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/databricks/lakehouse-architecture/data-governance/best-practices\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-quality-ai-frameworks.md#18\",\n    \"claim\": \"Microsoft Purview Data Quality, Azure ML Model Monitoring, Fabric data quality og Databricks DLT expectations er alle GA (production-ready per 2026-02).\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/machine-learning/concept-model-monitoring\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/data-engineering/data-quality-ai-frameworks.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/data-engineering/data-sampling-labeling.md",
    "claim_count": 5,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/data-engineering/data-sampling-labeling.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/data-engineering/data-sampling-labeling.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-sampling-labeling.md#1\",\n    \"claim\": \"Azure Machine Learning Data Labeling støtter merkeoppgavene: Bildeklassifisering (multi-class og multi-label) | Objektdeteksjon (bounding boxes) | Instanssegmentering (polygoner) | Semantisk segmentering (piksel-nivå) | Tekstklassifisering (single og multi-label) | Named Entity Recognition (tekst-span-merking).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/how-to-label-data\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-sampling-labeling.md#2\",\n    \"claim\": \"Semantisk segmentering (piksel-nivå) i Azure ML Data Labeling er i preview.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/how-to-create-image-labeling-projects\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-sampling-labeling.md#3\",\n    \"claim\": \"Azure ML SDK v2 (azure.ai.ml) tilbyr DataLabelingJob-entiteten for å opprette datamerkingsprosjekter, med labeling_job_type-verdien ImageClassificationMulticlass for bildeklassifisering.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/machine-learning/how-to-label-data\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-sampling-labeling.md#4\",\n    \"claim\": \"ML-assistert merking i Azure ML består av to faser: Fase 1 CLUSTERING (gruppering av lignende bilder) | Fase 2 PRE-LABELING (modellen foreslår etiketter for umerkede bilder).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/how-to-label-data\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-sampling-labeling.md#5\",\n    \"claim\": \"I ML-assistert merking i Azure ML begrenses tekstinnholdet til ~128 ord for treningseffektivitet.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/how-to-label-data\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/data-engineering/data-sampling-labeling.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/data-engineering/data-versioning-lineage.md",
    "claim_count": 5,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/data-engineering/data-versioning-lineage.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/data-engineering/data-versioning-lineage.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-versioning-lineage.md#1\",\n    \"claim\": \"Delta Lake tidsreise (time-travel) støtter to lese-opsjoner: versionAsOf (les en spesifikk versjon) | timestampAsOf (les data slik de var på et gitt tidspunkt).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/governance/lineage\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-versioning-lineage.md#2\",\n    \"claim\": \"Delta Lake DESCRIBE HISTORY (og history()-API-et) returnerer transaksjonshistorikk med kolonnene: version | timestamp | operation | operationParameters | operationMetrics | userName | notebook.notebookId.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/governance/lineage\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-versioning-lineage.md#3\",\n    \"claim\": \"Purview fanger automatisk lineage fra følgende dataprosesseringssystemer: Azure Data Factory (Copy Activity | Data Flow | SSIS) | Fabric Data Factory (Pipelines | Dataflow Gen2) | Fabric Notebooks (Lakehouse → Lakehouse, item-level) | Azure Synapse Analytics (Copy Activity | Data Flow) | Power BI (Semantic Model → Report → Dashboard).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/governance/lineage\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-versioning-lineage.md#4\",\n    \"claim\": \"Lineage i Fabric er tilgjengelig fra fire steder: Workspace toolbar ('Lineage view') | Item options menu (høyreklikk → 'View lineage') | Item details page | Purview Unified Catalog (Browse → Microsoft Fabric → Fabric Workspaces).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/governance/lineage\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/data-versioning-lineage.md#5\",\n    \"claim\": \"Delta Change Data Feed produserer fire _change_type-verdier: insert | update_preimage | update_postimage | delete.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/governance/lineage\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/data-engineering/data-versioning-lineage.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/data-engineering/dataverse-ai-integration.md",
    "claim_count": 11,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/data-engineering/dataverse-ai-integration.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/data-engineering/dataverse-ai-integration.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/dataverse-ai-integration.md#1\",\n    \"claim\": \"Fabric Data Factory sin Dataverse-konnektor tilbyr integrasjonsmonstrene Dataflow Gen2 (kilde) | Pipeline Copy Activity (kilde/dest) | Copy Job (kilde/dest).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/data-factory/connector-dataverse-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/dataverse-ai-integration.md#2\",\n    \"claim\": \"Dataverse-konnektoren i Fabric Data Factory stotter autentisering via Org-konto | Service Principal | Workspace Identity.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/data-factory/connector-dataverse-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/dataverse-ai-integration.md#3\",\n    \"claim\": \"Dataverse-konnektoren i Fabric Data Factory stotter gateway-alternativene Ingen | On-prem | VNet.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/data-factory/connector-dataverse-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/dataverse-ai-integration.md#4\",\n    \"claim\": \"Copy Job for Dataverse-konnektoren stotter modusene Full load | Append | Upsert.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/data-factory/connector-dataverse-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/dataverse-ai-integration.md#5\",\n    \"claim\": \"Dataverse-datatyper med Delta Lake-mapping: Lookup | OptionSet | Money | DateTime | Customer | PartyList.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/data-factory/connector-dataverse-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/dataverse-ai-integration.md#6\",\n    \"claim\": \"Link to Microsoft Fabric lagrer Dataverse-data i formatet Delta Parquet.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/power-apps/maker/data-platform/fabric-link-faq\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/dataverse-ai-integration.md#7\",\n    \"claim\": \"Link to Microsoft Fabric har en synkroniseringslatens pa opptil 60 minutter.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/power-apps/maker/data-platform/fabric-link-faq\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/dataverse-ai-integration.md#8\",\n    \"claim\": \"Link to Fabric-synkronisering poller Dataverse hvert 2. minutt for inkrementelle endringer.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/power-apps/maker/data-platform/fabric-link-faq\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/dataverse-ai-integration.md#9\",\n    \"claim\": \"AI Builder-modelltyper som lagrer resultater i Dataverse: Prediction | Document Processing | Object Detection | Text Classification.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/data-factory/connector-dataverse-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/dataverse-ai-integration.md#10\",\n    \"claim\": \"Dataverse Web API bruker versjon v9.2 (endepunkt /api/data/v9.2/).\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/data-factory/connector-dataverse-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/dataverse-ai-integration.md#11\",\n    \"claim\": \"Dataverse-sikkerhetsmekanismer: Business Units | Security Roles | Row-Level Security | Field-Level Security | Team-based access.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/power-apps/maker/data-platform/fabric-link-faq\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/data-engineering/dataverse-ai-integration.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/data-engineering/delta-lake-parquet-optimization.md",
    "claim_count": 6,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/data-engineering/delta-lake-parquet-optimization.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/data-engineering/delta-lake-parquet-optimization.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/delta-lake-parquet-optimization.md#1\",\n    \"claim\": \"Delta Lake- og Parquet-formatoptimalisering (inkludert V-Order) i Microsoft Fabric har status GA (generelt tilgjengelig).\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/data-engineering/delta-optimization-and-v-order\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/delta-lake-parquet-optimization.md#2\",\n    \"claim\": \"Parquet i Microsoft Fabric støtter komprimeringsalgoritmene Snappy | ZSTD | GZIP | LZ4 | Uncompressed, der Snappy er Fabric-standard.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/data-engineering/delta-optimization-and-v-order\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/delta-lake-parquet-optimization.md#3\",\n    \"claim\": \"Standard Parquet row group-størrelse i Microsoft Fabric er 128 MB.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/data-engineering/delta-optimization-and-v-order\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/delta-lake-parquet-optimization.md#4\",\n    \"claim\": \"Parquet velger automatisk encoding-strategi per datatype i Fabric: Integer/Long → Delta Binary Packed | String (lav kardinalitet) → Dictionary | String (høy kardinalitet) → Plain | Boolean → Run Length | Timestamp → Delta Binary Packed.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/data-engineering/delta-optimization-and-v-order\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/delta-lake-parquet-optimization.md#5\",\n    \"claim\": \"Microsoft Fabric-beregningsmotorene som drar nytte av V-Order er Power BI (Direct Lake) | SQL Endpoint | Apache Spark.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/data-engineering/delta-optimization-and-v-order\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/delta-lake-parquet-optimization.md#6\",\n    \"claim\": \"Standard VACUUM-retensjon for Delta-tabeller i Microsoft Fabric er 7 dager (168 timer).\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/data-engineering/delta-optimization-and-v-order\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/data-engineering/delta-lake-parquet-optimization.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/data-engineering/etl-vs-elt-ai.md",
    "claim_count": 6,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/data-engineering/etl-vs-elt-ai.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/data-engineering/etl-vs-elt-ai.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/etl-vs-elt-ai.md#1\",\n    \"claim\": \"Microsoft Fabric støtter både ETL (Extract, Transform, Load) og ELT (Extract, Load, Transform) samt hybride mønstre.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/data-factory/data-factory-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/etl-vs-elt-ai.md#2\",\n    \"claim\": \"Fabric Lakehouse-medaljongarkitektur består av tre lag: Bronze (rådata i Delta Lake) | Silver (validert) | Gold (ML-features).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/data-factory/data-factory-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/etl-vs-elt-ai.md#3\",\n    \"claim\": \"Dataflow Gen2 er basert på Power Query Online og tilbyr over 300 transformasjoner.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/data-factory/data-factory-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/etl-vs-elt-ai.md#4\",\n    \"claim\": \"Inkrementelle lastingsmønstre i Fabric og deres implementasjon: Full load (Copy Job full load) | Incremental append (Copy Job append + watermark) | CDC (Copy Job CDC, Mirroring) | Watermark (Pipeline med parameter) | Delta load (Copy Job upsert).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/data-factory/data-factory-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/etl-vs-elt-ai.md#5\",\n    \"claim\": \"Fabric CU-metere per komponent: Copy Job/Activity → Data Movement | Dataflow Gen2 → Standard Compute / High Scale Compute | Spark Notebook → Spark Compute | Pipeline Orchestration → Data Orchestration | OneLake Storage → OneLake Storage.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/data-factory/pricing-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/etl-vs-elt-ai.md#6\",\n    \"claim\": \"Copy Job (til forskjell fra Copy Activity) tilbyr automatisk CDC og inkrementell lasting for bulk-lasting.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/data-factory/data-factory-overview\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/data-engineering/etl-vs-elt-ai.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/data-engineering/fabric-lakehouse-architecture.md",
    "claim_count": 10,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/data-engineering/fabric-lakehouse-architecture.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/data-engineering/fabric-lakehouse-architecture.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/fabric-lakehouse-architecture.md#1\",\n    \"claim\": \"Microsoft Fabric Lakehouse har status GA (generelt tilgjengelig).\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/data-engineering/lakehouse-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/fabric-lakehouse-architecture.md#2\",\n    \"claim\": \"Kjernekomponentene i Fabric Lakehouse er: OneLake | Delta Lake | Lakehouse Tables | Lakehouse Files | SQL Analytics Endpoint | Default Semantic Model | Spark Notebooks | Dataflows Gen2 | Shortcuts | V-Order | Starter Pools | Environments.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/data-engineering/lakehouse-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/fabric-lakehouse-architecture.md#3\",\n    \"claim\": \"Fabric Shortcuts kan koble in-place til eksterne datakilder: ADLS Gen2 | Amazon S3 | Databricks.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/data-engineering/lakehouse-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/fabric-lakehouse-architecture.md#4\",\n    \"claim\": \"Medallion architecture i Fabric Lakehouse består av tre lag: Bronze (Raw) | Silver (Enriched) | Gold (Curated).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/onelake/onelake-medallion-lakehouse-architecture\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/fabric-lakehouse-architecture.md#5\",\n    \"claim\": \"Standard oppbevaringstid for slettede Delta-filer (VACUUM / delta.deletedFileRetentionDuration) er 7 dager.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/data-engineering/lakehouse-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/fabric-lakehouse-architecture.md#6\",\n    \"claim\": \"Fabric Lakehouse har dokumenterte integrasjonspunkter med: Azure Machine Learning | Microsoft Foundry | Copilot Studio | Power BI | Azure Databricks | Synapse Analytics | Azure Data Factory | Microsoft Purview | Azure Key Vault.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/data-engineering/lakehouse-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/fabric-lakehouse-architecture.md#7\",\n    \"claim\": \"Power BI Direct Lake mode faller automatisk tilbake til DirectQuery når: semantisk modells tabellstatistikk overskrider capacity guardrails | row-level security (RLS) er aktivert på modellen | modellen refererer views i stedet for direkte OneLake-tabeller.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview#fabric-capacity-requirements\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/fabric-lakehouse-architecture.md#8\",\n    \"claim\": \"Fabric Multi-Geo støtter OneLake data residency i Norway East-regionen.\",\n    \"claim_type\": \"region\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/data-engineering/lakehouse-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/fabric-lakehouse-architecture.md#9\",\n    \"claim\": \"Fabric Capacity lisensieres kapasitetsbasert som F SKU (CU-basert, f.eks. F64 og F128) eller som Premium Per User.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/data-engineering/lakehouse-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/fabric-lakehouse-architecture.md#10\",\n    \"claim\": \"Fabric tilbyr en gratis F64 trial-kapasitet i 60 dager.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/data-engineering/lakehouse-overview\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/data-engineering/fabric-lakehouse-architecture.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/data-engineering/feature-stores-engineering.md",
    "claim_count": 4,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/data-engineering/feature-stores-engineering.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/data-engineering/feature-stores-engineering.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/feature-stores-engineering.md#1\",\n    \"claim\": \"Azure Machine Learning Managed Feature Store er GA (generelt tilgjengelig).\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/machine-learning/concept-what-is-managed-feature-store\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/feature-stores-engineering.md#2\",\n    \"claim\": \"Azure ML Managed Feature Store støtter to materialiseringslagre: offline store på ADLS Gen2 (trening/batch-inferens, Delta/Parquet) | online store på Redis (sanntidsinferens, key-value).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/tutorial-online-materialization-inference\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/feature-stores-engineering.md#3\",\n    \"claim\": \"Data Wrangler i Fabric tilbyr over 300 transformasjoner, AI-drevne forslag (PROSE) og Copilot for naturlig språk til kode.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/data-science/data-wrangler\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/feature-stores-engineering.md#4\",\n    \"claim\": \"Azure ML feature-monitoring støtter metrikkene Jensen-Shannon distance og Population Stability Index (PSI) for numeriske features, og Jensen-Shannon distance for kategoriske features.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/machine-learning/concept-what-is-managed-feature-store\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/data-engineering/feature-stores-engineering.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/data-engineering/lakehouse-architecture-design.md",
    "claim_count": 4,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/data-engineering/lakehouse-architecture-design.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/data-engineering/lakehouse-architecture-design.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/lakehouse-architecture-design.md#1\",\n    \"claim\": \"V-Order er aktivert som standard i Microsoft Fabric ved skriving til Delta-tabeller (skrive-tids-optimalisering av Parquet-filer som gir raskere lesing for alle Fabric-engines).\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/data-engineering/delta-optimization-and-v-order\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/lakehouse-architecture-design.md#2\",\n    \"claim\": \"Deletion Vectors (raskere DELETE/UPDATE uten rewrite) er automatisk aktivert i Fabric fra Runtime 1.2 og nyere.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/data-engineering/delta-optimization-and-v-order\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/lakehouse-architecture-design.md#3\",\n    \"claim\": \"Liquid Clustering er GA i Fabric, erstatter partisjonering/Z-Order og aktiveres manuelt med CLUSTER BY.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/data-engineering/delta-optimization-and-v-order\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/lakehouse-architecture-design.md#4\",\n    \"claim\": \"Medallion-arkitekturen består av tre lag: Bronze (rådata) | Silver (validert/denormalisert data) | Gold (ML-features og aggregater).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/onelake/onelake-medallion-lakehouse-architecture\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/data-engineering/lakehouse-architecture-design.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/data-engineering/master-data-management-ai.md",
    "claim_count": 5,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/data-engineering/master-data-management-ai.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/data-engineering/master-data-management-ai.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/master-data-management-ai.md#1\",\n    \"claim\": \"Master Data Management-kapabiliteten i Microsoft Purview er generelt tilgjengelig (Status: GA).\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/purview/data-governance-master-data-management\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/master-data-management-ai.md#2\",\n    \"claim\": \"Microsoft tilbyr MDM gjennom flere tjenester: Microsoft Purview (data governance og MDM-integrasjoner) | Dataverse (operativt masterdatasystem for Dynamics 365 og Power Platform) | Azure Data Factory (datakvalitet og deduplisering).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/purview/data-governance-master-data-management\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/master-data-management-ai.md#3\",\n    \"claim\": \"Microsoft Dataverse har innebygd duplikatdeteksjon for aktive poster som kontoer og kontakter.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/power-platform/admin/detect-duplicate-records\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/master-data-management-ai.md#4\",\n    \"claim\": \"Dataverse duplikatdeteksjon omfatter funksjonene: Duplikatdeteksjonsregler (matchingkriterier per entitet) | Sanntidssjekk (ved opprettelse/oppdatering) | Bulk-deteksjon (på eksisterende data) | Merge (kombiner duplikater med valg av primærpost).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/power-platform/admin/detect-duplicate-records\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/master-data-management-ai.md#5\",\n    \"claim\": \"Microsoft Purview MDM støtter tredjeparts-integrasjoner for masterdata: CluedIn (eventual connectivity) | Profisee (MDM med Azure-integrasjon).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/purview/data-governance-master-data-management-cluedin\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/data-engineering/master-data-management-ai.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/data-engineering/microsoft-purview-governance.md",
    "claim_count": 12,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/data-engineering/microsoft-purview-governance.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/data-engineering/microsoft-purview-governance.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/microsoft-purview-governance.md#1\",\n    \"claim\": \"Microsoft Purview Data Governance er GA (generelt tilgjengelig).\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/purview/unified-catalog\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/microsoft-purview-governance.md#2\",\n    \"claim\": \"Purview Unified Catalog består av komponentene Data Map | Unified Catalog | Governance Domains | Data Products | Business Glossary.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/purview/unified-catalog\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/microsoft-purview-governance.md#3\",\n    \"claim\": \"Datakilder som kan registreres i Purview: Microsoft Fabric (Lakehouse | Data Warehouse | KQL Database | Notebooks | Pipelines/Data Factory | Dataflow Gen2 | Power BI) | Azure (Azure SQL Database | Azure Data Lake Storage Gen2 | Azure Cosmos DB | Azure Synapse Analytics | Azure Blob Storage) | On-premises (SQL Server | Oracle Database | File shares).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/purview/unified-catalog\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/microsoft-purview-governance.md#4\",\n    \"claim\": \"Fabric-elementer inventert i katalogen etter skanning per opplevelse: Real-Time Analytics (KQL Database | KQL Queryset) | Data Science (Experiment | ML Model) | Data Factory (Data Pipeline | Dataflow Gen2) | Data Engineering (Lakehouse | Notebook | Spark Job Definition | SQL Analytics Endpoint) | Data Warehouse (Warehouse) | Power BI (Dashboard | Dataflow | Datamart | Semantic Model | Report).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/governance/microsoft-purview-fabric\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/microsoft-purview-governance.md#5\",\n    \"claim\": \"Purview inkluderer over 200 innebygde klassifiserere for sensitive datatyper.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/purview/unified-catalog\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/microsoft-purview-governance.md#6\",\n    \"claim\": \"Støttede lineage-typer: Data Factory Pipeline (Copy Activity | Data Flow) | Dataflow Gen2 (alle transformasjoner) | Notebook (Lakehouse-til-Lakehouse) | Lakehouse (tabell-nivå metadata) | Power BI (Semantic Model → Report → Dashboard) | Azure Data Factory (Copy | Data Flow | SSIS).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/purview/data-map-lineage-fabric\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/microsoft-purview-governance.md#7\",\n    \"claim\": \"Kjente lineage-begrensninger: eksterne datakilder som upstream i non-Power BI lineage støttes ikke ennå | cross-workspace lineage for non-Power BI er begrenset | Notebook → Pipeline lineage støttes ikke.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/purview/data-map-lineage-fabric\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/microsoft-purview-governance.md#8\",\n    \"claim\": \"Purview Data Owner Policy-typer og støttede kilder: Read (Azure SQL | ADLS Gen2 | Fabric) | Modify (Azure SQL | ADLS Gen2) | Data Use (Fabric workspaces).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/purview/unified-catalog\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/microsoft-purview-governance.md#9\",\n    \"claim\": \"Bulk edit av glossary terms i Unified Catalog støtter opptil 50 terms (kun i Draft-state).\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/purview/unified-catalog-glossary-terms-create-manage\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/microsoft-purview-governance.md#10\",\n    \"claim\": \"Microsoft Purview gir nå governance-dekning for Fabric Copilots og agenter som et nytt område for AI-generert innhold i Fabric-arbeidsmiljøer.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/governance/microsoft-purview-fabric\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/microsoft-purview-governance.md#11\",\n    \"claim\": \"Purview governance for Fabric Copilots omfatter funksjonalitetene Risk discovery | Audit coverage | Retention policies | eDiscovery.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/governance/microsoft-purview-fabric\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/microsoft-purview-governance.md#12\",\n    \"claim\": \"Purview DLP-policyer støtter strukturert data i Fabric (lakehouse | warehouse | databaser | semantic models) og kan håndheve tilgangsbegrensninger på tvers av Fabric KQL Database | Fabric SQL Database | Fabric Data Warehouse.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/governance/microsoft-purview-fabric\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/data-engineering/microsoft-purview-governance.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/data-engineering/onelake-data-strategy.md",
    "claim_count": 18,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/data-engineering/onelake-data-strategy.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/data-engineering/onelake-data-strategy.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/onelake-data-strategy.md#1\",\n    \"claim\": \"Shortcuts, OneLake Security for kjerne-engines og Shortcut Transformations for CSV/Parquet/JSON er GA; OneLake Security på Eventhouse/3.-parts-engines og Shortcut Transformations for Excel + AI-powered er i Preview.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/real-time-intelligence/query-acceleration-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/onelake-data-strategy.md#2\",\n    \"claim\": \"Item-typer som støtter shortcuts: Lakehouse (Tables/ og Files/) | KQL Database (Shortcuts/-folder, behandles som external tables) | Warehouse (via SQL analytics endpoint, read-only) | Mirrored Databases (Azure Databricks Mirrored Catalog, Mirrored Databases).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/real-time-intelligence/query-acceleration-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/onelake-data-strategy.md#3\",\n    \"claim\": \"Internal OneLake shortcuts kan peke til: KQL databases | Lakehouses | Mirrored Catalogs | Warehouses | Semantic models | SQL databases.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/real-time-intelligence/query-acceleration-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/onelake-data-strategy.md#4\",\n    \"claim\": \"External shortcuts støtter kildene: Amazon S3 | S3-compatible | Azure Data Lake Storage Gen2 | Azure Blob Storage | Dataverse | Google Cloud Storage | OneDrive | SharePoint | on-premises/nettverksbegrenset (via OPDG).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/real-time-intelligence/query-acceleration-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/onelake-data-strategy.md#5\",\n    \"claim\": \"Caching støttes for shortcuts mot: Google Cloud Storage (GCS) | S3 | S3-compatible | OPDG.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/real-time-intelligence/query-acceleration-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/onelake-data-strategy.md#6\",\n    \"claim\": \"Shortcut-caching har oppbevaring på 1-28 dager og cacher kun filer under 1 GB.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/real-time-intelligence/query-acceleration-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/onelake-data-strategy.md#7\",\n    \"claim\": \"Maks 100 000 shortcuts per Fabric item.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/real-time-intelligence/query-acceleration-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/onelake-data-strategy.md#8\",\n    \"claim\": \"Maks 10 shortcuts per OneLake path.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/real-time-intelligence/query-acceleration-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/onelake-data-strategy.md#9\",\n    \"claim\": \"Maks 5 direkte shortcut-til-shortcut-lenker.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/real-time-intelligence/query-acceleration-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/onelake-data-strategy.md#10\",\n    \"claim\": \"Shortcut Transformations konverterer CSV | Parquet | JSON til Delta tables (GA), og Excel + AI-powered er i preview.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/real-time-intelligence/query-acceleration-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/onelake-data-strategy.md#11\",\n    \"claim\": \"OneLake security-rollens Type støtter kun GRANT; DENY er ikke støttet ennå.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/real-time-intelligence/query-acceleration-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/onelake-data-strategy.md#12\",\n    \"claim\": \"Workspace-roller: Admin | Member | Contributor | Viewer — Admin/Member/Contributor har alltid View/Write på OneLake-filer, Viewer krever OneLake security; kun Admin/Member kan redigere sikkerhetsroller.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/real-time-intelligence/query-acceleration-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/onelake-data-strategy.md#13\",\n    \"claim\": \"Standard OneLake security-roller for Lakehouse: DefaultReader (Read på alle mapper under Tables/ og Files/, tildeles brukere med ReadAll-permission) | DefaultReadWriter (Read på alle mapper, tildeles brukere med Write-permission).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/real-time-intelligence/query-acceleration-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/onelake-data-strategy.md#14\",\n    \"claim\": \"OneLake security-permissions: Read (= VIEW_DEFINITION + SELECT, kan inkludere RLS/CLS) | ReadWrite (= ALTER + DROP + UPDATE + INSERT, kan ikke inkludere RLS/CLS).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/real-time-intelligence/query-acceleration-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/onelake-data-strategy.md#15\",\n    \"claim\": \"RLS/CLS-filtrering er GA for Lakehouse, Spark notebooks, SQL Analytics Endpoint (user's identity mode) og Semantic models (DirectLake on OneLake); Planned for Eventhouse og Data warehouse external tables.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/real-time-intelligence/query-acceleration-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/onelake-data-strategy.md#16\",\n    \"claim\": \"OneLake security-grenser: maks 250 roller per Lakehouse, maks 500 medlemmer per rolle, maks 500 permissions per rolle.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/real-time-intelligence/query-acceleration-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/onelake-data-strategy.md#17\",\n    \"claim\": \"Cross-region shortcuts støttes ikke med OneLake security.\",\n    \"claim_type\": \"region\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/real-time-intelligence/query-acceleration-overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/onelake-data-strategy.md#18\",\n    \"claim\": \"OneLake storage krever Fabric Capacity, tilgjengelig som F- eller P-SKU.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/real-time-intelligence/query-acceleration-overview\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/data-engineering/onelake-data-strategy.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/data-engineering/real-time-streaming-ai.md",
    "claim_count": 7,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/data-engineering/real-time-streaming-ai.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/data-engineering/real-time-streaming-ai.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/real-time-streaming-ai.md#1\",\n    \"claim\": \"Microsoft Fabric Real-Time Intelligence / Eventstream har status GA (generelt tilgjengelig).\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/real-time-intelligence/overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/real-time-streaming-ai.md#2\",\n    \"claim\": \"Fabric Eventstream støtter kildetypene: Azure Event Hubs | Azure IoT Hub | Azure Service Bus | Azure SQL DB (CDC) | PostgreSQL | MySQL | Cosmos DB | SQL MI | Confluent Cloud | Apache Kafka | Amazon MSK | Amazon Kinesis | Google Cloud Pub/Sub | Workspace item events | Blob Storage events.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/real-time-intelligence/event-streams/overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/real-time-streaming-ai.md#3\",\n    \"claim\": \"Fabric Eventstream støtter destinasjonene: Eventhouse (KQL Database) | Lakehouse | Spark Notebook | Derived Stream | Fabric Activator | Custom Endpoint.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/real-time-intelligence/event-streams/add-manage-eventstream-destinations\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/real-time-streaming-ai.md#4\",\n    \"claim\": \"KQL Database i Fabric har innebygd ML: anomalideteksjon | forecasting.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/real-time-intelligence/overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/real-time-streaming-ai.md#5\",\n    \"claim\": \"Eventstream støtter no-code-transformasjonene: Filter | Manage Fields | Group By | Union | Expand.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/fabric/real-time-intelligence/event-streams/overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/real-time-streaming-ai.md#6\",\n    \"claim\": \"Hver Event Hubs-partisjon støtter opptil 1 MB/s inntak og 2 MB/s uttak.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/real-time-intelligence/overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/real-time-streaming-ai.md#7\",\n    \"claim\": \"Fabric Eventstream kjører som SaaS i europeisk region (Norway East / West Europe).\",\n    \"claim_type\": \"region\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/real-time-intelligence/overview\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/data-engineering/real-time-streaming-ai.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/data-engineering/schema-evolution-management.md",
    "claim_count": 7,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/data-engineering/schema-evolution-management.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/data-engineering/schema-evolution-management.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/schema-evolution-management.md#1\",\n    \"claim\": \"Delta Lake støtter følgende skjemaendringstyper: ny kolonne (legges til automatisk via schema evolution) | kolonnenavn-endring (via column mapping) | slettet kolonne (via column mapping) | type-utvidelse (type widening, f.eks. INT → BIGINT) | type-endring (via overwriteSchema, destruktiv).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/databricks/data-engineering/schema-evolution\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/schema-evolution-management.md#2\",\n    \"claim\": \"I Delta Lake krever funksjonen Column Mapping delta.minReaderVersion 2 og delta.minWriterVersion 5.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/databricks/delta/feature-compatibility\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/schema-evolution-management.md#3\",\n    \"claim\": \"I Delta Lake krever funksjonen Type Widening delta.minReaderVersion 3 og delta.minWriterVersion 7.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/databricks/delta/feature-compatibility\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/schema-evolution-management.md#4\",\n    \"claim\": \"I Delta Lake krever Table Features delta.minReaderVersion 3 og delta.minWriterVersion 7.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/databricks/delta/feature-compatibility\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/schema-evolution-management.md#5\",\n    \"claim\": \"I Delta Lake krever Liquid Clustering delta.minReaderVersion 2 og delta.minWriterVersion 7.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/databricks/delta/feature-compatibility\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/schema-evolution-management.md#6\",\n    \"claim\": \"Delta Lake støtter følgende trygge type-utvidelser (type widening): BYTE → SHORT | SHORT → INT | INT → LONG | LONG → DECIMAL (betinget) | FLOAT → DOUBLE | DATE → TIMESTAMP | DECIMAL(p,s) → DECIMAL(p',s') (hvis p'>=p og s'>=s).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/databricks/delta/type-widening\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/schema-evolution-management.md#7\",\n    \"claim\": \"Schema evolution-støtte per komponent i Delta Lake/Fabric: Auto Loader (nye kolonner ja ved restart, rename ja ved restart, drop soft delete, type-utvidelse nei) | Delta Connector (nye kolonner via mergeSchema, rename/drop via column mapping, type widening ja) | Streaming Tables (nye kolonner/rename/drop/type widening ja) | Materialized Views (alle endringer krever full recompute) | Delta Tables (nye kolonner/rename/drop/type-utvidelse ja via auto/DDL).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/databricks/data-engineering/schema-evolution\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/data-engineering/schema-evolution-management.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/data-engineering/synthetic-data-generation.md",
    "claim_count": 5,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/data-engineering/synthetic-data-generation.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/data-engineering/synthetic-data-generation.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/synthetic-data-generation.md#1\",\n    \"claim\": \"Azure AI Evaluation SDK inneholder en Simulator-klasse (importeres fra azure.ai.evaluation.simulator) som er i preview.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/foundry-classic/how-to/develop/simulator-interaction-data\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/synthetic-data-generation.md#2\",\n    \"claim\": \"Azure OpenAI-integrasjonen bruker API-versjon 2024-12-01-preview.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/foundry-classic/openai/concepts/use-your-data\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/synthetic-data-generation.md#3\",\n    \"claim\": \"Microsoft Foundry Synthetic Data (UI-drevet syntetisk datagenerering under Fine-tuning > Generate Data) er i Preview.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/foundry/fine-tuning/data-generation\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/synthetic-data-generation.md#4\",\n    \"claim\": \"Microsoft Foundry data-generering tilbyr tre generatortyper: Simple Q&A (JSONL messages) | Tool Use (JSONL tool calls) | Conversation (JSONL conversation).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/foundry/fine-tuning/data-generation\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/synthetic-data-generation.md#5\",\n    \"claim\": \"Microsoft Foundry data-generering lar deg velge antall samples i området 50-1000.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/foundry/fine-tuning/data-generation\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/data-engineering/synthetic-data-generation.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/data-engineering/zero-etl-fabric-patterns.md",
    "claim_count": 16,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/data-engineering/zero-etl-fabric-patterns.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/data-engineering/zero-etl-fabric-patterns.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/zero-etl-fabric-patterns.md#1\",\n    \"claim\": \"Database Mirroring i Microsoft Fabric er GA, mens Open Mirroring er i Preview for enkelte kilder.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/mirroring/overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/zero-etl-fabric-patterns.md#2\",\n    \"claim\": \"Støttede kilder for database mirroring i Fabric (per februar 2026): Azure SQL Database | Azure SQL Managed Instance | Azure Database for PostgreSQL | SQL Server (on-prem/VM) | Azure Cosmos DB (NoSQL) | Snowflake | Azure Databricks (metadata mirroring) | Oracle | SAP | Google BigQuery.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/mirroring/overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/zero-etl-fabric-patterns.md#3\",\n    \"claim\": \"Google BigQuery database mirroring i Fabric er i Preview.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/mirroring/overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/zero-etl-fabric-patterns.md#4\",\n    \"claim\": \"Open mirroring i Fabric er GA (per februar 2026).\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/mirroring/overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/zero-etl-fabric-patterns.md#5\",\n    \"claim\": \"Direct Lake for mirrored databases i Power BI er GA-funksjonalitet.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/mirroring/overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/zero-etl-fabric-patterns.md#6\",\n    \"claim\": \"Standard retention for mirrored databases er 1 dag for nye mirrors og 7 dager for legacy mirrors.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/mirroring/overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/zero-etl-fabric-patterns.md#7\",\n    \"claim\": \"Data-in-transit for mirrored data (OneLake) krypteres med TLS 1.2+.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/mirroring/overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/zero-etl-fabric-patterns.md#8\",\n    \"claim\": \"Mirroring inkluderer gratis lagring på 1 TB per CU (F64 gir 64 TB gratis mirroring-lagring).\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/mirroring/overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/zero-etl-fabric-patterns.md#9\",\n    \"claim\": \"Fabric capacity-SKUer og deres CU: F2 (2 CU) | F8 (8 CU) | F16 (16 CU) | F32 (32 CU) | F64 (64 CU) | F128 (128 CU).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/mirroring/overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/zero-etl-fabric-patterns.md#10\",\n    \"claim\": \"Fabric Trial inkluderer gratis mirroring i 60 dager (med begrenset lagring).\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/mirroring/overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/zero-etl-fabric-patterns.md#11\",\n    \"claim\": \"For PostgreSQL mirroring har serverparameteren azure_cdc.change_batch_export_timeout standardverdi 30 sekunder.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/postgresql/integration/concepts-fabric-mirroring\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/zero-etl-fabric-patterns.md#12\",\n    \"claim\": \"For PostgreSQL mirroring har serverparameteren azure_cdc.max_snapshot_workers standardverdi 3.\",\n    \"claim_type\": \"tpm\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/postgresql/integration/concepts-fabric-mirroring\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/zero-etl-fabric-patterns.md#13\",\n    \"claim\": \"CDC-mekanisme og latens per kilde: SQL Server = Change Feed / transaction log scanning (15+ sek) | PostgreSQL = Logical replication via azure_cdc-extension (15+ sek) | Azure Cosmos DB = Change Feed API (15+ sek) | Snowflake = Snowflake Streams API (30+ sek).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/mirroring/overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/zero-etl-fabric-patterns.md#14\",\n    \"claim\": \"MongoDB-mirroring til Fabric er planlagt Q2 2026 (annonsert på Microsoft Ignite 2025).\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/mirroring/overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/zero-etl-fabric-patterns.md#15\",\n    \"claim\": \"SAP-kilder (S/4HANA, BW/4HANA m.fl.) mirrores til OneLake via SAP-mirroring (GA, via SAP Datasphere); Copy job auto-partition for SAP HANA er i preview.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/mirroring/overview\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/data-engineering/zero-etl-fabric-patterns.md#16\",\n    \"claim\": \"MySQL-mirroring støttes p.t. kun for Azure Database for MySQL via Open Mirroring.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/fabric/mirroring/overview\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/data-engineering/zero-etl-fabric-patterns.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/mlops-genaiops/ab-testing-llm-applications.md",
    "claim_count": 10,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/mlops-genaiops/ab-testing-llm-applications.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/mlops-genaiops/ab-testing-llm-applications.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/ab-testing-llm-applications.md#1\",\n    \"claim\": \"Azure Machine Learning Managed Online Endpoints består av komponentene: Endpoint | Deployment | Traffic splitting | Data collection.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/overview-what-is-azure-machine-learning?view=azureml-api-2#deploy-models\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/ab-testing-llm-applications.md#2\",\n    \"claim\": \"Microsoft-tilnærminger for evaluering av LLM-eksperimenter: LLM-as-judge (Microsoft Foundry evaluators, Databricks judges) | Rule-based scorers (BLEU, ROUGE, exact match) | Human evaluation (Microsoft Foundry thumbs up/down, red teaming) | Business metrics (conversion rate, task completion, bounce rate).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/ai-studio/how-to/develop/flow-evaluate-sdk#built-in-evaluators\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/ab-testing-llm-applications.md#3\",\n    \"claim\": \"Microsoft Foundry safety evaluations støtter automatisert vurdering av: Groundedness (hallucination detection) | Relevance | Safety (harmful content, jailbreaks) | Coherence | Fluency.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/ai-studio/how-to/develop/flow-evaluate-sdk#built-in-evaluators\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/ab-testing-llm-applications.md#4\",\n    \"claim\": \"Azure Machine Learning managed online endpoints støtter: Kubernetes-basert deployment (AKS) | Serverless compute | Data collection via DataCollector | Monitoring via Azure Monitor og Application Insights.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/overview-what-is-azure-machine-learning?view=azureml-api-2#deploy-models\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/ab-testing-llm-applications.md#5\",\n    \"claim\": \"Microsoft Foundry het tidligere Azure OpenAI Studio (navnet er omdøpt).\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/ai-studio/how-to/develop/flow-evaluate-sdk#built-in-evaluators\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/ab-testing-llm-applications.md#6\",\n    \"claim\": \"Microsoft Foundry Evaluations tilbyr: Pre-built evaluators (groundedness, relevance, safety) | Custom evaluators med egne prompts | Batch evaluation på validation sets | A/B comparison via Scorecards.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/ai-studio/how-to/develop/flow-evaluate-sdk#built-in-evaluators\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/ab-testing-llm-applications.md#7\",\n    \"claim\": \"Prompt Flow støtter Variants — flere versjoner av samme prompt i samme flow — som kan brukes til A/B-testing av prompts.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/databricks/mlflow3/genai/eval-monitor/concepts/scorers\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/ab-testing-llm-applications.md#8\",\n    \"claim\": \"MLflow 3 har et utvidet scorer-sett: Correctness | RelevanceToQuery | RetrievalGroundedness | ToolCallEfficiency | Fluency.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/databricks/mlflow3/genai/eval-monitor/concepts/scorers\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/ab-testing-llm-applications.md#9\",\n    \"claim\": \"MLflow 3 tilbyr multi-turn scorers: ConversationCompleteness | UserFrustration (for conversational AI A/B-testing).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/databricks/mlflow3/genai/eval-monitor/concepts/scorers\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/ab-testing-llm-applications.md#10\",\n    \"claim\": \"Azure ML managed online endpoints støtter shadow testing nativt via mirror_traffic-property (speiler X % av trafikken til ny modell uten brukerpåvirkning).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/how-to-safely-rollout-online-endpoints?view=azureml-api-2\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/mlops-genaiops/ab-testing-llm-applications.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/mlops-genaiops/automated-retraining-pipelines.md",
    "claim_count": 9,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/mlops-genaiops/automated-retraining-pipelines.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/mlops-genaiops/automated-retraining-pipelines.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/automated-retraining-pipelines.md#1\",\n    \"claim\": \"Azure Machine Learning SDK v2 og CLI v2 tilbyr native støtte for recurrence-baserte og cron-baserte schedules for pipeline-kjøringer.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/how-to-schedule-pipeline-job?view=azureml-api-2\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/automated-retraining-pipelines.md#2\",\n    \"claim\": \"Azure Databricks støtter både scheduled og triggered retraining via Databricks Jobs og SQL-alerts.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/databricks/machine-learning/mlops/mlops-workflow\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/automated-retraining-pipelines.md#3\",\n    \"claim\": \"Azure ML Python SDK v2 tilbyr klassene RecurrenceTrigger, RecurrencePattern, CronTrigger og JobSchedule for pipeline-scheduling.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/how-to-schedule-pipeline-job?view=azureml-api-2\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/automated-retraining-pipelines.md#4\",\n    \"claim\": \"Azure ML støtter AutoMLStep for automatisk feature selection og algorithm selection i pipelines.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/how-to-use-automlstep-in-pipelines?view=azureml-api-1\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/automated-retraining-pipelines.md#5\",\n    \"claim\": \"Azure ML SDK v2 støtter ikke event-baserte triggere natively; må integreres via Azure Event Grid | Azure Data Factory | Azure Functions.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/how-to-schedule-pipeline-job?view=azureml-api-2\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/automated-retraining-pipelines.md#6\",\n    \"claim\": \"Databricks Unity Catalog støtter model-aliaser (f.eks. Champion og Challenger) på registrerte modeller.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/databricks/machine-learning/mlops/mlops-workflow\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/automated-retraining-pipelines.md#7\",\n    \"claim\": \"Databricks Unity Catalog støtter multi-cloud (Azure | AWS | GCP), mens Azure ML kun er Azure-native.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/databricks/machine-learning/mlops/mlops-workflow\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/automated-retraining-pipelines.md#8\",\n    \"claim\": \"Databricks krever Premium- eller Enterprise-lisens for retraining (Jobs + Unity Catalog); Unity Catalog krever minimum Premium-tier.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/architecture/ai-ml/guide/mlops-maturity-model\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/automated-retraining-pipelines.md#9\",\n    \"claim\": \"Differential privacy i Azure ML er i preview, ikke fullt GA.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/architecture/ai-ml/guide/mlops-maturity-model\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/mlops-genaiops/automated-retraining-pipelines.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/mlops-genaiops/azure-ml-pipelines-orchestration.md",
    "claim_count": 12,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/mlops-genaiops/azure-ml-pipelines-orchestration.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/mlops-genaiops/azure-ml-pipelines-orchestration.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/azure-ml-pipelines-orchestration.md#1\",\n    \"claim\": \"Azure Machine Learning pipelines har status GA (generelt tilgjengelig).\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/machine-learning/concept-ml-pipelines\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/azure-ml-pipelines-orchestration.md#2\",\n    \"claim\": \"Azure ML pipelines bygges med Python SDK v2 (azure.ai.ml-pakken, med @dsl.pipeline-dekoratør og command()-komponenter).\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/how-to-create-component-pipeline-python?view=azureml-api-2\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/azure-ml-pipelines-orchestration.md#3\",\n    \"claim\": \"Curated environment sklearn-1.0 og standard base-image mcr.microsoft.com/azureml/openmpi4.1.0-ubuntu22.04:latest brukes for pipeline-komponentmiljøer.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/machine-learning/concept-ml-pipelines\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/azure-ml-pipelines-orchestration.md#4\",\n    \"claim\": \"Azure ML pipeline-komponenttyper: Command component | Pipeline component | Parallel component | Spark component | AutoML component.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/how-to-create-component-pipeline-python?view=azureml-api-2\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/azure-ml-pipelines-orchestration.md#5\",\n    \"claim\": \"Pipeline input/output-typer: uri_file | uri_folder | mlflow_model | Literal inputs (string/int/float/bool).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/how-to-manage-inputs-outputs-pipeline?view=azureml-api-2\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/azure-ml-pipelines-orchestration.md#6\",\n    \"claim\": \"Azure ML pipeline schedule-typer: Recurrence (tidsbasert) | Cron expression (crontab) | Event-driven (kun v1, blob storage change).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/how-to-schedule-pipeline-job?view=azureml-api-2\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/azure-ml-pipelines-orchestration.md#7\",\n    \"claim\": \"V2 schedules støtter ikke event-driven triggers; den change-baserte/event-drevne v1-varianten er deprecated (bruk Azure Data Factory eller Logic Apps for event-basert orkestrering).\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/how-to-schedule-pipeline-job?view=azureml-api-2\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/azure-ml-pipelines-orchestration.md#8\",\n    \"claim\": \"Azure ML compute targets: Compute clusters (auto-scaling, multi-node) | Compute instances (single VM, alltid-på) | Serverless compute (zero-config, on-demand) | Kubernetes (AKS-integrert).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/machine-learning/concept-ml-pipelines\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/azure-ml-pipelines-orchestration.md#9\",\n    \"claim\": \"Azure ML data access-moduser: ro_mount (default, read-only) | rw_mount (read-write) | download | direct (Spark) | upload.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/how-to-manage-inputs-outputs-pipeline?view=azureml-api-2\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/azure-ml-pipelines-orchestration.md#10\",\n    \"claim\": \"Integrasjon Microsoft Fabric Notebook → Azure ML Batch Endpoint er preview-funksjonalitet per februar 2026.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/machine-learning/concept-ml-pipelines\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/azure-ml-pipelines-orchestration.md#11\",\n    \"claim\": \"Azure ML data residency for offentlig sektor i Norge tilbys i Azure-regionene Norway East og Norway West.\",\n    \"claim_type\": \"region\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/machine-learning/concept-ml-pipelines\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/azure-ml-pipelines-orchestration.md#12\",\n    \"claim\": \"RBAC-actions for Azure ML schedules: Microsoft.MachineLearningServices/workspaces/schedules/read | .../schedules/write | .../schedules/delete.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/machine-learning/concept-ml-pipelines\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/mlops-genaiops/azure-ml-pipelines-orchestration.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/mlops-genaiops/ci-cd-for-ml-models.md",
    "claim_count": 12,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/mlops-genaiops/ci-cd-for-ml-models.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/mlops-genaiops/ci-cd-for-ml-models.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/ci-cd-for-ml-models.md#1\",\n    \"claim\": \"Azure ML Managed Endpoints støtter flere deployments samtidig og muliggjør dermed blue-green-deployment med zero-downtime rollback.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/machine-learning/concept-ml-pipelines\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/ci-cd-for-ml-models.md#2\",\n    \"claim\": \"Azure ML tilbyr prosentbasert traffic routing for canary-deployment (gradvis utrulling til en økende andel brukere).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/machine-learning/concept-ml-pipelines\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/ci-cd-for-ml-models.md#3\",\n    \"claim\": \"Azure Machine Learning CLI v2 er gjeldende CLI for ML-orkestrering og deployment.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/how-to-github-actions-machine-learning\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/ci-cd-for-ml-models.md#4\",\n    \"claim\": \"Databricks-basert CI/CD for ML bygger på Databricks MLOps Stacks med Unity Catalog-integrasjon.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/databricks/machine-learning/mlops/ci-cd-for-ml\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/ci-cd-for-ml-models.md#5\",\n    \"claim\": \"Anbefalt autentiseringsmetode for GitHub Actions mot Azure Machine Learning er OpenID Connect (OIDC) med federated credentials, som eliminerer langlivede secrets.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/how-to-github-actions-machine-learning\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/ci-cd-for-ml-models.md#6\",\n    \"claim\": \"OIDC-federated-credentials kan settes opp på to måter: Microsoft Entra-applikasjon (app-registrering) | brukertildelt managed identity (user-assigned managed identity).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/how-to-github-actions-machine-learning\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/ci-cd-for-ml-models.md#7\",\n    \"claim\": \"Anbefalt end-to-end MLOps-v2-oppsett for GitHub bruker mal-repoet Azure/mlops-v2-gha-demo.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/how-to-setup-mlops-github-azure-ml\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/ci-cd-for-ml-models.md#8\",\n    \"claim\": \"MLOps v2 GitHub-oppsett krever GitHub-secretene ARM_CLIENT_ID | ARM_CLIENT_SECRET | ARM_SUBSCRIPTION_ID | ARM_TENANT_ID.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/how-to-setup-mlops-github-azure-ml\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/ci-cd-for-ml-models.md#9\",\n    \"claim\": \"MLOps v2-pipelinen består av stegene Prepare Data → Train Model → Evaluate Model → Register Model → Deploy Endpoint.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/how-to-setup-mlops-github-azure-ml\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/ci-cd-for-ml-models.md#10\",\n    \"claim\": \"Parameterne --json-auth/--sdk-auth for `az ad sp create-for-rbac` er deprecated; nye prosjekter bør bruke OIDC med federated credentials.\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/how-to-setup-mlops-github-azure-ml\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/ci-cd-for-ml-models.md#11\",\n    \"claim\": \"GitHub Actions bruker action-en azure/login@v2 for autentisering mot Azure.\",\n    \"claim_type\": \"version\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/how-to-github-actions-machine-learning\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/ci-cd-for-ml-models.md#12\",\n    \"claim\": \"Azure ML compute-typer for CI/CD omfatter Compute Instance | Compute Cluster | Managed Endpoints | Batch Endpoints.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/machine-learning/concept-ml-pipelines\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/mlops-genaiops/ci-cd-for-ml-models.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  },
  {
    "file": "skills/ms-ai-engineering/references/mlops-genaiops/cost-optimization-mlops-pipelines.md",
    "claim_count": 10,
    "prompt": "# Per-claim groundedness judge — bake-off **v3.1** (recall-hardened over v3's 3 confirmed FNs)\n\nv3.1 of `judge-claim-prompt-v3.md`. Same blind, per-claim, one-subagent-per-file\ndesign, same three verdicts, same output schema, same evidence discipline. v3.1\nchanges only **three reasoning rules** (R1, R7, and a new R8), each fixing one of the\n**3 false negatives v3 still carried** (the judge-vs-gold disagreements G5 confirmed\nwere genuine judge misses, not stale gold).\n\n**Why v3.1 exists — and what it is NOT (transparent, not p-hacking).** The G5b\nfreshness spot-check (2026-06-30) blind-re-adjudicated v3's 4 apparent *false\npositives* against live Microsoft Learn. **All 4 turned out to be stale gold — v3\nflagged every one correctly** (`adr-template#1` \"zero permission management\" is\ncontradicted; `multi-region#2` lists retired `gpt-35-turbo`; `network-resilience#4`\noverstates \"recommended\" as \"obligatorisk\"; `vector-storage#7` cites the wrong GA\ndate). So **v3 has zero real false positives** (P = 100% on corrected gold), and the\nprecision-side \"FP-vakt\" originally planned for v3.1 is **dropped — there is nothing to\ndefend.** v3.1 is therefore a **pure recall hardening**: it tightens three rules so the\njudge catches 3 documented failure modes it currently misses, without touching the\nprecision-side rules (R2, R5, R6 and v3's R7 capability-following are unchanged).\n\n**Adoption is gated on measurement, not assertion — and the bar is now v3 (P 100% /\nR 92.9% on corrected gold), not v2.** v3 sits at the precision ceiling, so v3.1 can only\nbe adopted if it **holds P = 100% AND lifts R above 92.9%** (catches FNs without\nintroducing a single new false positive). Any new FP drops P below 100% and fails the\ngate — keep v3. Recall rules are double-edged over the full population (v3's own\nbake-off taught this), so the 45-way fan-out, not this prose, decides. v3 results stay\nfrozen; v3.1 writes to `judge-bakeoff-results-v3.1.json` and is graded against the\ncorrected `gold-correctness-set.json`.\n\n---\n\nYou are a correctness judge for Microsoft AI reference documentation. You verify\nfactual claims against **live, official Microsoft Learn** (`learn.microsoft.com`).\nBe strict and adversarial — do not give the benefit of the doubt, do not pad, do not\ninfer a value the source does not state.\n\nYou are judging claims extracted from `skills/ms-ai-engineering/references/mlops-genaiops/cost-optimization-mlops-pipelines.md`. For EACH claim in the batch below,\ndecide whether the cited Microsoft Learn source **grounds** the claim.\n\n## The three verdicts (exhaustive, mutually exclusive)\n\n- **`grounded`** — you fetched a `learn.microsoft.com` page that states the claimed\n  value(s). The page supports the claim. (Maps to gold `correct`.)\n- **`not_grounded`** — you fetched a `learn.microsoft.com` page that states a\n  **different / contradicting / superseded** value for what the claim asserts. The\n  claim disagrees with the source. (Maps to gold `outdated` + `wrong`.)\n- **`source_silent`** — you fetched the cited page (and searched as a fallback) but\n  **no** `learn.microsoft.com` page states the claimed value at all. You cannot\n  confirm or refute it. (Maps to gold `unsourced`.) Pricing on JS-rendered Azure\n  pages typically lands here — that is expected, not a failure. **Exception: existence\n  claims — see Rule R2.**\n\n## ⚠️ EXACT-VALUE RULE (inherited from v2 — still in force)\n\nA claim is `grounded` ONLY if the fetched page states the **exact** asserted value(s).\nVerifying that the page \"is about\" the SKU/model/feature is **not** enough — the\nspecific number, name, date, tier, dimension, or status must match. If the claim\nasserts value **X** and the page states a **different** value **Y** (even if adjacent\nor plausible), the verdict is **`not_grounded`**. This rule does NOT lower the bar for\n`not_grounded`: you still need a fetched quote stating the **differing** value.\n\nApplies with special force to `sku`, `taxonomy`, `version`, `tpm`, `region`, `status`.\n\n---\n\n## CALIBRATION RULES — read all eight before judging\n\nThe exact-value rule is a blunt instrument. The 8 rules below sharpen it on both\nedges: **R1–R4 and R8 catch real errors** (more `not_grounded`); **R5–R7 stop\nover-flagging where the core is grounded** (more correctly `grounded`). When a rule\nbelow conflicts with a literal reading of the exact-value rule, the rule below governs\n— it is the more precise standard.\n\n### Recall side — flag these as `not_grounded`\n\n**R1 — Bound understatement / overstatement (fixes FN2; v3.1 splits lower vs upper).**\nA claim may assert a **bound**. Direction matters — judge it by which side the bound\nconstrains:\n\n- **Lower bound** (\"100+\", \"200k+\", \"at least N\", \"minimum N\"): do not auto-`grounded`\n  it just because the true value satisfies the inequality. Apply the **lower-bound\n  policy:** if the true current value **grossly exceeds** the stated bound — roughly\n  **>2× and decision-changing** — the bound materially misleads → `not_grounded`. A\n  *tight* lower bound (true value within the same order of magnitude) stays `grounded`.\n  *Example (FN2): \"200k+ context\" while the page states 1,047,576 (~1M) — ~5× → `not_grounded`.*\n- **Upper bound** (\"up to N\", \"opptil N\", \"maximum N\", \"no more than N\", \"as many as N\"):\n  this is a **ceiling**, not a floor. The lower-bound leniency does **NOT** apply. The\n  exact-value rule governs: if the live page states a current maximum **higher** than N,\n  the stated ceiling is **superseded** → `not_grounded` — **regardless of ratio** (even\n  a 1.1× exceedance breaks a ceiling). The claim tells the reader the limit is N when it\n  is really higher. *Example (v3-FN): claim \"up to 18 underlying models\" while the page\n  states 28 → the ceiling has moved → `not_grounded`.* (Only `grounded` if the true\n  maximum is N or the claim's ceiling still binds.)\n\n**R2 — `source_silent` does NOT excuse an existence claim (fixes FN3, FN5).** When the\nclaim asserts that a named entity **exists / is offered / is in a list** (\"X is a\nbuilt-in judge\", \"feature Y is available\", \"tier Z exists\"), and you fetch the\nauthoritative page that *would* enumerate it and the entity is **absent**, that absence\nis **evidence the claim is wrong** — return `not_grounded`, not `source_silent`. Reserve\n`source_silent` for values a page would not be expected to enumerate (e.g. JS-rendered\nprices). State in `reason` that you checked the canonical enumerating page and the\nentity was not present. *Example (FN5): claim \"99.99% SLA tier\" while the reliability\npage lists only 99.9% → absence of any 99.99% tier = `not_grounded`.*\n\n**R3 — Frame/unit replacement (fixes FN4).** A claim's **organizing frame or unit** can\nbe superseded even when derived ratios survive. If the page shows the claim's framing\nhas been **replaced** (e.g. \"1 Unit Capacity\" → \"Quota Tiers\"; a renamed/retired\nmetric), the claim is `not_grounded` even if some embedded numbers still appear\nsomewhere — the claim describes a world that no longer exists. Check that the *unit and\nstructure* the claim assumes still match the current page, not just the digits.\n\n**R4 — Current row, never a legacy row (fixes FN6).** Pages often carry historical or\neffective-dated rows (\"Before April 3, 2024\", \"Legacy\", \"Retiring\"). A claim is\n`grounded` only if it matches the **current/effective** row. Matching a clearly\ntime-stamped *past* row is `not_grounded` (the value has since changed). Always locate\nthe row that applies *today*. *Example (FN6): storage limits matching only the\n\"Before April 3, 2024\" row while current limits differ → `not_grounded`.*\n\n**R8 — Multi-part claims: every load-bearing part must hold (v3.1 — fixes the\n`ai-foundry-dr#9` FN).** A single claim often bundles **several load-bearing\nsub-assertions** (a status AND a region; a capability AND a named target; a date AND a\nGA level). Verify **each load-bearing part separately**. If **any one** load-bearing\npart is contradicted by the source, the whole claim is `not_grounded` — even when the\nother parts check out. Do not let a correct first half earn a `grounded` for a wrong\nsecond half. *Example (v3-FN): \"Global training (Public Preview), cheaper, no data\nresidency; use regional in Norway East\" — the GA-vs-Preview part and the \"no residency\"\npart hold, but **Norway East is a Global (non-residency) training region, not a regional\none** → one load-bearing part is wrong → `not_grounded`.* (R8 is the mirror of R6:\nR6 forgives an **omitted, non-load-bearing** detail; R8 condemns a **stated,\nload-bearing** part that is wrong. Decide first whether the part is load-bearing — if\nthe claim *asserts* it and a reader would act on it, it is.)\n\n### Precision side — keep these `grounded` (do not over-flag)\n\n**R5 — Documented theoretical↔benchmark equivalence (fixes FP3).** Do not flag a\nnumeric claim merely because the exact string is not verbatim, when the asserted value\nis the **documented theoretical or benchmark equivalent** of what the page states and\nboth trace to Microsoft sources (e.g. a theoretical max vs a measured benchmark of the\nsame technique, same order of magnitude, same direction). The exact-value rule targets\n*drifted/contradicting* values — not two Microsoft-sourced expressions of the same\nfact. If the page substantiates the magnitude and the technique, keep `grounded` and\nnote the equivalence in `reason`.\n\n**R6 — Core grounded, detail omitted ≠ ungrounded (fixes FP4).** Distinguish \"the\nclaim's **core** assertion is grounded but it omits a sub-category\" from \"the core is\nungrounded.\" If the page confirms the claim's **central** behavior/categorization and\nthe only gap is an *unstated additional* case the claim did not deny, that is\n`grounded` (the claim is incomplete, not wrong). Reserve `not_grounded` for when the\npage **maps the core differently** or the claim **asserts** something the page\ncontradicts. Omission ≠ contradiction. (Contrast R8: an omitted case is forgiven here;\na *stated* but wrong load-bearing part is not — that is R8's domain.)\n\n**R7 — Follow the capability to its canonical page; don't punish illustrative numbers\n(fixes FP5; v3.1 sharpens the load-bearing carve-out).** If a claim asserts a **real\ncapability** and the cited `evidence_url` does not foreground it, search for the\n**canonical** page that documents the capability before judging — do not return\n`not_grounded` merely because the *cited* page was a weak choice. And when a capability\nis solidly grounded, do **not** flag it over an *illustrative* attached number (e.g.\n\"~0 RTO/RPO\", \"≈15 min\") that the claim offers as an order-of-magnitude illustration\nrather than a cited spec. Judge the **capability**; treat an illustrative figure as\ngrounded if the capability is.\n\n> **⚠️ Load-bearing carve-out (v3.1, fixes the `token-usage#3` FN).** R7's leniency\n> covers only *illustrative* values. It does **NOT** cover a value or **exact string**\n> that **IS the assertion** — a metric name, an API field, an SDK identifier, an enum\n> value, a specific date/version. When the claim's load-bearing content is the literal\n> name/string itself (e.g. \"the metrics are `PromptTokens` and `CompletionTokens`\"),\n> the exact-value rule applies in full: if the live page names them differently\n> (`ProcessedPromptTokens` / `InputTokens` / `GeneratedTokens` / `OutputTokens`), the\n> claim is `not_grounded`. \"Follow to the canonical page\" means find the **right\n> names**, not rescue wrong ones. A reader would copy that string into code; an\n> illustrative magnitude they would not.\n\n---\n\n## Procedure (per claim)\n\n1. **Identify the volatile assertion(s)** in the claim text — and when the claim\n   bundles several (R8), enumerate **each load-bearing part**. The `claim_type` tells\n   you what to check:\n   - `version` → model/API version, GA date, context window, max output, training cutoff\n   - `tpm` → tokens-per-minute / throughput / quota numbers\n   - `sku` → SKU name, tier, PTU minimums, deployment type\n   - `region` → regional availability\n   - `status` → GA / preview / retirement / deprecation status\n   - `taxonomy` → categorization, capability mapping, which-feature-does-what\n2. **Fetch the cited source** with `microsoft_docs_fetch` on the claim's\n   `evidence_url`. If the claim has no `evidence_url`, or the fetched page does not\n   address the assertion, run `microsoft_docs_search` to find the authoritative page.\n   **Under R2/R7, actively seek the canonical enumerating/capability page** — a weak\n   cited URL is not the last word.\n3. **Exact-value entailment check** each checkable value (and each load-bearing part\n   under R8), then apply the calibration rules R1–R8. Classify which rule(s), if any,\n   govern the claim. For R1, first decide whether the bound is a **lower** bound (floor)\n   or an **upper** bound (ceiling) — they invert.\n4. **Strict evidence rule:** a `grounded` or `not_grounded` verdict REQUIRES a verbatim\n   quote you actually fetched from a `learn.microsoft.com` URL. For R2 (existence\n   absence), the quote is the canonical enumeration in which the entity does **not**\n   appear — quote the enumeration and state the entity is absent. No quote → `source_silent`.\n\n## Hard rules\n\n- Verify against the fetched page only. Do not rely on prior knowledge of model\n  specs / prices — those are exactly what may have drifted.\n- Stable identifiers are not volatile and are not your job to refute: regulation year\n  (2024/1689), case numbers (C-311/18), standard version names (OWASP LLM Top 10\n  2025, MADR v3.0), file names. If a claim is purely such an identifier, judge it on\n  whatever volatile value it carries, else `source_silent`.\n- One verdict per claim. Return EXACTLY the JSON below — no prose, no markdown fence.\n- `evidence_quote` = the verbatim sentence/value from the fetched page that drove the\n  verdict (empty string for `source_silent`). `evidence_url` = the page you actually\n  used (may differ from the cited one if you fell back to search).\n- `rule` = which calibration rule governed, if any (`R1`–`R8`), else empty.\n\n## Batch to judge (from `skills/ms-ai-engineering/references/mlops-genaiops/cost-optimization-mlops-pipelines.md`)\n\n[\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/cost-optimization-mlops-pipelines.md#1\",\n    \"claim\": \"AmlCompute-cluster kan konfigureres med tier Dedicated | LowPriority (low-priority/preemptible VMs for ikke-tidskritiske batch-workloads).\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/machine-learning/concept-ml-pipelines\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/cost-optimization-mlops-pipelines.md#2\",\n    \"claim\": \"Compute instance idle shutdown og scheduled start/stop er begge GA (generelt tilgjengelig).\",\n    \"claim_type\": \"status\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/machine-learning/concept-ml-pipelines\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/cost-optimization-mlops-pipelines.md#3\",\n    \"claim\": \"Reserved VM Instances tilbys som commitment på 1 år | 3 år.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/machine-learning/concept-ml-pipelines\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/cost-optimization-mlops-pipelines.md#4\",\n    \"claim\": \"Azure ML early termination policies for hyperparameter tuning: Bandit | Median stopping | Truncation selection.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/machine-learning/concept-ml-pipelines\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/cost-optimization-mlops-pipelines.md#5\",\n    \"claim\": \"Typiske årsaker til at Azure ML pipeline-gjenbruk (reuse) ikke skjer: endringer i data | kode | miljø | compute-konfigurasjon.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/en-us/azure/machine-learning/how-to-debug-pipeline-reuse-issues\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/cost-optimization-mlops-pipelines.md#6\",\n    \"claim\": \"Azure-regionen West Europe ligger i Amsterdam og North Europe i Dublin; Norway East og Norway West finnes for data residency-krav.\",\n    \"claim_type\": \"region\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/machine-learning/concept-ml-pipelines\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/cost-optimization-mlops-pipelines.md#7\",\n    \"claim\": \"Autoskalering av managed online endpoints via Azure Monitor autoscale støtter metrikk-basert (f.eks. CPU-utilisering) | tidsplan-basert | kombinasjon av begge.\",\n    \"claim_type\": \"taxonomy\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/machine-learning/concept-ml-pipelines\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/cost-optimization-mlops-pipelines.md#8\",\n    \"claim\": \"VM-størrelsen STANDARD_DS3_V2 har 4 vCPU og 14 GB RAM.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/machine-learning/concept-ml-pipelines\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/cost-optimization-mlops-pipelines.md#9\",\n    \"claim\": \"VM-størrelsen STANDARD_NC4AS_T4_V3 har 4 vCPU, 28 GB RAM og 1× NVIDIA T4 GPU.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/machine-learning/concept-ml-pipelines\"\n  },\n  {\n    \"id\": \"ms-ai-engineering/mlops-genaiops/cost-optimization-mlops-pipelines.md#10\",\n    \"claim\": \"VM-størrelsen STANDARD_NC64AS_T4_V3 har 64 vCPU, 440 GB RAM og 4× NVIDIA T4 GPU.\",\n    \"claim_type\": \"sku\",\n    \"evidence_url\": \"https://learn.microsoft.com/azure/machine-learning/concept-ml-pipelines\"\n  }\n]\n\n## Output (strict JSON, no fence)\n\n```\n{\"file\":\"skills/ms-ai-engineering/references/mlops-genaiops/cost-optimization-mlops-pipelines.md\",\"results\":[\n  {\"id\":\"<claim id>\",\"judge_verdict\":\"grounded|not_grounded|source_silent\",\"rule\":\"<R1-R8 or empty>\",\"evidence_url\":\"<url actually used>\",\"evidence_quote\":\"<verbatim quote or empty>\",\"reason\":\"<one sentence: what the source said vs the claim>\"}\n]}\n```\n"
  }
]