# Runbook — v3.1 judge bake-off fan-out (resume-ready)

_Opprettet 2026-06-30. Selvbærende oppskrift for å kjøre v3.1-bake-offen (programdok §8 G1, option A) i en fersk sesjon. Deterministisk der det går; den ene LLM-tunge delen (45 subagenter) er isolert og eksplisitt. Forutsetter INGEN kontekst utover denne fila + de refererte artefaktene._

## Hvorfor / hva dette avgjør

v3 er adoptert baseline, målt **P 100,0 % / R 92,9 % / 0 FP** på G5b-korrigert gull (`scripts/kb-eval/data/judge-bakeoff-report-v3-g5bgold.{json,md}`). v3.1 (`scripts/kb-eval/judge-claim-prompt-v3.1.md`) er en ren recall-hardning av de 3 gjenstående FN (R1 øvre/nedre-grense-skille, R7 last-bærende-streng-carve-out, ny R8 fler-delt-fullstendighet). Denne kjøringen måler om v3.1 fanger de 3 FN UTEN å innføre nye FP.

**Forhåndsregistrert adopsjonsgate (låst FØR fan-out):** adopter v3.1 KUN hvis den **holder P = 100 % OG løfter R over 92,9 %** (mot G5b-gull). Enhver ny FP feller den → behold v3. Rapportens egen «GATE: PASS» (R≥0,70/P≥0,60) er kun gulvet, IKKE adopsjonsbaren.

## Forutsetninger (verifiser FØRST — premiss-sjekk)

```bash
cd /Users/ktg/repos/ktg-plugin-marketplace/ms-ai-architect
# 1. Manifest + gull fortsatt i sync (skal si 255 claims / 45 files):
node scripts/kb-eval/extract-judge-claims.mjs        # -> "blind manifest: 255 claims across 45 files"
# 2. Suite + gull-lint grønt:
node --test tests/kb-update/*.test.mjs tests/kb-eval/*.test.mjs   # -> pass 641
node scripts/kb-eval/lint-gold-consistency.mjs       # -> "0 uwaived ... (373 claims)"
```

Hvis manifestet IKKE er 255/45: gullet er endret siden 2026-06-30 → regenerer manifest (`node scripts/kb-eval/extract-judge-claims.mjs --write`) og re-mål v3-baseline mot oppdatert gull FØR du måler v3.1 (baren må være fersk — [[gold-freshness-can-invert-adoption]]).

## Steg 1 — generer payloads (deterministisk, ingen LLM)

```bash
node scripts/kb-eval/build-judge-payloads.mjs \
  --prompt judge-claim-prompt-v3.1.md \
  --out judge-bakeoff-payloads-v3.1.json --write
# -> "45 per-file payloads, 255 claims total, prompt=judge-claim-prompt-v3.1.md"
```

Output: `scripts/kb-eval/data/judge-bakeoff-payloads-v3.1.json` (gitignored, regenererbar) = array av `{file, claim_count, prompt}`. Hver `prompt` er v3.1-malen med `<FILE>` + `<CLAIMS>` allerede substituert — klar til å dispatche ordrett.

## Steg 2 — fan-out (DEN dyre delen: 45 Opus-4.8-subagenter)

For HVER av de 45 payload-oppføringene, spawn ÉN subagent (inline `Agent`-verktøy):
- **model:** `opus` (4.8), reasoning **xhigh** ([[subagent-model-opus-xhigh]]). Aldri Sonnet/Haiku.
- **prompt:** payload-oppføringens `prompt`-felt, ordrett (ingen tillegg).
- **subagent_type:** `general-purpose` (trenger `microsoft_docs_fetch`/`microsoft_docs_search`).
- **blind:** payloaden inneholder ALDRI gull-verdikt/notes (manifestet er strippet) — ikke lekk dem.
- **read-only:** subagenter skriver ALDRI til disk; hovedkonteksten aggregerer.
- Kjør i batcher (f.eks. 8–10 samtidige) for å holde kontekst håndterbar; 45 totalt.

Hver subagent returnerer streng JSON: `{"file":"...","results":[{"id","judge_verdict","rule","evidence_url","evidence_quote","reason"},...]}`.

**Aggreger** alle 45 `results`-arrays til én fil. Behold MINST `id` + `judge_verdict` (+ `rule` anbefalt; scoreren bruker kun `judge_verdict`). Skriv:

`scripts/kb-eval/data/judge-bakeoff-results-v3.1.json` = `{"results":[ {"id":..., "judge_verdict":..., "rule":...}, … 255 totalt ]}`

(Format = identisk med `judge-bakeoff-results-v3.json` — sjekk den som mal.)

## Steg 3 — score (deterministisk) + anvend gaten

```bash
node scripts/kb-eval/run-judge-bakeoff.mjs \
  --min-recall 0.70 --min-precision 0.60 \
  --results judge-bakeoff-results-v3.1.json \
  --report-prefix judge-bakeoff-report-v3.1 --write
```

- Scoreren FEILER hardt hvis < 255 verdikt (ufullstendig fan-out) — fix manglende ids og kjør på nytt.
- Les `data/judge-bakeoff-report-v3.1.json` → `arms.judge`: `precision`, `recall`, `fp`, `fn`, `tp`, `tn`.
- **Adopsjon:** sammenlign mot v3 (P 100 / R 92,9, FP 0). Adopter v3.1 KUN hvis `precision == 1.0` (FP 0) OG `recall > 0.929`. Ellers: behold v3, dokumenter hvilke nye FP/regresjoner v3.1 innførte (input til en evt. v3.2).
- Hvis v3.1 fanget noen men ikke alle 3 FN, eller innførte FP: det er et MÅLT resultat — før det i §8 G1-raden, ikke en feil.

## Steg 4 — uansett utfall

- Oppdater programdok §8 G1-rad + lukke-logg med målt P/R for v3.1 + adopsjonsbeslutning.
- **Hvis adoptert:** den adopterte prompten (v3 eller v3.1) blir input til **G2** (wire inn i `scripts/kb-update/lib/transform.mjs`-judge-passet, Port 2 born-verified, + kadens-runner Port 3).
- Forventede artefakter etterpå: `judge-bakeoff-results-v3.1.json` (commit), `judge-bakeoff-report-v3.1.{json,md}` (commit). Payloads-fila er gitignored.
- Commit (`[skip-docs]`, ingen AI-trailers, Forgejo `origin`).

## De 3 FN v3.1 sikter på (forventet flip grounded→not_grounded)

| Claim | Feilmodus | v3.1-regel | Forventet |
|---|---|---|---|
| `ms-ai-security/cost-optimization/multi-model-strategy-costs.md#2` | «opptil 18» tak brutt av live 28 | R1 (øvre grense) | not_grounded |
| `ms-ai-governance/monitoring-observability/token-usage-tracking-attribution.md#3` | metrikk-navn `PromptTokens`/`CompletionTokens` finnes ikke (live: `ProcessedPromptTokens`/`InputTokens`/`GeneratedTokens`/`OutputTokens`) | R7 (last-bærende streng) | not_grounded |
| `ms-ai-infrastructure/bcdr/ai-foundry-disaster-recovery-planning.md#9` | Norway East er Global (ikke-residency) trenings-region, ikke regional | R8 (fler-delt) | not_grounded |

Disse er gull=`outdated` (positive). Fanger v3.1 alle 3 uten ny FP → R 92,9 → 100 ved P 100. Det er max-utfallet.

## Bakgrunn (les ved tvil)

`docs/ref-kb-correctness-program-2026-06.md` §8 (G1/G5/G5b) · `scripts/kb-eval/judge-claim-prompt-v3.1.md` (R1–R8) · `docs/ref-kb-gold-reconciliation-2026-06.md` (gull-flip-ledger) · STATE.md «👉 NESTE».