fix(ms-ai-architect): idx-26f dialekt-retting — reparasjonen feilet paa sin egen begrunnende akse

Punkt 2 landet som 'fairness-target values', et hybridkompositum som er hverken
norsk eller engelsk, der punkt 1 gjengir samme kildebegrep som 'target-verdiene'.
Dialekt-konsistens var HELE argumentet for aa velge omskriving framfor sletting,
saa reparasjonen feilet paa aksen den ble begrunnet med. Rettet til
'fairness-maalverdiene'.

Koherens-gjennomlesingen etter foerste edit sjekket innholds-samsvar og slapp den
gjennom - den sjekket ikke kompositum-former. En koherens-sjekk arver aksen du
hadde i tankene da du skrev den.

Ratifiseringen laa i LABELEN ('kildens ordlyd i idx-26d-dialekten'); previewet bar
den defekte formen. Labelen er det ratifiserte objektet, saa rettingen krevde ingen
re-ratifisering - men et preview som gjengir labelen feil er en levende maate aa
smugle en uratifisert form forbi en operatoer som leser previewet.

I tillegg: idx-26f-resolutionen skiller naa eksplisitt mellom punkt 2/5 (re-verifisert
denne oekten) og punkt 1/3/6/7 (verifisert under idx-26d samme dag, arvet - ikke
re-kjoert her).

Suite 1047/1047.

.claude-plugin/plugin.json

@@ -1,11 +1,11 @@
 {
   "name": "ms-ai-architect",
-  "version": "1.16.2",
+  "version": "1.17.0",
   "description": "Microsoft AI Solution Architect - structured architecture guidance for the full Microsoft AI stack",
   "author": {
     "name": "Kjell Tore Guttormsen"
   },
   "license": "MIT",
-  "repository": "https://git.fromaitochitta.com/open/ktg-plugin-marketplace",
+  "repository": "https://git.fromaitochitta.com/open/ms-ai-architect",
   "keywords": ["microsoft", "azure", "ai-architect", "governance", "security", "norwegian-public-sector", "eu-ai-act"]
 }

.gitignore

@@ -23,10 +23,15 @@ node_modules/
 .work/
 org/
 # Generated KB-update artifacts (registry, reports) are ignored, but the
-# hand-authored taxonomy (lag 0) and the decision ledger (lag 2) are tracked.
+# hand-authored taxonomy (lag 0), the decision ledger (lag 2), the curated
+# AI Act deadline source (RX-REG, sync-tested consumer contract) and the
+# adjudicated Layer B allowlist (Enhet A2 — the gate's strictness contract,
+# human-reviewed per entry, must survive a fresh clone) are tracked.
 scripts/kb-update/data/*
 !scripts/kb-update/data/domain-taxonomy.json
 !scripts/kb-update/data/decisions.json
+!scripts/kb-update/data/ai-act-deadlines.json
+!scripts/kb-update/data/layerb-allowlist.json
 # Generated skill-lifecycle detection report (Spor B / B1) — regenerated on demand,
 # like the kb-update reports above. The detector script + curated inputs are tracked.
 scripts/kb-eval/data/skill-lifecycle-report.json
@@ -34,7 +39,14 @@ scripts/kb-eval/data/skill-lifecycle-report.json
 # regenerated by `score-skill.mjs --write` and the apply-skill-op gate. Consumed by
 # the STEG C SessionStart surfacing; not committed (avoids churn in the public repo).
 scripts/kb-eval/data/skill-score-report.json
+# Generated judge bake-off fan-out payloads (45 per-file prompts, ~760KB) — derived
+# deterministically from judge-bakeoff-claims.json + the judge prompt by
+# build-judge-payloads.mjs; regenerated on demand, not committed (bulk + churn).
+scripts/kb-eval/data/judge-bakeoff-payloads-*.json
 .kb-backup/
+# atomic-write temp files (atomicWriteSync writes `<name>.tmp.<pid>.<n>` then renames);
+# a crash mid-write could leave one behind — never let it reach the public mirror.
+*.tmp.*
 .rollback-in-progress
 
 # --- session/local state — LOCAL-ONLY (gitignored) ---

CHANGELOG.md

@@ -5,6 +5,72 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [Unreleased]
+
+### Changed
+
+- **OKF second-brain (sporet for brukerens egen kontekst-wiki — IKKE de 389 skill-refs):** Ratifiserte den delte katalog-spec-en `catalog/docs/okf-second-brain/spec.md` v0.1 som eneste kilde for konvensjonen; lokal brief (`docs/okf-second-brain-brief-2026-06.md`) *refererer* den nå i stedet for å restate. Premiss-korreksjoner registrert (spec §9): `mdcode`/`kcmd` er ikke et OKF-verktøy (droppet fra adopsjonsplanen); ingen gjenbrukbar OKF-ingest-kode finnes (`reference_agent` er GCP/Gemini-bundet → adopter prompt-mønstre, ikke kode); kanonisk anbefalt feltnavn er `resource` (ikke `source`). Full OKF-pakke-ambisjon består — minimal kontrakt (spec §3) er gulvet, rike felt rir over som extension keys (spec §5). Kun docs/plan-justering; bygging er separat go.
+
+## [1.17.0] - 2026-07-04
+
+Spor 1 — Port-1-substrat migrert på korpuset (de 4 ikke-advisor-skills) via den deterministiske `migrate-corpus.mjs`-applieren. Reference-kontrakten (`**Type:**` / `**Source:**` / TOC) er nå påført på tvers av korpuset, og stale `**Verified:** MCP`-poison er fjernet. Ingen kommando-, agent- eller persona-endringer; prosa-kropper byte-identisk; advisor-skillen urørt.
+
+### Changed
+
+- **Reference-headere (327 filer):** `**Type:**` stemplet på alle 327 (reference/methodology/regulatory/template); `**Source:**` (Microsoft Learn-autoritet, satt per fil i manifestet) backfilt på 243 sourced reference-filer; `## Innhold` TOC innsatt på 325 store filer (≥100 linjer). `verified` forblir null — settes først i en senere corpus-judge-pass.
+- **Full-pass-worklist aktivert:** 243 due, 0 fresh. CT5 (referanse-kontrakt) available på alle 4 skills; N4 (TOC) 0 → 1.000/pass. Skill-scorer steg (95→98–100); den forhåndsdeklarerte «transient sub-90 dip» inntraff ikke (registrert i utfallsdoc).
+
+### Fixed
+
+- **Stale-verified poison:** `**Verified:** MCP <dato>` fjernet — 14 header-forekomster + 9 stray body-duplikater innenfor 500-byte-scan-vinduet (mlops-genaiops). Disse ble ellers falskt lest som «verified» og droppet fra worklisten. Kun stray metadata-linjer fjernet, aldri prosa.
+- **`insertHeaderFields` anker-overshoot:** når en meta-linje selv passerer 500 B (2 filer med et avsnitt pakket i `**Status:**`), faller ankeret nå tilbake til siste meta-linje innenfor scan-vinduet, så Type/Source forblir parsbare. TDD.
+- **`normalizeStaleVerified`:** fjerner nå alle stale non-date `**Verified:**` i 500B-vinduet uansett `---`-posisjon (operatør-godkjent utvidelse av carve-out). TDD.
+
+Suite 728/728 grønn. Detaljert utfall + policy-delta + base-felt-restanse: `docs/spor1-migration-outcome.md`.
+
+## [1.16.5] - 2026-06-24
+
+KB-refresh-patch. LOW-tier (52 reference docs) verifisert mot Microsoft Learn (post-1.16.4 baseline). Ingen kommando-, agent- eller skill-endringer — kun reference docs. ~33 filer var TRYGT (innhold gjeldende, kun header-bump); resten hadde reell drift, URL- eller syntaksfiks. Hver `VERIFY`-påstand re-bekreftet av main-agent mot sitert Microsoft Learn-kilde FØR skriving; `git diff` + plugin-validering (239/0). Needing-update 52 → 0 (alle tiers nå 0).
+
+### Changed
+
+- **Agent Framework (materiell fiks):** `agent-framework` fullstendig omskrevet — tidligere utgave bygde på et oppdiktet API (`azure.ai.agent`, `FoundryClient`/`FoundryTools`, `Swarm`/`Handoff`, `Memory`, `@checkpoint`, `enable_tracing`). Korrigert til det ekte SDK-et `agent-framework` (Python) / `Microsoft.Agents.AI` (.NET): `Agent(client=...)`, `@tool`, `AgentSession`, graf-baserte `WorkflowBuilder`/`SequentialBuilder`, OpenTelemetry-observability, og den faktiske Foundry-verktøykatalogen. Etterfølger til **BÅDE** Semantic Kernel **og** AutoGen; `.as_agent_framework_tool`-bro (krever `semantic-kernel` ≥ 1.38). `migration-patterns` §6 tilsvarende korrigert (Agent Framework = eget SDK, ikke et SK-namespace).
+- **Regulatorisk (norsk AI Act):** `public-sector-checklist` + `ai-utredning-template` — norsk ikrafttredelse mykgjort fra «aug 2026 samtidig med EU» til «forsinket pga. EØS-tilpasning, ventet 2026»; Foundry URL-slug `ai-studio` → `foundry`.
+- **Copilot/lisens:** Copilot Studio «billed sessions» → **Copilot Credits** (felles valuta fra 1. sep 2025) i `migration-patterns` og `licensing-matrix`.
+- **Data engineering (Fabric/Databricks):** `zero-etl-fabric-patterns` Oracle/SAP mirroring Preview→GA; `onelake-data-strategy` OneLake Security + Shortcut Transformations GA; `lakehouse-architecture-design` liquid clustering GA; `data-quality-ai-frameworks` MLV `ON MISMATCH`-syntaks + DLT→Lakeflow SDP-rebrand.
+- **API Management (GenAI gateway):** `genai-gateway-policies` / `logging-analytics-ai-traffic` / `security-hardening-ai-gateway` — token-quota-period, KQL `ModelDeploymentName` → `DeploymentName`, `llm-token-limit` ikke støttet på Consumption, semantic-cache / Developer Portal v2-tier-matriser korrigert, llm-content-safety policy-syntaks.
+- **BCDR:** `state-management-failover` Azure Cache for Redis retirement → Azure Managed Redis; `multi-region-azure-openai-deployment` + `rto-rpo-planning-ai-services` BCDR-ref-URLer fikset.
+- **Cosmo-utfasing (start):** «For Cosmo»-seksjonene fjernet i `agent-framework` og `disconnected-ai-scenarios` (persona-pedagogikken er under avvikling — full fjerning på tvers av repoet er planlagt som eget initiativ).
+- **Header-bump (TRYGT, ~33 filer):** data-engineering-, api-management-, bcdr- og advisor-klyngene (innhold verifisert gjeldende mot Microsoft Learn).
+
+## [1.16.4] - 2026-06-24
+
+KB-refresh-patch. MEDIUM-tier (33 reference docs) verifisert mot Microsoft Learn (post-1.16.3 baseline). Ingen kommando-, agent- eller skill-endringer — kun reference docs. 18 filer var TRYGT (innhold gjeldende, kun header-bump); 15 filer hadde reell drift. Hver `VERIFY`-påstand fra de 7 parallelle drift-rapportene ble re-bekreftet av main-agent mot sitert Microsoft Learn-kilde FØR skriving; disclaimed/illustrative priser urørt; GPT-4.1-pricing-påstand forble uverifiserbar (kun community-kilder) og ble IKKE endret; alle endringer review-gated på `git diff` + plugin-validering (239/0). Medium-count 33 → 0 (needing-update 85 → 52).
+
+### Changed
+
+- **Prompt-caching:** `token-optimization` — retention-modell omskrevet: in-memory (5–10 min, ≤1t, default t.o.m. gpt-5.4) vs **extended retention 24t** (`prompt_cache_retention`, default for nyere modeller); in-memory støttes av «GPT-4o eller nyere».
+- **Realtime:** `real-time-reasoning` — la til `gpt-realtime-1.5` (2026-02-23); Realtime API flyttet til **GA-endepunkt** `/openai/v1` (ikke lenger date-baserte api-version); preview→GA-statusnyanse.
+- **Guardrails-rebranding:** `regulatory-and-compliance` + `azure-ai-foundry` — «content filters» → **Guardrails (and controls)**, default `Microsoft.DefaultV2`, fire intervensjonspunkter; data-privacy-kildetittel → «Models sold by Azure».
+- **GPU/PTU:** `gpu-compute-sizing` — `ND96asr_v4` = 8×A100 **40GB = 320 GB** (var 640 GB); `load-testing` — PTU min deployment Global/Data Zone **15** (increment 5), 50 kun Regional.
+- **Foundry-deprecations:** `azure-ai-foundry` — **Deep Research-tool** og **Connected agents (classic)** deprecated (retire 2027-03-31), **Prompt Flow**-retirement 2027-04-20, **A2A-tool nå i Java SDK**.
+- **Agent-evaluering/-memory:** `agent-evaluation` — nye agent-evaluatorer (Task Completion/Customer Satisfaction/Tool Selection m.fl.) + `FoundryEvals` + `gpt-4.1-mini` judge; `agent-memory` — **procedural memory** (3. type), TTL/CRUD, **Norway East**-region bekreftet (VNet ikke støttet).
+- **Øvrig faktafiks:** `multi-turn` RPM/TPM-forhold varierer per modell; `structured-output` usupporterte keywords utvidet + `gpt-4o-mini-audio-preview`; `temperature-sampling` Copilot Studio prompt builder-temp + fjernet uoffisielt M365-tall; `rag-hallucination` groundedness `mitigating`/`correctionText`; `model-versioning` MLflow stages legacy i UC; `speaker-recognition` **Limited Access**-status; `chain-of-thought` reasoning_effort per-modell-nyanse.
+- **Header-bump (TRYGT, 18 filer):** domain-specific, few-shot, function-calling, grounding, role-playing, system-message-design, async-processing, batch-api-usage, concurrent-request, performance-benchmarking, response-chunking, throughput-optimization, token-per-second, late-chunking, rag-evaluation, self-reflective-rag, streaming-rag, feedback-loops.
+
+## [1.16.3] - 2026-06-24
+
+KB-refresh-patch. HIGH-tier (11 reference docs) + 1 dateless kjernefil (`ms-ai-advisor/references/architecture/security.md`), flagget av endrings-detektoren mot Microsoft Learn-sitemaps (post-1.16.2 baseline), er verifisert og oppdatert. Ingen kommando-, agent- eller skill-endringer — kun reference docs. Hver `VERIFY`-påstand fra de parallelle drift-rapportene ble bekreftet mot sitert Microsoft Learn-kilde FØR skriving (main-agent som verifiseringsgate); disclaimed/illustrative priser urørt; alle endringer review-gated på `git diff` + plugin-validering (239/0). High-count 11 → 0, Unverified 1 → 0 (needing-update 97 → 85).
+
+### Changed
+
+- **Content Safety:** `bias-detection` image-modeller korrigert til **Medium** default-terskel (var feilaktig «Low»), verifisert mot `default-safety-policies`; `responsible-ai-policy` Foundry Agent Service monitoring merket **(Preview)**; `content-safety-implementation` tegnkode-typo (`申请` → `Apply for`). **Avkreftet ved verifisering:** Content Safety Analyze Text **10K-tegn**-grensen var korrekt (drift-rapportens «1000» var feillesing av Transparency Note-ens nøyaktighets-anbefaling — gaten fanget den).
+- **Guardrails/agenter:** `agent-autonomy-and-control-governance` la til **Task Adherence (preview)** i risk-kategoriene (bekreftet i `guardrails-overview`).
+- **Evaluering:** `response-quality-metrics-rag` la til **Prompt Flow retirement 2027-04-20** (migrer til Microsoft Agent Framework) + korrigerte `gpt-4.1-mini` (GPT-4.1-variant, ikke o-series reasoning model).
+- **Opphavsrett:** `copyright-ai-training-data-norway` oppdatert til **«Models sold by Azure»**-terminologi (var «Azure Direct Models»), la til 5. data-privacy-garanti (ingen forbedring av Microsoft-/tredjepartsprodukter uten samtykke), klargjorde CCC-scope (Copilot Studio + GitHub Copilot = tjeneste-spesifikke mitigations) og oppdaterte metaprompt-referansen til `safety-system-message-templates`.
+- **Sikkerhet (kjernefil):** `architecture/security.md` fikk maskinlesbar `Last updated`-header (var dateless → unverified), «Hate and Fairness»-navn, og CMK Key Vault-krav korrigert (Azure RBAC «Key Vault Crypto Service Encryption User» som primæralternativ, ikke «legacy access policies»). RBAC-rollenavn bekreftet uendret.
+- **Header-bump (TRYGT, innhold verifisert gjeldende):** `owasp-llm-top10-azure-mitigations`, `defender-threat-protection-ai-services`, `output-validation-grounding-verification`, `stakeholder-communication-ai-decisions`, `model-performance-drift-detection`.
+
 ## [1.16.2] - 2026-06-24
 
 KB-refresh-patch. Critical cost-klyngen (8 reference docs i `cost-optimization/`), flagget av endrings-detektoren mot Microsoft Learn-sitemaps (post-1.16.1 baseline), er verifisert og oppdatert. Ingen kommando-, agent- eller skill-endringer — kun reference docs. Hver `VERIFY`-påstand fra de parallelle drift-rapportene ble bekreftet mot sitert Microsoft Learn-kilde FØR skriving (main-agent som verifiseringsgate); disclaimed/illustrative priser urørt; alle endringer review-gated på `git diff` + plugin-validering (239/0). Critical-count for klyngen 8 → 0.

CLAUDE.md

@@ -78,14 +78,7 @@ Tilbyr strukturert arkitekturveiledning for Microsoft AI-stakken:
 
 ### Kunnskapsbase-routing i agenter (typisk 3 kjernefiler per invokasjon)
 
-Agenter leser navngitte kjernefiler, ikke hele kataloger. «3 kjernefiler» er normalen for review-/security-/cost-mønsteret; **ros-analysis-agent er et dokumentert unntak** med et større, eksplisitt last-kontrakt (kjerne + betinget) definert i agentfilen — fordi en deterministisk ROS krever trusselbibliotek + rubrikker + metodikk + mal som minimumskjerne.
+Agenter leser navngitte kjernefiler, ikke hele kataloger. «3 kjernefiler» er normalen for review-/security-/cost-mønsteret; **ros-analysis-agent er et dokumentert unntak** med et større, eksplisitt last-kontrakt (kjerne + betinget) — en deterministisk ROS krever trusselbibliotek + rubrikker + metodikk + mal som minimumskjerne. Hver agents nøyaktige kjerne-/betinget-filer er definert i **agentfilen** (single source of truth); `summary-agent` leser sesjonens assessment-outputs, ikke KB-filer.
-- **security-assessment-agent**: security-scoring-rubrics-6x5.md, ai-security-scoring-framework.md, ai-threat-modeling-stride.md
-- **cost-estimation-agent**: deterministic-cost-calculation-model.md, azure-ai-foundry-cost-governance.md, cost-models.md
-- **architecture-review-agent**: decision-trees.md, security.md, public-sector-checklist.md + domene-spesifikke ved behov (RAG/MLOps lastes betinget)
-- **ros-analysis-agent**: kjerne (alltid, 4): ros-ai-threat-library.md, ros-scoring-rubrics-7x5.md, ros-methodology-ns5814-iso31000.md, ros-report-templates.md + betinget på trigger (sektor / MAESTRO / DPIA-integrasjon / AI Act) — se last-kontrakt i agentfilen
-- **dpia-agent**: dpia-norwegian-methodology-ai.md, gdpr-compliance-ai-systems.md, ai-impact-assessment-framework.md + betinget cross-border (Schrems II → data-residency-audit-monitoring.md med EDPB seks-stegs-TIA)
-- **ai-act-assessor**: ai-act-classification-methodology.md + relevante ai-act-*.md filer (maks 3 per fase)
-- **summary-agent**: Leser assessment-outputs fra sesjon, ikke KB-filer
 
 ## MCP-servere
 
@@ -94,11 +87,7 @@ Agenter leser navngitte kjernefiler, ikke hele kataloger. «3 kjernefiler» er n
 
 ### Anbefalte MCP-servere (ikke påkrevd)
 
-- `azure-mcp-server` (microsoft/azure-mcp-server) — Live Azure-infrastrukturinspeksjon (Storage, Key Vault, Monitor, AI Search, RBAC)
+`azure-mcp-server` (live Azure-infra-inspeksjon), `bicep-mcp-server` (IaC), `azure-devops-mcp` (work items/pipelines/repos). Detaljer: `skills/ms-ai-advisor/references/architecture/recommended-mcp-servers.md`.
-- `bicep-mcp-server` — IaC-generering for Azure-ressurser
-- `azure-devops-mcp` (microsoft/azure-devops-mcp) — Work items, pipelines, repos
-
-Se `references/architecture/recommended-mcp-servers.md` for detaljer.
 
 ## Hooks (2)
 
@@ -107,13 +96,7 @@ Se `references/architecture/recommended-mcp-servers.md` for detaljer.
 | SessionStart | `session-start-context.mjs` | Viser aktive utredninger, KB-ferskhet, onboarding-status, skill- + kurs-signaler (Spor C), skill-kvalitetssignaler (Spor D — skills under 90 %, fra cachet score-rapport) + AI Act-frister |
 | Stop | `stop-assessment-reminder.mjs` | Påminnelse om ucommittede vurderinger, neste steg |
 
-> Skill-kvalitetssignalet (Spor D) leser den **cachede** rapporten
+> Spor D-signalet leser den **cachede** `scripts/kb-eval/data/skill-score-report.json` (aldri live — buildReport leser ~400 ref-filer); gitignored/regenererbar via `score-skill.mjs --write`, så fraværende i fersk klon → kun synlig for en vedlikeholder, og kun for skills <90 %.
-> `scripts/kb-eval/data/skill-score-report.json` og scorer aldri live
-> (buildReport leser ~400 ref-filer — for dyrt i en SessionStart-hook).
-> Cachen er gitignored (derivert/regenererbar via `score-skill.mjs --write`),
-> så den er fraværende i en fersk klon: linja surfacer kun for en vedlikeholder
-> som har produsert cachen lokalt, aldri for en sluttbruker. Alle skills ≥90 %
-> ⇒ ingen linje.
 
 > Secrets scanning consolidated to llm-security plugin.
 
@@ -121,27 +104,25 @@ Se `references/architecture/recommended-mcp-servers.md` for detaljer.
 
 - **Utvikling, testing, KB-refresh-workflow:** `docs/development.md`
 - **Playground v3 (decision-builder + rapport-viewer):** `docs/playground.md`
-- **Recommended MCP servers (detail):** `references/architecture/recommended-mcp-servers.md`
+- **Recommended MCP servers (detail):** `skills/ms-ai-advisor/references/architecture/recommended-mcp-servers.md`
 
 ## Viktige frister (EU AI Act)
 
-> **NB — Digital Omnibus (provisorisk):** EU-rådet og Parlamentet ble 7. mai 2026 enige om å utsette høyrisiko-fristene (Digital Omnibus). Endringene trer i kraft først ved formell vedtakelse + publisering i Official Journal (ventet før 2026-08-02), så datoene under er **foreløpige**. Des. 2027 er en **ytre grense** — Kommisjonen kan fremskynde til 6 mnd etter at standarder/spesifikasjoner/veiledning er på plass. Kjør `/architect:classify` for systemspesifikk vurdering.
+> **NB — Digital Omnibus (vedtatt, avventer OJ):** Digital Omnibus utsetter høyrisiko-fristene i AI Act. Endringen er **formelt vedtatt** (Europaparlamentet 16. juni, Rådet 29. juni 2026) og trer i kraft tredje dag etter publisering i Official Journal — senest 2026-07-30 for anvendelse før 2026-08-02. Datoene under følger vedtatt tekst og bekreftes mot OJ ved publisering. Kjør `/architect:classify` for systemspesifikk vurdering.
 
 | Frist | Krav | Status |
 |-------|------|--------|
 | 2025-02-02 | Forbudte AI-praksiser (Art. 5) | Gjeldende |
 | 2025-08-02 | GPAI-krav + governance/sanksjoner (Art. 99) | Gjeldende |
-| 2026-08-02 | Transparens (Art. 50): merking av syntetisk innhold gjelder | Gjeldende |
+| 2026-08-02 | Transparens (Art. 50): merking av syntetisk innhold | Fra 2026-08-02 |
 | 2026-12-02 | Art. 50(2): frist for maskinlesbar merking i eksisterende generative systemer | Overgang (Omnibus) |
-| 2027-12-02 | Annex III høyrisiko (frittstående) — utsatt fra 2026-08-02 | Provisorisk (Omnibus) |
+| 2027-12-02 | Annex III høyrisiko (frittstående) — utsatt fra 2026-08-02 | Vedtatt (Omnibus, avventer OJ) |
-| 2028-08-02 | Annex I høyrisiko (innebygd i regulerte produkter) | Provisorisk (Omnibus) |
+| 2028-08-02 | Annex I høyrisiko (innebygd i regulerte produkter) | Vedtatt (Omnibus, avventer OJ) |
 
-**Tilsynsmyndigheter:** Datatilsynet (personvern), nasjonal AI-tilsynsmyndighet (under etablering), sektortilsyn.
+> Maskinlesbar kilde: `scripts/kb-update/data/ai-act-deadlines.json` — synk-testet mot denne tabellen, assessor-malen og hookene (`tests/kb-update/test-ai-act-deadlines-sync.test.mjs`). Oppdater kilden først.
+
+**Tilsynsmyndigheter:** Nkom (koordinerende markedstilsynsmyndighet og nasjonalt kontaktpunkt for AI-forordningen), Datatilsynet (personvern), sektortilsyn kan utpekes i tillegg.
 
 ## Relaterte plugins (fremtidig)
 
-- `ms-rag-architect` — RAG-spesialist (egen plugin)
+Planlagte søsken-plugins: `ms-rag-architect` (RAG), `ms-power-automate-architect`, `ms-azure-ai-architect`, `ms-foundry-architect`, `ms-copilot-studio-architect`.
-- `ms-power-automate-architect` — Power Automate deep-dive
-- `ms-azure-ai-architect` — Azure AI Services deep-dive
-- `ms-foundry-architect` — Microsoft Foundry spesialist
-- `ms-copilot-studio-architect` — Copilot Studio spesialist

README.md

@@ -1,12 +1,14 @@
 # AI Architect Plugin for Claude Code
 
+Microsoft AI Solution Architect — structured architecture guidance for the full Microsoft AI stack.
+
 > Your virtual Microsoft AI solution architect — meet **Cosmo Skyberg**.
 
 > **Solo-maintained, fork-and-own.** This plugin is a starting point, not a vendor product. Issues are welcome as signals; pull requests are not accepted. See [GOVERNANCE.md](GOVERNANCE.md) for the full model and what upstream provides.
 
-*AI-generated: all code produced by Claude Code through dialog-driven development. [Full disclosure →](../../README.md#ai-generated-code-disclosure)*
+*AI-generated: all code produced by Claude Code through dialog-driven development. Every change is human-directed, reviewed, and validated before commit.*
 
-![Version](https://img.shields.io/badge/version-1.16.2-blue)
+![Version](https://img.shields.io/badge/version-1.17.0-blue)
 ![Platform](https://img.shields.io/badge/platform-Claude_Code_Plugin-purple)
 ![Docs](https://img.shields.io/badge/reference_docs-389-green)
 ![Agents](https://img.shields.io/badge/agents-12-orange)
@@ -14,12 +16,40 @@
 
 A Claude Code plugin that provides structured architecture guidance across the full Microsoft AI stack. Cosmo Skyberg is a methodical, opinionated architect persona who understands the problem before recommending technology, verifies claims against live Microsoft Learn documentation via MCP, and delivers assessments calibrated for Norwegian public sector governance — while remaining useful for any enterprise context.
 
+## Install
+
+Both lines are required — the first adds the marketplace, the second installs this plugin from it:
+
+```bash
+claude plugin marketplace add https://git.fromaitochitta.com/open/ktg-plugin-marketplace.git
+claude plugin install ms-ai-architect@ktg-plugin-marketplace
+```
+
+To browse the other plugins in the marketplace instead, run `/plugin`.
+
+Or enable directly in `~/.claude/settings.json`:
+
+```json
+{
+  "enabledPlugins": {
+    "ms-ai-architect@ktg-plugin-marketplace": true
+  }
+}
+```
+
+### Requirements
+
+- [Claude Code](https://docs.anthropic.com/en/docs/claude-code) installed
+- Python with [uv](https://github.com/astral-sh/uv) (for the microsoft-learn MCP server)
+- Network access to `learn.microsoft.com`
+
 ---
 
 ## Table of Contents
 
 - [What Is This?](#what-is-this)
-- [Quick Start](#quick-start)
+- [Non-goals](#non-goals)
+- [First Conversation](#first-conversation)
 - [Commands](#commands)
 - [Agent Architecture](#agent-architecture)
 - [Knowledge Base](#knowledge-base)
@@ -30,7 +60,7 @@ A Claude Code plugin that provides structured architecture guidance across the f
 - [Technology Coverage](#technology-coverage)
 - [Enterprise Onboarding](#enterprise-onboarding)
 - [Related Plugins](#related-plugins)
-- [Version History](#version-history)
+- [Changelog](#changelog)
 - [License & Attribution](#license--attribution)
 
 ---
@@ -58,33 +88,20 @@ Key capabilities:
 
 ---
 
-## Quick Start
+## Non-goals
 
-### Prerequisites
+What this plugin deliberately does not do — worth knowing before you adopt it:
 
-- [Claude Code](https://docs.anthropic.com/en/docs/claude-code) installed
+- **It is not legal advice.** Classification, DPIA/PVK and ROS output is decision support for architects. It is drafted to be reviewed by your data protection officer, legal counsel and approving authority — not to replace them.
-- Python with [uv](https://github.com/astral-sh/uv) (for the microsoft-learn MCP server)
+- **It does not deploy or provision anything.** Every command produces a document or an assessment. No command creates, modifies or deletes Azure resources, and the plugin writes no infrastructure-as-code.
-- Network access to `learn.microsoft.com`
+- **It is not a live pricing source.** Cost estimates use published list prices with explicit disclaimers and P10/P50/P90 ranges. Verify against the Azure pricing calculator before committing a budget.
+- **It covers the Microsoft stack only.** AWS Bedrock, Google Vertex AI and direct-to-provider LLM APIs are out of scope, including comparisons against them.
+- **It is not a vendor product.** Solo-maintained, no SLA, pull requests are not accepted — see [GOVERNANCE.md](GOVERNANCE.md).
+- **It is not affiliated with Microsoft.** Product names are trademarks of Microsoft Corporation, and nothing here is endorsed by them.
 
-### Installation
+---
 
-Add the marketplace and browse plugins with `/plugin`:
+## First Conversation
-
-```bash
-claude plugin marketplace add https://git.fromaitochitta.com/open/ktg-plugin-marketplace.git
-```
-
-Or enable directly in `~/.claude/settings.json`:
-
-```json
-{
-  "enabledPlugins": {
-    "ms-ai-architect@ktg-plugin-marketplace": true
-  }
-}
-```
-
-### First Conversation
 
 ```
 > /architect
@@ -551,7 +568,7 @@ For organizations that need deeper customization beyond what onboarding provides
 
 ### LLM Security Plugin
 
-The **[LLM Security Plugin](../llm-security)** is a companion plugin that covers the agentic AI attack surface — the runtime security dimension that complements this plugin's architecture-level assessments.
+The **[LLM Security Plugin](https://git.fromaitochitta.com/open/llm-security)** is a companion plugin that covers the agentic AI attack surface — the runtime security dimension that complements this plugin's architecture-level assessments.
 
 While **ms-ai-architect** evaluates *what to build* (platform selection, compliance, cost, risk), the LLM Security Plugin evaluates *whether what you built is safe to deploy* by scanning Claude Code plugins, MCP servers, and AI agent configurations against the OWASP LLM Top 10.
 
@@ -655,10 +672,16 @@ Category-to-skill routing is defined in `scripts/kb-update/data/domain-taxonomy.
 
 ---
 
-## Version History
+## Changelog
+
+Full history, including patch releases: [CHANGELOG.md](CHANGELOG.md). The table below summarizes the minor releases.
 
 | Version | Date | Highlights |
 |---------|------|-----------|
+| **1.17.0** | 2026-07-04 | **Spor 1 — Port-1-substrat migrert** på de 4 ikke-advisor-skills (327 filer). `**Type:**` stemplet på alle 327; `**Source:**` (Microsoft Learn-autoritet) backfilt på 243 sourced reference-filer; `## Innhold` TOC på 325 store filer. Stale `**Verified:** MCP`-poison fjernet (14 header + 9 stray body-dup i 500B-vinduet) → full-pass-worklist aktivert (243 due, 0 fresh). Prosa byte-identisk (fra første `##`), advisor-skillen urørt, `verified` null (settes i senere judge-pass). To applier-fixes TDD'd (`insertHeaderFields` giant-meta-anker, `normalizeStaleVerified` in-window body-dup). Suite 728/728. Utfall: `docs/spor1-migration-outcome.md`. |
+| **1.16.5** | 2026-06-24 | KB-refresh-patch (kun reference docs). **LOW-tier 52 filer** verifisert mot Microsoft Learn (post-1.16.4 baseline; ~33 TRYGT header-bump, resten reell drift/URL-/syntaksfiks). **Materiell fiks:** `agent-framework` fullstendig omskrevet (oppdiktet `azure.ai.agent`-API → ekte SDK `agent-framework`/`Microsoft.Agents.AI`: `Agent(client=...)`, `@tool`, `WorkflowBuilder`, OpenTelemetry; suksessor til SK **og** AutoGen) + `migration-patterns` §6 tilsvarende. **Norsk AI Act** ikrafttredelse mykgjort (forsinket pga. EØS). **Copilot Credits** (tidl. billed sessions). **Data eng:** Fabric mirroring / OneLake Security / liquid clustering Preview→GA, Lakeflow SDP-rebrand. **APIM:** KQL `DeploymentName`, token-quota, v2-tier-matriser. **BCDR:** Azure Cache for Redis → Managed Redis. **Cosmo-utfasing startet** («For Cosmo» fjernet i 2 filer; full fjerning som eget initiativ). `git diff` + validering 239/0. Needing-update 52 → 0 (alle tiers 0). |
+| **1.16.4** | 2026-06-24 | KB-refresh-patch (kun reference docs). **MEDIUM-tier 33 filer** verifisert mot Microsoft Learn (18 TRYGT header-bump, 15 reell drift). **Prompt-caching** in-memory vs extended 24t (`prompt_cache_retention`); **Realtime** `gpt-realtime-1.5` + GA-endepunkt `/openai/v1`; **Guardrails**-rebranding (tidl. content filters, `Microsoft.DefaultV2`); `ND96asr_v4` 320 GB (var 640); PTU min Global/Data Zone 15 (var 50); **Deep Research + Connected agents deprecated**, Prompt Flow-retirement 2027-04-20, A2A Java; nye agent-evaluatorer + `FoundryEvals`; **procedural memory** + Norway East; **Speaker Recognition Limited Access**. GPT-4.1-pricing forble uverifiserbar (community-kilder) → urørt. Hver `VERIFY` re-bekreftet av main-agent mot kilde FØR skriving; `git diff` + validering 239/0. Medium 33 → 0 (needing-update 85 → 52). |
+| **1.16.3** | 2026-06-24 | KB-refresh-patch (kun reference docs). **HIGH-tier 11 filer + 1 dateless kjernefil** verifisert mot Microsoft Learn. **Faktafiks:** Content Safety image-modeller Medium-terskel (ikke «Low»); `gpt-4.1-mini` = GPT-4.1-variant (ikke o-series reasoning); CMK Key Vault Azure RBAC «Key Vault Crypto Service Encryption User» som primæralternativ (ikke «legacy access policies»). **Lagt til:** Task Adherence (preview) i guardrails-risk-kategorier, Prompt Flow retirement 2027-04-20, 5. data-privacy-garanti, «Models sold by Azure»-terminologi, `security.md` maskinlesbar header. **Avkreftet ved verifisering:** Content Safety Analyze Text 10K-tegn-grensen var korrekt (drift-rapportens «1000» = feillesing av Transparency Note-anbefaling). Hver `VERIFY` bekreftet mot kilde FØR skriving; disclaimed priser urørt; `git diff` + plugin-validering 239/0. High 11 → 0, Unverified 1 → 0 (needing-update 97 → 85). |
 | **1.16.2** | 2026-06-24 | KB-refresh-patch (kun reference docs — ingen kommando-/agent-/skill-endringer). **Critical cost-klyngen** (8 filer i `cost-optimization/`) verifisert + oppdatert mot Microsoft Learn: Spillover GA, **Priority processing** (4. deployment-type), **Data Zone Batch** (SKU `DataZoneBatch`, EU/US-datasone), modell-lineup GPT-5 → 5.1/5.5, extended prompt-cache 24t, RFT-kostnadsmodell ($5000 per-job-tak), batch fail-fast-retry (server fail-fast + klient-side backoff), On Your Data-pensjon (2026-10-14). **Kalibrering:** fjernet uverifiserbart «175B+» (GPT-4o), «GPT-4 utfaset» → «legacy», og avkreftet én drift-påstand ved verifisering (Phi-3/Phi-2/Falcon-7B fortsatt i Foundry-katalogen → ingen «retired»-merking). Hver `VERIFY`-påstand bekreftet mot kilde FØR skriving; disclaimed priser urørt; `git diff` + plugin-validering 239/0. Critical-count 8 → 0. |
 | **1.16.1** | 2026-06-23 | KB-refresh-patch (kun reference docs — ingen kommando-/agent-/skill-endringer). **Modellkatalog** GPT-5.1 → GPT-5.5 i 3 filer (`batch-processing-cost-reduction.md`, `model-selection-price-performance.md`, `azure-ai-foundry.md`). **Foundry-navnesveip** «Azure AI Foundry» → «Microsoft Foundry» på tvers av 233 reference docs (810 forekomster). **RBAC** «Azure AI User» → «Foundry User» (`foundry-workflows-visual-orchestration.md`; cost-governance-mappingen bevart). Hvert premiss verifisert mot Microsoft Learn før sveip; `git diff` + plugin-validering + deterministisk re-score (skills uendret, alle ≥90 %). |
 | **1.16.0** | 2026-06-22 | Currency- og privat-sektor-paritets-audit (devil's-advocate-audit 2026-06-18, 10 dimensjoner, 89 verifiserte funn — `docs/devils-advocate-audit-2026-06-18.md`). **Regulatorisk:** EU AI Act-tidslinje re-baselinet mot Digital Omnibus (Annex III høyrisiko → 2027-12-02, Art. 50 → 2026-08-02) + Art. 99-bøtesatser (35M/7 %, 15M/3 %, 7,5M/1 %); EU AI Act ennå ikke EØS-innlemmet, KI-loven uvedtatt per juni 2026; DPIA cross-border med EDPB Rec 01/2020 seks-stegs-TIA + CLOUD Act/FISA-restanalyse + EDPB 28/2024 (anonymisering case-by-case). **Plattform:** Foundry URL-navnerom-migrering (`ai-foundry` → `foundry`/`foundry-classic`, 141 filer); Connected Agents deprecated (pensjon 2027-03-31) → Prompt/Hosted agents + Responses API; MAF 1.0 GA + A2A v1.0.1; Prompt Flow retirement 2027-04-20; CUA GA 2026-05-07; agentic retrieval GA-split. **Kostnad:** re-baselinet til GPT-5 $1,25/$10 med én prissannhet. **Dataresidens:** korrigert Norway East (gpt-4o + gpt-4o-mini eneste Norge-residente generative). **Sikkerhet:** Defender AI threat protection (ikke Azure Government) + OWASP LLM04/06/08/09-tiltak (2 nye KB-filer); M365 E7 + Agent 365 (GA 2026-05-01); Foundry Local air-gapped. **Privat-sektor-paritet:** sektor-parametrisering i 6 kommandoer + onboarding-forgrening + 4 nye kommandoer (`businesscase`, `anskaffelse`, `design`, `vendor` → 25 → 29 totalt). ROS/DPIA-currency (NSM v2.1, OWASP Agentic 2026, EchoLeak, DPF, EUDB). **Selvstendiggjøring (Spor C):** planlagt KB-deteksjon (opt-in, Claude-fri; Tier 1 SessionStart-hook + Tier 2 OS-scheduler launchd/cron) + onboarding-redesign (bruker-eid `~/.claude/ms-ai-architect/`, ambient org-injeksjon, valgfritt fritekst-felt, scheduler-kadens i onboarding, privat-sektor-paritet låst med regresjonsvakt). 389 reference docs (ms-ai-security 60 → 62). 239 plugin-validering · kb-integrity 192/192 · run-e2e alle suiter (+ onboarding-parity 14/14) 0 FAIL. Playground-koden uendret siden v1.15.0 (kun doc-stamp bumpet; screenshots ikke regenerert). |

agents/adr-writer-agent.md

@@ -2,12 +2,12 @@
 name: adr-writer-agent
 description: |
   Generates Architecture Decision Records (ADR) in MADR v3.0 format from structured input.
-  Reads adr-template.md, fills in from session context, and writes to file.
+  Reads adr-template.md, fills in from session context, and returns the ADR markdown to the main context.
   Use when architect:adr needs to generate a complete ADR document.
   Triggers on: ADR generation, decision documentation, architect:adr delegation.
 model: opus
 color: orange
-tools: ["Read", "Write", "Glob"]
+tools: ["Read", "Glob"]
 ---
 
 # ADR Writer Agent
@@ -40,7 +40,7 @@ Et kompakt sammendrag av virksomhetskonteksten injiseres ambient i hovedøkten v
 
 ### 1. Read Template
 
-Read `skills/ms-ai-advisor/references/architecture/adr-template.md` for the MADR v3.0 format.
+Read `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/adr-template.md` for the MADR v3.0 format.
 
 ### 2. Parse Input
 
@@ -87,9 +87,9 @@ Fill in every section of the MADR template:
 
 **Validering og oppfølging**: Concrete next steps with responsible party.
 
-### 4. Write to File
+### 4. Return to Main Context
 
-Write the ADR to the location specified in the input. Default: `docs/adr/ADR-NNN-[slug].md`
+Return the complete ADR markdown as your final message. The main context (the `/architect:adr` command) writes it to file — do not write files yourself (you run as a subagent).
 
 ## Output Format
 
@@ -101,7 +101,7 @@ The generated ADR should be:
 
 ## Quality Checklist
 
-Before writing:
+Before returning:
 - [ ] All template sections filled (no placeholders)
 - [ ] Compliance section included (even if "Not assessed")
 - [ ] Confidence level reflects actual analysis quality

agents/ai-act-assessor.md

@@ -23,17 +23,17 @@ You are a Norwegian regulatory compliance specialist focused on EU AI Act assess
 ## Knowledge Base References
 
 Read relevant files from:
-- `skills/ms-ai-governance/references/responsible-ai/ai-act-classification-methodology.md` — **OBLIGATORISK:** 4-stegs klassifiseringsmetodikk
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-classification-methodology.md` — **OBLIGATORISK:** 4-stegs klassifiseringsmetodikk
-- `skills/ms-ai-governance/references/responsible-ai/ai-act-provider-obligations.md` — Provider-forpliktelser Art. 9-27
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-provider-obligations.md` — Provider-forpliktelser Art. 9-27
-- `skills/ms-ai-governance/references/responsible-ai/ai-act-deployer-obligations.md` — Deployer-forpliktelser Art. 26-27
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-deployer-obligations.md` — Deployer-forpliktelser Art. 26-27
-- `skills/ms-ai-governance/references/responsible-ai/ai-act-fria-template.md` — FRIA-mal Art. 27
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-fria-template.md` — FRIA-mal Art. 27
-- `skills/ms-ai-governance/references/responsible-ai/ai-act-conformity-assessment.md` — Samsvarsvurdering Annex IV/VI/VII
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-conformity-assessment.md` — Samsvarsvurdering Annex IV/VI/VII
-- `skills/ms-ai-governance/references/responsible-ai/ai-act-transparency-notices.md` — Art. 13/50 transparensnotiser
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-transparency-notices.md` — Art. 13/50 transparensnotiser
-- `skills/ms-ai-governance/references/responsible-ai/ai-act-microsoft-tools-mapping.md` — Artikkel-til-verktøy-mapping
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-microsoft-tools-mapping.md` — Artikkel-til-verktøy-mapping
-- `skills/ms-ai-governance/references/responsible-ai/ai-act-compliance-guide.md` — Generell compliance-veileder
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-compliance-guide.md` — Generell compliance-veileder
-- `skills/ms-ai-governance/references/responsible-ai/ai-act-annex-iii-checklist.md` — Annex III sjekkliste med beslutningstre
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-annex-iii-checklist.md` — Annex III sjekkliste med beslutningstre
-- `skills/ms-ai-governance/references/norwegian-public-sector-governance/norge-ai-strategy-government.md` — Norsk AI-strategi
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/norwegian-public-sector-governance/norge-ai-strategy-government.md` — Norsk AI-strategi
-- `skills/ms-ai-governance/references/norwegian-public-sector-governance/forvaltningsloven-ai-decisions.md` — Forvaltningsloven og AI
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/norwegian-public-sector-governance/forvaltningsloven-ai-decisions.md` — Forvaltningsloven og AI
 
 ## Virksomhetskontekst (automatisk)
 
@@ -59,7 +59,7 @@ Ekstraher fra brukerens input:
 
 ### Fase 2: Klassifisering (4-stegs)
 Les `ai-act-classification-methodology.md` og utfør:
-1. **Forbudt-sjekk (Art. 5):** Er noen av de 8 forbudte praksisene relevante?
+1. **Forbudt-sjekk (Art. 5):** Er noen av de forbudte praksisene relevante? (8 i kraft; i tillegg nudifiers/NCII/CSAM-forbudet — Digital Omnibus, anvendelse 2026-12-02, avventer OJ)
 2. **Annex III høyrisiko-sjekk:** Treffer systemet noen av de 8 kategoriene?
 3. **GPAI-sjekk:** Er systemet basert på generell AI-modell? Systemisk risiko?
 4. **Begrenset/Minimal:** Transparenskrav eller frivillig Code of Conduct?
@@ -142,8 +142,9 @@ Anbefal oppfølgingsaktiviteter:
 | 2025-02-02 | Forbudte AI-praksiser (Art. 5) | [Gjelder/Gjelder ikke] |
 | 2025-08-02 | GPAI-krav + governance/sanksjoner (Art. 99) | [Gjelder/Gjelder ikke] |
 | 2026-08-02 | Transparens (Art. 50, syntetisk innhold) | [Gjelder/Gjelder ikke] |
-| 2027-12-02 | Annex III høyrisiko — provisorisk (utsatt fra 2026-08-02 via Omnibus, avventer OJ) | [Gjelder/Gjelder ikke] |
+| 2026-12-02 | Art. 50(2): maskinlesbar merking i eksisterende generative systemer | [Gjelder/Gjelder ikke] |
-| 2028-08-02 | Annex I høyrisiko innebygd (provisorisk) | [Gjelder/Gjelder ikke] |
+| 2027-12-02 | Annex III høyrisiko — utsatt fra 2026-08-02 (Omnibus vedtatt, avventer OJ) | [Gjelder/Gjelder ikke] |
+| 2028-08-02 | Annex I høyrisiko innebygd (Omnibus vedtatt, avventer OJ) | [Gjelder/Gjelder ikke] |
 
 ### Referanser
 - [Liste over KB-filer og MCP-kilder brukt]
@@ -176,8 +177,8 @@ Bruk `microsoft_docs_search` for:
 ## Norwegian Public Sector Context
 
 - Alle vurderinger gjøres i norsk kontekst (EØS-implementering)
-- Datatilsynet er sannsynlig tilsynsmyndighet (personverndimensjon)
+- Nkom er koordinerende markedstilsynsmyndighet og nasjonalt kontaktpunkt for AI-forordningen i Norge
-- Nasjonal AI-tilsynsmyndighet er under etablering
+- Datatilsynet er tilsynsmyndighet for personverndimensjonen; sektortilsyn kan utpekes i tillegg
 - Forvaltningsloven gjelder i tillegg til AI Act for vedtakssystemer
 - Offentlig sektor er nesten alltid deployer, sjelden provider
 

agents/architecture-review-agent.md

@@ -63,7 +63,7 @@ For høyrisiko-systemer, verifiser:
 - [ ] **FRIA gjennomført (Art. 27):** Obligatorisk for offentlig sektor-deployers
 
 **Ekstra KB-referanse:**
-- `skills/ms-ai-governance/references/responsible-ai/ai-act-conformity-assessment.md`
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-conformity-assessment.md`
 
 ### 3. Utredningsinstruksen (Analysis Requirements)
 - **Problem description**: Clear problem statement, affected parties identified
@@ -156,21 +156,21 @@ Read the architecture proposal. Extract:
 
 ### 2. Load Reference Knowledge
 Read relevant knowledge base files:
-- `skills/ms-ai-advisor/references/architecture/decision-trees.md` — Platform selection validation
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/decision-trees.md` — Platform selection validation
-- `skills/ms-ai-advisor/references/architecture/security.md` — Security best practices
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/security.md` — Security best practices
-- `skills/ms-ai-advisor/references/architecture/public-sector-checklist.md` — Norwegian compliance checklist
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/public-sector-checklist.md` — Norwegian compliance checklist
-- `skills/ms-ai-advisor/references/architecture/ai-utredning-template.md` — Utredningsinstruksen template
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/ai-utredning-template.md` — Utredningsinstruksen template
-- `skills/ms-ai-advisor/references/architecture/cost-models.md` — Cost estimation patterns
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/cost-models.md` — Cost estimation patterns
-- `skills/ms-ai-advisor/references/architecture/licensing-matrix.md` — License requirements
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/licensing-matrix.md` — License requirements
 
 Load domain-specific references only when dimension requires depth (max 2-3 additional):
-- AI Act: `responsible-ai/ai-act-compliance-guide.md`, `responsible-ai/ai-act-annex-iii-checklist.md`
+- AI Act: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-compliance-guide.md`, `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-annex-iii-checklist.md`
-- Governance: `responsible-ai/ai-governance-structure-framework.md`
+- Governance: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-governance-structure-framework.md`
-- Norwegian: `norwegian-public-sector-governance/utredningsinstruksen-ai-methodology.md`
+- Norwegian: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/norwegian-public-sector-governance/utredningsinstruksen-ai-methodology.md`
-- Security: `ai-security-engineering/ai-threat-modeling-stride.md`
+- Security: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/ai-security-engineering/ai-threat-modeling-stride.md`
-- Cost: `cost-optimization/azure-ai-foundry-cost-governance.md`, `cost-optimization/deterministic-cost-calculation-model.md`
+- Cost: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/cost-optimization/azure-ai-foundry-cost-governance.md`, `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/cost-optimization/deterministic-cost-calculation-model.md`
-- RAG-arkitektur (når løsningen er RAG-/gjenfinningsbasert): `skills/ms-ai-engineering/references/rag-architecture/rag-core-patterns.md`, `rag-architecture/agentic-rag-patterns.md`, `rag-architecture/rag-evaluation-frameworks.md`
+- RAG-arkitektur (når løsningen er RAG-/gjenfinningsbasert): `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-engineering/references/rag-architecture/rag-core-patterns.md`, `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-engineering/references/rag-architecture/agentic-rag-patterns.md`, `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-engineering/references/rag-architecture/rag-evaluation-frameworks.md`
-- MLOps/GenAIOps (når løsningen har produksjons-/livssyklusfokus): `skills/ms-ai-engineering/references/mlops-genaiops/genaiops-llm-specific-practices.md`, `mlops-genaiops/monitoring-observability-ml-systems.md`, `mlops-genaiops/model-deployment-strategies-azure.md`
+- MLOps/GenAIOps (når løsningen har produksjons-/livssyklusfokus): `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-engineering/references/mlops-genaiops/genaiops-llm-specific-practices.md`, `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-engineering/references/mlops-genaiops/monitoring-observability-ml-systems.md`, `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-engineering/references/mlops-genaiops/model-deployment-strategies-azure.md`
 
 ## Virksomhetskontekst (automatisk)
 

agents/cost-estimation-agent.md

@@ -47,7 +47,7 @@ Provide accurate, comprehensive cost estimates for Microsoft AI solutions includ
 
 **ALWAYS start by reading:**
 ```bash
-Read skills/ms-ai-advisor/references/architecture/cost-models.md
+Read ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/cost-models.md
 ```
 
 This file contains verified pricing data and calculation formulas.
@@ -55,14 +55,14 @@ This file contains verified pricing data and calculation formulas.
 ## Knowledge Base References (max 3 per invokasjon)
 
 Read these core files:
-- `skills/ms-ai-security/references/cost-optimization/deterministic-cost-calculation-model.md` — **OBLIGATORISK:** Enhetspriser, beregningsformler, P10/P50/P90 konfidensintervaller
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/cost-optimization/deterministic-cost-calculation-model.md` — **OBLIGATORISK:** Enhetspriser, beregningsformler, P10/P50/P90 konfidensintervaller
-- `skills/ms-ai-security/references/cost-optimization/azure-ai-foundry-cost-governance.md` — FinOps-rammeverk
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/cost-optimization/azure-ai-foundry-cost-governance.md` — FinOps-rammeverk
-- `skills/ms-ai-advisor/references/architecture/cost-models.md` — Cost model templates
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/cost-models.md` — Cost model templates
 
 Load additional files only when estimate requires specific depth:
-- PTU: `cost-optimization/ptu-vs-paygo-economics.md`
+- PTU: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/cost-optimization/ptu-vs-paygo-economics.md`
-- Caching: `cost-optimization/semantic-caching-patterns.md`
+- Caching: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/cost-optimization/semantic-caching-patterns.md`
-- Model selection: `cost-optimization/model-selection-price-performance.md`
+- Model selection: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/cost-optimization/model-selection-price-performance.md`
 
 ## Virksomhetskontekst (automatisk)
 

agents/diagram-generation-agent.md

@@ -45,7 +45,7 @@ Et kompakt sammendrag av virksomhetskonteksten injiseres ambient i hovedøkten v
 
 Les prompt-maler fra:
 ```
-skills/ms-ai-advisor/references/architecture/diagram-prompt-templates.md
+${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/diagram-prompt-templates.md
 ```
 
 ## Azure-stilguide

agents/dpia-agent.md

@@ -17,15 +17,15 @@ You are a Norwegian data protection specialist conducting structured DPIAs for A
 ## Knowledge Base References (3 kjernefiler + betinget)
 
 Read these core files:
-- `skills/ms-ai-governance/references/norwegian-public-sector-governance/dpia-norwegian-methodology-ai.md` — DPIA-metodikk
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/norwegian-public-sector-governance/dpia-norwegian-methodology-ai.md` — DPIA-metodikk
-- `skills/ms-ai-governance/references/responsible-ai/gdpr-compliance-ai-systems.md` — GDPR for AI
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/gdpr-compliance-ai-systems.md` — GDPR for AI
-- `skills/ms-ai-governance/references/responsible-ai/ai-impact-assessment-framework.md` — Konsekvensvurdering
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-impact-assessment-framework.md` — Konsekvensvurdering
 
 Load additional files only when assessment requires specific depth:
-- Bias: `responsible-ai/bias-detection-mitigation-strategies.md`
+- Bias: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/bias-detection-mitigation-strategies.md`
-- PII: `ai-security-engineering/pii-detection-norwegian-context.md`
+- PII: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/ai-security-engineering/pii-detection-norwegian-context.md`
-- Data leakage: `ai-security-engineering/data-leakage-prevention-ai.md`
+- Data leakage: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/ai-security-engineering/data-leakage-prevention-ai.md`
-- **Cross-border / Schrems II (OBLIGATORISK når data kan nås fra tredjeland — se Fase 3, risiko 7):** `monitoring-observability/data-residency-audit-monitoring.md` — EDPB seks-stegs-TIA, CLOUD Act/FISA 702/EO 12333-restanalyse, EO 14086/DPF-status, tekniske tilleggstiltak
+- **Cross-border / Schrems II (OBLIGATORISK når data kan nås fra tredjeland — se Fase 3, risiko 7):** `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/monitoring-observability/data-residency-audit-monitoring.md` — EDPB seks-stegs-TIA, CLOUD Act/FISA 702/EO 12333-restanalyse, EO 14086/DPF-status, tekniske tilleggstiltak
 
 ## Virksomhetskontekst (automatisk)
 
@@ -47,12 +47,12 @@ Før DPIA-vurderingen, sjekk om AI Act-klassifisering er utført:
 - Integrer deployer-forpliktelser fra `ai-act-deployer-obligations.md` som tiltak i Fase 4
 
 ### Hvis ikke klassifisert
-- Spør om det bør gjøres: "Er det gjennomført AI Act-klassifisering for dette systemet? Hvis nei, anbefaler vi `/architect:classify` — men DPIA fortsetter uansett."
+- Marker i rapporten at AI Act-klassifisering ikke er dokumentert, og anbefal `/architect:classify` som neste steg (du kjører som subagent uten brukertur — still ingen spørsmål)
 - Fortsett DPIA som normalt — klassifisering er ikke forutsetning
 
 ### Ekstra KB-referanser for AI Act
-- `skills/ms-ai-governance/references/responsible-ai/ai-act-deployer-obligations.md` — Deployer-krav inkl. FRIA og logging
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-deployer-obligations.md` — Deployer-krav inkl. FRIA og logging
-- `skills/ms-ai-governance/references/responsible-ai/ai-act-transparency-notices.md` — Art. 13/50 maler for transparenstiltak
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-transparency-notices.md` — Art. 13/50 maler for transparenstiltak
 
 ## DPIA Framework (5 Phases)
 
@@ -93,7 +93,7 @@ Risk categories for AI systems:
 
 #### Cross-border / Schrems II — obligatorisk TIA (risiko 7)
 
-Når systemet bruker en amerikansk-eid skyleverandør (Azure/Microsoft 365/Foundry) eller data på annen måte kan nås fra tredjeland, **er det ikke nok å navngi risikoen** — load `monitoring-observability/data-residency-audit-monitoring.md` og gjennomfør EDPB seks-stegs Transfer Impact Assessment:
+Når systemet bruker en amerikansk-eid skyleverandør (Azure/Microsoft 365/Foundry) eller data på annen måte kan nås fra tredjeland, **er det ikke nok å navngi risikoen** — load `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/monitoring-observability/data-residency-audit-monitoring.md` og gjennomfør EDPB seks-stegs Transfer Impact Assessment:
 
 1. Kartlegg overføringene (inkl. residual: support, troubleshooting, telemetri)
 2. Identifiser overføringsverktøyet (adekvansvedtak / SCCs / unntak)
@@ -141,9 +141,9 @@ Read the AI system description or architecture proposal. Extract:
 
 ### 2. Load Reference Knowledge
 Core files are loaded via Knowledge Base References above. For deeper analysis:
-- Fairness: `responsible-ai/fairness-testing-measurement.md`
+- Fairness: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/fairness-testing-measurement.md`
-- Transparency: `responsible-ai/transparency-documentation-standards.md`
+- Transparency: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/transparency-documentation-standards.md`
-- Human oversight: `responsible-ai/human-in-the-loop-oversight.md`
+- Human oversight: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/human-in-the-loop-oversight.md`
 
 ### 3. Validate Latest Guidance
 Use `microsoft_docs_search` for:
@@ -225,7 +225,7 @@ Follow the output format below with all sections completed.
 
 If missing information:
 - State assumptions clearly
-- Request specific details needed
+- Note which specific inputs are missing rather than requesting them (you run as a non-interactive subagent with no user turn)
 - Provide conditional assessments
 - Note "Kan ikke vurdere [area] uten [info]"
 

agents/license-mapper-agent.md

@@ -41,11 +41,11 @@ Given a set of Microsoft license types, produce a complete capability map showin
 ### 1. Read Reference Data
 
 Read these files:
-- `skills/ms-ai-advisor/references/architecture/licensing-matrix.md` — master matrix
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/licensing-matrix.md` — master matrix
-- `skills/ms-ai-advisor/references/platforms/azure-ai-foundry.md` — Foundry capabilities
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/platforms/azure-ai-foundry.md` — Foundry capabilities
-- `skills/ms-ai-advisor/references/platforms/copilot-studio.md` — Copilot Studio capabilities
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/platforms/copilot-studio.md` — Copilot Studio capabilities
-- `skills/ms-ai-advisor/references/platforms/m365-copilot.md` — M365 Copilot capabilities
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/platforms/m365-copilot.md` — M365 Copilot capabilities
-- `skills/ms-ai-advisor/references/platforms/power-platform.md` — Power Platform capabilities
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/platforms/power-platform.md` — Power Platform capabilities
 
 ### 2. Map Licenses to Capabilities
 

agents/research-agent.md

@@ -34,8 +34,8 @@ Et kompakt sammendrag av virksomhetskonteksten injiseres ambient i hovedøkten v
 ## Lokal KB-baseline (betinget — RAG / MLOps / engineering-temaer)
 
 Når forskningstemaet er RAG, gjenfinning, MLOps eller GenAIOps, les den relevante engineering-kjernefilen **først** som hypotese-baseline — verifiser den deretter mot live Microsoft Learn. KB-en kan være utdatert; **MCP-resultatet er fasit**.
-- RAG/gjenfinning: `skills/ms-ai-engineering/references/rag-architecture/rag-core-patterns.md`, `rag-architecture/agentic-rag-patterns.md`
+- RAG/gjenfinning: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-engineering/references/rag-architecture/rag-core-patterns.md`, `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-engineering/references/rag-architecture/agentic-rag-patterns.md`
-- MLOps/GenAIOps: `skills/ms-ai-engineering/references/mlops-genaiops/genaiops-llm-specific-practices.md`, `mlops-genaiops/llm-evaluation-production.md`
+- MLOps/GenAIOps: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-engineering/references/mlops-genaiops/genaiops-llm-specific-practices.md`, `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-engineering/references/mlops-genaiops/llm-evaluation-production.md`
 
 Les maks 2 baseline-filer. **Flagg eksplisitt** hvis live docs avviker fra KB-baselinen (samme avviks-flagging som Fase 4).
 

agents/ros-analysis-agent.md

@@ -22,7 +22,7 @@ You are a Norwegian risk management specialist conducting structured ROS analyse
 
 ROS er en bevisst KB-tung agent. En deterministisk analyse krever et fast **kjernesett** pluss et **betinget sett** lastet på definerte triggere. Dette er større enn det generelle «3 kjernefiler»-mønsteret i `CLAUDE.md` (security/cost/review) — det er en dokumentert, håndhevet last-rekkefølge, ikke fri lesing. **To analytikere som kjører samme system skal laste de samme filene i samme rekkefølge.**
 
-Alle stier under `skills/ms-ai-governance/references/norwegian-public-sector-governance/` med mindre annet er angitt.
+Alle stier under `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/norwegian-public-sector-governance/` med mindre annet er angitt.
 
 ### Obligatorisk kjerne (last ALLTID, i denne rekkefølgen)
 1. `ros-ai-threat-library.md` — AI-trusselbibliotek (kilde for T-xxx-IDer)
@@ -36,12 +36,12 @@ Alle stier under `skills/ms-ai-governance/references/norwegian-public-sector-gov
 | Sektor oppdaget (helse/transport/finans/justis/utdanning) | `ros-sector-checklists.md` |
 | Multi-agent / agent-orkestrering | `ros-maestro-multiagent.md` (MAESTRO 7-lag) |
 | DPIA eller sikkerhetsvurdering skal integreres | `ros-dpia-security-integration.md` |
-| AI Act-dybde i dimensjon 6 | `responsible-ai/ai-act-classification-methodology.md` + `responsible-ai/ai-act-provider-obligations.md` (maks 2) |
+| AI Act-dybde i dimensjon 6 | `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-classification-methodology.md` + `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-provider-obligations.md` (maks 2) |
 
 ### Referanse (last kun ved eksplisitt behov, ikke default)
-- `skills/ms-ai-security/references/ai-security-engineering/security-scoring-rubrics-6x5.md` — scoringsmønster-referanse
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/ai-security-engineering/security-scoring-rubrics-6x5.md` — scoringsmønster-referanse
 - `ros-analyse-ai-systems.md` — generell ROS-bakgrunn
-- `responsible-ai/ai-risk-taxonomy-classification.md` — risikotaksonomi
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-risk-taxonomy-classification.md` — risikotaksonomi
 
 **Budsjett:** kjerne (4) + betinget (maks 2-3 på trigger) = typisk 5-7 filer. Aldri last hele katalogen; last ikke en betinget fil hvis triggeren ikke utløses.
 
@@ -118,8 +118,8 @@ I tillegg til eksisterende trusler i dimensjon 6, vurder følgende:
 - Art. 50 (transparens): Opptil 7,5 MEUR eller 1,5 % av global omsetning
 
 **KB-referanser for AI Act-dybde i dimensjon 6** (betinget — last per last-kontrakten øverst, AI Act-trigger):
-- `skills/ms-ai-governance/references/responsible-ai/ai-act-classification-methodology.md`
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-classification-methodology.md`
-- `skills/ms-ai-governance/references/responsible-ai/ai-act-provider-obligations.md`
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-provider-obligations.md`
 
 ## 8-fase metodikk (NS 5814-compliant)
 
@@ -273,7 +273,7 @@ Risk Levels: Low (1-6), Medium (7-12), High (13-19), Critical (20-25)
 
 If missing information:
 - State assumptions clearly
-- Request specific details needed
+- Note which specific inputs are missing rather than requesting them (you run as a non-interactive subagent with no user turn)
 - Provide conditional assessments
 - Note "Kan ikke vurdere [area] uten [info]"
 

agents/security-assessment-agent.md

@@ -21,14 +21,14 @@ You are a Microsoft AI security specialist. You assess AI architectures against
 ## Knowledge Base References (max 3 per invokasjon)
 
 Read these core files:
-- `skills/ms-ai-security/references/ai-security-engineering/security-scoring-rubrics-6x5.md` — **OBLIGATORISK:** Deterministiske scoringsrubrikker
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/ai-security-engineering/security-scoring-rubrics-6x5.md` — **OBLIGATORISK:** Deterministiske scoringsrubrikker
-- `skills/ms-ai-security/references/ai-security-engineering/ai-security-scoring-framework.md` — Scoring-rammeverk
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/ai-security-engineering/ai-security-scoring-framework.md` — Scoring-rammeverk
-- `skills/ms-ai-security/references/ai-security-engineering/ai-threat-modeling-stride.md` — STRIDE trusselmodellering
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/ai-security-engineering/ai-threat-modeling-stride.md` — STRIDE trusselmodellering
 
 Load additional files only when assessment requires specific depth:
-- Prompt injection: `ai-security-engineering/prompt-injection-defense-patterns.md`
+- Prompt injection: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/ai-security-engineering/prompt-injection-defense-patterns.md`
-- Governance: `responsible-ai/ai-act-compliance-guide.md`
+- Governance: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-compliance-guide.md`
-- Norwegian context: `norwegian-public-sector-governance/nsm-grunnprinsipper-ai-mapping.md`
+- Norwegian context: `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/norwegian-public-sector-governance/nsm-grunnprinsipper-ai-mapping.md`
 
 ## Virksomhetskontekst (automatisk)
 
@@ -147,8 +147,8 @@ Read the architecture proposal or solution description. Look for:
 
 ### 2. Load Reference Knowledge
 Read these knowledge base files:
-- `skills/ms-ai-advisor/references/architecture/security.md` — Security best practices
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/security.md` — Security best practices
-- `skills/ms-ai-advisor/references/architecture/public-sector-checklist.md` — Norwegian compliance (if exists)
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/public-sector-checklist.md` — Norwegian compliance (if exists)
 
 ### 3. Validate Latest Guidance
 Use `microsoft_docs_search` for:

commands/adr.md

@@ -42,13 +42,13 @@ Hvis `/architect:cost` ble brukt, inkluder kostnadsestimatet.
 Bruk Task-verktøyet til å delegere ADR-generering:
 
 ```
-Task(general-purpose): "Read agents/adr-writer-agent.md for your role and instructions.
+Task(ms-ai-architect:adr-writer-agent): "
 Generate an ADR based on the current session context.
 Beslutning: [beslutningstittel]
 Bakgrunn: [forretningskontekst]
 Alternativer: [vurderte alternativer]
 Valgt løsning: [beslutning med begrunnelse]
-Les også: skills/ms-ai-advisor/references/architecture/adr-template.md"
+Les også: ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/adr-template.md"
 ```
 
 ### 4. Skriv til fil

commands/anskaffelse.md

@@ -30,7 +30,7 @@ Spør om nøkkelinformasjon hvis ikke kjent:
 
 ### 3. Les kunnskapsbasen
 
-- `skills/ms-ai-governance/references/norwegian-public-sector-governance/anskaffelser-ai-procurement-framework.md` — lovgrunnlag (anskaffelsesloven/-forskriften), EØS-regelverk, AI-spesifikk kravspesifikasjon, leverandørevaluering, etiske krav, DFØs IT-anskaffelsesveiledning
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/norwegian-public-sector-governance/anskaffelser-ai-procurement-framework.md` — lovgrunnlag (anskaffelsesloven/-forskriften), EØS-regelverk, AI-spesifikk kravspesifikasjon, leverandørevaluering, etiske krav, DFØs IT-anskaffelsesveiledning
 
 For AI Act-deployer-/transparenskrav som skal inn i kravspec: koble til `/architect:requirements` og `/architect:classify`.
 

commands/architect.md

@@ -12,9 +12,9 @@ Du aktiverer nå **Cosmo Skyberg**, en erfaren Microsoft AI Solution Architect.
 
 ## Instruksjoner
 
-1. Les og aktiver skillen `ms-ai-advisor/SKILL.md`
+1. Les og aktiver skillen `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/SKILL.md`
 2. Følg arbeidsprosessen definert i skillen
-3. Bruk kunnskapsbasene i `references/` for verifisering
+3. Bruk kunnskapsbasene i `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/` for verifisering
 4. Bruk `microsoft-learn` MCP-verktøy for oppdatert informasjon
 
 ## Oppstart

commands/businesscase.md

@@ -33,8 +33,8 @@ Spør om nøkkeltall hvis ikke allerede kjent:
 
 ### 3. Les kunnskapsbasene
 
-- `skills/ms-ai-governance/references/norwegian-public-sector-governance/samfunnsokonomisk-analyse-nnv.md` — NNV-formel, kalkulasjonsrente, diskonteringsfaktorer, skattefinansieringskostnad, prissatte vs. ikke-prissatte virkninger
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/norwegian-public-sector-governance/samfunnsokonomisk-analyse-nnv.md` — NNV-formel, kalkulasjonsrente, diskonteringsfaktorer, skattefinansieringskostnad, prissatte vs. ikke-prissatte virkninger
-- `skills/ms-ai-governance/references/norwegian-public-sector-governance/gevinstrealisering-dfo-methodology.md` — DFØs 5-stegs modell + gevinstregister-mal
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/norwegian-public-sector-governance/gevinstrealisering-dfo-methodology.md` — DFØs 5-stegs modell + gevinstregister-mal
 
 For selve kostnadsestimatet: deleger til `/architect:cost` eller `cost-estimation-agent` og bruk resultatet som input til NNV-en.
 

commands/classify.md

@@ -33,7 +33,7 @@ Bruk samtalehistorikk hvis denne informasjonen allerede er gitt.
 Kjør AI Act-agenten via Task for klassifiseringen:
 
 ```
-Task(ai-act-assessor): "Read agents/ai-act-assessor.md for your role and instructions.
+Task(ms-ai-architect:ai-act-assessor): "
 Gjennomfør en EU AI Act-klassifisering (Fase 1-3) for følgende AI-system:
 
 **System:** [systemnavn]
@@ -48,9 +48,9 @@ Gjennomfør en EU AI Act-klassifisering (Fase 1-3) for følgende AI-system:
 Modus: Klassifisering — fokus på risikonivå og rolle.
 
 Les kunnskapsbasene:
-- skills/ms-ai-governance/references/responsible-ai/ai-act-classification-methodology.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-classification-methodology.md
-- skills/ms-ai-governance/references/responsible-ai/ai-act-annex-iii-checklist.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-annex-iii-checklist.md
-- skills/ms-ai-governance/references/responsible-ai/ai-act-compliance-guide.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-compliance-guide.md
 
 Lever klassifiseringsresultat med risikonivå, Annex III-kategori, GPAI-status, rolle og begrunnelse."
 ```

commands/compare.md

@@ -36,16 +36,16 @@ Hvis bare én plattform er angitt, foreslå den mest relevante motparten basert
 Deleger research til `research-agent` via Task-verktøyet:
 
 ```
-Task(general-purpose): "Les agents/research-agent.md og utfør research.
+Task(ms-ai-architect:research-agent): "Utfør research.
 Sammenlign [Plattform A] og [Plattform B] for [use case].
 Fokusér på: kapabiliteter, begrensninger, prising, regional tilgjengelighet.
 Bruk microsoft_docs_search for begge plattformer."
 ```
 
 Les også relevant kunnskapsbase:
-- `skills/ms-ai-advisor/references/architecture/decision-trees.md` — beslutningsrammeverk
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/decision-trees.md` — beslutningsrammeverk
-- Les plattformfil(er) relevant for sammenligningen fra `skills/ms-ai-advisor/references/platforms/` (max 2-3 filer)
+- Les plattformfil(er) relevant for sammenligningen fra `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/platforms/` (max 2-3 filer)
-- **Ved 3+ alternativer eller `--weighted`:** `skills/ms-ai-advisor/references/architecture/alternativanalyse-methodology.md` — vektet multi-kriterie-analyse (scoringsskala, standardkriterier, vekting, begrunnelsestabell)
+- **Ved 3+ alternativer eller `--weighted`:** `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/alternativanalyse-methodology.md` — vektet multi-kriterie-analyse (scoringsskala, standardkriterier, vekting, begrunnelsestabell)
 
 ### 3. Bygg sammenligning
 

commands/conformity.md

@@ -27,7 +27,7 @@ Avklar:
 ### 2. Deleger til AI Act-agent
 
 ```
-Task(ai-act-assessor): "Read agents/ai-act-assessor.md for your role and instructions.
+Task(ms-ai-architect:ai-act-assessor): "
 Gjennomfør samsvarsvurdering for følgende AI-system:
 
 **System:** [systemnavn]
@@ -40,8 +40,8 @@ Gjennomfør samsvarsvurdering for følgende AI-system:
 Modus: Conformity — Annex IV sjekkliste og samsvarserklæring.
 
 Les kunnskapsbasene:
-- skills/ms-ai-governance/references/responsible-ai/ai-act-conformity-assessment.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-conformity-assessment.md
-- skills/ms-ai-governance/references/responsible-ai/ai-act-provider-obligations.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-provider-obligations.md
 
 Lever:
 1. Annex IV 9-element sjekkliste med status per element

commands/cost.md

@@ -24,25 +24,25 @@ Hvis informasjon mangler, spør brukeren om nøkkeltall.
 
 ### 2. Les kostnadsreferanse
 
-Les `skills/ms-ai-advisor/references/architecture/cost-models.md` for baseline-priser per plattform.
+Les `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/cost-models.md` for baseline-priser per plattform.
-Les `skills/ms-ai-security/references/cost-optimization/deterministic-cost-calculation-model.md` for enhetspriser, beregningsformler og P10/P50/P90 konfidensintervaller.
+Les `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/cost-optimization/deterministic-cost-calculation-model.md` for enhetspriser, beregningsformler og P10/P50/P90 konfidensintervaller.
 
 **Ved selvhostede modeller / GPU-inferens eller `--capacity`:** Les også
-- `skills/ms-ai-security/references/performance-scalability/gpu-compute-sizing.md` — GPU VM-serier, modellstørrelse→GPU-krav, minnebudsjett, batch/throughput
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/performance-scalability/gpu-compute-sizing.md` — GPU VM-serier, modellstørrelse→GPU-krav, minnebudsjett, batch/throughput
-- `skills/ms-ai-advisor/references/architecture/capacity-feasibility-benchmarks.md` — kompetanse-gap-matrise + tidsplan-validering mot bransjebenchmarks
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/capacity-feasibility-benchmarks.md` — kompetanse-gap-matrise + tidsplan-validering mot bransjebenchmarks
 
 ### 3. Deleger estimering
 
 Bruk Task-verktøyet til å lansere `cost-estimation-agent`:
 
 ```
-Task(general-purpose): "Les agents/cost-estimation-agent.md og utfør kostnadsestimering.
+Task(ms-ai-architect:cost-estimation-agent): "Utfør kostnadsestimering.
 Plattform: [plattform]
 Brukere: [antall]
 Volum: [volum]
 Region: [region]
-Les også: skills/ms-ai-advisor/references/architecture/cost-models.md
+Les også: ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/cost-models.md
-og skills/ms-ai-advisor/references/architecture/licensing-matrix.md
+og ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/licensing-matrix.md
 Verifiser priser via microsoft_docs_search."
 ```
 

commands/design.md

@@ -36,9 +36,9 @@ Avklar hvis ikke kjent (gjenbruk samtalehistorikk og `org/`-filer hvis onboardet
 
 ### 3. Les kunnskapsbasene
 
-- `skills/ms-ai-advisor/references/architecture/decision-trees.md` — plattformvalg (Foundry / Copilot Studio / Power Platform / Agent Framework)
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/decision-trees.md` — plattformvalg (Foundry / Copilot Studio / Power Platform / Agent Framework)
-- `skills/ms-ai-advisor/references/architecture/security.md` — sikkerhetsarkitektur og soneinndeling
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/security.md` — sikkerhetsarkitektur og soneinndeling
-- `skills/ms-ai-advisor/references/architecture/cost-models.md` — kostnadsdimensjonering
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/cost-models.md` — kostnadsdimensjonering
 
 For dybde, deleger til eksisterende kommandoer/agenter og bruk resultatene som input:
 - `/architect:compare` — strukturert alternativanalyse (bruk `--weighted` ved 3+ alternativer)

commands/diagram.md

@@ -46,11 +46,11 @@ Hvis kontekst mangler, still korte spørsmål:
 Kjør `diagram-generation-agent` via Task:
 
 ```
-Task(general-purpose): "Read agents/diagram-generation-agent.md for your role and instructions.
+Task(ms-ai-architect:diagram-generation-agent): "
 Generer [type]-diagram for [scenario].
 Komponenter: [liste over tjenester].
 Kontekst: [ekstra detaljer].
-Les: skills/ms-ai-advisor/references/architecture/diagram-prompt-templates.md"
+Les: ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/diagram-prompt-templates.md"
 ```
 
 ## Format Parameter

commands/dpia.md

@@ -32,7 +32,7 @@ Bruk samtalehistorikk hvis denne informasjonen allerede er gitt.
 Kjør DPIA-agenten via Task for selve vurderingen:
 
 ```
-Task(architect:dpia-agent): "Read agents/dpia-agent.md for your role and instructions.
+Task(ms-ai-architect:dpia-agent): "
 Gjennomfør en komplett DPIA for følgende AI-system:
 
 **System:** [systemnavnet]
@@ -41,14 +41,15 @@ Gjennomfør en komplett DPIA for følgende AI-system:
 **Registrerte:** [hvem som berøres]
 **Behandlingsgrunnlag:** [GDPR art. 6/9]
 **Kontekst:** [sektor/kontekst — offentlig, privat, finans, helse, etc.]
+**AI Act-klassifisering (fra /architect:classify, hvis utført):** [risikonivå + rolle + Annex III-kategori — ellers "ikke klassifisert"]
 
 Les kunnskapsbasene (kjerne):
-- skills/ms-ai-governance/references/norwegian-public-sector-governance/dpia-norwegian-methodology-ai.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/norwegian-public-sector-governance/dpia-norwegian-methodology-ai.md
-- skills/ms-ai-governance/references/responsible-ai/gdpr-compliance-ai-systems.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/gdpr-compliance-ai-systems.md
-- skills/ms-ai-governance/references/responsible-ai/ai-impact-assessment-framework.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-impact-assessment-framework.md
 
 Betinget (OBLIGATORISK hvis amerikansk-eid skyleverandør eller data nåbar fra tredjeland):
-- skills/ms-ai-governance/references/monitoring-observability/data-residency-audit-monitoring.md (EDPB seks-stegs-TIA + CLOUD Act/FISA 702/EO 14086-restanalyse for risiko 7)
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/monitoring-observability/data-residency-audit-monitoring.md (EDPB seks-stegs-TIA + CLOUD Act/FISA 702/EO 14086-restanalyse for risiko 7)
 
 Lever en komplett DPIA-rapport med alle 5 faser, risikomatrise og anbefaling."
 ```

commands/frimpact.md

@@ -28,7 +28,7 @@ Avklar:
 ### 2. Deleger til AI Act-agent
 
 ```
-Task(ai-act-assessor): "Read agents/ai-act-assessor.md for your role and instructions.
+Task(ms-ai-architect:ai-act-assessor): "
 Gjennomfør en FRIA (Art. 27) for følgende AI-system:
 
 **System:** [systemnavn]
@@ -41,8 +41,8 @@ Gjennomfør en FRIA (Art. 27) for følgende AI-system:
 Modus: FRIA — utfyll Art. 27-malen.
 
 Les kunnskapsbasene:
-- skills/ms-ai-governance/references/responsible-ai/ai-act-fria-template.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-fria-template.md
-- skills/ms-ai-governance/references/responsible-ai/ai-act-deployer-obligations.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-deployer-obligations.md
 
 Lever en komplett FRIA med alle 7 seksjoner: systembeskrivelse, berørte grupper, rettighetsmatrise (12 rettigheter), konsekvensanalyse, tilsynsnotifikasjon, godkjenning, vedlegg."
 ```

commands/generate-skills.md

@@ -42,7 +42,7 @@ Dette gir ~15-20 skills per sesjon istedenfor ~5.
 
 ### Strategi: Én agent per skill
 
-Hver skill delegeres til én `general-purpose` Task-agent (sonnet) som utfører:
+Hver skill delegeres til én `general-purpose` Task-agent (opus) som utfører:
 1. MCP-research (5-8 kall)
 2. Filskriving (Write-verktøyet)
 3. Returnerer kort kvittering
@@ -55,7 +55,7 @@ Kjør **5 agenter parallelt** i én melding. Vent på resultat, oppdater state,
 
 ### Agent-prompt (bruk denne malen)
 
-For HVER skill, send denne prompten til en `general-purpose` Task-agent med `model: sonnet`:
+For HVER skill, send denne prompten til en `general-purpose` Task-agent med `model: opus`:
 
 ```
 Du er Cosmo Skyberg, senior Microsoft AI Solution Architect. Generer en kunnskapsreferanse.
@@ -64,7 +64,7 @@ Du er Cosmo Skyberg, senior Microsoft AI Solution Architect. Generer en kunnskap
 
 Skriv kunnskapsreferanse: **{SKILL_TITLE}**
 Kategori: {CATEGORY_NAME}
-Fil: skills/{TARGET_SKILL}/references/{CATEGORY_DIR}/{SKILL_ID}.md
+Fil: ${CLAUDE_PLUGIN_ROOT}/skills/{TARGET_SKILL}/references/{CATEGORY_DIR}/{SKILL_ID}.md
 
 ## Steg 1: Research (OBLIGATORISK)
 
@@ -80,15 +80,19 @@ Bruk MCP-verktøy for oppdatert informasjon:
 ## Steg 2: Skriv filen
 
 Bruk Write-verktøyet til å skrive filen til:
-{PLUGIN_ROOT}/skills/{TARGET_SKILL}/references/{CATEGORY_DIR}/{SKILL_ID}.md
+${CLAUDE_PLUGIN_ROOT}/skills/{TARGET_SKILL}/references/{CATEGORY_DIR}/{SKILL_ID}.md
 
 Format (STRENGT — alle seksjoner påkrevd):
 
 # {SKILL_TITLE}
 
-**Last updated:** 2026-02
+**Last updated:** {dagens måned, YYYY-MM}
 **Status:** [GA | Preview | Announced]
 **Category:** {CATEGORY_NAME}
+**Type:** reference
+**Source:** {den autoritative Microsoft Learn-URLen fra research — den faktiske doc-siden påstandene hviler på, ikke et søketreff}
+**Verified:** {SETTES i Steg 2.5 etter judge — IKKE her}
+**Verified by:** {SETTES i Steg 2.5 etter judge — IKKE her}
 
 ---
 
@@ -127,6 +131,23 @@ Format (STRENGT — alle seksjoner påkrevd):
 - Confidence markers: "Verified" (fra MCP), "Baseline" (modellkunnskap)
 - Konkret og balansert — vis fordeler OG ulemper
 
+## Steg 2.5: Født-verifisert (judge FØR du returnerer)
+
+Filen skal være *født verifisert*: ingen reference-fil forlater agenten uten at de
+maskin-verifiserbare påstandene er bekreftet mot `Source`-URLen.
+
+1. Kjør den gjeldende claim-judgen (`scripts/kb-eval/judge-claim-prompt-v3.1.md`) over
+   filens maskin-verifiserbare påstander (sku/version/tpm/status/region/taxonomy) mot
+   `Source`-URLen du hentet i Steg 1.
+2. **Hvis alle påstander er `grounded`:** sett i headeren
+   `**Verified:** {dagens dato, YYYY-MM-DD}` og `**Verified by:** judge-v3.1`.
+3. **Hvis noen påstand IKKE er grounded:** IKKE stempl `Verified`. Rett påstanden mot
+   kilden og kjør judgen på nytt, eller — hvis verdien er maskin-uverifiserbar (pris/
+   JS-rendret) — merk den eksplisitt og la filen gå til menneske-gaten (den blir IKKE
+   committet; se batch-gaten under).
+
+Aldri stempl `Verified` spekulativt. Stempelet betyr «judgen bekreftet mot kilde».
+
 ## Steg 3: Returner kvittering
 
 Returner KUN dette (ingenting annet):
@@ -146,11 +167,11 @@ error: {only if failed}
 
 ```
 # Batch 1: 5 parallelle agenter
-Task(general-purpose, sonnet): "Research + write skill: Hybrid Search..."
+Task(general-purpose, opus): "Research + write skill: Hybrid Search..."
-Task(general-purpose, sonnet): "Research + write skill: Semantic Ranker..."
+Task(general-purpose, opus): "Research + write skill: Semantic Ranker..."
-Task(general-purpose, sonnet): "Research + write skill: Citation Tracking..."
+Task(general-purpose, opus): "Research + write skill: Citation Tracking..."
-Task(general-purpose, sonnet): "Research + write skill: RAG Evaluation..."
+Task(general-purpose, opus): "Research + write skill: RAG Evaluation..."
-Task(general-purpose, sonnet): "Research + write skill: Multi-Index..."
+Task(general-purpose, opus): "Research + write skill: Multi-Index..."
 
 # Vent på alle 5 → oppdater state.json → neste batch
 ```
@@ -159,11 +180,24 @@ Task(general-purpose, sonnet): "Research + write skill: Multi-Index..."
 
 1. **Parse kvitteringer** fra agentene
 2. **Verifiser filer finnes** med Glob
-3. **Oppdater state.json:**
+3. **Create-guard (OBLIGATORISK — to sibling-gater):** kjør BEGGE over batchens nye filer:
-   - Legg til ferdige skill-IDer i `completed`
+   ```bash
-   - Legg til eventuelle feilede i `failed`
+   node scripts/kb-update/validate-kb-file.mjs <fil1.md> <fil2.md> ...
+   node scripts/kb-update/scan-adversarial-content.mjs <fil1.md> <fil2.md> ...
+   ```
+   Kontrakt-gaten exit-er ≠0 hvis en fil mangler `Source`, ikke er født-verifisert (mangler
+   `Verified`/`Verified by`), eller er en stor fil uten TOC. **Layer B ingestion-gaten
+   (G6 §8 / R6 punkt d)** exit-er 1 (BLOCK — aldri committ, karantene) på adversarielt
+   innhold (unicode/injection/base64 i prosa + fenced code blocks, via delte llm-security-
+   detektorer) eller 2 (WARN — flagg for operatør, ikke auto-committ). **En fil som FAIL-er
+   noen av gatene committes IKKE** — logg den i `state.failed` og send den til menneske-
+   gaten. Dette hindrer generatoren i å re-introdusere drift (kontrakt) OG i å persistere en
+   forgiftet referansefil (Layer B — ortogonal til korrekthet).
+4. **Oppdater state.json:**
+   - Legg til ferdige (gate-PASS) skill-IDer i `completed`
+   - Legg til feilede/gate-FAIL i `failed`
    - Oppdater `stats.total_generated` og `stats.total_bytes`
-4. **Neste batch** eller avslutt
+5. **Neste batch** eller avslutt
 
 ## Etter hele sesjonen
 
@@ -180,13 +214,19 @@ Task(general-purpose, sonnet): "Research + write skill: Multi-Index..."
    Gjenstår: N skills
    ```
 
-2. **Commit:**
+2. **Create-guard FØR commit (OBLIGATORISK — begge gater):** kjør BEGGE over ALLE filer du er
+   i ferd med å committe. Bare filer som passerer BEGGE skal med:
    ```bash
+   FILES=$(git diff --name-only --diff-filter=AM -- 'skills/ms-ai-*/references/**/*.md')
+   node scripts/kb-update/validate-kb-file.mjs $FILES
+   node scripts/kb-update/scan-adversarial-content.mjs $FILES   # Layer B ingestion-gate (G6 §8)
    git add skills/ms-ai-*/references/<dirs>/ scripts/skill-gen/state.json
    git commit -m "docs(architect): generate N knowledge skills (category-names)"
    ```
+   Hvis noen av gatene exit-er ≠0: IKKE commit de feilende filene — fjern dem fra staging og
+   send til menneske-gaten (kontrakt-FAIL rettes; Layer B BLOCK karantenes/adjudiseres).
 
-3. **Oppdater REMEMBER.md** med ny status
+3. **Oppdater STATE.md** med ny status
 
 ## Feilhåndtering
 
@@ -263,8 +303,16 @@ Bruk Edit-verktøyet (IKKE Write) for å:
 - Oppdatere "Last updated" til gjeldende måned
 - Oppdatere utdaterte fakta, priser, datoer
 - Oppdatere Microsoft Learn-URLer
-- Markere oppdatert innhold med "Verified (MCP {måned})"
 - Beholde eksisterende struktur og seksjoner
+- **Backfill kontrakt-headeren** (Spor 3 Port 1) hvis legacy-fila mangler den: legg til
+  `**Type:** reference` og `**Source:** {autoritativ Learn-URL}` i header-blokken (en
+  berørt fil skal forlate oppdateringen kontrakt-kompatibel — inkrementell Spor 1).
+
+## Steg 2.5: Født-verifisert (judge FØR du returnerer)
+Kjør claim-judgen (`scripts/kb-eval/judge-claim-prompt-v3.1.md`) over de oppdaterte maskin-
+verifiserbare påstandene mot `Source`. Alle `grounded` ⇒ sett `**Verified:** {dagens dato}`
++ `**Verified by:** judge-v3.1`. Ikke grounded ⇒ IKKE stempl; rett mot kilde og kjør på nytt,
+eller send til menneske-gaten (fila committes ikke; se batch-gaten). Aldri stempl spekulativt.
 
 ## Steg 3: Returner kvittering
 SKILL_UPDATED
@@ -275,7 +323,8 @@ status: success|no_changes|failed
 ```
 
 4. Track in `state.json` under a new `"updated"` array
-5. After each batch, verify files still pass `validate-plugin.sh`
+5. **Create-guard (OBLIGATORISK — begge gater):** `node scripts/kb-update/validate-kb-file.mjs <oppdaterte filer>` + `node scripts/kb-update/scan-adversarial-content.mjs <oppdaterte filer>` (Layer B ingestion-gate, G6 §8) — FAIL på noen av dem committes IKKE
+6. After each batch, verify files still pass `validate-plugin.sh`
 
 **Key difference from generation:** Update uses Edit (preserves structure), generation uses Write (creates from scratch).
 

commands/kb-update.md

@@ -127,11 +127,15 @@ saveDecisions(led);
 d. **For `approved`:** registrér URLen i `url-registry` (gated) så den fanges av polling heretter — via `lib/registry-io.mjs` `saveRegistry`. Bruk `suggested_skill`/`suggested_category` fra kandidaten. Deretter kjør **transformasjonslaget (lag 4)** for å lage KB-fila:
    1. `microsoft_docs_fetch` på den godkjente URLen → kildedokument.
    2. Destillér via `scripts/kb-update/transform-prompt.md` (doc→KB-fil; status-påstander holdes eksplisitte). Multi-agent parallell fan-out foreslås i produksjon (roadmap §71), speilet på `generate-skills`-mønsteret.
-   3. `content = buildKbHeader({title, status, category, source: <godkjent URL>, lastUpdated: <YYYY-MM>}) + body` (`lib/transform.mjs`). **`Status` + `Source` er obligatoriske** — `Source` i header-blokka (øverste 500 bytes) er det som lar lag 3 backfille `authority_source`.
+   3. **Født-verifisert (Spor 3 Port 2):** kjør claim-judgen (`scripts/kb-eval/judge-claim-prompt-v3.1.md`) over brødtekstens maskin-verifiserbare påstander mot den godkjente URLen → `verdict = {pass}`. Så `meta = stampVerifiedMeta({title, status, category, source: <godkjent URL>, lastUpdated: <YYYY-MM>}, verdict, <i dag>)` — stempler `type='reference'` + `verified` + `verified_by='judge-v3.1'` **kun** ved `pass`; ellers KASTER (ingen fil, flagg for menneske). Deretter `content = composeKbFile(meta, body)` (`lib/transform.mjs`) — header + (store filer >100 linjer) en deterministisk `## Innhold`-TOC + brødtekst. **`Status` + `Source` + `Verified` + `Verified by` er obligatoriske** — `Source` i header-blokka (øverste 500 bytes) er det som lar lag 3 backfille `authority_source`. TOC-en fødes inn så regenerering ikke stripper den (Fase 1c).
-   4. `validateKbFile(content)` MÅ være `valid: true` før noe gates videre (ellers be modellen fylle manglende felt).
+   4. `validateKbFile(content)` MÅ være `valid: true` (title + Last updated + Status + Source + **Verified + Verified by**; **store filer også TOC**) før noe gates videre (ellers be modellen fylle manglende felt).
    5. For hver status-/load-bearing-påstand: `buildChange({...})` → **lag 5** `classifyChange(...)` (samme gate som §4 c2). Status-påstander er alltid `flagged`.
    6. `resolveTargetPath(tax, category, filename)` → eierskill-sti via taksonomien (`null` = ukjent kategori → flagg for operatør, ikke skriv).
-   7. Først etter operatør-gate: atomisk skriving (`lib/atomic-write.mjs` + `lib/backup.mjs`). **`transform.mjs` skriver aldri selv** — verifisert av `tests/kb-update/test-transform.test.mjs` (import-invariant). Kriterium verifisert av `tests/kb-eval/test-transform-criterion.test.mjs` (regenerer 1 fil → eval ≥ baseline).
+   7. **Create-guard FØR skriving (to sibling-gater):** kjør BEGGE (exit ≠0 på noen av dem ⇒ ikke skriv):
+      - `node scripts/kb-update/validate-kb-file.mjs <sti>` — kontrakt (Source/født-verifisert/TOC).
+      - `node scripts/kb-update/scan-adversarial-content.mjs <sti>` — **Layer B ingestion-gate (G6 §8 / R6 punkt d):** deterministisk adversariell-innhold-skann (unicode/injection/base64, prosa + fenced code blocks) via de delte llm-security-detektorene. **exit 1 = BLOCK** (aldri skriv — karantene, operatør adjudiserer); **exit 2 = WARN** (flagg → samme menneske-i-loop som en status-påstand; ikke auto-committ). Gaten er ortogonal til korrekthets-judgen: en faktakorrekt men forgiftet fil blokkeres likevel.
+
+      Først etter operatør-gate + BEGGE create-guards grønne: atomisk skriving (`lib/atomic-write.mjs` + `lib/backup.mjs`). **`transform.mjs` skriver aldri selv** — verifisert av `tests/kb-update/test-transform.test.mjs` (import-invariant). Kriterium verifisert av `tests/kb-eval/test-transform-criterion.test.mjs` (regenerer 1 fil → eval ≥ baseline). Layer B verifisert av `tests/kb-update/test-adversarial-scan.test.mjs` + `test-scan-adversarial-content.test.mjs` + `test-adversarial-detect-integration.test.mjs`.
 
 e. **Invariant:** `discover-new-urls.mjs` (deteksjon) skriver **aldri** ledgeren — den kun leser. Bare denne gaten skriver. Verifisert av `tests/kb-update/test-discover-invariant.test.mjs`.
 
@@ -185,14 +189,16 @@ c2. **Verifisering-ut (lag 5) — FØR du skriver.** Hver kandidat-endring fra (
    - **`auto-applied`** → trygt å ta inn i (d) (benign, ikke-status, ingen motbevis, autoritets-match).
    - **Adversarial motbevis-panel (LLM-runtime):** for status-/load-bearing-påstander, kjør et lite panel som *prøver å motbevise* `new_value` mot den utpekte `authority_source`, og mat resultatene inn som `refutations[]` (`[{refuted, reason}]`). Multi-agent foreslås når lag 4/5 kjøres i produksjon (roadmap §71).
    - **Invariant:** `verify-out.mjs` skriver aldri — den returnerer kun en verdict. Selve skrivingen skjer i (d), gated. Verifisert av `tests/kb-update/test-verify-out.test.mjs`.
-d. **Oppdater fila:** `Edit` med endringer som er `auto-applied` eller eksplisitt godkjent av operatør i (c2). Behold "For Cosmo"-seksjonen og overordnet struktur. Oppdater `Last updated: YYYY-MM-DD`-header til dagens dato. **Lag-4-kontrakt:** kjør `validateKbFile(<ny fil-innhold>)` (`lib/transform.mjs`) før skriving — den skal være `valid: true`. Mangler fila et `**Source:**`-header, legg det til i header-blokka med den utpekte autoritets-URLen for hovedkilden — da fanger lag 3 (`resolveAuthority` + `build-registry`) den som `authority_source`, og lag-5 regel 3 blir virksom for fila.
+d. **Oppdater fila:** `Edit` med endringer som er `auto-applied` eller eksplisitt godkjent av operatør i (c2). Behold "For Cosmo"-seksjonen og overordnet struktur. Oppdater `Last updated: YYYY-MM-DD`-header til dagens dato. **Lag-4-kontrakt:** kjør `validateKbFile(<ny fil-innhold>)` (`lib/transform.mjs`) før skriving — den skal være `valid: true`. Mangler fila et `**Source:**`-header, legg det til i header-blokka med den utpekte autoritets-URLen for hovedkilden — da fanger lag 3 (`resolveAuthority` + `build-registry`) den som `authority_source`, og lag-5 regel 3 blir virksom for fila. Mangler en **stor fil (>100 linjer)** en `## Innhold`-TOC, generer den med `buildToc(<brødtekst>)` og legg den inn rett etter header-`---` — `validateKbFile` krever den nå for store filer, så in-place-oppdateringer backfiller TOC inkrementelt (Fase 1c).
-e. **Committ:** `git add <fil>` + `git commit -m "chore(ms-ai-architect): refresh KB $(basename <fil>) [skip-docs]"` med mindre `--single-commit` ble gitt
+d1. **Layer B FØR skriving/commit (ingestion-gate, G6 §8):** kjør `node scripts/kb-update/scan-adversarial-content.mjs <fil>` på den oppdaterte fila. exit 1 (BLOCK) ⇒ ikke skriv/committ — karantene, operatør adjudiserer; exit 2 (WARN) ⇒ flagg for operatør, ikke auto-committ. Deterministisk adversariell-innhold-skann via delte llm-security-detektorer; ortogonal til korrekthets-gatene i (c1/c2).
+e. **Committ:** kjør create-guardene (`validate-kb-file.mjs` + `scan-adversarial-content.mjs`) grønne på fila, deretter `git add <fil>` + `git commit -m "chore(ms-ai-architect): refresh KB $(basename <fil>) [skip-docs]"` med mindre `--single-commit` ble gitt
 
 ### 5. Single-commit modus
 
-Hvis `--single-commit`: skip committer per fil, og lag én samlet commit til slutt:
+Hvis `--single-commit`: skip committer per fil, og lag én samlet commit til slutt. **Layer B FØR commit (ingestion-gate, G6 §8):** skann alle endrede `skills/**/*.md` — en BLOCK (exit 1) tas ut av staging (aldri committet, karantene); en WARN (exit 2) flagges for operatør før commit:
 
 ```bash
+node scripts/kb-update/scan-adversarial-content.mjs $(git diff --name-only --diff-filter=AM -- 'skills/**/*.md')
 git add skills/
 git commit -m "chore(ms-ai-architect): refresh KB — N files [skip-docs]"
 ```

commands/license.md

@@ -23,17 +23,17 @@ Ekstraher lisenstype(r) fra argumentet. Vanlige kombinasjoner:
 
 ### 2. Les referanse
 
-Les `skills/ms-ai-advisor/references/architecture/licensing-matrix.md` for komplett lisensmatrise.
+Les `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/licensing-matrix.md` for komplett lisensmatrise.
 
 ### 3. Deleger kartlegging
 
 Bruk Task-verktøyet til å lansere `license-mapper-agent`:
 
 ```
-Task(general-purpose): "Les agents/license-mapper-agent.md og kartlegg lisenser.
+Task(ms-ai-architect:license-mapper-agent): "Kartlegg lisenser.
 Lisenser: [lisenstype(r)]
-Les: skills/ms-ai-advisor/references/architecture/licensing-matrix.md
+Les: ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/licensing-matrix.md
-og skills/ms-ai-advisor/references/platforms/ (alle plattformfiler).
+og ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/platforms/ (alle plattformfiler).
 Verifiser kritiske punkter via microsoft_docs_search."
 ```
 

commands/migrate.md

@@ -23,7 +23,7 @@ Ekstraher:
 
 ### 2. Les migrasjonsreferanse
 
-Les `skills/ms-ai-advisor/references/architecture/migration-patterns.md` for:
+Les `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/migration-patterns.md` for:
 - Migrasjonsmatrise (innsats, risiko, tidslinje)
 - Detaljerte migrasjonsmønstre med steg-for-steg
 - Kodeeksempler for vanlige migrasjoner

commands/onboard.md

@@ -86,7 +86,7 @@ Deretter start onboarding-agenten (se under).
 Sjekk eksisterende `$ORG_DIR/*.md`-filer for å avgjøre resume-punkt:
 
 ```
-Task(architect:onboarding-agent): "Read agents/onboarding-agent.md for your role and instructions.
+Task(ms-ai-architect:onboarding-agent): "
 
 Gjennomfør onboarding-intervju for å samle virksomhetsspesifikk kontekst.
 

commands/poc.md

@@ -29,13 +29,13 @@ Spør brukeren om nøkkelinformasjon (hvis ikke allerede kjent):
 
 ### 3. Les template
 
-Les `skills/ms-ai-advisor/references/architecture/poc-template.md` for komplett POC-rammeverk.
+Les `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/poc-template.md` for komplett POC-rammeverk.
 
 ### 3b. Les domene-spesifikke mønstre (betinget)
 
 Hvis use-caset treffer et engineering-domene, les 1-2 kjernefiler for å forankre scope og suksesskriterier (ikke hele katalogen):
-- **RAG / gjenfinning:** `skills/ms-ai-engineering/references/rag-architecture/rag-core-patterns.md`, `rag-architecture/rag-evaluation-frameworks.md` — sett målbare gjenfinnings-/grounding-kriterier
+- **RAG / gjenfinning:** `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-engineering/references/rag-architecture/rag-core-patterns.md`, `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-engineering/references/rag-architecture/rag-evaluation-frameworks.md` — sett målbare gjenfinnings-/grounding-kriterier
-- **MLOps / produksjonssetting:** `skills/ms-ai-engineering/references/mlops-genaiops/genaiops-llm-specific-practices.md`, `mlops-genaiops/llm-evaluation-production.md` — POC-evaluering + driftskriterier
+- **MLOps / produksjonssetting:** `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-engineering/references/mlops-genaiops/genaiops-llm-specific-practices.md`, `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-engineering/references/mlops-genaiops/llm-evaluation-production.md` — POC-evaluering + driftskriterier
 
 ### 4. Generer POC-plan
 

commands/requirements.md

@@ -27,7 +27,7 @@ Avklar:
 ### 2. Deleger til AI Act-agent
 
 ```
-Task(ai-act-assessor): "Read agents/ai-act-assessor.md for your role and instructions.
+Task(ms-ai-architect:ai-act-assessor): "
 Kartlegg konkrete AI Act-forpliktelser (Fase 4-5) for følgende system:
 
 **System:** [systemnavn]
@@ -40,12 +40,12 @@ Kartlegg konkrete AI Act-forpliktelser (Fase 4-5) for følgende system:
 Modus: Requirements — fokus på forpliktelser og tiltaksplan.
 
 Les kunnskapsbasene:
-- skills/ms-ai-governance/references/responsible-ai/ai-act-provider-obligations.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-provider-obligations.md
-- skills/ms-ai-governance/references/responsible-ai/ai-act-deployer-obligations.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-deployer-obligations.md
-- skills/ms-ai-governance/references/responsible-ai/ai-act-microsoft-tools-mapping.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-microsoft-tools-mapping.md
 
 Betinget (kun ved regulert privat sektor):
-- Hvis sektor = finans: skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-sector-checklists.md (§3 Finans — 17-punkts sjekkliste med DORA, Finanstilsynets IKT-forskrift, EBA/GL/2023/06). Kartlegg DORA-forpliktelser i tillegg til AI Act-kravene.
+- Hvis sektor = finans: ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-sector-checklists.md (§3 Finans — 17-punkts sjekkliste med DORA, Finanstilsynets IKT-forskrift, EBA/GL/2023/06). Kartlegg DORA-forpliktelser i tillegg til AI Act-kravene.
 
 Lever detaljert forpliktelsesliste med gap-analyse og tiltaksplan."
 ```

commands/research.md

@@ -36,7 +36,7 @@ Ekstraher:
 Bruk Task-verktøyet til å lansere `research-agent`:
 
 ```
-Task(general-purpose): "Les agents/research-agent.md og utfør research.
+Task(ms-ai-architect:research-agent): "Utfør research.
 Plattform: [full plattformnavn]
 Tidsperiode: [periode]
 Fokusområder:

commands/review.md

@@ -44,16 +44,16 @@ Identifiser hvilke dimensjoner som er mest kritiske for scenarioet:
 Bruk Task-verktøyet til å lansere `architecture-review-agent`:
 
 ```
-Task(general-purpose): "Les agents/architecture-review-agent.md og utfør en
+Task(ms-ai-architect:architecture-review-agent): "Utfør en
 arkitekturgjennomgang for [løsningsnavn].
 Arkitekturbeskrivelse: [beskrivelse fra bruker]
 Kontekst: [offentlig sektor / sektor / stadium]
 Vurder alle 6 dimensjoner med 1-5 score.
 Les også:
-- skills/ms-ai-advisor/references/architecture/decision-trees.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/decision-trees.md
-- skills/ms-ai-advisor/references/architecture/public-sector-checklist.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/public-sector-checklist.md
-- skills/ms-ai-advisor/references/architecture/security.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/security.md
-- skills/ms-ai-advisor/references/architecture/ai-utredning-template.md"
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/ai-utredning-template.md"
 ```
 
 ### 4. Berik med arkitekturperspektiv

commands/ros.md

@@ -33,7 +33,7 @@ Sjekk om --quick er angitt. Bruk samtalehistorikk hvis info allerede er gitt.
 Kjør ROS-agenten via Task for selve vurderingen:
 
 ```
-Task(ros-analysis-agent): "Read agents/ros-analysis-agent.md for your role and instructions.
+Task(ms-ai-architect:ros-analysis-agent): "
 Gjennomfør en [komplett / quick] ROS-analyse for følgende AI-system:
 
 **System:** [systemnavn]
@@ -43,21 +43,23 @@ Gjennomfør en [komplett / quick] ROS-analyse for følgende AI-system:
 **Sektor:** [sektor]
 **Borgermøtende:** [ja/nei]
 **Kontekst:** [ytterligere kontekst]
+**AI Act-klassifisering (dimensjon 6, fra /architect:classify):** [risikonivå + rolle — ellers "ikke klassifisert"]
+**DPIA-funn (fra /architect:dpia, hvis utført):** [sentrale personvernrisikoer — ellers "ikke utført"]
 [**Modus:** Quick (top-10 risikoer, trafikklys) — if --quick]
 
 Les kunnskapsbasene per last-kontrakten i agentfilen — kjerne (alltid) + betinget (kun på trigger):
 
 Kjerne (alltid, i rekkefølge):
-- skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-ai-threat-library.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-ai-threat-library.md
-- skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-scoring-rubrics-7x5.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-scoring-rubrics-7x5.md
-- skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-methodology-ns5814-iso31000.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-methodology-ns5814-iso31000.md
-- skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-report-templates.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/norwegian-public-sector-governance/ros-report-templates.md
 
 Betinget (kun når triggeren utløses):
 - ros-sector-checklists.md (hvis relevant sektor oppdaget)
 - ros-maestro-multiagent.md (hvis multi-agent / agent-orkestrering)
 - ros-dpia-security-integration.md (hvis DPIA/sikkerhet skal integreres)
-- responsible-ai/ai-act-classification-methodology.md + ai-act-provider-obligations.md (hvis AI Act-dybde i dimensjon 6)
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-classification-methodology.md + ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-provider-obligations.md (hvis AI Act-dybde i dimensjon 6)
 
 Lever en [komplett ROS-rapport med alle 8 faser / Quick ROS med top-10 og trafikklys]."
 ```

commands/security.md

@@ -34,13 +34,13 @@ Identifiser hvilke sikkerhetsdimensjoner som er mest kritiske for scenarioet:
 Bruk Task-verktøyet til å lansere `security-assessment-agent`:
 
 ```
-Task(general-purpose): "Les agents/security-assessment-agent.md og utfør en
+Task(ms-ai-architect:security-assessment-agent): "Utfør en
 sikkerhetsassessment for [plattform] brukt til [scenario].
 Kontekst: [offentlig sektor / privat / etc.]
 Vurder alle 6 dimensjoner med 1-5 score.
-Les også: skills/ms-ai-advisor/references/architecture/security.md
+Les også: ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/security.md
-og skills/ms-ai-advisor/references/architecture/public-sector-checklist.md
+og ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/public-sector-checklist.md
-og skills/ms-ai-security/references/ai-security-engineering/security-scoring-rubrics-6x5.md"
+og ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/ai-security-engineering/security-scoring-rubrics-6x5.md"
 ```
 
 ### 4. Berik med arkitekturperspektiv

commands/summary.md

@@ -33,7 +33,7 @@ Hvis ingen vurderinger er gjennomført, informer brukeren om at summary krever m
 Kjør summary-agenten via Task:
 
 ```
-Task(general-purpose): "Read agents/summary-agent.md for your role and instructions.
+Task(ms-ai-architect:summary-agent): "
 Generer teknisk sammendrag og executive summary for:
 
 **Løsning:** [navn]

commands/transparency.md

@@ -27,7 +27,7 @@ Avklar:
 ### 2. Deleger til AI Act-agent
 
 ```
-Task(ai-act-assessor): "Read agents/ai-act-assessor.md for your role and instructions.
+Task(ms-ai-architect:ai-act-assessor): "
 Generer transparensnotiser for følgende AI-system:
 
 **System:** [systemnavn]
@@ -39,7 +39,7 @@ Generer transparensnotiser for følgende AI-system:
 Modus: Transparens — generer Art. 13/50 notiser.
 
 Les kunnskapsbasene:
-- skills/ms-ai-governance/references/responsible-ai/ai-act-transparency-notices.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-transparency-notices.md
 
 Lever:
 1. Art. 50(1) AI-interaksjonsnotis (norsk)

commands/utredning.md

@@ -23,9 +23,9 @@ Hvis kommandoen kjøres etter `/architect` (Fase 1-3), gjenbruk innsamlet kontek
 ### 1. Last kontekst
 
 Les malen som styrer utredningen:
-- `skills/ms-ai-advisor/references/architecture/ai-utredning-template.md`
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/ai-utredning-template.md`
 
-Aktiver Cosmo Skyberg-personaen fra `skills/ms-ai-advisor/SKILL.md`.
+Aktiver Cosmo Skyberg-personaen fra `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/SKILL.md`.
 
 ### 2. Parse input og bestem kompleksitet
 
@@ -115,7 +115,7 @@ Orkestratoren gjør alt selv. Ingen TeamCreate.
 4. Fullfør J, L→M, skriv til fil
 5. Kjør diagram-generation-agent for S8.2 (arkitekturoversikt):
    ```
-   Task(architect:diagram-generation-agent): "Generer arkitekturoversikt-diagram for {scenario}.
+   Task(ms-ai-architect:diagram-generation-agent): "Generer arkitekturoversikt-diagram for {scenario}.
    Komponenter: {fra S8.1}. Skriv til {output_dir}/.work/diagrams/architecture-overview.md"
    ```
 6. Kjør summary-agent (steg N) — les worker-mal nedenfor
@@ -206,15 +206,15 @@ Alle arbeidere spawnes med `Task` og skriver output til `.work/`-filer. Bruk `te
 
 #### Security Worker
 ```
-Task(architect:security-assessment-agent, name="security-worker", team_name="{team}"):
+Task(ms-ai-architect:security-assessment-agent, name="security-worker", team_name="{team}"):
 "Utfør sikkerhetsvurdering for: {scenario}
 Plattform: {plattform}
 Kontekst: {sektor/virksomhet fra Fase 1}
 
 Les relevante KB-filer (max 3):
-- skills/ms-ai-security/references/ai-security-engineering/security-scoring-rubrics-6x5.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/ai-security-engineering/security-scoring-rubrics-6x5.md
-- skills/ms-ai-security/references/ai-security-engineering/ai-security-scoring-framework.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/ai-security-engineering/ai-security-scoring-framework.md
-- skills/ms-ai-advisor/references/architecture/security.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/security.md
 
 VIKTIG: Skriv KOMPLETT output til {output_dir}/.work/security.md med Write-verktøyet.
 Inkluder: Score-matrise (6 dimensjoner), P0/P1-funn, anbefalinger."
@@ -222,14 +222,14 @@ Inkluder: Score-matrise (6 dimensjoner), P0/P1-funn, anbefalinger."
 
 #### Cost Worker
 ```
-Task(architect:cost-estimation-agent, name="cost-worker", team_name="{team}"):
+Task(ms-ai-architect:cost-estimation-agent, name="cost-worker", team_name="{team}"):
 "Estimer kostnader for: {scenario}
 Plattform: {plattform}, Brukere: {antall}, Volum: {volum}
 
 Les relevante KB-filer (max 3):
-- skills/ms-ai-security/references/cost-optimization/deterministic-cost-calculation-model.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/cost-optimization/deterministic-cost-calculation-model.md
-- skills/ms-ai-security/references/cost-optimization/azure-ai-foundry-cost-governance.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/cost-optimization/azure-ai-foundry-cost-governance.md
-- skills/ms-ai-advisor/references/architecture/cost-models.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/cost-models.md
 
 VIKTIG: Skriv KOMPLETT output til {output_dir}/.work/cost.md med Write-verktøyet.
 Inkluder: Månedskostnad, TCO 3 år, alle alternativer, konfidensgradering."
@@ -237,14 +237,14 @@ Inkluder: Månedskostnad, TCO 3 år, alle alternativer, konfidensgradering."
 
 #### DPIA Worker
 ```
-Task(architect:dpia-agent, name="dpia-worker", team_name="{team}"):
+Task(ms-ai-architect:dpia-agent, name="dpia-worker", team_name="{team}"):
 "Gjennomfør DPIA/PVK for: {scenario}
 Datatype: {datatype}, Behandlingsgrunnlag: {grunnlag}
 
 Les relevante KB-filer (max 3):
-- skills/ms-ai-governance/references/norwegian-public-sector-governance/dpia-norwegian-methodology-ai.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/norwegian-public-sector-governance/dpia-norwegian-methodology-ai.md
-- skills/ms-ai-governance/references/responsible-ai/gdpr-compliance-ai-systems.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/gdpr-compliance-ai-systems.md
-- skills/ms-ai-governance/references/responsible-ai/ai-impact-assessment-framework.md
+- ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-impact-assessment-framework.md
 
 VIKTIG: Skriv KOMPLETT output til {output_dir}/.work/dpia.md med Write-verktøyet.
 Inkluder: Risikomatrise, tiltakstabell, bias/forklarbarhet/HITL-vurdering."
@@ -252,7 +252,7 @@ Inkluder: Risikomatrise, tiltakstabell, bias/forklarbarhet/HITL-vurdering."
 
 #### Diagram Worker
 ```
-Task(architect:diagram-generation-agent, name="diagram-worker", team_name="{team}"):
+Task(ms-ai-architect:diagram-generation-agent, name="diagram-worker", team_name="{team}"):
 "Generer diagrammer for: {scenario}
 Komponenter: {fra S8.1}
 
@@ -263,7 +263,7 @@ Diagrammer å generere:
 - Sikkerhetssoner (S5.1) — hvis sikkerhet er kritisk
 - Implementeringstidslinje (S9.1) — hvis faseplan er definert
 
-Les: skills/ms-ai-advisor/references/architecture/diagram-prompt-templates.md
+Les: ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/diagram-prompt-templates.md
 
 VIKTIG: Skriv output til {output_dir}/.work/diagrams/ (én fil per diagram).
 Hvis mcp-image er utilgjengelig: generer Mermaid-syntaks som fallback."
@@ -271,7 +271,7 @@ Hvis mcp-image er utilgjengelig: generer Mermaid-syntaks som fallback."
 
 #### Summary Worker (kjøres ALLTID som siste agent)
 ```
-Task(architect:summary-agent, name="summary-worker"):
+Task(ms-ai-architect:summary-agent, name="summary-worker"):
 "Generer sammendrag for utredningen.
 
 Les utredningen: {output_dir}/utredning.md

commands/vendor.md

@@ -35,9 +35,9 @@ Avklar hvis ikke kjent:
 
 ### 3. Les kunnskapsbasene
 
-- `skills/ms-ai-governance/references/monitoring-observability/data-residency-audit-monitoring.md` — Schrems II, EDPB seks-stegs-TIA, CLOUD Act/FISA 702-restanalyse for tredjelandsoverføring
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/monitoring-observability/data-residency-audit-monitoring.md` — Schrems II, EDPB seks-stegs-TIA, CLOUD Act/FISA 702-restanalyse for tredjelandsoverføring
-- `skills/ms-ai-governance/references/responsible-ai/ai-act-deployer-obligations.md` — deployerforpliktelser hvis leverandøren leverer et AI-system
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-governance/references/responsible-ai/ai-act-deployer-obligations.md` — deployerforpliktelser hvis leverandøren leverer et AI-system
-- `skills/ms-ai-advisor/references/architecture/security.md` — sikkerhetskrav til eksterne tjenester
+- `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/security.md` — sikkerhetskrav til eksterne tjenester
 
 For personvern-/cross-border-dybde: deleger til `/architect:dpia` (full TIA). For anskaffelseskrav: `/architect:anskaffelse`.
 

docs/cosmo-removal-brief-2026-06.md

@@ -0,0 +1,51 @@
+# Cosmo-persona — full utfasing (brief)
+
+**Opprettet:** 2026-06-24
+**Status:** PLANLAGT — godkjent av operatør, men skal gjøres **SIST** (etter pågående arbeid). Operatør: «Fjern hele Cosmo-personaen (også i README), men vent med dette som det siste vi gjør, HVIS ikke du anbefaler at det gjøres før.» Anbefaling gitt: **ikke tidligere** — KB-refresh (faktaferskhet) og Cosmo-fjerning (persona-ramming) er ortogonale; egen plan + egen versjonsbump (sannsynlig **minor**, f.eks. v1.17.0, siden persona er en dokumentert feature).
+
+## Bakgrunn
+
+Operatør-direktiv 2026-06-24: «Cosmo-pedagogikken er en gammel idé og må ikke fortsettes.» «Cosmo Skyberg» er advisor-personaen i `ms-ai-advisor`-skillen og brukes som et pedagogisk grep både i dialog (`/architect` «med Cosmo Skyberg») og som `## For Cosmo`-notater adressert til personaen i KB-filene.
+
+Utfasing er **startet** i v1.16.5: «For Cosmo»-seksjonene fjernet i `agent-framework.md` (omskrevet) og `disconnected-ai-scenarios.md` (erstattet med «## Oppsummering»). Resten gjenstår.
+
+## Omfang (ground truth, målt 2026-06-24)
+
+- **417 filer** nevner «Cosmo» · **956 totale forekomster**
+- **188 filer** har en `## For Cosmo`- / `For Cosmo:`-seksjon
+- Fordeling (topp): ms-ai-engineering 154 · ms-ai-governance 77 · ms-ai-security 61 · ms-ai-advisor 56 · ms-ai-infrastructure 35
+- Arkitektur-lag (utenfor KB-seksjonene): `ms-ai-advisor/SKILL.md` (persona-definisjon), `commands/architect.md` (+ flere kommandoer: vendor, utredning, transparency, summary, security, ros …), `README.md`, `NOTICE.md`, `CLAUDE.md` («Cosmo Skyberg-persona»), `scripts/skill-gen`, `scripts/kb-update`, playground/docs.
+
+> Reproduser tellingen: `grep -rl "Cosmo" --include="*.md" . | wc -l` · `grep -rao "Cosmo" --include="*.md" . | wc -l` · `grep -rl "## For Cosmo\|For Cosmo:" --include="*.md" . | wc -l`.
+
+## Foreslått tilnærming (utkast — krever egen plan før start)
+
+1. **Avklar erstatning FØRST (operatør-beslutning):** Skal advisor-dialogen ha en ny nøytral ramme («arkitekturrådgiver»), en ny navngitt persona, eller ingen persona? Dette styrer SKILL.md + kommando-omskrivingen og er den eneste reelle designbeslutningen — resten er mekanisk.
+2. **KB-seksjonene (188 `## For Cosmo`):** erstatt med nøytral heading («## Oppsummering» / «## Nøkkelpunkter for rådgivning») — innholdet (bullets) er stort sett nøytrale arkitekt-takeaways og kan beholdes. Kandidat for batch (men header varierer; per-fil eller forsiktig sed med review).
+3. **Persona-lag:** SKILL.md, kommandoer, README, NOTICE, CLAUDE.md, scripts — kirurgisk, per-fil (her sitter den faktiske persona-definisjonen).
+4. **Verifisering:** `bash tests/validate-plugin.sh` (239/0), `grep -rc Cosmo` → 0 (eller dokumentert restmengde), skill-re-score uendret (≥90 %).
+5. **Release:** egen versjonsbump + CHANGELOG; oppdater CLAUDE.md (fjern «Cosmo Skyberg-persona»-beskrivelsen).
+
+## Sammenfall: registry-herding Fase 1a endring C (utsatt hit — operatør 2026-06-26)
+
+Fase 1a A+B (sitemap-prefiks + skjemaløs URL-ekstraksjon) er levert (`e74646d`). **Endring C** (redirect-følging) ble bevisst utsatt og foldet inn HER, fordi **20 av 21 filer med legacy-citater er `ms-ai-advisor`** (copilot-extensibility) — de samme filene Cosmo-utfasingen uansett redigerer. Når du redigerer advisor copilot-extensibility-filene:
+
+- **Re-kanonikaliser 44 legacy `/microsoft-365-copilot/...`-citater → `/microsoft-365/copilot/...`** via **ekte redirect-resolusjon** (ikke streng-rewrite: slug-en kan endres, f.eks. `overview-graph-connector`→`overview-copilot-connector`, verifisert 2026-06-26). Disse står i dag som `not_in_sitemap`.
+- **3 omdøpte microsoftsearch-citater** (`connectors-overview`, `federated-connectors-overview`, `licensing`) — samme redirect-fiks.
+- Etterpå: `node scripts/kb-update/build-registry.mjs --merge` + poll fanger dem som tracked. Gjør dette som ren citat-fiks (root-cause), ikke en ny redirect-map-mekanisme.
+
+## Sammenfall: store-fil-TOC / ref-KB Fase 1b (foldet inn hit — operatør 2026-06-26)
+
+Fase 1b (innholdsfortegnelse i de **20 filene >800 linjer**) ble opprinnelig skopet som «trygt håndverk, uavhengig av Cosmo». Ground truth motbeviste premisset: **11 av 12 ikke-advisor-storfiler** (og alle advisor-storfilene) har en `## …Cosmo…`-seksjon på nivå 2. En TOC bygget fra `##`-overskriftene ville da emittere en **ny Cosmo-anker** (`- [For arkitekten (Cosmo)](#…)`) → bryter «aldri ny Cosmo-innhold», og å nøytralisere overskriften er nettopp denne persona-fjerningen (ikke en sidehandling). Store-fil-TOC folder derfor inn her.
+
+- **Når du nøytraliserer `## …Cosmo…`-overskriften i en storfil (R13/R14):** bygg `## Innhold` på nytt via `transform.insertToc` (primitiven overlever; det tidligere TOC-backfill-CLI-scriptet er **retired i R6 Step 6** — ikke-atomisk `writeFileSync`, 0 programmatiske kallere, superseded av `insertToc` i `transform.mjs` / `migrate-corpus`). NB: `migrate-corpus` fencer ut advisor OG mangler single-fil-modus, så den er **ikke** en drop-in for den advisor-rettede cosmo-use-casen — R13/R14 håndterer TOC via et advisor-kapabelt single-fil-steg, ELLER heading-fjerningen løser det selv.
+- **§8-residual (gap-discipline, [[gap-discipline-must-close]]):** `insertToc` er en no-op på en fil som allerede har `## Innhold`, så en heading-nøytralisering som endrer en **oppført** overskrift etterlater en stale TOC-entry (latent link-rot). Lukkes i R13/R14 ved å regenerere TOC etter nøytralisering (eller nøytralisere før TOC-en bygges).
+- **Mekanismen** er `transform.insertToc` (testet, `tests/kb-update/test-transform.test.mjs`). Nye filer fødes allerede med TOC via `composeKbFile` (Fase 1c, `2240f1e`).
+- **Verifisering:** `node scripts/kb-eval/eval.mjs` → `checkN4 hasToc` = true for de berørte filene; ingen diff-churn på små filer (<100 linjer røres ikke).
+- Eneste storfil uten `##`-Cosmo-overskrift: `zero-trust-ai-services.md` (eneste Cosmo-token er inline `**For Cosmo:**`) — kan TOC-es uten å skape Cosmo-anker, men tas naturlig i samme pass.
+
+## Risiko / merknader
+
+- **Ikke en bugfix-sidehandling.** Persona er en dokumentert feature — full plan + godkjenning før start (scope-guard).
+- Batch-sed på 188 filer er fristende, men `## For Cosmo`-seksjonene har varierende innhold/lengde — review `git diff` per fil eller per klynge.
+- Hold KB-faktainnhold urørt; dette er ren ramme-/persona-endring, ikke en ny KB-refresh.

docs/development.md

@@ -4,7 +4,7 @@ Plugin development, testing, KB-refresh. Imported from `CLAUDE.md` via pointer.
 
 ## Legge til ny kunnskapsbase
 1. Opprett `.md`-fil i riktig undermappe under den relevante skillens `references/`-mappe (f.eks. `skills/ms-ai-engineering/references/`)
-2. Følg format fra eksisterende filer (header, dato, seksjoner, "For Cosmo"-seksjon)
+2. Følg format fra eksisterende filer (header, dato, seksjoner)
 3. Oppdater relevant SKILL.md med referanse
 
 ## Legge til ny kommando

docs/eu-ai-act-integration-handover.md

@@ -9,7 +9,7 @@
 
 ## Kontekst
 
-ms-ai-architect er en Claude Code-plugin for Microsoft AI-arkitektur i norsk offentlig sektor, primært brukt av KTG (AI-rådgiver, Direktoratet for digital tjenesteutvikling). Pluginen har allerede DPIA- og ROS-agenter. EU AI Act-støtte skal integreres som en **overordnet regulatory layer** som feeder inn i eksisterende arbeidsflyt.
+ms-ai-architect er en Claude Code-plugin for Microsoft AI-arkitektur i norsk offentlig sektor. Pluginen har allerede DPIA- og ROS-agenter. EU AI Act-støtte skal integreres som en **overordnet regulatory layer** som feeder inn i eksisterende arbeidsflyt.
 
 **Logisk sekvens (uforanderlig):**
 ```

docs/ingestion-security-brief-2026-07.md

@@ -0,0 +1,256 @@
+# Brief: Ingestion-pipeline security gate (G6 / R6 punkt d)
+
+**Design input for the two-layer ingestion security gate. Goal: the highest
+feasible level of adversarial-content defense on the chain that turns fetched
+Microsoft Learn content into a publicly distributed knowledge base.**
+
+Status: design brief. This sharpens and hardens the gate already decided in
+`docs/ref-kb-correctness-program-2026-06.md` §8 (G6) and scoped for
+`docs/plugin-roadmap-2026-07.md` R6 punkt (d). It does **not** invent a parallel
+mechanism — it is the concrete design for that existing item.
+
+---
+
+## 1. Why this is load-bearing for *this* plugin specifically
+
+The KB is not a private cache. Reference files under `skills/**/references/**`
+become **instruction-adjacent context in future agent sessions**, and the plugin
+ships on a public remote to the whole of Norwegian public sector. One poisoned
+reference file is re-served to every user of every downstream session (G6 §8,
+verbatim: *"references-filene blir instruksjonsnær kontekst i fremtidige
+agent-sesjoner, én forgiftet fil re-serveres til alle brukere (hele Norge)"*).
+That makes write-time adversarial-content defense a first-class control, not
+hygiene — the opposite end of the risk spectrum from a pinned, single-author
+source.
+
+## 2. The pipeline as it actually is (grounded)
+
+Verified by reading `commands/kb-update.md` and `CLAUDE.md`:
+
+- **Ingestion runs in-session, in Claude Code, via the `microsoft-learn` MCP.**
+  Apply is *"alltid manuell og kjøres in-session"* (`kb-update.md:13`); content
+  enters through `microsoft_docs_fetch` / `microsoft_docs_search` /
+  `microsoft_code_sample_search` (`kb-update.md:5,22,180`). `generate-skills`
+  (batch MCP-research) and `research` / `research-agent` follow the same
+  in-session-MCP-fetch → persist pattern (`CLAUDE.md:39,56`).
+- **The detection tier is Claude-free** — it polls sitemaps for `<lastmod>` only
+  and never feeds fetched *content* to a model (`kb-update.md:13,52-73`). The
+  adversarial-content-into-model boundary is therefore the **in-session apply**,
+  not the schedulable detection.
+- **Write and commit points are explicit.** New file: fetch → transform
+  (`transform-prompt.md`) → born-verified judge → `composeKbFile` →
+  `validateKbFile` → create-guard `validate-kb-file.mjs` → atomic write
+  (`kb-update.md:127-134`). Update: fetch → classify change → `Edit` →
+  `validateKbFile` → commit `chore(ms-ai-architect): refresh KB <fil>`
+  (`kb-update.md:180-189`); bulk commit `git add skills/` (`kb-update.md:196`).
+- **Existing defenses are substantial — but aimed at correctness, not
+  adversarial content.** Authority-source binding (`lib/authority.mjs`),
+  verify-out with an adversarial refutation panel (`lib/verify-out.mjs`; status
+  claims are *always* flagged), the born-verified judge (v3.1), the create-guard,
+  and the "never auto-fix KB — flag → human → fix" discipline all answer *"is
+  this claim true against its authority?"* None of them answers *"is this fetched
+  chunk trying to inject instructions or smuggle an invisible payload?"* G6 §8
+  states this precisely: *"Tillit til MS Learn dekker faktisk korrekthet — ikke
+  adversarielt innhold i kanalen eller i kodeeksempler/lokalisert stoff."*
+
+**That is the gap this brief closes.** It is orthogonal to the correctness
+machinery, and must not replace or weaken it.
+
+## 3. Threat model
+
+- **Vector.** Microsoft Learn is authoritative for its core docs, but it has
+  surfaces that are community-contributable or machine-ingested and *not* authored-
+  and-reviewed to the same standard: **code samples**, **localized strings**,
+  community doc contributions, and Q&A / forum-ingested material where fetched.
+  An adversary who lands a payload in one of those surfaces gets it fetched,
+  summarized, and **persisted** into a reference file.
+- **Payload classes.** Indirect prompt injection (imperative text aimed at a
+  future reading agent: spoofed `<system>` blocks, "note to the assistant…",
+  identity redefinition), invisible-character / bidi steganography, and
+  encoded (base64/hex) smuggling — especially inside fenced **code blocks**,
+  which G6 explicitly flags and which a correctness judge will happily pass as
+  "a valid code sample."
+- **Impact.** Persisted once, re-served to all downstream sessions. Because the
+  KB loads as instruction-adjacent context, a successful payload is a
+  supply-chain compromise of every consumer, not a single bad answer.
+
+## 4. Architecture reconciliation (read this before choosing a layer)
+
+The sibling repo `llm-ingestion-pipeline-security` establishes the principle:
+*defense belongs at the layer where the fetch and the LLM call actually happen.*
+Applied honestly, that principle points in **opposite directions** for two
+plugins, and the difference is the whole design:
+
+- **`claude-code-llm-wiki`** calls the Anthropic SDK from a **standalone script**.
+  Claude Code plugin hooks never fire there, so the `llm-security` plugin is the
+  *wrong layer* — its defense must live in the pipeline code.
+- **`ms-ai-architect`** fetches **in-session via MCP**. Here the `llm-security`
+  plugin's `post-mcp-verify` hook *does* fire and *does* scan MCP tool output
+  (including `microsoft_docs_fetch`). So the plugin is the **right layer for the
+  input scan** — which is exactly why G6 layer (a) is coherent.
+
+But right-layer is **not sufficient**, for two reasons:
+
+1. **Hooks are unreliable headless** (GH #36071, flagged in STATE). This is
+   partly mitigated because kb-update *apply* is in-session-only by design
+   (`kb-update.md:237`), but the R7+ judge-pass and any future automation cannot
+   depend on a hook firing.
+2. **The hook scans the input, not the artifact.** `post-mcp-verify` sees the MCP
+   response; it does **not** see what the model writes to `skills/**/*.md` after
+   transformation. The persisted file is the poisoning vector, and nothing
+   currently scans it before commit (the commit gate is gitleaks = secrets only).
+
+**Conclusion:** the deterministic, always-on **output scan before commit** is the
+load-bearing gate for *both* plugins. The plugin hook is an in-session
+early-warning bonus that happens to apply here — valuable, but not the gate.
+
+## 5. The two-layer gate, hardened
+
+Building on G6/R6, with the emphasis corrected per §4:
+
+### Layer A — input scan (in-session, advisory / early warning)
+
+- `llm-security` active and `post-mcp-verify` verified firing in every in-session
+  fetch (kb-update apply, generate-skills, research, R7+ judge-pass). This is the
+  G6 activation rule — already in effect for fetch sessions (STATE bears it).
+- **Sanitize + spotlight-fence fetched content before it reaches the transform /
+  judge model.** Strip carrier classes (invisible chars, bidi, HTML comments)
+  and wrap the fetched markdown as untrusted data in `transform-prompt.md` and
+  `judge-claim-prompt-v3.1.md`, so the *in-session* model itself is not steered.
+  (This protects the transform step; Layer B protects the artifact.)
+- Treat Layer A as **advisory**. It must never be the sole gate, because of §4.1.
+
+### Layer B — output scan before commit (deterministic, always-on, authoritative)
+
+This is the gate. A deterministic Node scan (unicode / decode / injection —
+covering prose **and fenced code blocks**) over changed `skills/**/*.md`, wired in
+at two existing chokepoints so it runs regardless of any hook:
+
+1. **Into the create-guard.** Add a security-scan sibling to
+   `validate-kb-file.mjs` (`kb-update.md:134`): a file that fails the adversarial-
+   content scan is never written — same shape as the existing "transform.mjs never
+   writes / create-guard before write" invariant.
+2. **Before commit.** Scan the staged `skills/**/*.md` set before the
+   `chore(...): refresh KB` commit (`kb-update.md:189,196`). A hit blocks the
+   commit.
+
+### Disposition — provenance-tiered, composed with existing discipline
+
+- Reuse the existing authority/`**Source:**` machinery (`lib/authority.mjs`) to
+  tag each fetched chunk's **provenance trust**: authored-doc vs code-sample vs
+  localized vs community/Q&A.
+- **High-severity injection in a low-trust chunk → hard-fail / quarantine** (never
+  written). **Any-severity in a high-trust chunk → WARN + human review.** Source
+  trust is a first-class input to disposition, not a global constant
+  (mirrors the sibling brief's principle 4.7).
+- An injection flag routes to the **same human-in-loop** as a status-claim flag:
+  quarantine, operator adjudicates, never auto-committed. No new mechanism — this
+  reuses "never auto-fix KB — flag → human → fix."
+
+## 5b. Layer A-aktiveringsprotokoll (R7-gate)
+
+R7 (og enhver senere fetch-økt) starter **ALDRI** før denne sjekklisten passerer. Den
+operasjonaliserer Layer A som en hard R7-gate, ikke bare en aktiveringsregel:
+
+1. **Aktiver hooken.** Slå på `llm-security`s `post-mcp-verify` i `~/.claude/settings.json`
+   (PostToolUse på `microsoft_docs_fetch`). Dette er en konfig-endring i operatørens
+   `settings.json`, ikke i plugin-repoet.
+2. **Verifiser at den fyrer.** Kjør ÉN live **foreground** `microsoft_docs_fetch` og bekreft
+   at `post-mcp-verify` faktisk fyrte (observer hook-output). En hook som ikke observeres fyre
+   teller som IKKE aktiv.
+3. **Kompenserende skann hvis den ikke fyrer.** Fyrer den ikke (headless / GH #36071), kjøres
+   den kompenserende deterministiske skannen **foreground** på den komponerte artefakten FØR
+   write: Layer B (`scan-adversarial-content.mjs`) + Step 3s pre-write unicode/carrier-scan
+   (`detectAdversarial` uten `path` → temp-fil, R6 Step 3). Denne er alltid-på og autoritativ
+   (§5 Layer B); Layer A er kun tidlig-varsling.
+4. **Frossen judge → foreground er obligatorisk.** Det fetchede innholdet **prompt-fences IKKE**
+   inn i judgen: v3.1-judgen er frosset (G1-adoptert), og å legge til fencing ville være en
+   judge-bump (Non-goal §7, krever re-måling av P/R). Uten judge-side fencing er **foreground
+   fetch obligatorisk** — det er det som lar Layer A-hooken (og operatørens øye) se innholdet
+   før judgen. (§5s fencing-ambisjon gjelder transform-steget, ikke den frosne judgen.)
+5. **Bekreft Layer B-substratet før R7.** `llm-security`-sibling MÅ være til stede (ev. via
+   `LLM_SECURITY_ROOT`) — ellers fail-closer Layer B og **BLOCKer alt** (gaten blir en vegg).
+   Bekreft at `../llm-security/scanners/…` løser før første fetch.
+
+**R7 starter KUN når 1–5 er grønne.**
+
+**Rollback:** aktiveringen i pkt. 1 er reverserbar — fjern `post-mcp-verify`-oppføringen fra
+`~/.claude/settings.json` (og ev. `LLM_SECURITY_ROOT`) for å ta ned Layer A igjen. Layer B
+(deterministisk, in-repo) er upåvirket av denne rollback-en.
+
+## 6. No local solutions — the deterministic scanner is a shared asset
+
+Per house policy (*ingen lokale løsninger*, *showcase reusable patterns*): the
+Layer B scanner is **not** a bespoke ms-ai-architect script. Two horizons:
+
+- **Near-term:** run the existing `llm-security` deterministic scanners
+  (`unicode-scanner`, `injection-patterns` lexicon, entropy/base64) as a **CLI**
+  over the changed files — already ToS-safe (local scripts, no Claude), already
+  the plan of record in G6 layer (b).
+- **Target:** that same deterministic scanner is the core of the sibling
+  `llm-ingestion-pipeline-security` library. Both this plugin's Layer B and
+  `claude-code-llm-wiki`'s A13 output-lint should converge on **one**
+  implementation and **one** lexicon dataset, so the pattern table does not drift
+  into two copies. This brief is the second consumer that justifies extracting it.
+
+**Coordination (2026-07-05).** The durable cross-repo mechanism is **hub-and-spoke**:
+the canonical convergence contract lives in the hub (`llm-ingestion-pipeline-security`,
+the designated shared asset); ms-ai-architect's spoke pointer is roadmap **R19**. See the
+outgoing brief delivered to the hub repo (2026-07-05) for the proposed contract, the
+confirmed language data points (ms-ai-architect Layer B = Node), and the open
+`claude-code-llm-wiki` language brick that locks the polyglot-vs-Node-primary decision.
+
+## 7. Non-goals
+
+- **Not** a query-time guardrail (downstream sessions can layer their own).
+- **Not** a replacement for the correctness / judge / authority machinery — this
+  is orthogonal, adversarial-content defense. Both run.
+- **Not** an auto-fixer — it blocks and flags; humans adjudicate.
+- **Not** a ToS change — detection stays Claude-free; the deterministic scan is
+  local; in-session hooks are unaffected.
+
+## 8. Verification (testable, TDD / Iron Law)
+
+Write the failing tests first; no production scan code without a red test.
+
+- **Seeded adversarial fixtures blocked before commit.** A synthetic "MS Learn"
+  doc carrying (a) a spoofed `<system>` / "note to the assistant" payload, (b)
+  zero-width / bidi smuggling, (c) a base64 blob inside a code sample — each is
+  rejected by the Layer B create-guard *before* write, and blocks the commit if
+  staged. Test asserts no file written and non-zero guard exit.
+- **Clean doc passes** untouched (byte-identical), guard exit 0.
+- **Provenance tiering.** A high-severity hit in a code-sample/Q&A-tier chunk
+  hard-fails; the same string in an authored-doc-tier chunk yields WARN + review,
+  not a silent block. Test both directions.
+- **Composition with correctness.** A doc that is factually correct but carries a
+  payload is still blocked (proves the gate is orthogonal to the judge).
+- **Full suite** `node --test tests/kb-update/*.test.mjs tests/kb-eval/*.test.mjs`
+  exit 0; corpus untouched by the security-code change.
+- **Layer A firing check** documented for one live fetch session
+  (`post-mcp-verify` observed firing), with the headless caveat noted.
+
+## 9. Relationship to the roadmap
+
+This brief IS the design for **R6 punkt (d)** / **G6 §8**. Sequencing is
+unchanged: gate designed at R6, enforced from R7 and in the kb-update cadence.
+The G6 **activation rule already applies immediately** to any fetch session
+(`/architect:kb-update`, `generate-skills`, research, judge-pass) — this brief
+does not change that; it specifies what the enforced gate must do.
+
+## 10. Verification log (sources; what is code-verified vs manifest-sourced)
+
+- **Code-verified (read directly this session):** the in-session-MCP architecture,
+  fetch tools, write/commit chokepoints, and existing defenses — all from
+  `commands/kb-update.md` (line refs cited inline) and `CLAUDE.md`.
+- **Decision text:** G6 register and R6 punkt (d) quoted from
+  `docs/ref-kb-correctness-program-2026-06.md` §8 and
+  `docs/plugin-roadmap-2026-07.md`.
+- **Manifest-sourced, confirm in code before wiring:** the exact write/commit
+  insertion points for `generate-skills`, `research`/`research-agent`, and the
+  R7 judge-pass follow the same pattern per `CLAUDE.md:39,56` but were not read
+  line-by-line here (an initial recon subagent was interrupted by a model usage
+  limit; this brief is grounded in the files read directly by the main session).
+  The implementing session must confirm those insertion points against the live
+  command/agent code before wiring Layer B into them.
+- **Sibling contract:** `llm-ingestion-pipeline-security/docs/BRIEF.md` (the
+  write-time ingestion contract and the source-trust disposition principle).

docs/kb-refresh-backlog-2026-06.md

@@ -0,0 +1,49 @@
+# KB-refresh backlog — etter critical-klyngen (juni 2026)
+
+_Prioritert rekkefølge for gjenstående KB-refresh etter at critical cost-klyngen (8 filer) + release v1.16.2 ble fullført 2026-06-24. Tall fra `node scripts/kb-update/report-changes.mjs` (leser url-registry, ingen nettverk). Status-of-play i STATE.md._
+
+## Arbeidsmønster (bevist på critical-klyngen — gjenbruk per batch)
+1. Spawn read-only **Sonnet** drift-rapporter per batch (parallelt) → samler `✅ TRYGT` vs `VERIFY`-funn.
+2. **Main-agent = verifiseringsgaten:** hver `VERIFY`-påstand bekreftes mot sitert MS Learn-kilde (search/fetch) FØR den skrives. Agenter kan feillese/overgeneralisere (jf. fil 8: Phi/Falcon-«retired»-påstand ble avkreftet).
+3. Kirurgiske edits — **disclaimed/illustrative priser røres ALDRI**. Bump header (dag-presis dato hvis kilde endret midt i måneden, ellers `YYYY-MM`).
+4. `git diff`-gate → `./tests/validate-plugin.sh` (må være 239/0) → **1 fil = 1 commit** (`KB-refresh <tier> N/M`).
+5. Når en tier er tom: re-kjør `report-changes.mjs` (bekreft count faller) → **release** via `catalog/scripts/release-plugin.mjs ms-ai-architect <ver> --create-tag` så `--write --commit --push` (krever plugin.json == README-badge == ver + CHANGELOG + version-history FØRST; check-versions 0 ERROR).
+
+## Rekkefølge
+
+### 0. Quick-triage: UNVERIFIED (1) — gjør først, billig
+- `ms-ai-advisor/references/architecture/security.md` — **dateless** (mangler `Last updated`-header). Kjernefil lest av architecture-review-agent. Verifiser innhold + stamp header. Kan foldes inn i HIGH-sesjonen.
+
+### 1. HIGH (11) → release v1.16.3
+Batch etter område for kilde-gjenbruk:
+- **A — ms-ai-security/ai-security-engineering (3):** owasp-llm-top10-azure-mitigations · defender-threat-protection-ai-services · output-validation-grounding-verification. (Deler OWASP/Defender-kilder.)
+- **B — ms-ai-governance/responsible-ai (4):** content-safety-implementation · responsible-ai-policy-development · stakeholder-communication-ai-decisions · bias-detection-mitigation-strategies.
+- **C — ms-ai-governance/monitoring-observability (2):** model-performance-drift-detection · response-quality-metrics-rag.
+- **D — blandet (2):** governance/norwegian-public-sector-governance/copyright-ai-training-data-norway · engineering/agent-orchestration/agent-autonomy-and-control-governance.
+
+### 2. MEDIUM (33) → release v1.16.4 (vurder splitt)
+- **prompt-engineering (13, ms-ai-advisor):** few-shot, domain-specific, temperature-sampling, multi-turn, chain-of-thought, regulatory-prompting, grounding-injection, token-optimization, real-time-reasoning, role-playing, structured-output, system-message-design, function-calling. (Stor kohesiv batch.)
+- **performance-scalability (9, ms-ai-security):** async-processing, response-chunking, perf-benchmarking, throughput, token-per-second, gpu-sizing, concurrent-request, load-testing, batch-api-usage.
+- **rag-architecture (5, ms-ai-engineering):** streaming-rag, rag-evaluation, self-reflective-rag, rag-hallucination-mitigation, late-chunking.
+- **engineering-misc (5):** agent-orchestration (2: evaluation-testing, memory-context) · mlops-genaiops (2: model-versioning, feedback-loops) · azure-ai-services (1: speech-speaker-recognition).
+- **advisor/platforms (1):** azure-ai-foundry (kjernefil — høyere reell verdi enn MEDIUM antyder; vurder å løfte tidlig).
+
+### 3. LOW (52) → release v1.16.5 (splitt anbefalt, største område først)
+- **data-engineering (20, ms-ai-engineering)** — størst.
+- **api-management (13, ms-ai-engineering).**
+- **bcdr (10, ms-ai-infrastructure).**
+- **advisor/architecture (7):** ai-utredning-template, regional-availability-verification, migration-patterns, poc-template, licensing-matrix, public-sector-checklist, adr-template. (Templates + kjernefiler — lav drift-risiko, men leses ofte.)
+- **rest (2):** advisor/development/agent-framework · infrastructure/hybrid-edge/disconnected-ai-scenarios.
+
+> **KB-refresh FERDIG 2026-06-24:** alle tiers (Critical/High/Medium/Low) → 0. Releases v1.16.2 (critical) · v1.16.3 (high) · v1.16.4 (medium) · v1.16.5 (low 52/52). `report-changes.mjs` = 0 needing-update.
+
+## Separate spor (IKKE KB-refresh — egen prioritering)
+Disse er kjent fra memory/docs, men ikke re-verifisert denne sesjonen — bekreft status før start:
+- **Cosmo-persona — full utfasing (NY, godkjent 2026-06-24, gjøres SIST):** se `docs/cosmo-removal-brief-2026-06.md`. 417 filer / 188 `## For Cosmo`-seksjoner + persona-lag (SKILL.md, kommandoer, README, NOTICE, CLAUDE.md). Startet i v1.16.5 (2 filer). Egen plan + versjonsbump.
+- **Spor C — kurs/training-deteksjon (C3):** C3 Learn Platform API-creds satt opp (se memory `c3-learn-platform-api-setup`). Neste: faktisk deteksjons-implementasjon.
+- **Onboarding-uplift-måling:** alt onboarding-maskineri bygget; gjenstår å MÅLE faktisk uplift (memory `onboarding-quality-bar`).
+- **Ref-fil INNHOLDSkvalitet — ikke dekket av Spor D (NY, notert 2026-06-26):** Skill-kvalitetsscoringen (`scripts/kb-eval/`, Spor D, K1-K10 + N1-N5 + refCount) scorer SKILL.md-forfatterkvalitet + ref-filenes STRUKTUR/hygiene — IKKE den substansielle korrektheten/ferskheten i de ~389 ref-filenes innhold. De eneste kriteriene som leser ref-innhold er strukturelle: K8 (kilde-/Verified-header finnes, andel ≥0.80), N3 (ingen nøstede ref→ref-lenker), N4 (TOC i filer >100 linjer), refCount (tall matcher SKILL.md). Substansiell ferskhet dekkes av et SEPARAT system — KB-refresh (`report-changes.mjs` sitemap-poll: header-dato vs kilde-lastmod → `microsoft_docs_fetch` + agent-verifisering). Det flagger STALENESS, men gir ingen kvalitets-SCORE og hviler på per-refresh agent-verifisering — det finnes INGEN stående «er dette ref-innholdet korrekt + oppdatert mot Microsoft Learn»-score analogt til 0-100 skill-scoren. Operatøren markerer dette som det VIKTIGSTE å gjøre skikkelig. Neste steg: bekreft ønsket form (utvid Spor D med et content-correctness-kriterium? eget ref-eval-spor? styrke KB-refresh til å produsere en score?) FØR bygging.
+
+## Notater
+- Falske positiver er forventet: header-dato < sitemap-lastmod = KANDIDAT, ikke bekreftet drift. Mange LOW/MEDIUM kan vise seg å være header-bump-only (jf. critical-klyngens 2 falske positiver).
+- Tier-grensene er detektor-heuristikk, ikke hellige — løft en kjernefil (f.eks. azure-ai-foundry) tidligere hvis den har reell verdi.

docs/okf-second-brain-brief-2026-06.md

@@ -0,0 +1,167 @@
+# Brief — Google OKF for brukerens «second brain» (LLM-wiki), IKKE for skill-refs
+
+_Notert 2026-06-26. Fremtidig initiativ — IKKE implementer før operatør sier fra. Bygger på research av GoogleCloudPlatform/knowledge-catalog (spec + samples + toolbox). State-of-play i `STATE.md`._
+
+## Delt spec er nå kilden (2026-06-29, ratifisert)
+Konvensjonen er **ikke lenger definert lokalt** — den bor i `catalog/docs/okf-second-brain/spec.md` (v0.1, eid av ingen enkelt plugin; linkedin-studios `brain/` er referansedesign, okrs `okf-check.mjs` referanse-checker; rollout/koordinering i samme mappes `log.md`). Denne brief-en er nå **plugin-spesifikk plan**, ikke konvensjonsdefinisjon — den *refererer* spec-en. Bekreftet for ms-ai-architect: minimal kontrakt (spec §3: `type` per konseptfil + `index.md` per nivå + `okf_version` i rot-`index.md`) er **gulvet, ikke taket** — vår «fulle OKF-pakke» rir over som **extension keys** (spec §5), ikke nivellert ned til bar OKF.
+
+**Premiss-korreksjoner (spec §9, ground-truth mot live repo — overstyrer økosystem-digesten under):**
+1. **`mdcode`/`kcmd` er IKKE et OKF-verktøy** — det er et Dataplex git-sync-verktøy med annet frontmatter-schema. **Droppet** fra adopsjonsplanen.
+2. **Ingen gjenbrukbar OKF-*ingest*-kode finnes** — `reference_agent` er BigQuery+Gemini/GCP-bundet. Adopter *prompt-mønstrene*, ikke koden. Classify/convert = bygg-selv.
+3. **Kanonisk anbefalt feltnavn er `resource`** (ikke `source`).
+
+## Implementasjonskilde: delt bibliotek, ikke lokal bygging (2026-07-19, verifisert)
+Tooling-en under «Hva som må bygges» **bygges ikke lokalt her**. Den kommer fra det delte biblioteket `~/repos/llm-ingestion-okf` (offentlig Forgejo `open/`), som syv repo skal konsumere — så standard-forbedringer arver alle, i stedet for at hver plugin drifter sin egen kopi.
+
+**Tre-delt eierskap (hold dem fra hverandre):**
+- **Konvensjon** → `catalog/docs/okf-second-brain/spec.md` (uendret, se over).
+- **Implementasjon** → `llm-ingestion-okf` fase 4 = `node/`-halvdelen: zero-dep ESM, importerbar + CLI-invokerbar, **vendret per plugin** (ikke npm). Python- og Node-halvdelen deler kontrakt + fixtures, aldri kode.
+- **Sikkerhet** → alltid `llm-ingestion-guard`. Fase 4 leverer kun hook-punktet ved persist (guard-as-contract); scan-/sanitize-logikk hører ALDRI hjemme her. Vår `docs/ingestion-security-brief-2026-07.md`-ambisjon om Node Layer-B-scan er guard-territorium.
+
+**Vår rolle er greenfield-konsument, ikke migrering.** `llm-ingestion-okf/docs/plan/phase-4-node-half.md` koordineringspunkt 5: pluginens designet-men-ubygde behov (writer, indeksgenerator, checker, retrieval-støtte) er **akseptanse-skissen for pakkens API-flate**. Vi har null OKF-kode i dag — det er en fordel her, ikke en gjeld.
+
+**Tidshorisont og gate (per 2026-07-19):** `node/` finnes ikke ennå; biblioteket er ren Python (v0.3.0, fase 1 levert). Fase 4 ← fase 3 ← fase 2, og fase 2 er **blokkert på avklaring B2** (guard-distribusjonskanal for CI — operatørbeslutning, `phase-2-doors-b-c.md:96`). Fase 4 starter dessuten med sign-off-kjede, ikke kode, der vi er punkt 5 av 5: *«okr/ms-ai-architect adopterer i egne repo (egne sesjoner, eksplisitt instruks per repo)»*. **Konsekvens: ikke start S-OKF-implementasjon før B2 er avklart og fase 4 har levert `node/`.**
+
+## Scope-grense + ambisjon (ufravikelig, operatør-bekreftet 2026-06-26)
+- **OKF gjelder KUN brukerens egen kontekst/data** — hans person- og organisasjonsspesifikke «second brain» / LLM-wiki (i dag onboarding-output i `~/.claude/ms-ai-architect/org/*.md`).
+- **For dette sporet kjøres FULL Google OKF-pakke** (ikke bare lån av mønstre): frontmatter-kontrakt + `index.md`-progressiv-disclosure + retrieval + vedlikeholds-/enrichment-mekanisme, modellert på `samples/` + `toolbox/`. **Og adopsjonen holdes oppdatert etter hvert som OKF-standarden utvikler seg** (v0.1 → senere versjoner; fang `okf_version`-bump). Operatør-direktiv 2026-06-26.
+- **OKF gjelder IKKE de 389 skill-reference-filene.** De forblir Claude Code skill-references (native mekanisme, Anthropic-anbefalt flat/progressiv-disclosure-struktur). Begrunnelse: se `docs/ref-kb-direction-note-2026-06.md` + rekonsidererings-konklusjon i memory `okf-scope-second-brain-only`.
+
+## Hvorfor OKF passer second brain (men ikke skill-refs)
+Avgjørende skille er **ikke** «er det en LLM-wiki» (begge er det) — men **«finnes det allerede en native, anbefalt mekanisme?»**:
+- **Skill-refs:** JA — Claude Code skills + references + progressiv disclosure, allerede Anthropic-best-practice (flat, ett nivå dypt, store filer lastet on-demand, SKILL.md-hub + domene-mapper + grep). OKF ville erstattet et fungerende native system med et ekvivalent fremmed (OKFs retrieval-verdi over skills ≈ null; Grep/Glob/Read dekker allerede OKFs list/search/read).
+- **Second brain:** NEI — bor i dag i ad-hoc `org/*.md` uten retrieval-mekanisme under chat. OKF fyller et reelt tomrom: struktur + retrieval + vedlikeholds-tooling, vendor-nøytralt, portabelt, bruker-eid.
+
+## Lastemodell-skifte (operatør-presisering 2026-06-26 — reverserer tidligere antakelse)
+- **Før (antatt):** all kontekst injiseres når hver `/architect:*`-kommando kjøres.
+- **Nå (mål):** kontekst hentes **smart/selektivt** per kommando *og per interaksjon* — fordi de fleste ganger **chatter** brukeren med pluginen lastet, uten å kjøre kommandoer. Konteksten må være tilgjengelig i fri chat, hentet on-demand, ikke forhåndsinjisert.
+- Implikasjon: «second brain» trenger en **retrieval-skill** (list → search → read) som er aktiv uavhengig av kommandoer, + en **vedlikeholds-mekanisme** som holder wikien oppdatert etter hvert som brukeren tilfører kontekst OG etter hvert som OKF-standarden utvikler seg.
+
+## OKF v0.1 — kjernekontrakt (verifisert mot spec)
+
+> ⚠️ **v0.2 ER UTE (Google, 2026-07-25) — denne seksjonen beskriver v0.1-formen.**
+> Verifisert 2026-08-03 mot `okf/SPEC.md` §13.1 (ikke mot coord-melding): to felt er
+> retirert, begge med fallback, så en v0.1-formet bundle er fortsatt KONFORM:
+> - **`timestamp` er avløst av `generated.at`** — siste innholdsendring føres som
+>   `generated: { by, at }`. «Consumers MAY fall back to a legacy `timestamp` when
+>   `generated` is absent.»
+> - **Body-seksjonen `# Citations` er avløst av `sources`** — proveniens flyttet til
+>   frontmatter. «Consumers SHOULD read `sources` and MAY still parse a legacy
+>   `# Citations` body list for v0.1 documents.»
+>
+> **Vi er greenfield: de 6 filslotene finnes ikke på disk, så vi sikter v0.2 fra
+> første byte** og arver ingen migreringsbyrde. Der `timestamp` og `# Citations`
+> nevnes nedenfor, les dem som v0.1-form som IKKE skal kopieres inn i nytt arbeid.
+
+- Bundle = katalogtre av markdown-filer, ett konsept per fil. Påkrevd frontmatter-felt: `type`. Anbefalt: `title`, `description`, `resource` (kilde-URI), `tags`, `timestamp` (**v0.2: `generated.at`**). Konsumenter MÅ bevare ukjente felt.
+- Reserverte filnavn: `index.md` (katalog-enumerasjon, ingen frontmatter, progressiv disclosure), `log.md` (endringslogg).
+- Kryss-lenking: bundle-relativ (`/...`) eller relativ markdown; relasjonstype utledes av prosa. Konsumenter må tolerere brutte lenker.
+- v0.1 (12. juni 2026), «starting point, not finished standard» → hold OKF-adopsjonen oppdatert ettersom standarden bumpes (`okf_version` i rot-`index.md`).
+- Kilde: https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md
+
+## Økosystem-digest (les disse FØRST ved implementasjon)
+Repo: `GoogleCloudPlatform/knowledge-catalog`. Mye er GCP/Dataplex/Gemini-bundet (ikke direkte gjenbrukbart); de **rene mønstrene** vi adopterer er markert.
+
+**Konsum / smart retrieval (kjernen — ADOPTER MØNSTERET):**
+- `samples/enrichment/sample/config/skills/kb-search/SKILL.md` — kanonisk skill-basert henteguide. Eksponerer trioen `list_contents` / `read_file` / `search_content` (= progressiv disclosure: finn → åpne kun relevant). **Mest verdifulle fil å lese først.**
+- `samples/enrichment/sample/config/mcp.json` + `samples/enrichment/src/tools/fileskb/{README.md,main.py}` — minimal stdio-MCP-server som eksponerer list/search/read over en markdown-katalog. _NB: i Claude Code dekker Grep/Glob/Read dette allerede — egen MCP-server er trolig unødvendig; SKILL-instruksen («søk wikien først, åpne kun relevant») er det bærende._
+- `samples/discovery/*` — Dataplex-bundet søke-agent (Google ADK + CatalogServiceClient). IKKE gjenbrukbart; kun mønster-referanse.
+
+**Struktur / frontmatter-eksempler:**
+- `okf/bundles/ga4/index.md` + `okf/bundles/ga4/references/metrics/avg_pageviews.md` — ekte `index.md`-hierarki + leaf-konsept med frontmatter (`type`/`resource`/`title`/`description`/`tags`/`timestamp`) + `# Citations`-seksjon. ⚠️ **IKKE kopier ordrett — dette upstream-eksempelet er v0.1-formet på nøyaktig de to aksene v0.2 retirerte** (`timestamp` → `generated.at`; `# Citations` → `sources` i frontmatter). Kopier hierarkiet og felt-disiplinen, ikke de to feltene.
+
+**Produksjon / vedlikehold (ADOPTER MØNSTERET, ikke koden):**
+- `okf/src/reference_agent/prompts/web_ingestion_instruction.md` — kilde-drevet oppdatering: `list_concepts → fetch → enrich/mint/skip` med strenge frontmatter-/heading-bevaringsregler. Moden mal for «hold wikien oppdatert fra kilder».
+- `okf/src/reference_agent/prompts/reference_instruction.md` — deterministisk konsept-syntese (frontmatter + fast body-rekkefølge).
+- `okf/src/reference_agent/cli.py` — `enrich` / `visualize`-kommandoer (Gemini/BQ-bundet impl).
+- ~~`toolbox/mdcode/...`~~ — **DØDT SPOR (spec §9.1):** `mdcode`/`kcmd` er IKKE et OKF-verktøy, men et Dataplex git-sync-verktøy med et annet frontmatter-schema (`id`/`resource.name`/`createTime`/`links`). Ikke planlegg OKF-emit/sync via det.
+
+## Hva som må bygges (fremtidige faser — ikke nå)
+> **Leses sammen med «Implementasjonskilde» over:** punkt 1–3 beskriver *behovet*, ikke et byggeoppdrag her. Tooling-en leveres av `llm-ingestion-okf` fase 4 (writer/inbox-primitiver, `okf index`, `okf check`, retrieval-støtte). Vår jobb ved adopsjon er konfigurasjon + vendring + å prøve API-flaten mot behovene under — ikke implementasjon.
+
+1. **Frontmatter-/struktur-konvensjon** for second brain: bygg mot delt spec §3 (`type` påkrevd + `index.md` per nivå + `okf_version` i rot — **sett den til `"0.2"`**). Anbefalte felt (spec §4): **`resource`** (kanonisk kilde-URI — IKKE `source`), `title`, `description`, `tags`, **`generated: { by, at }`** (v0.2; erstatter `timestamp`) og **`sources`** i frontmatter (v0.2; erstatter body-seksjonen `# Citations`). Migrer dagens `org/*.md` (de mangler bare `type:` — nær OKF allerede).
+2. **Retrieval-skill** («second-brain-search» e.l.): list → search → read over `~/.claude/ms-ai-architect/org/`, aktiv i fri chat (ikke bare kommandoer). Avgjør: ren SKILL+Grep/Glob/Read vs. dedikert MCP-server (build-both-and-measure-kandidat — se under).
+3. **Vedlikeholds-mekanisme**: hvordan wikien oppdateres når brukeren tilfører kontekst (onboarding-agent skriver OKF-konform), + en oppdaterings-rutine når OKF-standarden bumpes.
+
+## Åpne valg (operatør / måling)
+- **Retrieval-mekanisme:** SKILL + native Grep/Glob/Read vs. dedikert fileskb-MCP-server. Ekte tvil → kandidat for «implementer begge, mål hvilken gir best kontekst-treff for brukeren» (operatørs faktabasert-prinsipp).
+- **Hvor mye av OKF formaliseres:** full v0.1-konformitet vs. «OKF-kompatibel form» (frontmatter + index.md uten resten). Lén mot det letteste som gir smart retrieval.
+- **Oppdaterings-kadens mot standarden:** hvordan fange OKF-versjonsbump (v0.1 → …) uten manuell polling.
+
+## Suksesskriterium (per operatør 2026-06-26)
+Det viktigste er **ikke teknologien**, men at second brain blir **så bra som mulig for brukeren** og at **oppdateringsmekanismene fungerer veldig bra**. Mål mot brukerverdi (henter pluginen riktig personlig/org-kontekst i chat?) + vedlikeholds-pålitelighet — ikke mot formell OKF-konformitet i seg selv.
+
+## Fase-4-kartlegging: hva vi faktisk trenger fra biblioteket (2026-07-20, verifisert)
+
+Svar på koordineringspunkt 5 (vi = akseptanse-skisse for Node-API-flaten). Markørlinje satt i `STATE.md`: **`planned`**.
+
+**Ground truth denne kartleggingen hviler på (verifisert, ikke antatt):**
+- `~/repos/llm-ingestion-okf`: v0.3.1, `node/` finnes **ikke** (kun `src/` = Python). `docs/plan/phase-4-node-half.md:12,49-62` planlegger `okf check|index|inbox|convert` — altså writer/index/checker uten connector-krav.
+- `~/.claude/ms-ai-architect/org/` **finnes ikke på denne maskinen** — second brain er designet (6 filslots konsumert av `research-agent`, `adr-writer-agent`, `architecture-review-agent` m.fl.) men aldri materialisert. Vi er greenfield i bokstavelig forstand.
+- `scripts/kb-update/` er **ikke** en OKF-flate (se under).
+
+### kb-update-pipelinen: generisk mekanikk vs. MS Learn-domenelogikk
+Deteksjonslaget er 100 % deterministisk node (null modellkall, strukturelt garantert i `run-detection.mjs:6-9`); apply-laget er LLM/MCP og alltid manuelt in-session.
+
+| Generisk ingestion-mekanikk | MS Learn-domenelogikk |
+|---|---|
+| `lib/atomic-write.mjs` (tmp+rename), `lib/backup.mjs` (scoped restore + sentinel) | `lib/sitemap-stream.mjs` (hardkodet `learn.microsoft.com/_sitemaps/`), `lib/url-normalize.mjs` (locale-stripping) |
+| `lib/registry-io.mjs`, `lib/decisions-io.mjs` (manifest + ledger/idempotens) | `data/domain-taxonomy.json` (sitemap-prefikser → category → skill-routing) |
+| `lib/verified-staleness.mjs`, `lib/full-pass-worklist.mjs` (kilde-timestamp vs. verifisert-timestamp) | `lib/kb-headers.mjs` + `lib/transform.mjs` (bold-label-header-kontrakten), `lib/verify-out.mjs` (GA/preview/pris-regexer), `lib/learn-api.mjs` |
+| Invarianten «pure lib skriver aldri; kun gated caller skriver» | `transform-prompt.md` + `kb-eval/judge-claim-prompt-v3.1.md` (claim/judge-format) |
+
+Den generiske kolonnen overlapper reelt med det fase 4 skal levere (atomisk write, manifest, ledger, ferskhet). **Men den flytter vi ikke** — se «Aldri hit» under.
+
+### Vår adopsjonsflate = second brain, og den trenger ikke dør A
+Second brain-filene fødes av et **onboarding-intervju** (LLM → `Write`), ikke av en kildekonnektor. Det finnes ingen manifest, ingen CSV, ingen SQL, ingen URL å hente. Dør A (manifest → connector → materialisering) er derfor **irrelevant for oss** — vi trenger den *bakre halvdelen* av dør A, frikoblet fra connector-halvdelen.
+
+**Konkret krav til Node-API-flaten (punkt (b) i rapporteringen):**
+1. **Writer uten connector.** `writeConcept({path, frontmatter, body})` må være kallbar direkte med LLM-forfattet innhold — ikke bak et manifest/connector-krav. Deterministisk frontmatter-emit (`type` påkrevd, `resource`/`title`/`description`/`tags`, **`generated: { by, at }` — `generated.by` er PÅKREVD når `generated` finnes — og `verified` som liste**; v0.2-formen, ikke `timestamp`), ukjente felt bevart, atomisk skriv, idempotent re-kjøring.
+2. **`okf index` som bibliotekfunksjon, ikke bare CLI.** Vi må regenerere `index.md` per nivå fra en in-process hook (onboarding-agent skriver én fil → indeks oppdateres i samme operasjon), uten å shelle ut.
+3. **`okf check` med maskinlesbar exit + funn-struktur.** Vi har allerede create-guard-mønsteret (`validate-kb-file.mjs`, exit≠0 = stopp) og vil speile det for OKF-flaten.
+4. **Guard-hook ved persist, ikke i biblioteket.** `free-context.md` er den ene slotten der brukeren limer inn vilkårlig eksternt innhold — der må `llm-ingestion-guard` kalles på kallstedet. Vi leser IKKE «security is delegated» som «trygt by default» (jf. v0.3.1-presiseringen).
+5. ~~**Fritekst-kravet (F1) gjelder oss, men via dør B — ikke dør A.**~~ **Trukket 2026-07-20 (trinn D-review).** Premisset var at dørene er monolitter; når de blir komposisjoner over offentlige primitiver, forsvinner det. Vi har ingen preferanse for hvordan F1 løses, så lenge writeren ikke låses bak connector-laget (krav 1).
+6. **Vendring, ikke npm** — zero-dep ESM som kan sjekkes inn under `scripts/`, konsistent med at pluginen distribueres offentlig og må kjøre uten install-steg.
+7. **Bundlen bærer ingen fullstendighetsegenskap** (trinn D-review 2026-07-20, **skjerpet trinn E 2026-07-20**). Onboarding er resumbar på tvers av økter — `agents/onboarding-agent.md:29-31` gjenopptar fra første fil uten `completed: true`, og sesjonshooken rapporterer delvis tilstand som gyldig (`hooks/scripts/session-start-context.mjs:160-161`). `check` må derfor skille **ufullstendig-men-gyldig** fra **ugyldig**, og `index` må være kallbar etter hver enkeltfil-skriving uten å feile på at resten mangler. Speiler vi `check` inn i create-guard-mønsteret (krav 3) og den feiler midt i et intervju, blokkerer vi vår egen onboarding.
+   - **Korreksjon (trinn E):** trinn D-formuleringen sa at hooken rapporterer «Onboarding 3/6». Den rapporterer `X/5` — `session-start-context.mjs:160-161` gater på `ORG_FILES.length`, og `scripts/kb-update/lib/user-data.mjs:27-33` definerer `ORG_FILES` som fem filer. `free-context.md` er **bevisst utenfor tellingen** (`user-data.mjs:35-38`). En fullført bundle har derfor **enten 5 eller 6 filer**, og ingenting i bundlen skiller de to. Riktig krav er ikke «delvis er også gyldig», men: fullstendighet er en egenskap ved **kalleren**, ikke ved bundlen. Biblioteket må aldri utlede et forventet entry-sett fra annet enn filene som faktisk finnes.
+8. **Skriveren må avvise stempelfeltene** (nytt, trinn E 2026-07-20 — svar på bibliotekets D1). `write_concept` skal ta frontmatter verbatim **med nøyaktig ett unntak**: `generated` og `ingest_manifest` MÅ avvises i innlevert frontmatter og kun kunne emitteres via ingest-stien. Begrunnelse: de to feltene *er* §7-stempelet, og `ingest-spec.md` §3 nøkler en unwaivable slette-regel på dem. Gjøres §5s nøkkelliste til et obligatorisk prefiks for konsepter som sådan, må våre kuraterte bruker-eide onboarding-filer bære stempelet som gjør dem slettbare ved re-materialisering — vi ville måttet **forfalske stempelet for å være compliant**. Vår frontmatter (`category`/`completed`/`last_updated`, `onboarding-agent.md:54-58`, `:147-151`) har null overlapp med §5-listen, ikke engang `type`.
+
+**Kollisjon med `portfolio-optimiser`s P1 — løsning foreslått (trinn E 2026-07-20):** P1 krever at `write_index(mode="regenerate")` **feiler høyt** på en uidentifisert linje; krav 7 krever at den **ikke feiler** på manglende konsepter. Predikatene kvantifiserer over disjunkte inndata (P1 leser indeksfila, krav 7 leser bundle-katalogen), og løses av pinningsregelen i krav 7-korreksjonen. Hos oss blir P1s predikat aldri sant — vi skriver aldri en indekslinje før fila finnes. **Tvinges valget, viker vi:** vårt behov kan dekkes på kallstedet (utsett indeksskriving), et stille tapt linje kan per definisjon ikke oppdages av kalleren. Vi ber i stedet om separate funn-koder + én negativ fixture per kode. Merk at P1 kun gjelder `write_index`; på `check_bundle` finnes ingen kollisjon.
+
+**Index-semantikk (avklart trinn D-review):** vi legger ikke til et fjerde uforenlig krav. Ingen konsument leser en indeks — alle 12 agenter leser navngitte filer direkte via absolutt sti. Indeksen er for oss en kontrakts-/oppdagelsesforpliktelse (markøren `okf_version`), ikke en retrieval-mekanisme; bibliotekets default holder.
+
+### Aldri hit (punkt (c))
+- **De 389 skill-reference-filene.** Stående operatør-direktiv (§ «Scope-grense»); native Claude Code-mekanisme dekker allerede OKFs list/search/read.
+- **Hele MS Learn KB-refresh-pipelinen.** Header-kontrakt, judge/claim-format, GA/preview-semantikk og Layer A/B-plassering er domenelogikk med egen testsuite — en delt ingestion-standard ville verken forstå eller forbedre den.
+- **All sikkerhetslogikk.** Eies av `llm-ingestion-guard` (vårt repo er `guard: active`, Layer A+B live). Ambisjonen i `docs/ingestion-security-brief-2026-07.md` om Node Layer-B-scan er guard-territorium, ikke OKF-territorium.
+
+### Bundle-plassering: vi er allerede compliant (operatørbeslutning 2026-07-20)
+Beslutningen «bruker-initierte OKF-bundles bor utenfor repoet» krever **null endring** hos oss. Second brain har aldri bodd i plugin-treet: `agents/onboarding-agent.md:23` instruerer absolutt bruker-eid sti og eksplisitt «aldri plugin-roten». KB-referansene (389 filer) er plugin-eide og distribueres med pluginen — de blir.
+
+**To funn meldt tilbake til biblioteket:**
+1. **Taksonomi-hull.** Beslutningstabellen sier at pluginens rolle for bruker-eide bundles er «leser via referanse». For oss er det feil — onboarding **skriver** til den bruker-eide katalogen. Klassen «bruker-eid katalog, plugin-skrevet innhold» har ingen boks.
+2. **Gate-tap (sikkerhet).** Vår Layer B commit-gate filtrerer til kun staged `skills/**/*.md` (`pre-commit-scan.mjs:11,34`). Innhold i `~/.claude/ms-ai-architect/org/` passerer aldri en commit og ligger utenfor ethvert git-tre. For bruker-eide bundles er guard-kallet ved persist derfor **det eneste laget**, ikke et ekstra — særlig for `free-context.md`. Krav 4 over er dermed bærende, ikke «nice to have».
+
+### KB-korpuset er bevisst aldri-OKF (avklart 2026-07-20)
+Biblioteket leste «S-OKF åpent punkt» som at korpus-spørsmålet var ubesluttet. Det er det ikke — direktivet fra 2026-06-26 står; det åpne punktet gjelder second-brain-bygget. Presisering verdt å bære: **passformen er bedre enn tidligere formulert** (`VALID_TYPES` i `classify-ref-type.mjs:14` er allerede et lukket type-vokabular; `Source`/`Last updated` mapper til `resource`/`timestamp`). Det som blokkerer er kost/nytte — bold-label-headeren er bærende for judge-/stemplingsmaskineriet, og retrieval-gevinsten over native skills er null. Vi ville dessuten aldri brukt dør A-s `http`-connector: innholds-fetch går via den offisielle `microsoft-learn` MCP-serveren, rå HTTP kun mot sitemaps (metadata).
+
+### Gate før implementasjon (uendret)
+Fase 4 ← fase 3 ← fase 2, og fase 2 er blokkert på **avklaring B2** (guard-distribusjonskanal for CI, operatørbeslutning). Ingen S-OKF-kode skrives her før `node/` er levert.
+
+### Rundeutfall: konsensus ratifisert, runden avsluttet (2026-07-21)
+Kunngjøring fra koordineringsdriveren (`llm-ingestion-okf`): de fire beslutningsaksene er avgjort og medunderskrevet; runden er avsluttet og ikke lenger åpen for innspill. Beslutningsrecord: `llm-ingestion-okf/docs/beslutninger-okf-runden.local.md` §10 + `docs/plan/2026-07-21-trinn-f-konsensus-arkitektur.local.md`. **ms-ai-architect er ikke tildelt noe utførelsessteg** (konsument-stegene navngir `okr` og `portfolio-optimiser`, ikke oss); våre posisjoner konvergerte.
+
+**D1 landet i vår favør.** Krav 8-innvendingen bortfaller: §5-prefikset (de sju stempelnøklene) er obligatorisk **kun på stemplede dør-A-filer, aldri på konsepter som sådan** — våre kuraterte onboarding-filer tvinges dermed aldri til å bære stempelet. Håndhevingen er flyttet til `check_bundle` (per-fil-utfall) = nøyaktig krav 7-mekanismen. Writer-avvisningen er skjerpet til en **dør C-garanti**: skriveren avviser det **komplette eierskapsstempelet** (`generated:true` **og** `ingest_manifest` sammen), ikke de enkelte navnene — round-trip for legitim dør C bevart. **Immaterielt for oss** (vår frontmatter `category`/`completed`/`last_updated` bærer ingen av feltene). Merk: krav 8-formuleringen «avvis begge navnene verbatim» er **superseded** av den ratifiserte «avvis kombinasjonen». `type` er ikke lenger et påkrevd felt pålagt oss av prefikset — det forblir vårt eget valg for våre filer (krav 1). Restrisiko (uforfalskbar mot uhell, ikke mot vilje): `ingest-spec.md:69-72`.
+
+**D3** (`partial`/bevisst-terminal-skillet) tatt inn som innspill; commons avgjør endelig vokab-opptak. Vår sannsynlige sluttilstand (second brain gjennom biblioteket, 389-korpuset bevisst utenfor) er nettopp et bevisst-terminalt `partial`.
+
+**D2-friksjonen ble tatt opp av runden som ÅS#5 (2026-07-21) — interim avgjort, endelig form delegert.** Ratifisert bærer for koordineringsregisteret = en **committet, ikke-gitignored fil ved siden av STATE.md** hos hvert repo (fordi STATE.md er gitignored og ikke fjern-hentbar), og tverrsnittet **genereres** fra de ni per-repo-filene og «må kunne hente oppføringen». For vårt **offentlig-speil-repo** (`open/ms-ai-architect`, distribuert til hele Norge) betyr «committet + fjern-hentbar» = **publisert offentlig** — nøyaktig den flaten vi i trinn E §4 sa vi ikke lager (markøren navngir søsken-repo + adopsjonsstatus = intern koordineringsmetadata). Vårt funn er **formelt anerkjent som en klassefeil**, ikke en enkeltsak: treffer minst `ms-ai-architect`, `llm-ingestion-okf` og `catalog`. Eierskap for endelig løsning: **commons + catalog**, avgjøres ved register-build, med tre kandidatformer — (i) generator tolererer fraværende bærer, (ii) minimal redigert offentlig bærer (status + repo-navn, uten søsken/arkitektur), eller (iii) privat sidekanal. **Interim ratifisert (og allerede vår tilstand):** hold markøren **LOCAL-ONLY** og aksepter eksklusjon fra tverrsnittet. Reåpner ikke D1–D4. **Ingen gjenstående operatørbeslutning hos oss** — vi reagerer når commons+catalog velger form; vi er uansett gated på B2 med umaterialisert second brain.
+
+**Postkasse-teardown:** `~/repos/_okf-interim/` (transport) slettes. Vår svarfil `svar/ms-ai-architect.md` var transport — alt varig innhold ligger her i briefen (verifisert: krav 1–8 + P1-løsning + trinn E-korreksjoner). **Intet datatap for oss.**
+
+## Referanser
+- **Delt konvensjon (KILDEN):** `catalog/docs/okf-second-brain/spec.md` (v0.1) + `log.md` (koordinering/rollout) — les FØRST.
+- OKF upstream-spec: https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md
+- Samples: https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/samples
+- Toolbox: https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/toolbox
+- Relatert (skill-ref-sporet, separat): `docs/ref-kb-direction-note-2026-06.md`, `docs/ref-kb-audit-2026-06.md`

docs/r11-flag-format-2026-07.md

@@ -0,0 +1,92 @@
+# R11 flag format — the judge-pass → fix-work-list contract
+
+**Spec for the flag record the R7–R10 judge pass emits and R11 (the fix step)
+consumes. A flag is a judged claim the pass could NOT ground against its cited
+Microsoft Learn source. The pass never fixes — it stamps (born-verified) or
+flags; R11 does the human-confirmed fix.**
+
+Status: design spec (R6 Step 5). Builds on the frozen v3.1 claim judge
+(`scripts/kb-eval/judge-claim-prompt-v3.1.md`) and the judge-pass ledger
+(`scripts/kb-eval/judge-pass-manifest.mjs`, R6 Step 4). Consumed by R11.
+
+---
+
+## Where a flag comes from
+
+The v3.1 judge returns, per claim, a strict-JSON result (no fence):
+
+```
+{"file":"<FILE>","results":[
+  {"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>"}
+]}
+```
+
+The pass augments each **non-grounded** result (`judge_verdict !== 'grounded'`)
+into a flag record. This is a **minimal augmentation, not a pass-through** — the
+judge output is a subset of the flag record; the pass adds four fields from the
+fan-out context and the claim manifest:
+
+| Added field | Source |
+|-------------|--------|
+| `file` | the fan-out context (one subagent per file) — also echoed by the judge output's top-level `file` |
+| `line` | the claim manifest (`scripts/kb-eval/extract-judge-claims.mjs` output) |
+| `claim` | the claim manifest (the verbatim claim text that was judged) |
+| `disposition` | mapped from `judge_verdict` (see the vocabulary mapping below) |
+
+## The flag record
+
+A flag record is the union of the judge result and the four augmented fields:
+
+```
+{
+  "id":            "<claim id>",
+  "judge_verdict": "not_grounded" | "source_silent",   // 'grounded' is never flagged
+  "rule":          "R1".."R8" | "",
+  "evidence_url":  "<url the judge actually used>",
+  "evidence_quote":"<verbatim quote or empty>",
+  "reason":        "<one sentence: what the source said vs the claim>",
+  "file":          "skills/.../x.md",
+  "line":          <number>,
+  "claim":         "<verbatim claim text>",
+  "disposition":   "outdated" | "wrong" | "unsourced"   // R11 fix disposition
+}
+```
+
+In the ledger (R6 Step 4), a flagged file is a manifest record with
+`per_file_verdict: "flagged"` and one `flags[]` entry per non-grounded claim —
+the structural mirror of `spor0-fix-manifest.json`'s "fix-record with
+`applied:false`". A file is `flagged` if **any** judgeable claim is non-grounded
+(the born-verified rule is AND: `pass` requires EVERY claim grounded).
+
+## The two vocabularies + the mapping
+
+There are two distinct enumerations, and conflating them is the trap this spec
+exists to prevent:
+
+1. **`judge_verdict`** — the judge's per-claim output (v3.1 prompt):
+   - `grounded` — the source confirms the claim → never flagged.
+   - `not_grounded` — the source contradicts / does not support the claim.
+   - `source_silent` — the source does not address the claim at all.
+
+2. **`disposition`** — the R11 fix disposition, the correctness vocabulary from
+   `scripts/kb-eval/lib/base-rate.mjs` (`VERDICTS`): `correct`, `outdated`,
+   `wrong`, `unsourced`. Its `ERROR_VERDICTS` subset — `outdated` and `wrong` —
+   are the only ones R11 treats as **fix targets**. `unsourced` is recorded but
+   is not, on its own, a content error (no MS source confirms it either way).
+
+**Mapping** (`judge_verdict` → `disposition`):
+
+| `judge_verdict` | `disposition` | R11 fix target? |
+|-----------------|---------------|-----------------|
+| `grounded` | `correct` | no (never flagged) |
+| `not_grounded` | `outdated` or `wrong` | **yes** — the human assigns which at R11 |
+| `source_silent` | `unsourced` | no (flagged, but not a fix target) |
+
+`not_grounded → {outdated, wrong}` is deliberately a one-to-two mapping: the
+judge establishes the claim is not grounded; whether it is stale-but-once-true
+(`outdated`) or never-true (`wrong`) is a human call at R11, re-verified against
+the live source (verification duty). The pass never auto-fixes — every flag is
+human-confirmed in R11, so a judge false-positive becomes a human review, never
+silent corruption of a public file.

docs/r11-tiered-fix-design.md

@@ -0,0 +1,333 @@
+# R11 execution design — tiered fixes over an already-evidenced flag population
+
+**How the R11 fix step consumes the judge-pass flags. Extends
+`docs/r11-flag-format-2026-07.md` (the record contract) with the execution
+contract: what the fix operation is per flag, what is machine-provable, what
+requires human judgement, and what may never be automated.**
+
+Status: design spec. Written 2026-08-03 against a ledger snapshot of **222
+records / 902 flags** (`scripts/kb-eval/data/judge-pass-manifest.json`). The
+population is **not yet complete** — batch R7.5 stood at 30 of 51 files — so
+every count below is a snapshot, not a final figure. The design does not depend
+on the exact counts; the classifier re-derives them at run time.
+
+---
+
+## 1. The measurement this design is built on
+
+**All 712 `not_grounded` flags carry a non-empty verbatim `evidence_quote`.**
+712 of 712, measured. Every flag also carries the `evidence_url` the judge
+actually fetched, the rule that fired, and a one-sentence `reason` stating what
+the source said versus what the claim said.
+
+The consequence is the whole point of this document: **R11 does not start from
+zero evidence.** The expensive half — locating the authoritative page, reading
+it, and extracting the passage that decides the claim — was already paid for by
+the judge pass. A fix step designed as "fetch the source, confirm, correct"
+re-does work that is already on disk.
+
+What actually remains per flag is narrower:
+
+1. is the quote still current (freshness, §7), and
+2. what should the sentence say instead (§3).
+
+## 2. Measured shape of the flag population
+
+| Measurement | Value |
+|---|---|
+| Flags total | 902 |
+| `not_grounded` (fix targets per flag-format spec) | 712 |
+| `source_silent` (recorded, not a fix target) | 190 |
+| Flags carrying a verbatim `evidence_quote` | **712 / 712** |
+| Distinct `evidence_url` across the 712 | **540** |
+| Files carrying at least one `not_grounded` flag | 199 |
+| Files with 1 flag | 45 |
+| Files with 2–6 flags | 133 (489 flags) |
+| Files with ≥7 flags | 21 (**178 flags — 25 % of the volume in 10 % of the files**) |
+
+Rule distribution over the 712: R8 339 · R2 176 · (no rule) 72 · R4 41 · R3 40 ·
+R7 28 · R1 16.
+
+**540 distinct source URLs for 712 flags** is the number that forecloses the
+obvious optimisation: there is no batching win hiding in shared sources. The
+largest cluster is 12 flags on one page. This is ~700 separate facts, and the
+work is irreducibly per-claim.
+
+## 3. Three fix operations — the partition is by operation, not by rule
+
+The tiering is defined by **what the fix does to the file**, because that is what
+determines whether a machine can prove it and whether a human must decide it.
+Rule codes are a signal, not the partition.
+
+| Op | Fix operation | Provable? | Who decides |
+|---|---|---|---|
+| **O1** | **Value swap** — the claim states X, the cited source states Y; replace the token. | **Yes** (§4) | Machine proposes, human reviews a diff list |
+| **O2** | **Subtraction** — remove or generalise the specificity the source does not support. Covers: source-silent claims, absent entities (retired SKUs/models/services), and multi-part claims where the failing sub-assertion can be dropped while the grounded part survives. | Partly — the *invariant* is that no new fact is introduced | Human ratifies the policy once (§5), then reviews proposals |
+| **O3** | **Rewrite** — the corrected sentence requires a judgement about what to assert. | No | Human, per claim |
+
+**Do not read the §2 rule counts as tier sizes.** They overlap: of the 202 flags
+whose claim *and* quote contain a numeric token — the naive O1 signal — **94 are
+R8 multi-part claims**, which are not clean swaps. Heuristics over this
+population give upper bounds in several directions at once, never a partition.
+
+**The classifier fails closed to O3.** If it cannot prove an item is O1 or O2, the
+item is O3 and a human sees it. A misrouted O3 costs one review; a misrouted O1
+ships a wrong edit to a public file.
+
+R8 deserves a specific note, because it is the largest rule class and it is *not*
+automatically the most expensive one: the judge's `reason` names **which**
+sub-assertion failed. Where the grounded part stands on its own, the fix is O2
+(drop the unsupported part), not O3 (rewrite the sentence). ~~How much of R8 falls
+that way is unknown and is a primary pilot measurement (§10).~~
+
+**MEASURED 2026-08-03 — `docs/r11-pilot-results.md` §9. It falls that way for a
+minority.** Over the 46 pilot flags with the O2 shape (R8 ∧ `MULTI_PART_CLAIM`):
+17 O2 candidates, 29 O3, and **all 29 are blocked by §5 condition 3** — the
+source supplies a corrected value, so the fix is a swap or a rewrite and
+subtraction would destroy true information. Only 2 of the 46 clear both
+human-judged conditions affirmatively. The paragraph above is not wrong, but the
+case it describes is the exception in R8, not the rule.
+
+## 4. The O1 invariant (what makes a value swap provable)
+
+An O1 proposal is only valid if, after the edit:
+
+1. the new value appears **verbatim inside the cited `evidence_quote`**, and
+2. the rest of the line is **byte-identical** to before, and
+3. exactly one line in the file changed.
+
+A driver that cannot establish all three for an item **aborts before writing** and
+routes the item to O3. This is the same discipline already proven in the
+header-backfill drivers (frozen manifest, hard per-file invariant, abort before
+write, idempotent re-run, `atomicWriteSync`) — see `scripts/kb-update/backfill-*.mjs`.
+
+~~This invariant is deliberately stronger than human review at scale.~~
+**FALSIFIED 2026-08-03 — see `docs/r11-pilot-results.md` §2.** Run exactly as
+written it admitted 6 swaps of which **4 were wrong edits**. Conditions 1–3
+constrain where the value *came from* and what the edit *looks like*, and nothing
+about whether the two tokens denote the same quantity. Conditions 1–3 are
+necessary; they are not sufficient.
+
+### 4a. Condition 4 — context correspondence (added 2026-08-03)
+
+4. the token must sit under **the same label, or the same trailing unit, on both
+   sides** (`contextCorresponds()` in `scripts/kb-eval/lib/fix-op.mjs`).
+
+Deliberately lexical, with no translation table beyond §4b: a swap is therefore
+provable essentially only where the context is language-neutral — a URL, a code
+sample, a parameter key.
+
+**Condition 5 — the applied class is `iso_date` only** (operator decision,
+2026-08-03). Condition 4 is still not sufficient: a matching identifier *prefix*
+(`AI-`, `gpt-`, `Agent `) satisfies it while the digit is part of a **name**
+rather than a quantity, which produced `AI-900` → `AI-901`, `gpt-4o` →
+`gpt-5.1o` (twice) and a Java-agent downgrade. Hand-verification over the whole
+population: **`iso_date` 9/9 correct, `number` and `version` 0/6**. A driver may
+apply `iso_date` proposals and **must never apply `number` or `version` ones**.
+The classifier keeps reporting all admitted types — that is the measurement — and
+marks the applicable set as `o1_recommended`.
+
+### 4b. The ratified status-synonym table (operator decision, 2026-08-03)
+
+`STATUS_SYNONYM` — 15 pilot flags, **54 corpus-wide** — is the class where the
+corpus writes `**Preview**` / `**GA**` while the source writes *"generally
+available"*. A narrow, **closed** equivalence table is ratified:
+
+| Corpus-side label | Source-side phrasing (must appear verbatim in `evidence_quote`) |
+|---|---|
+| `GA` | `generally available`, `general availability` |
+| `Preview`, `Public Preview` | `public preview`, `preview` |
+| `Private Preview` | `private preview` |
+| `Deprecated`, `Utfaset` | `deprecated`, `retired` |
+
+Three constraints, because this is the **one** place where the value written into
+the file does not itself appear verbatim in the quote:
+
+- The table is **closed**. Any pair not listed aborts to O3; it is never extended
+  by inference at run time.
+- The file-side token must be a **complete lifecycle label** (a whole table cell
+  or emphasised token), never a substring of a longer sentence.
+- The written value is the **corpus-side** equivalent with the file's own markup
+  preserved (`**Preview**` → `**GA**`), never the English phrase pasted in.
+
+**IMPLEMENTED 2026-08-03** in `classifyStatusSynonym()` / `fileStatusLabel()` /
+`sourceStatusRows()` (`scripts/kb-eval/lib/fix-op.mjs`), 19 tests. Two
+implementation decisions the ratified text left open, both resolved towards
+failing closed:
+
+- **The status locator is LINE-scoped**, not block-scoped like the numeric one.
+  Lifecycle vocabulary repeats down every column of a status table, so a block
+  window is ambiguous by construction; all 15 pilot flags in this class point at
+  the row that carries the claim.
+- **A quote asserting two different rows aborts** (`SOURCE_STATUS_AMBIGUOUS`), and
+  a row with two corpus-side labels writes the **first** — the least specific one,
+  so a source saying only "preview" can never produce "Public Preview".
+
+Aborts keep the `STATUS_SYNONYM` code and name their cause in `detail.reason`, so
+the §10 abort taxonomy stays comparable across the implementation.
+
+**Measured: 15 pilot / 54 corpus-wide flags → 5 and 8 proven; 5 of the 8 are
+correct** (`docs/r11-pilot-results.md` §8 + appendix B). The three defects are one
+family: §4b binds the table, the completeness of the file label and the written
+value, and **nothing about whether the source phrasing refers to the row's own
+subject** — provenance without referent, the same defect that falsified §4. The
+class is therefore **review-grade, not apply-grade**: `status` is absent from
+`o1_recommended` and no driver applies it.
+
+**Open operator decision — a referent condition for §4b.** Two candidates are
+costed over the eight in `r11-pilot-results.md` §8; both kill wrong proposals and
+no correct one, and neither is implemented, because extending a table ratified as
+*closed* is an operator decision, exactly as condition 5 was in §4a.
+
+## 5. The O2 policy — RATIFIED 2026-08-03, with a remainder check
+
+O2 fixes by **subtraction**: the unsupported specificity is removed or
+generalised rather than replaced with a researched value.
+
+**Ratified by the operator on 2026-08-03, with one condition: the remainder
+check.** Subtraction is not admitted as a blanket rule, because the pilot found
+two ways it fails (`docs/r11-pilot-results.md` §5):
+
+- It can leave a **misleading remainder**. Removing `er GA (juni 2025)` from a
+  claim about a tool the source calls *deprecated* leaves that tool standing in a
+  list of available ones. Strictly less asserted, still misleading.
+- It can **destroy true information**. Dropping `prebuilt-check` from a model list
+  removes a model that exists — its ID is `prebuilt-check.us`, so the correct fix
+  is a swap.
+
+**An O2 proposal is valid only if all three hold, and a human confirms them:**
+
+1. the edited sentence asserts **strictly less** than before;
+2. the **remainder carries no false or misleading standing implication** — read as
+   a reader would read it, not as a logician would;
+3. nothing the source **confirms** is removed. Where the source supports a
+   corrected value, the fix is O1 or O3, never subtraction.
+
+Conditions 2 and 3 require a human to read the remainder. O2 is therefore
+**cheaper than O3 — no fact-finding — but not mechanical**, and the §10
+throughput assumption should be re-measured against that.
+
+- It requires **no new fact-finding**, which is what makes it cheap.
+- It **reduces information density**. That is the real cost, and it is an
+  operator decision, not an engineering one.
+
+The position this design recommends: a knowledge base that says less and says
+nothing false is worth more than one carrying stale precision. The corpus is
+publicly distributed; an incorrect specific number is a worse failure than an
+honest general statement.
+
+Ratifying O2 also resolves the standing `source_silent` question as **one class
+decision** instead of 190 individual ones. ~~Until it is ratified, every O2
+candidate falls to O3.~~ Ratified — O2 is in use, subject to the remainder check
+above. **Not implemented in the classifier, and now measured to be the right
+call:** the classifier still routes every non-O1 item to O3, because O2 candidacy
+turns on the judge's prose `reason`. The prose classification was run separately
+(`docs/r11-pilot-results.md` §9) and found that condition 3 forecloses **every**
+non-candidate in the class — a mechanical O2 driver would therefore have proposed
+deletions where the source hands over a corrected value, which is precisely the
+F2 failure. O2 output is a human review list, like §4b's.
+
+## 6. What stays human, permanently
+
+- **Never auto-fix.** No fix reaches a file without human confirmation of the
+  class (O1/O2) or the item (O3). A judge false positive must become a human
+  review, never silent corruption of a public file.
+- **Subagents never write.** Proposal generation is read-only fan-out; all
+  writes happen in one place (§8).
+- **O3 is not a backlog to automate later.** It is the class where the corrected
+  assertion is a judgement call, and it is the reason the loop reaches ~100 % fix
+  precision on top of a fallible judge.
+
+## 7. Evidence freshness
+
+Each `evidence_quote` is current as of the judge's fetch date, not the fix date.
+Before any file is touched, the evidence base is refreshed by **re-fetching per
+distinct URL — 540, not 712** — as read-only fan-out. A refreshed quote that no
+longer supports the flag re-routes the item (possibly closing it as no longer an
+error). This preserves the verification duty — fresh confirmation before a public
+file changes — without paying for 712 separate fetches.
+
+## 8. Concurrency: one writer, many readers
+
+R11 phases that are machine-bound (evidence refresh, proposal generation) may run
+across concurrent sessions. The corpus and the ledger may not.
+
+**Single-writer state** — never written by more than one session:
+`scripts/kb-eval/data/judge-pass-manifest.json`, the corpus files themselves, and
+the repo's state file.
+
+**Protocol:**
+
+- Worker sessions write **only** disjointly-named artefacts to a local, untracked
+  working directory (one file per unit of work). They do not ingest, stamp, or
+  commit.
+- One integrator session ingests serially, stamps, and commits.
+- If two sessions must write corpus files concurrently, shard **by file, never by
+  claim**, one git worktree per shard. Disjoint file sets merge without conflict;
+  the ledger is still written only by the integrator, after merge.
+
+Git worktrees share the main `.git` directory, so the Layer B `pre-commit` scan
+symlink applies inside every worktree — verified 2026-08-03 by creating a
+worktree and resolving `git rev-parse --git-common-dir` plus the hook target.
+The security gate does not weaken under sharding.
+
+The reason this protocol is explicit: whole-tree backup/restore in the write
+drivers previously caused silent data loss across concurrent sessions (closed in
+the write-safety hardening pass — scoped restore + atomic writes). Sharded writes
+without a single-writer rule would reintroduce that class through a different door.
+
+## 9. No full re-judge after fixing
+
+A fixed file does **not** require a fresh judge pass over all of its claims.
+
+- Claims already judged `grounded` keep that verdict; the fix did not touch them.
+- A fixed claim's evidence is the O1 invariant (§4) or the human confirmation
+  (§5–6), recorded with the fix.
+- The programme's end-proof is a **fresh blind gold sample** measured after the
+  fixes, not a re-run of the corpus pass.
+
+This is stated explicitly because assuming otherwise would silently add a second
+full corpus pass to the plan.
+
+## 10. Pilot and acceptance criterion
+
+Before any scaling, run the classifier and the O1 driver against the **24 files
+carrying ≥7 `not_grounded` flags (202 flags)** — a quarter of the volume in a
+tenth of the files, and the densest available sample.
+
+> Recount 2026-08-03 after R7.5 completed (ledger 222 → 243 records). The rule is
+> unchanged — densest ≥7 sample — only the count moved: 21 files / 178 flags was
+> measured against the 222-record ledger, before the last 21 R7.5 files were
+> ingested. Three files entered the sample (`semantic-caching-patterns.md`,
+> `small-language-models-economics.md`, `vector-storage-cost-optimization.md`).
+> The threshold counts `not_grounded` only, not `source_silent`; on all-flags it
+> would be 39 files / 352.
+
+Measure and record:
+
+1. the actual O1 / O2 / O3 split (this design's central unknown);
+2. how much of R8 resolves as O2 rather than O3 (§3);
+3. the O1 driver's abort rate — items it could not prove, which must land in O3;
+4. review throughput per operation class, measured rather than assumed.
+
+Scale to the remaining files only on measured numbers. If the split is materially
+worse than assumed, that is known after one session rather than after ten.
+
+> **RUN 2026-08-03 — results in `docs/r11-pilot-results.md`.** The split is
+> materially worse than assumed: **9 provable, correct value swaps in the whole
+> 776-flag `not_grounded` population (1.2 %)**, all of them `api-version` bumps.
+> The pilot also falsifies §4 as written — run exactly as specified it admitted 6
+> swaps of which **4 were wrong edits** (unit crossing, metric crossing, two
+> mutilated identifiers), so the invariant is *not* "stronger than human review at
+> scale". A context-correspondence condition was added; read §4 together with the
+> results doc, not on its own. §5 (O2) and the `STATUS_SYNONYM` class are the open
+> operator decisions, and they now carry the whole programme's leverage.
+
+## 11. Out of scope
+
+- **Rebuild instead of repair.** Regenerating flagged files from source rather
+  than editing them is a settled decision: the corpus is repaired, not rebuilt.
+  Reopening it is an operator call, not a design choice made here.
+- **Auto-fix in any form** (§6).
+- **Price and other unsourced claims** beyond the O2 class decision — these
+  remain operator-gated as a separate matter.

docs/ref-kb-audit-2026-06.md

@@ -0,0 +1,37 @@
+# Reference-KB audit — verifisert ground truth (2026-06-26)
+
+_Read-only audit av de 389 ref-filene under `skills/<skill>/references/**/*.md`. Reproduserbar via `python3 scripts/kb-eval/ref-file-audit.py`. Utløst av spørsmålet «måler vi kvaliteten på ref-filene, og brukes de best mulig?». Beslutningsnotatet som velger retning lever separat (se nederst)._
+
+## Bakgrunn
+Skill-kvalitetsscoringen (Spor D, `scripts/kb-eval/`) scorer SKILL.md-forfatterkvalitet + ref-filenes STRUKTUR/hygiene — ikke substansiell innholdskorrekthet mot MS Learn. KB-refresh (`scripts/kb-update/`) flagger staleness, men gir ingen score. Gapet — «stemmer ref-innholdet mot MS Learn i dag» — måles ikke. Denne auditen kartla ref-filenes faktiske tilstand før vi velger hvordan gapet skal lukkes.
+
+## Selvkorreksjoner (premiss-verifisering fanget to artefakter i en tidligere kjøring)
+- **«220 orphans» → ekte: 0.** Den første heuristikken testet kun om filnavnet var navngitt i en hub. Men 220 filer nås via **mappe-referanse** (progressive disclosure — K5 named-ratio-mål er bare 0,2). Folder-bevisst telling gir 0 ekte orphans. KB-en bærer ingen død vekt.
+- **«136 datoløse» → ekte: 6.** Heuristikken krevde full `YYYY-MM-DD`. 130 filer har bevisst **måned-presisjon** (`YYYY-MM`), som er konvensjonen `report-changes.mjs` forutsetter. Kun 6 er ekte datoløse.
+
+## Verifiserte funn
+
+| Dimensjon | Tall | Vurdering |
+|-----------|------|-----------|
+| **Inventar** | 389 filer: advisor 62, engineering 153, governance 78, infrastructure 34, security 62 | — |
+| **Størrelse** | median 481 linjer, snitt 507, **183/389 >500 linjer**, største 1265 (`adr-template.md`); kun 2 filer ≤100 | KB-en er nesten utelukkende store filer. Granularitets-spørsmål (se notat). |
+| **Dato** | 253 dag-presise · 130 måned-presise · **6 ekte datoløse** | De 6 (4 er AI Act-filer) bør stemples — kort, høyverdi fiks. |
+| **Reachability** | 169 navngitt · 220 via mappe · **0 ekte orphans** | Ingen død vekt. Mappe-referanse er den dominerende lastemekanismen. |
+| **Kilde-URI** | **83 filer (21 %) har ingen MS Learn/docs-URL** | Noen legitimt kildeløse (maler/metodikk); andre gjør MS-påstander uten sporbar kilde → ikke auto-verifiserbare. |
+| **Metadata** | **34 distinkte prosa-header-nøkler**, 0 YAML-frontmatter (`Category` ×322 vs `Kategori` ×42; `Last updated` vs `Sist oppdatert` vs `Dato` vs `Oppdatert`) | Fragmentert → skjør detektor, ingen maskinlesbar kilde-URI for en korrekthets-judge. |
+| **Topologi** | flatt tre; N3 forbyr ref→ref-lenker; kun 2/389 har .md-kryss-lenke | Bevisst — progressive disclosure, ikke en graf. |
+| **TOC** | 384/389 store filer uten TOC (N4) | Reell, men lavvekt — skills står på 91–96 likevel. Polish. |
+
+## Eksisterende Spor D-scorer (kontekst)
+advisor 91 · engineering 96 · governance 96 · infrastructure 96 · security 96. **Null under mål (90).** Struktur/forfatterkvalitet er altså ikke problemet — innholdskorrekthet er den umålte aksen.
+
+## De 6 ekte datoløse (quick-fix-kandidater)
+- `ms-ai-advisor/references/architecture/decision-trees.md`
+- `ms-ai-governance/references/monitoring-observability/anomaly-detection-ai-systems.md`
+- `ms-ai-governance/references/responsible-ai/ai-act-classification-methodology.md`
+- `ms-ai-governance/references/responsible-ai/ai-act-deployer-obligations.md`
+- `ms-ai-governance/references/responsible-ai/ai-act-fria-template.md`
+- `ms-ai-governance/references/responsible-ai/ai-act-provider-obligations.md`
+
+## Neste steg
+Et faktabasert, best-practice-forankret beslutningsnotat (5 akser: struktur/størrelse · innhold/korrekthet · kvalitetsmåling · MS Learn-fetch-dekning · metadata-substrat) avgjør retning før noen av de 389 filene endres. Se `docs/ref-kb-direction-note-2026-06.md` (genereres). Bakgrunn for gapet: `docs/kb-refresh-backlog-2026-06.md` («Separate spor»).

docs/ref-kb-correctness-program-2026-06.md

@@ -0,0 +1,156 @@
+# Program — Reference-fil-korrekthet mot nær-100 % + mekanisme som holder den der
+
+_Opprettet 2026-06-26. Operatør-mandat (eksakt): «Alle reference-filene må til enhver tid være 100 % til å stole på, og du må lage en mekanisme som sikrer dette.» Full kvalitetsoffensiv godkjent; Spor 0 først, så grønt lys for skala (Spor 1–3). Dokumenteres skikkelig her; Voyage (`/trekplan` / `/trekexecute`) er foreslått motor for skala-fasen._
+
+_Forutsetning: S1 de-risket judgen (v1 FAIL → v2 målrettet iterasjon GATE PASS, recall 84,2 % / presisjon 84,2 % — **historiske S1-tall**; judgen er senere herdet og adoptert som **v3.1 med P 100 % / R 100 %** på G5b-korrigert gull, se §8 G1/G2). Grunnlag: `docs/ref-kb-workflow-plan-2026-06.md` (Fase 0–4 + roadmap), `docs/ref-kb-audit-2026-06.md`, `docs/ref-kb-direction-note-2026-06.md`._
+
+---
+
+## 1. Ærlig ramme (premisser programmet bygger på — ikke re-litiger)
+
+1. **«100 % til enhver tid» er en *prosess*-garanti, ikke en *øyeblikks*-garanti.** Microsoft endrer kildene kontinuerlig; ingen statisk fil kan være korrekt i evig tid. Den oppnåelige garantien er: *intet upekt/uverifisert innhold shipper, og enhver drift fanges innen én refresh-syklus.* Det er den operasjonelle definisjonen av «100 % til å stole på» (§4).
+2. **De 38 kjente feilene er et utvalg, ikke fasiten.** Målt på 255 volatile påstander; base-rate 13,4 % ⇒ det fulle korpuset (~306 kildebelagte filer) har statistisk hundrevis av samme feilklasse vi ennå ikke har sett. Spor 0 fikser utvalget; Spor 1 avdekker resten korpus-vidt.
+3. **Taket på én judge-runde er ~84 % recall.** Judgen er en høystakk-reduserer, ikke siste autoritet. Nær-100 % *fiks*-korrekthet oppnås av loopen (judge flagger → menneske bekrefter mot kilde → fiks), ikke av judgen alene. **Aldri auto-fiks.**
+4. **Pris/unsourced er maskin-uverifiserbar** (74 % av pris; JS-rendrede Azure-sider). Disse merkes eksplisitt «ikke maskinverifiserbar» og forblir operatør-gated. Nær-100 %-målet gjelder den maskin-verifiserbare populasjonen (`sku/version/tpm/status/region/taxonomy`).
+
+## 2. Mål (suksesskriterium — måles mot brukerverdi)
+
+En bruker som chatter med pluginen får **korrekte, kilde-belagte MS-svar**, og mekanismen **holder det slik automatisk**: (a) flagget feilrate på maskin-verifiserbar populasjon < ~2 % målt på et *ferskt* gull-utvalg; (b) ingen `reference`-fil shipper uten kilde + verifiseringsdato; (c) drift fanges innen én KB-refresh-syklus; (d) pris/unsourced er ærlig merket og operatør-gated.
+
+## 3. De fire sporene
+
+### Spor 0 — Fiks de kjente 38 nå (judge-uavhengig, trygt) — STARTET
+Fiks-manifest: `scripts/kb-eval/data/spor0-fix-manifest.json` (38 fikser, 25 filer, deterministisk fra gull-settet). Hver fiks har `reverify_required: true`.
+- **Protokoll per fiks (ufravikelig):** (1) re-hent kilden (`microsoft_docs_fetch` på `source`) og bekreft korrekt verdi *live* (gull-`notes` er subagent-produsert — verifiseringsplikten krever fersk bekreftelse FØR en offentlig fil endres); (2) lokaliser den eksakte foreldede strengen i fila; (3) erstatt med kilde-bekreftet verdi; (4) sett `fixed: true` + `verified`-stempel.
+- **Rydd tverteklyngene:** AI Search storage-tall er utdaterte *og* selvmotsigende på tvers av `rag-cost-optimization.md`, `embedding-models-selection.md`, `rag-query-cost-reduction.md`, `vector-storage-cost-optimization.md` — reconcile til én kilde-sann verdi. Samme for «Default/Enterprise → Quota Tiers»-omtalen (4 filer).
+- **Kvalitets-disiplin:** kjøres i en *fokusert* sesjon (ikke som hale på en mettet kontekst) — offentlige filer for hele Norge tåler ikke hastverk.
+- **Verifisering:** re-kjør judge på de 38 → alle `grounded`; storage-tall konsistente på tvers; suite grønn.
+
+### Spor 1 — Avdekk *hele* feilsettet korpus-vidt (S3-forutsetning + skalering)
+- **Authority-backfill:** hver kildebelagt fil → sin autoritets-URL (recon: kun 3 URL-er har `authority_source` i dag — re-verifiseres mot `url-registry.json` FØR start).
+- **Full frontmatter** (Fase 2 full): `type` / `source` / `verified` / `verified_by` per fil (OKF-kompatibel form).
+- **Korpus-pass:** kjør v2-judgen over *alle* verifiserbare påstander i alle ~306 filer (ikke bare 255-utvalget). Output: komplett flagg-liste → mater Spor 0-protokollen korpus-vidt.
+- **Kostnad (ærlig):** ~2700 ikke-batchbare `microsoft_docs_fetch` per full-pass — IKKE «$20–40 Batch». Flersesjons.
+- **Verifisering:** hver ikke-advisor kildebelagt fil har `authority_source`; frontmatter validerer; flagg-lista persistert.
+
+### Spor 2 — Press pålitelighet mot 100 % (hardningen)
+- **(a) Ensemble for recall:** union av N *diverse* judge-linser (f.eks. eksakt-verdi / strukturell / status-fokus). Mål single vs ensemble på gull-settet FØR adopsjon (operatørens «bygg begge og mål»). Union hever recall (mål: > 84,2 %), senker presisjon — tapet absorberes av menneske-i-loopen (c). Adopter kun hvis gull-målt forbedring.
+- **(b) Gull-rekonsiliering:** ✅ **FERDIG (2026-06-30)** — alle 12 uenigheter løst mot live kilde. **4 gull-feil rettet** + 1 note-fiks; **8 judge-feil** dokumentert som kalibreringsmål. Herdet fasit: presisjon 84,2 %→**92,1 %**, recall 84,2 %→**87,5 %** (judgen var bedre enn rå-bakeoffen viste — fasiten var kontaminert). Nedre-grense-policy vedtatt (grov understatement >~2× = feil). **0 uløste uenigheter.** Full logg: `ref-kb-gold-reconciliation-2026-06.md`; herdet rapport: `judge-bakeoff-report-v2-reconciled.{json,md}` (frozen v2 beholdt som gate-artefakt).
+- **(c) Menneske-i-loopen fiks-protokoll:** judge flagger → operatør/ekspert bekrefter mot kilde → fiks + `verified`-bump. Garanterer ~100 % *fiks*-presisjon selv ved 84 % *judge*-presisjon. **Aldri auto-fiks.**
+- **Verifisering:** ensemble P/R ≥ single på gull; 0 uløste judge-vs-gull-uenigheter; dokumentert at ingen fiks shippet uten menneske-bekreftelse.
+
+### Spor 3 — Mekanismen som holder det nær-100 % (Fase 4) — SE §4
+Create-time-guard + kadens-judge + rapporterende gulv + frontmatter-kontrakt. Detaljert under, fordi dette ER «mekanismen som sikrer dette».
+
+## 4. MEKANISMEN — «100 % til å stole på, til enhver tid» (operatørens kjernekrav)
+
+> **Status (2026-06-29):** Port 1 ✅ · Port 2 ✅ (`5a0ba1f`) · **Port 3 ✅ KOMPLETT** — inkrementell stale-since-verified (`fea5df5`), rapporterende gulv / SessionStart KB-tillit-signal (`08e7e72`), CT5 sourcedness som erstatter K8 (`75ee9ec`), og periodisk full-pass worklist (P3d, `a1d72fa`). **P3d-designvalg avklart: arbeidsliste** (operatør kickstarter judging separat — §5 «ikke auto-lansert», §4c «aldri auto-fiks»; den ærlige ~2700-fetch/flersesjons-kosten forekluderer inline på korpus-skala). `report-full-pass-worklist.mjs` er lastmod-UAVHENGIG (gater på Port 1-kontrakt `type:reference`+`source` + cadence-alder på `verified`, default 90 d), så den fanger drift-klassen inkrementell bommer (staleness-recall 0/40). Ekte kjøring: 389 ref-filer alle `unmigrated` ⇒ **dormant til Spor 1-migrering** backfiller `source`/`verified`. **Mekanismen (Spor 3) er nå komplett.**
+
+Garantien er en **invariant håndhevet av tre porter**, ikke et engangs-opprydding:
+
+> **Invariant:** Hver maskin-verifiserbar påstand i en `reference`-fil er bekreftet mot sin siterte kilde innen siste `<kadens>`-vindu; intet `reference`-innhold shipper uten `source` + `verified`; drift flagges innen én refresh-syklus.
+
+**Port 1 — Frontmatter-kontrakt (tilstanden).** Hver fil bærer:
+`type` (`reference|template|methodology|regulatory`) · `source` (autoritets-URL) · `verified` (dato sist bekreftet korrekt mot kilde) · `verified_by` (`judge-vN` / `human`). Template/methodology/regulatory er unntatt korrekthets-scope (skal ikke ha MS-`source`).
+
+**Port 2 — Create-time-guard (innløpet).** `scripts/kb-update/lib/transform.mjs` (`buildKbHeader`/`validateKbFile`) + `generate-skills`:
+- Nekter å emitte en `reference`-fil uten `source`.
+- Nytt/regenerert innhold kjøres gjennom judgen FØR commit → *født verifisert* (`verified=<i dag>`, `verified_by=judge-vN`). Ellers re-introduserer neste KB-update driften (å øse en lekk båt).
+- **Verifisering:** generator-test — `reference`-output har `source`+`verified`; mangler `source` ⇒ hard feil.
+
+**Port 3 — Kadens-judge (vedlikeholdet).** På KB-refresh-kadens (IKKE SessionStart — for dyrt):
+- *Inkrementell:* re-judge filer hvis `source` sitemap_lastmod > `verified` (akkurat det staleness-loopen ser — billig, fanger lastmod-synlig drift).
+- *Periodisk full-pass:* judge over hele korpuset (fanger den drift-klassen staleness bommer på — base-rate viste staleness-recall 0/40).
+- Flagg → menneske-bekreft → fiks → `verified`-bump. **Rapporterende gulv** (Spor D peker: «N filer eldre enn X siden verified» / «M ubekreftede flagg»), ikke hard SessionStart-gate (unngå alarm-tretthet på et 84 %-signal).
+- **Verifisering:** SessionStart surfacer trust-ferskhets-signal uten falske alarmer; operatør-waiver-sti finnes; CT5 (sourcedness) ERSTATTER K8s rolle.
+
+**Hvorfor dette gir «til enhver tid»:** du kan ikke garantere null drift i et øyeblikk (MS endrer ting når som helst), men du garanterer at (a) intet uverifisert shipper (Port 2), (b) tilstanden er eksplisitt og sporbar (Port 1), (c) drift fanges innen én syklus (Port 3). Det er den sterkeste ærlige garantien — og den er buildbar.
+
+## 5. Voyage-bruk (operatør: «kanskje bruke Voyage aktivt»)
+
+- **Skala-fasen (Spor 1–3) er et lærebok-flersesjons-implementeringsløp** → `/trekplan` med dette dokumentet som brief gir en revidert, adversarielt gjennomgått implementeringsplan; `/trekexecute` kjører den på tvers av sesjoner med failure-recovery.
+- **Spor 1 korpus-pass** kan dra nytte av Voyage-orkestrering (parallelle judge-agenter per fil, schema-validert output).
+- **Spor 0** er lite nok til direkte utførelse (manifest finnes) — trenger ikke Voyage.
+- **Ikke auto-lansert:** Voyage er tung maskineri; operatør kickstarter (`/trekbrief` el. `/trekplan --brief <dette docet>`). Anbefaling: kjør Spor 0 først, så `/trekplan` for Spor 1–3.
+
+## 6. Sekvensering + status (2026-06-26; à jour per §8 2026-07-03)
+
+| Spor | Status | Neste konkrete handling |
+|---|---|---|
+| S1 (de-risk) | ✅ FULLFØRT | — (v2 GATE PASS; historisk — se §8 G1 for adoptert v3.1) |
+| Spor 0 (fiks 38) | 🟡 STARTET (manifest klart) | Kjøres i fokusert sesjon m/ kilde-reverifisering ETTER substrat-migreringen (roadmap R5, `docs/plugin-roadmap-2026-07.md`) |
+| Spor 1 (korpus-skala) | ⏳ plan klar (trekplan v1.7, adversarielt reviewet) | Eksekver substrat-migreringen (roadmap R1–R4); korpus-judge-pass planlegges i R6, kjøres R7–R10 |
+| Spor 2 (hardning) | 🟢 FERDIG — 2a v3.1 MÅLT + ADOPTERT (P 100 / R 100, §8 G1 🟢) · 2b gull herdet + G5/G5b re-adjudert · 2c menneske-i-loop = stående disiplin | — (2c-protokollen brukes i flag→fiks-loopen, roadmap R11) |
+| Spor 3 (mekanisme) | 🟢 Port 1+2+3 ✅ KOMPLETT (inkr/gulv/CT5 + full-pass worklist P3d; v3.1 wired i Port 2+3, §8 G2 🟢) | Mekanismen ferdig; dormant til Spor 1-migreringen backfiller `source`/`verified` (roadmap R1–R4) |
+
+**Avhengigheter:** Spor 0 sekvensert etter substrat-migreringen (roadmap R5 — substratet i ro først). Spor 3 Port 2 (create-guard) MÅ på plass før/sammen med korpus-fiksing (ellers reverserer generatoren). Spor 2b (gull-rekonsiliering) ✅ ferdig 2026-06-30 — bunnsolid fasit på plass før Spor 1 skalerer målingen. Advisor-filer koordineres mot Cosmo-utfasing (S-Cosmo).
+
+**Avhengighet til skill-eval-rutinen (Spor b, eget spor — kanonisert 2026-06-30):** Spor 1 korpus-migrering MÅ kjøres FØR skill-eval-rutine-v2 kalibreres. Koblingen går én vei: migreringen muterer reference-filene (`skills/*/references/`) som skill-scoringen (`scripts/kb-eval/lib/skill-score.mjs` + `eval.mjs`) skanner, og **flytter skill-scoren** via to deterministiske dimensjoner — **CT5** (sourcedness) går `available:false`→aktiv når `**Type:**`/`**Source:**` stemples (`skill-score.mjs:114-122`), og **N4** (TOC) løftes ~0→~1 når `## Innhold`-TOC fødes inn på store filer (387/389 filer >100 linjer, kun 3 har TOC før migrering). Kalibrering av v2 før migrering måler en korpus-tilstand som straks endres ([[gold-freshness-can-invert-adoption]] generalisert). **Paritets-binding (test-håndhevet, ikke import):** `transform.mjs:55-56` holder `TOC_MIN_LINES=100`/`hasToc` i paritet med `eval.mjs.checkN4` via assertion i `test-transform`; skill-eval-v2 som vurderer å endre TOC-terskelen (BP100 vs SC300) MÅ bevare den pariteten, ellers brytes create-guardens fil-fødsel. Migreringen har INGEN runtime-avhengighet til skill-eval (judge/gull er helt separate stakker; metodikk flyter kun KB→skill — port bake-off-disiplinen). **Handlingsrekkefølge:** (a) Spor 1 → (b) re-score skill-eval ETTER migrering for å fange flyttet CT5+N4.
+
+## 7. Verifisering — slik beviser vi «nær-100 %» (nordstjerne)
+Etter Spor 0+1-fiksing: trekk et **NYTT, ferskt gull-utvalg** (friske påstander, ikke de vi fikset mot) og mål feilraten på maskin-verifiserbar populasjon → **mål < ~2 %**. Måling på den fikset-mot prøven er kontaminert; kun en fersk prøve beviser at korpuset faktisk er nær-100 %. Dette gull-utvalget blir også neste kalibreringssett for kadens-judgen.
+
+## 8. Mekanisme-gap-register (MÅ lukkes — stående disiplin)
+
+> **Invariant (operatør 2026-06-30, ufravikelig):** ingen funnet feilklasse forlates som *kun et funn*. Hvert gap mellom en oppdaget feilklasse og mekanismen som forhindrer gjentakelse MÅ føres her med en lukke-fase, og MÅ lukkes i en fremtidig sesjon. Å finne + dokumentere er ikke det samme som å lukke loopen. Når et nytt spor/en ny audit avdekker en feilklasse, legg den til her samme sesjon. Registeret er kanonisk; STATE peker hit.
+
+Status-nøkkel: 🔴 ikke startet · 🟡 pågår · 🟢 lukket.
+
+| # | Gap (mekanismen mangler) | Forhindrer feilklasse | Lukke-fase | Status | MÅ lukkes før |
+|---|---|---|---|---|---|
+| **G1** | Judgen er ikke herdet mot de 8 dokumenterte feilmodusene (`source_silent`-maskerer-fravær, legacy-rad-match, ramme-skifte-tall-overlever, nedre-grense-understatement, eksakt-streng-pedanteri, taksonomi-nyanse, kapabilitet-bom) | Judge-FN/FP påvist i Spor 2b (8 mål, se `ref-kb-gold-reconciliation-2026-06.md`) | **Spor 2a** — judge-prompt-v3, MÅLT single vs v3/ensemble på herdet gull; adopter kun ved målt forbedring (ad-hoc-patch overfitter + bytter P/R) | 🟢 **LUKKET 2026-06-30 — v3.1 MÅLT + ADOPTERT.** 45-veis fan-out kjørt (255 claims, 45 Opus-4.8-xhigh-subagenter, live MS Learn, én per fil) → deterministisk re-score mot G5b-korrigert gull: **v3.1 = P 100,0 % / R 100,0 % / 0 FP / 0 FN** (TP 39→42: fanget alle 3 gjenstående FN; TN 198 + FP 0 uendret). Forhåndsregistrert gate (hold P=100 ∧ løft R>92,9) **klarert** → **v3.1 adoptert som judge**. Se lukke-logg. | Spor 1 korpus-pass (judgen brukes i ~2700 fetches) |
+| **G2** | Herdet judge er ikke wired inn i Port 2 (born-verified create-guard) + Port 3 (kadens) — uten innplugging binder ikke hardningen mekanisk | Re-introdusert drift ved nye/regenererte filer + kadens-bom | Del av Spor 2a→3: bytt ut v2 med v3 i `transform.mjs`-judge-passet + kadens-runneren | 🟢 **LUKKET 2026-06-30 — v3.1 wired (TDD).** `JUDGE_VERSION 2 → '3.1'` (label-streng, provenance navner adoptert judge eksakt); prompt-/command-sites (`transform-prompt.md`, `kb-update.md` Port 2+Port 3, `generate-skills.md`) byttet `judge-claim-prompt-v2.md → -v3.1.md`. Suite 641/641. Se lukke-logg. | Spor 1 |
+| **G3** | Ingen deterministisk gull-intern-konsistens-vakt (`verdict=correct` mens egen `notes` sier «uverifisert/illustrativ») | Gull-labeling-feil av FP1-klassen (selvmotsigende annotasjon) | Liten TDD-lint over `gold-correctness-set.json` (+ kjøres på fremtidige gull-bygg) | 🟢 **lukket 2026-06-30** | Spor 1 (nytt gull bygges) / §7 friskt utvalg |
+| **G4** | Nedre-grense-policyen lever kun i prosa (denne dok + reconciliation-logg) — ikke kodet i judge-prompt ELLER `build-gold-set`-instruks | Re-introdusert nedre-grense-ambivalens i fremtidige gull-bygg + judge-kjøringer | Kod policyen inn i judge-prompt-v3 (G1) + build-gold-set-instruks | 🟢 **kodet 2026-06-30** (build-instruks + v3 R1); håndheving rir på G1/G2-adopsjon | Spor 1 / §7 friskt utvalg |
+| **G5** | Gull-fasiten kan aldre — ingen friskhets-/re-adjuderings-vakt på selve svarnøkkelen. v3-målingen avdekket at flere judge-«feil» trolig er *utdatert gull*, ikke judge-feil (`genaiops-llm-specific#2`: claim «1600+», live=1900 ⇒ 1,19× tett nedre grense, R1 sier korrekt `grounded`, gull sier `outdated` — gull-standarden er her for streng) | Feil adopsjonsbeslutning bygd på aldrende baseline; falsk feilrate i §7-nordstjernen | Friskhets-mikropass: re-adjuder de ~5 omstridte v3-vs-v2-claims mot live MS Learn (avgjør gull-feil vs judge-feil) + periodisk gull-re-adjudering knyttet til §7 friskt utvalg | 🟢 **lukket 2026-06-30** (G5: 2 gull-feil rettet, 3 judge-feil bekreftet, **reverserte adopsjonsbeslutningen**; **G5b: completeness-caveat lukket** — de 4 v3-FP re-sjekket, ALLE 4 stale gull, v3 → P 100 % / R 92,9 % / 0 FP — se lukke-logg) | v3.1-adopsjon (baseline må være til å stole på FØR ny prompt måles mot den) |
+
+| **G6** | Ingen sikkerhetsgate på ingestion-kjeden (hentet eksternt innhold → korpus): llm-security-pluginen er **deaktivert globalt** (verifisert 2026-07-03 i `~/.claude/settings.json`), så `post-mcp-verify`-hooken (injection-skann på all tool-output, inkl. `microsoft_docs_fetch`) fyrer ikke; commit-gaten dekker kun secrets (gitleaks), ikke injeksjon/steganografi i `.md`-innhold. Tillit til MS Learn dekker faktisk korrekthet — ikke adversarielt innhold i kanalen eller i kodeeksempler/lokalisert stoff | Indirekte prompt-injeksjon/steganografi persistert i offentlig distribuert KB: references-filene blir instruksjonsnær kontekst i fremtidige agent-sesjoner, én forgiftet fil re-serveres til alle brukere (hele Norge) | **R6-briefen designer gaten, to lag** (`docs/ingestion-security-brief-2026-07.md`, committet 2026-07-04): (a) llm-security AKTIV + verifisert fyrende i enhver fetch-økt (kb-update, research, generate-skills, judge-pass); headless-caveat GH #36071 → foreground eller kompenserende skann; (b) deterministisk node-skann (unicode/decode/injection — de DELTE llm-security-detektorene importert in-process, ikke kopiert; operatør-valg 2026-07-04) over endrede `skills/**/*.md` før commit. Håndheves fra R7 og i kb-update-kadensen | 🟢 **Layer B (b) LUKKET 2026-07-04 (TDD).** Bærende gaten bygget: `scan-adversarial-content.mjs` (+ `lib/adversarial-scan.mjs` disposition-kjerne, `lib/adversarial-detect.mjs` llm-security-bro), wiret som sibling til `validate-kb-file.mjs` ved det eneste skrive-chokepunktet (kb-update §3b.d.7/§4/§5 + generate-skills per-batch/pre-commit). Provenance-tiered BLOCK/WARN; injection-flagg → samme menneske-i-loop som status-påstand. 30 tester (692/0). Premiss-korr.: research/research-agent skriver ingenting (kun Layer A); CLI-scan alene misset injection+base64 → importerer rene primitiver. **Baseline-adjudikering (Enhet A2) LUKKET 2026-07-18 (TDD):** korpus-baseline 55/389 flagget (83 funn) → 4 ekte defekter fikset (2 Cyrillic-homoglyph-ord, 2 filer med U+00AD) + 75 funn human-adjudikert inn i innholds-basert allowlist (`scripts/kb-update/data/layerb-allowlist.json`: class+evidence+tier+eksakt trimmet linjeinnhold per entry, med begrunnelse; flyttet linje forblir grønn, endret innhold GJENOPPSTÅR som flagg — scanneren selv usvekket, korrupt/manglende allowlist → tom = full strenghet). Korpus 389/389 OK exit 0; commit-gaten (pre-commit-scan) leser samme allowlist. **Layer A (a) LUKKET 2026-07-18 (Enhet B):** `post-mcp-verify` aktivert kirurgisk i `~/.claude/settings.json` (PostToolUse-matcher `mcp__microsoft-learn__.*`) + live-verifisert fyrende med 2 foreground `microsoft_docs_fetch` — og en **ekte hook-defekt funnet+fikset underveis** (hooken leste `tool_output`, live-protokollen sender `tool_response` → hooken skannet ingenting; fiks TDD i llm-security `44aa390` v7.8.3). Se lukke-logg. | Layer A: R7 (første judge-pass-fetch-økt) / enhver `/architect:kb-update`/`generate-skills`-fetch-økt |
+
+| **G7** | **Ingen rute for korreksjoner som er RIKTIGE, men større enn O2-konvolutten.** O2 er definert som én lokator + kun-sletting. R11 §9.3/§9.4 produserte fire funn der den korrekte fiksen beviselig ligger utenfor: idx 18 (`rag-caching-optimization.md:29` — den overlevende påstanden er en hel titulert seksjon 303-318 **pluss** en `**Verified**`-rad på 510; ingen sletting begrenset til linje 29 kan reparere fila), idx 36 (`ai-threat-modeling-stride.md:38` — companion-edit på 310 kreves for at prosaen skal matche den innsnevrede severity-tabellen), idx 17 (`**Verified**`-stemplet på 258 stempler etter editen kun retnings-utsagnet), idx 33 (innholdet overlever på 357 under CAF-attribusjon, så editens gevinst er mindre enn den ser ut). Alle fire er i dag kun prosa i `r11-pilot-results.md` | **Sanne defekter som stille faller ut av programmet fordi ingen mekanisme eier dem.** O2-triagen avviser dem (utenfor konvolutt), O3 dekker dem ikke (fiksen er ikke en verdi-swap), og det menneskelige review-sporet har ingen inngangskø. Nettoeffekten er at den *vanskeligste* klassen — der fila motsier seg selv — er den eneste uten eier | **DESIGNET + BYGGET 2026-08-03 (form b — navngitt kø).** Valget ble tatt på måling, ikke på form-preferanse: av de fire subtraksjonene i `957ebef` etterlot **to** en rest (§9.6), så rester er delete-only-konvoluttens normale biprodukt, ikke et unntak. Og **to av de fem medlemmene (idx 17, 33) er erstatninger, ikke fler-lokator** — en delete-orientert O4-klasse med egen retur-kontrakt ville ikke fikset dem, altså vært feil dimensjonert mot evidensen. Køen absorberer begge klasser. Artefakter: `scripts/kb-eval/data/g7-review-queue.json` (tracked, 6 entries) + `lib/g7-queue.mjs` + `check-g7-queue.mjs` + 15 tester. **Ankere er ordrette strenger, ALDRI linjenummer** (`line` ≠ `real_line` i 9 av 17 R11-records); en åpen entry hvis anker slutter å matche gir `anchor_drift` og exit 1 — den kan ikke falle stille ut. ⚠️ **Presisering om hva som faktisk HÅNDHEVER dette:** `check-g7-queue.mjs` har ingen runner og kjører kun når noen skriver kommandoen. Den bindende gaten er **testen** — `test-g7-queue.test.mjs` siste case (`the real queue file validates against the live corpus`) kjører den ekte køen mot live korpus i hver suite-kjøring. CLI-en er for lesbar status; suiten er gaten. Ingenting i køen er maskin-anvendbart per definisjon; lukking er en menneskelig review-handling som MÅ føre `resolution`. Kobles fra ÅPEN OPERATØRBESLUTNING #2: køen står uansett hvordan den lander | 🟡 **pågår — mekanismen står, køen er ikke tømt.** 5 åpne (idx 26, 27, 33, 36, 18), 1 lukket (idx 17: dinglende ledetekst → kolon-til-punktum, operatør-ratifisert). idx 27 kom hit ved å FALLE UT av O2 på cond 3 (§9.6), idx 26 ved operatørens avvisning av delvis fiks | Før R11s menneskelige review-fase erklæres ferdig. **Mekanismen er nå lukke-vilkåret oppfylt for; det som gjenstår er innholdet i køen** |
+
+**Ikke mekanisme-gap, men sporet backlog (innhold, ikke loop):** reference-`.md`-fil-fiksene fra Spor 2b (FP1 11000+/40+, FP2 «kun», FP6 Preview/Norway-East, FN2–FN6 utdaterte tall) **+ G5b** (`adr-template.md` fjern «zero permission management»; `multi-region-azure-openai-deployment.md` bytt retired `gpt-35-turbo` → gjeldende modell; `network-resilience-patterns-ai.md` «obligatorisk» → «anbefalt»; `vector-storage-cost-optimization.md` GA-dato `2024-11-01` → `2024-07-01`) er **Spor 0/1**-innholdsarbeid — pekt per-claim i `notes`, ikke gjentakelses-mekanisme. Føres i Spor 0-manifest / Spor 1-korpus-pass, ikke her.
+
+### Lukke-logg
+
+- **G3 🟢 lukket (2026-06-30).** Deterministisk lint `lib/gold-consistency.mjs` + CLI `lint-gold-consistency.mjs` + TDD `tests/kb-eval/test-gold-consistency.test.mjs` (4 tester); wiret som hard gate på `build-gold-set.mjs --write` (dry-run forhåndsviser ikke-fatalt). De 3 nåværende shippet-gull-treffene resolvert med `consistency_waiver` (én — `reserved-capacity-planning#5` — live kilde-bekreftet FØR waiver, verifiseringsplikt). **Bevist mot FP1:** rebuild fra batch-returns flagger `azure-ai-foundry.md#2` (verdict=correct, note «11000+/40+ uverifisert») — nøyaktig claimen Spor 2b fant via dyr live re-fetch. Linten fanger klassen gratis ved bygg.
+- **G4 🟢 kodet (2026-06-30).** Nedre-grense-policyen + konsistens-policyen kodet inn i `build-gold-set.mjs` `_meta.lower_bound_policy` / `_meta.consistency_policy` (instruks subagenter følger ved fremtidig gull-bygg) OG inn i `judge-claim-prompt-v3.md` som **R1** (nedre-grense-understatement >~2× = `not_grounded`). Policyen er nå kodet begge steder; **håndheving** rir på at G1/G2 adopterer en prompt som bærer R1 (v3 hvis bakeoff-målt forbedring; ellers carry R1 inn i adoptert prompt).
+- **G1 (Spor 2a) 🟡 v3 MÅLT + FORKASTET (2026-06-30).** Fan-out kjørt: 255 claims / 45 filer, inline Agent-fan-out (45 Opus-4.8-xhigh-subagenter, live MS Learn, én per fil), aggregert 255/255 rent → `judge-bakeoff-results-v3.json`, deterministisk re-score mot herdet gull → `judge-bakeoff-report-v3.{json,md}`.
+  - **Resultat: v3 P 89,7 % / R 87,5 % vs v2 P 92,1 % / R 87,5 %.** Recall flat, **presisjon −2,4 pp** (FP 3→4). Adopsjonsgaten (P OG R ≥ v2) **ikke klarert** → **v2 beholdt** (forhåndsregistrert regel). Rapportens egen «GATE: PASS» er kun det løse gulvet (R≥0,70/P≥0,60), ikke adopsjonsbaren.
+  - **22 claims flippet v3-vs-v2:** 8 forbedringer (5 FN→TP via R1/R2/R3/R4; 3 FP→TN via R5/R6) + 9 regresjoner (5 TP→FN; 4 TN→FP). Recall-gevinst/-tap kansellerte eksakt; presisjon endte −1 FP. Reglene er **dobbelteggede ved full populasjon** — table-top validerte de 8 målene isolert, men over de 247 øvrige produserer R1–R7 like mange nye feil som de fikser.
+  - **Konkrete bakslag (input til v3.1):** R1 misanvendt på *øvre* grense (`multi-model-strategy-costs#2`: «up to 18» tak, live 28 — R1 er for *nedre* grenser); R7 for ettergivende (`model-selection#8`, `token-usage#3`, `ai-foundry-dr#9` — fulgte til kanonisk side, fant grunnlag, flippet v2s korrekte `not_grounded`) **[G5-korreksjon: `model-selection#8` var gull-feil, ikke R7-bom; se G5-lukke-logg]**; R2/R6 nye FP (`adr-template#1`, `multi-region-azure-openai#2`, `network-resilience#4`, `vector-storage#7`).
+  - **Nyanse → G5:** minst én «regresjon» er trolig aldrende gull, ikke v3-feil (`genaiops#2`, se G5-raden). Derfor må gull-friskhet (G5) avgjøres FØR v3.1 måles mot baseline.
+  - **Neste (ny sesjon):** (1) G5 friskhets-mikropass på de ~5 omstridte claims → fastslå gull-feil vs judge-feil; (2) v3.1 = v3 minus bakslagene (R1 kun nedre grenser; R7-ettergivenhets-vakt; R2/R6 FP-vakt); (3) re-mål samme 45-veis fan-out; (4) adopter vinneren; (5) G2-wiring av adoptert judge.
+- **G5 🟢 lukket (2026-06-30) — REVERSERTE adopsjonsbeslutningen.** Friskhets-mikropass: de 5 omstridte claims (alle v2=`not_grounded`, v3=`grounded`, gull=`outdated`) re-adjudert mot live MS Learn, én Opus-4.8-subagent per claim, blinde for gull/v3-verdikt (anti-anchoring).
+  - **Utfall — 2 gull-feil + 3 judge-feil (even-handed: rettet gull i begge retninger etter ground truth):**
+    1. `genaiops-llm-specific-practices#2` «1600+» — live «over 1 900» (1,19×, tett nedre grense). **Gull-feil** (motsa egen ratifiserte nedre-grense-policy): outdated→correct. v3 `grounded` (R1) korrekt.
+    2. `multi-model-strategy-costs#2` «opptil 18» — live 28 (v2025-11-18). **Judge-feil**: «up to 18» er et *tak* som er brutt; v3 misanvendte R1 (nedre-grense) på en øvre grense. Gull `outdated` opprettholdt. → v3.1 R1-vakt (kun nedre grenser).
+    3. `model-selection-price-performance#8` «Model Router GA» — live GA (nov 2025; kanonisk concept-side uten «(preview)»; siteringssiden bar stale «(preview)»-lenkelabel). **Gull-feil** (aldret — GA skjedde etter gull-bygg): outdated→correct. v3 `grounded` (R7) **vindisert** — R7s «følg til kanonisk side» fant GA korrekt.
+    4. `token-usage-tracking-attribution#3` metrikk-navn — live `ProcessedPromptTokens`/`InputTokens`/`GeneratedTokens`/`OutputTokens`; bare `PromptTokens`/`CompletionTokens` finnes ikke. **Judge-feil**: navnet er load-bearing → eksaktverdi skal styre, R7-leniens feil. Gull `outdated` opprettholdt. → v3.1 R7-load-bearing-vakt.
+    5. `ai-foundry-disaster-recovery-planning#9` Global training + Norway East — live: Global training er GA (ingen «Public Preview»-label), «billigere/ingen residency» stemmer, MEN Norway East er en **Global** (ikke-residency) trenings-region, ikke regional/residency (Standard fine-tune-regioner: North Central US / Sweden Central / East US2). 2 av 3 last-bærende delpåstander feil. **Judge-feil** (v3 `grounded`, ingen regel; ufullstendig fler-delt verifisering). Gull `outdated` opprettholdt. → v3.1 fler-delt-fullstendighets-krav. Fil-fiks (Spor 0): fjern «(Public Preview)» + rett Norway-East-anbefalingen.
+  - **Korreksjon av linje 114 (v3-måling, mot stale gull):** `model-selection#8` var IKKE «R7 for ettergivende» — det var R7 vindisert (gull-feil). v3.1 R7-vakten gjelder kun load-bearing-strenger (`token-usage#3`).
+  - **Baseline-revurdering (re-score, samme gull begge):** v2 falt 92,1/87,5 → **86,8/86,8** (mistet 2 TP→FP på de rettede claims — var oppblåst av stale gull). v3 steg 89,7/87,5 → **89,7/92,1** (2 FN→TN). **v3 slår nå v2 på BEGGE akser.** Den opprinnelige «v3 regredierte» var et stale-gull-artefakt. Den detaljerte 22-flip-tellingen i linje 113 var mot stale gull (2 «regresjoner» = claims 1+3 er nå presisjon-forbedringer FP→TN) — superseded av re-scoren. Artefakter: `judge-bakeoff-report-v2-g5gold.{json,md}`, `judge-bakeoff-report-v3-g5gold.{json,md}`. Gull-`_meta.reconciliation_log` + lint (373 claims, 0 flagget) + suite 641/641 grønt.
+  - **Beslutning:** v3 = **interim adoptert baseline** (slår v2 på fersk gull per forhåndsregistrert gate). v3.1-baren er nå **v3 (89,7/92,1)**, ikke v2 — strengere og ærligere. **Completeness-caveat:** kun de 5 omstridte ble re-sjekket; de 4 v3-FP-claims (`adr-template#1` m.fl.) sitt gull er IKKE re-verifisert (antatt `correct`; spot-sjekk under v3.1). Periodisk gull-re-adjudering knyttes til §7 friskt utvalg (G5-mekanismen er nå et mønster, ikke engangs).
+- **G5b 🟢 lukket (2026-06-30) — completeness-caveat innfridd; baseline løftet til P 100 %.** G5s eksplisitte gjenstående caveat (de 4 v3-FP-claims hadde antatt, ikke verifisert, `correct`-gull) lukket: de 4 (`adr-template#1`, `multi-region-azure-openai-deployment#2`, `network-resilience-patterns-ai#4`, `vector-storage-cost-optimization#7`) re-adjudert mot live MS Learn, **én Opus-4.8-subagent per claim, blind for gull/v3-verdikt** (anti-anchoring, samme protokoll som G5).
+  - **Utfall — ALLE 4 var stale gull; v3 flagget hver korrekt (0 ekte FP):**
+    1. `adr-template#1` (status) «zero permission management, permissions respekteres automatisk» — live (`data-privacy-security` + `connecting-external-content-manage-items`): del B (auto-respektert ved grounding) stemmer, men del A motsies — Graph connectors krever ACL per `externalItem` + identitets-mapping. **Gull-feil** `correct→wrong`. v3 `not_grounded` (R6) korrekt.
+    2. `multi-region-azure-openai-deployment#2` (region) «Sweden Central … gpt-4o, o1, gpt-35-turbo» — live: gpt-4o + o1 tilgjengelig, men **gpt-35-turbo er retired** (0301/0613 feb 2025; 0125/1106 fra sep 2025), borte fra katalogen. **Gull-feil** `correct→outdated`. v3 `not_grounded` (R2 entitet-fravær) korrekt.
+    3. `network-resilience-patterns-ai#4` (status) «Circuit Breaker + Retry … obligatorisk for alle Azure AI API-kall» — live (`how-to/quota`): MS rammer dette som «Rate limit best practices / recommended», circuit breaker kun valgfri Polly-utvidelse. «Obligatorisk for alle» overdriver modalitet + omfang. **Gull-feil** `correct→wrong`. v3 `not_grounded` (R6) korrekt.
+    4. `vector-storage-cost-optimization#7` (status) «Vector quantization GA siden 2024-11-01» — live (`search-api-migration`): quantization ER GA, men GA-dato var **2024-07-01** (stable release); «2024-11-01» finnes kun som *preview*-API-versjon (`2024-11-01-preview`). Last-bærende dato feil. **Gull-feil** `correct→wrong`. v3 `not_grounded` korrekt.
+  - **Baseline-revurdering (re-score, G5b-korrigert gull, samme gull begge):** de 4 flyttet FP→TP for v3. **v3: P 89,7/92,1 → 100,0 / 92,9 (TP 39, FP 0, FN 3, TN 198).** v2: 86,8/86,8 → **86,8 / 78,6** (de 4 ble FN for v2 — v2 flagget ingen). v3 dominerer nå v2 på begge akser med større margin; gull var fortsatt kontaminert. Artefakter: `judge-bakeoff-report-v3-g5bgold.{json,md}`, `judge-bakeoff-report-v2-g5bgold.{json,md}`. Gull `_meta.reconciliation_log` + lint (373 claims, 0 flagget) + suite 641/641 grønt.
+  - **Konsekvens for v3.1-design (PLAN-INVERSJON):** STATEs planlagte v3.1-endring #4 (R2/R6 «FP-vakt» for de 4) er **droppet** — R2/R6 fanget disse korrekt; en vakt ville re-knekt 3 reelle treff. v3.1 er nå **ren recall-hardning** av de 3 gjenstående FN (R1 øvre-grense-skille, R7 last-bærende-streng-carve-out, ny R8 fler-delt-fullstendighet) — `judge-claim-prompt-v3.1.md` forfattet. **Adopsjonsgate strammet:** v3 sitter på presisjonstaket (P=100), så v3.1 må **holde P=100 OG løfte R over 92,9** — enhver ny FP feller den. 45-veis fan-out gjenstår (operatør-gate, stor spend).
+  - **Mønster bekreftet:** G5b er andre gang gull-friskhet inverterte en adopsjonskonklusjon ([[gold-freshness-can-invert-adoption]]). Gull-re-adjudering FØR baseline stoles på er nå fast disiplin, ikke engangs — knyttes til §7 friskt utvalg.
+- **G1 (Spor 2a) 🟢 LUKKET (2026-06-30) — v3.1 MÅLT + ADOPTERT (max-utfall).** 45-veis v3.1-fan-out kjørt per `docs/v3.1-fanout-runbook.md`: 255 claims / 45 filer, 45 Opus-4.8-xhigh-subagenter (live MS Learn, én per fil, blinde for gull), aggregert 255/255 rent → `judge-bakeoff-results-v3.1.json`, deterministisk re-score mot G5b-korrigert gull → `judge-bakeoff-report-v3.1.{json,md}`.
+  - **Resultat: v3.1 = P 100,0 % / R 100,0 % / 0 FP / 0 FN / F1 1,000** (TP 42, TN 198, Wilson 95 % [91,6 %, 100 %]) mot v3-baren P 100,0 / R 92,9 / 0 FP / 3 FN (TP 39). v3.1 dominerer: **alle 3 gjenstående FN fanget** (R 92,9 → 100, TP 39→42) **uten én ny FP** (FP 0, P 100, TN 198 uendret). Begge scoret over identisk 240-claims-konfusjonsmatrise (samme G5b-gull).
+  - **De 3 FN fanget som designet:** `multi-model-strategy-costs#2` (R1 øvre-grense — «opptil 18» slått av live 28), `token-usage-tracking-attribution#3` (R7 last-bærende-streng — `PromptTokens`/`CompletionTokens` finnes ikke live), `ai-foundry-disaster-recovery-planning#9` (R8 fler-delt — Norway East er Global-trening, ikke regional). Alle tre flippet `grounded→not_grounded`, matchet gull `outdated`.
+  - **FP-risiko avkreftet (R1s dobbeltegg holdt):** R1-«+»-floor-flaggene over full populasjon (`rag-context-windows#2` «200k+»→1M, `ai-services-vs-foundry#5` «100+»→1900) er begge gull=`outdated` → **TP, ikke FP**; tette floors (`genaiops#2` «1600+»→1900, `reserved-capacity#3` «enkelte 100+») holdt `grounded`, gull=`correct` → TN. R1s magnitude-skille (>~2× decision-changing vs tett) sporet fasiten i begge retninger over de 255 — ingen ny FP innført.
+  - **Forhåndsregistrert gate klarert:** «adopter v3.1 KUN hvis P=100 OG R>92,9» → P=100 ✓ ∧ R=100>92,9 ✓ → **v3.1 ADOPTERT**. v3.1 (`judge-claim-prompt-v3.1.md`, R1–R8) er nå inngangen til G2.
+  - **Metode-note (portabelt mønster, [[showcase-reusable-patterns]]):** `build-judge-payloads.mjs` (deterministisk payload-generator) + per-payload-splitt + inkrementell per-fil-persistering (resume-trygg mot kvote-stopp) gjorde fan-outen reproduserbar og avbruddssikker. Artefakter: `judge-bakeoff-results-v3.1.json`, `judge-bakeoff-report-v3.1.{json,md}` (committet); payloads gitignored.
+- **G2 🟢 LUKKET (2026-06-30) — adoptert v3.1-judge wired inn i pipelinen (TDD).** RED→GREEN: testene `test-transform.test.mjs:200` (default-stempel) + `:235` (ende-til-ende) flippet `judge-v2 → judge-v3.1`, så feile, så `scripts/kb-update/lib/transform.mjs:44` `JUDGE_VERSION = 2 → '3.1'`.
+  - **Designvalg — version-label-streng, ikke integer (`judge-v3` forkastet):** v3 er en distinkt, målt, *forkastet* versjon (R 92,9 / 3 FN) med eget navn i programmets artefakter; et `judge-v3`-stempel ville navne feil judge og kollidere. Streng `'3.1'` lar provenance navne adoptert judge eksakt. Blast-radius null: `verified_by` lagres/parses kun som `\S+`-token + presence-sjekk (`parseVerifiedByHeader`), ingen kode trekker ut integeren; parseren tar `judge-v3.1` uendret (ende-til-ende-testen bekrefter det gjennom `composeKbFile`). Default-stien interpolerer strengen direkte (utenom `Number.isInteger`-guarden), så integer-override-stien (`judgeVersion:3 → judge-v3`) består.
+  - **Prompt-/command-wiring:** `transform-prompt.md` (46/101/105), `commands/kb-update.md` (130 — BÅDE Port 2 born-verified OG Port 3-kadens-inngang), `commands/generate-skills.md` (139/143/305/307) byttet `judge-claim-prompt-v2.md → -v3.1.md` + `judge-v2 → judge-v3.1`. `generate-skills.md`: kun kirurgisk judge-ref (Cosmo-heading urørt — «gjøres sist» per [[cosmo-persona-deprecated]]). Suite **641/641** (kun 2 eksisterende tester flippet, ingen lagt til).
+  - **Restgap (guard-minor-nit, §8-oppfølging):** stempel-guarden (`transform.mjs:165`) honorerer *integer*-override men ikke en minor-bærende streng-override (`judgeVersion:'3.2'` faller tilbake til default pga `Number.isInteger`). Harmløst — pipelinen bruker alltid default ('3.1'); en fremtidig judge-revisjon som vil *overstyre* til en minor må generalisere guarden til en version-label-regex. Logget her, ikke lukket (utenfor G2-scope; ingen failing behov i dag).
+- **G6 🟢 LUKKET (2026-07-18) — Layer A aktivert + live-verifisert (Enhet B); begge lag i drift.** Layer B var lukket 2026-07-04 (gate) + 2026-07-18 (baseline-adjudikering, Enhet A2 `af6c31c`); dette lukker Layer A og dermed hele G6.
+  - **Aktivering (kirurgisk):** PostToolUse-hook i `~/.claude/settings.json` med matcher `mcp__microsoft-learn__.*` → direkte node-kall mot `../llm-security/hooks/scripts/post-mcp-verify.mjs` (ikke global plugin-reaktivering — minst mulig flate). Backup av settings i scratchpad; rollback = fjern blokken. Edit/Write mot settings er pathguard-blokkert → endringen gjort via Bash/python3 med jq-validering (STATE-mandatert, se «Åpne spørsmål» i STATE for sanksjonert rute fremover).
+  - **Live-verifikasjon avdekket ekte defekt (verifikasjonens verdi bevist):** hooken leste `tool_output` fra stdin, men live hook-protokollen sender **`tool_response`** — hooken kjørte grønt og skannet INGENTING (stille no-op). Bevist ved stdin-nøkkel-dump i live fyring. Fiks i llm-security (TDD, 3 nye tester, 73/73): `tool_response ?? tool_output`. Bevis etter fiks: volum-state-filen viser `microsoft_docs_fetch: 8252` = eksakt resp_len av testfetchen. Fiksen landet i llm-securitys `44aa390` (v7.8.3; parallell release-økt feide de stagete filene med i sin commit — multisession-race, innhold komplett).
+  - **Håndhevelses-kjede nå komplett:** Layer A (post-mcp-verify på all MS Learn-fetch-output, foreground obligatorisk per mandat) + Layer B (scan-adversarial-content ved skrive-chokepunktet, 75-entry adjudikert allowlist) + commit-gate (`pre-commit-scan.mjs` git-hook-installert som `.git/hooks/pre-commit`-symlink `372a922`, e2e-testet: ren→exit 0, forgiftet staget fil→BLOCK exit 1). NB: symlinken er per-klon — fersk klon må re-installere (dokumentert i skriptets header).
+  - **Kjent søsken-defekt (utenfor scope, llm-security-økt):** `post-session-guard.mjs` leser trolig også `tool_output` — samme defektklasse, ikke fikset her. Suite 942/942 exit 0.

docs/ref-kb-direction-note-2026-06.md

@@ -0,0 +1,125 @@
+---
+Provenans: Generert av dynamic workflow `ref-kb-analysis` (2026-06-26) — 5 parallelle akse-analyser (Opus 4.8 xhigh) → adversariell kritiker → syntese. Gjennomgått av hovedkontekst. Bygger på `docs/ref-kb-audit-2026-06.md` (verifisert ground truth). Beslutning IKKE tatt — dette er input til operatør.
+Gjelder: skill-reference-filene (de 389). IKKE Google OKF — OKF er reservert for brukerens egen kontekst/«second brain» (se `docs/okf-second-brain-brief-2026-06.md`).
+---
+
+# Beslutningsnotat — Hvordan ms-ai-architect bør lage og oppdatere sine 389 reference-filer
+
+## Bunnlinje
+
+Diagnosen er korrekt og delt av alle fem aksene: ingen mekanisme måler i dag om en ref-fils *påstander* stemmer mot MS Learn — Spor D måler struktur per skill, KB-refresh måler alder per fil. Men «vi måler ikke korrekthet» er ikke det samme som «korrektheten er dårlig»: KB-en scorer 91–96 med 0 stale filer, og base-raten av faktiske feil er aldri målt. Anbefalt førstesteg er derfor **ikke å bygge**, men å **måle**: én sesjons stratifisert manuell stikkprøve (~30–40 filer vektet mot volatile påstander) mot live MS Learn fastslår feilraten — og den raten, ikke en antakelse, avgjør om noen av de dyre retningene (LLM-groundedness-judge, frontmatter-migrasjon, registry-herding) er berettiget. Den eneste rene struktur-fiksen som er verdt å gjøre uavhengig av målingen er TOC på de ~20–29 største filene (>800 linjer). Hvis judgen senere bygges, er retningen **#2 (eget ref-eval-spor) bygget på #3s substrat (KB-refresh-pipelinen)** — aldri #1.
+
+---
+
+## Akse 1 — Struktur og størrelse
+
+**Verifisert fakta.** Median 481 linjer, snitt 507, 183/389 filer >500 linjer, største 1265 (`architecture/adr-template.md`). Alle 5 SKILL.md er 169–294 linjer. 384 av 387 filer >100 linjer mangler innholdsfortegnelse (TOC). Eval N4 måler TOC, men med vekt 1 av 23 og uten gulv — nær-total svikt koster ~4 poeng og bryter aldri 90-målet.
+
+**Best practice.** 500-linjers-regelen gjelder SKILL.md-body, ikke ref-filer; ref-filer har «no context penalty until accessed» og kan bunte omfattende innhold. Men: filer >100 linjer skal ha TOC øverst slik at Claude ser hele omfanget selv ved delvis lesing. Kilde: Anthropic «Skill authoring best practices» (platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices), §Token budgets, §Runtime environment, §Structure longer reference files.
+
+**Anbefaling (vurdering).** Ikke masseoppdel for størrelsens skyld — store ref-filer er eksplisitt sanksjonert. TOC-løftet er reelt kun for de største filene: under whole-file named-core-routing (agenter leser ~3 hele kjernefiler) er partial-read en *uobservert* feilmodus, og de ~350 filene på 100–500 linjer leses helt og vinner ingenting. Legg derfor TOC kun på de ~20–29 filene >800 linjer der partial-read faktisk er plausibelt. Kirurgisk splitt av `adr-template` (flytte 2 av 3 ADR-eksempler ut) gir kun gevinst hvis adr-writer-agent laster malen men *ikke* trenger eksemplene — et **umålt** lastemønster; trenger den et eksempel laster den søsterfila, og nettogevinsten er null pluss migrasjonschurn. Utsett. (Merk: `adr-template` bor i `ms-ai-advisor`, som er gjenstand for forestående Cosmo-utfasing — se sekvenserings-risiko under.)
+
+---
+
+## Akse 2 — Innhold og korrekthet
+
+**Verifisert fakta.** Ingen mekanisme leser ref-body semantisk. KB-refresh har per-fil URL-mapping (306/389), per-fil staleness-post og adversariell klassifisering (verify-out: status-gate + refutation + authority-mismatch). Men kun **7/389 filer** har streng `**Source:**`-header, og kun **3 URL-er** i registryet har `authority_source` satt — det utpekte autoritets-ankeret en rigorøs grounding krever eksisterer praktisk talt ikke ennå.
+
+**Best practice.** Faithfulness/groundedness måles ved å dekomponere output i diskrete påstander og NLI-/entailment-sjekke hver mot kilden (RAGAS Faithfulness — docs.ragas.io). Microsofts egen analog: Azure AI Content Safety Groundedness detection (learn.microsoft.com/azure/ai-services/content-safety/concepts/groundedness). LLM-judge bør ikke skåre hver request med dyr frontier-judge — kombiner billige heuristikker + selektiv sampling + policy-trigget audit, og kalibrer mot et menneske-merket subset først (Langfuse/Confident AI-praksis). Anthropic: «Avoid time-sensitive information» — volatile fakta (GA/preview/versjon/pris) er høyest risiko.
+
+**Anbefaling (vurdering).** En per-fil groundedness-judge er teknisk riktig formet (per-fil enhet, claim-dekomponering, entailment mot utpekt kilde), MEN tre kritikk-punkter endrer kalkylen vesentlig:
+- **Invertert leverage.** Alle akser er enige om at de volatile påstandene — nøyaktig de som faktisk råtner — *må forbli operatør-gated og aldri auto-scores*. Judgen auto-scorer da de stabile, lav-risiko-påstandene og punter de høy-risiko-volatile til mennesket. Frontier-dollar brukes der feil er minst sannsynlig.
+- **Kostnaden er feilestimert.** «$20–40 via Batch API» er feil: `microsoft_docs_fetch` er et Claude-i-loop MCP-kall, ikke en Batch-workload. Ærlig kostnad er Akse 4s: per-fil × per-kilde (median 7 kilder/fil) ≈ ~2700 ikke-batchbare, rate-begrensede fetch-kall per full-pass.
+- **Den fjerner ikke verifiseringsplikten.** Judgen er ikke-deterministisk og claim-dekomponering er erkjent brittle; dens egen output må operatør-kalibreres og revideres. Netto menneske-innsats flyttes fra «stikkprøv KB-en» til «kalibrer + revider judgen» — ROI-premisset er udokumentert.
+
+Konklusjon: judgen bygges **kun hvis** den målte feilraten (se Bunnlinje) viser en restklasse av reelle feil *uten* lastmod-endring (feillesning/feildestillasjon) — det er den eneste verdien judgen tilfører over den eksisterende staleness-loopen, og den er aldri tallfestet.
+
+---
+
+## Akse 3 — Hvordan vi måler kvalitet
+
+**Verifisert fakta.** Spor D (skill-score.mjs) aggregerer per SKILL (5 enheter); K8 sjekker kun at en kilde-/Verified-header *finnes* (sample-ratio over 5 filer, vekt 1), aldri at innhold stemmer. Begge dashbord er grønne (alle skills ≥90, 0 stale). Scoringsmotoren har allerede gulv-mekanikk (K1/K10 `floor:true` ⇒ `min(rawScore, 89)`).
+
+**Best practice.** Groundedness-evaluator behandler «response» mot «context» med 1–5-skala + terskel→Pass/Fail (Azure RAG-evaluators — learn.microsoft.com/azure/foundry/concepts/evaluation-evaluators/rag-evaluators). Analytisk per-kriterium-scoring avslører *hvorfor* noe feiler; 3–5 kriterier er sweet spot; krev konkret bevis, ikke vage gradord (G-Eval, Liu et al., EMNLP 2023). Mål konsistens med repetisjoner for ikke-deterministisk judge (learn.microsoft.com/agent-framework/agents/evaluation).
+
+**Anbefaling (vurdering).** *Hvis* en innholds-akse bygges: opprett en EGEN, ortogonal akse (Spor E / innholds-troverdighet) per fil, ikke utvid Spor D — #1 er en granularitets-kategorifeil (én råtten fil fortynnes til 96/100 i et skill-snitt over 153 filer). Men kritikken avdekker en reell fare i Akse 3s forslag: et **hardt worst-file-gulv på et brittle judge-signal** gir alarm-tretthet og waiver-spam — én falsk-positiv gulver hele skillen under 90 og fyrer Spor D-alarmen i SessionStart. Gulv-grammatikk passer deterministiske kriterier (K1/K10), ikke et ikke-deterministisk judge-signal. Hvis aksen bygges, bør judge-gulv være *rapporterende* (worstFile + countBelow), ikke en hard SessionStart-gate, før judgen er kalibrert. Merk også overlapp: foreslått CT5 (sourcedness) er samme signal som dagens K8 — CT5 bør **erstatte** K8s rolle, ikke leve parallelt, ellers dobbelttelles og to dashbord kan divergere.
+
+---
+
+## Akse 4 — MS Learn fetch-dekning
+
+**Verifisert fakta.** Registryet dekker 306/389 filer (78,7 %) med ≥1 pollet kilde-URL; 83 (21,3 %) er helt utenfor (= audit-ens URL-løse filer). 309 siterte URL-er er `not_in_sitemap` (usynlige for ferskhets-flagget), inkl. hele M365-Copilot-kategorien og 12/17 Agent Framework-lenker. Kobling fil↔kilde er mange:mange (median 7 kilder/fil, maks 21). Pipelinen henter aldri innhold selv — `report-changes` er ren dato-aritmetikk; fetch + re-verifisering er et separat Claude-i-loop apply-steg på kun flaggede filer, mot ÉN utpekt kilde.
+
+**Best practice.** sitemap `<lastmod>` er publisher-kontrollert og ofte upålitelig — en side kan endre innhold uten lastmod-bump (Yoast, yoast.com/lastmod-xml-sitemaps-google-bing). MS Learn eksponerer `canonicalUrl` + `ms.date` + `updated_at`; siteringer bør peke kanonisk og verktøy bør følge redirect. `microsoft_docs_fetch` gir full sidetekst til grunning (microsoft-learn MCP tool-instruksjoner).
+
+**Anbefaling (vurdering).** Registry-herding er et reelt, billig og retnings-uavhengig forbedringspunkt: legg `graph`/`ai-builder`/`power-apps`/`power-automate`/`microsoftsearch` i sitemap-prefiksene (~25 stack-relevante URL-er reddes), fang skjemaløse siteringer (2 filer der `learn.microsoft.com` mangler `https://`), og følg redirect så legacy-stier (44 M365-Copilot-URL-er) re-kanonikaliseres. Dette er en konfig-justering, ikke et program — men det er ikke haster-kritisk så lenge feilraten er umålt. Viktigste innsikt herfra: «fersk» ≠ «korrekt» selv for de 306 dekkede filene (lastmod-only fanger ikke innholdsdrift uten bump) — dette er det reelle argumentet for en korrekthets-sjekk, men det tallfester ikke hvor stor restklassen er.
+
+---
+
+## Akse 5 — Metadata-substrat
+
+**Verifisert fakta.** 0/389 bruker YAML-frontmatter; alle bruker prosa-header med 34 distinkte nøkler på tre språk (Status ×344, Last updated ×337, Category ×322 + norske varianter). `report-changes` tolererer allerede 3 dato-mønstre og kjører grønt. Write-pathen er sentralisert i ÉN funksjon (`transform.mjs buildKbHeader`), og YAML-parser (`splitFrontmatter`) finnes og er battle-tested for SKILL.md.
+
+**Best practice.** Anthropic foreskriver *ingen* metadata for ref-filer (kun SKILL.md krever name+description) — minimalisme er legitimt. Maskinlesbar, konsistent frontmatter er en docs-as-code-standard (Diátaxis; docsio.co). Eksplisitt freshness-dato som maskinlesbart felt (MS Learn `ms.date` — learn.microsoft.com/contribute/content/metadata). Type-tagging slik at hver fil behandles etter sin art (Diátaxis). Ikke bak inn volatil status i det stabile substratet (Anthropic, §Avoid time-sensitive).
+
+**Anbefaling (vurdering).** Full YAML-frontmatter på 389 filer (6–8 script + write-path-regresjonsrisiko + dømmekrafts-pass på 81 filer) er over-engineering forbi det ene genuint nyttige feltet. Parsingen er *ikke ødelagt* — den løser et problem som ikke har feilet. Det verdifulle skillet er **`type: reference` vs `template`/`methodology`** (redder de 83 kildeløse fra urettferdig korrekthets-straff og gjør manglende kilde på en faktafil maskin-detekterbar). Det skillet trenger ikke YAML — en enkelt tag, mappekonvensjon eller sidecar-manifest gir samme nytte til en brøkdel av kostnaden. Full frontmatter blir først berettiget *hvis* #2/#3-judgen faktisk skal bygges (da trenger den per-fil `source`+`verified` deterministisk) — altså nedstrøms av målingen, ikke før.
+
+---
+
+## Anbefalt retning (#1 / #2 / #3)
+
+**Førstevalg: ingen av dem ennå — MÅL feilraten først.** Alle fem akser hopper fra «vi måler ikke korrekthet» til «bygg et stående system» uten å fastslå om korrektheten faktisk er ødelagt. Det bryter operatørens egne anti-patterns («starte ambisiøse tiltak når en konfig-justering holder»; «endre X filer når én holder») og er klassisk feilallokering: å bygge en $-per-kjøring-detektor før base-raten av det som skal detekteres er kjent.
+
+**Betinget valg, hvis målingen rettferdiggjør bygging: #2 bygget på #3s substrat — aldri #1.**
+- **#1 forkastes** (delt konklusjon, høy konfidens): Spor D scorer per SKILL (5 enheter); korrekthet er per-fil/per-påstand og aggregerer til usynlighet der.
+- **#2 som enhet** (per-fil korrekthetsdom) **på #3s substrat** (KB-refresh-pipelinen: `microsoft_docs_fetch` + url-registry + judge-gating, refresh-kadens — ikke SessionStart). Ren #3 (score på staleness-flagget) bommer på korrekthet-uten-staleness; ren parallell pipeline dupliserer infrastruktur som allerede finnes.
+
+**Hva kritikken endret** (mot de fem aksenes opprinnelige «bygg nå»):
+- Degraderte hele judge-programmet fra «bygg nå» til «bygg kun hvis målt rate krever det».
+- Avdekket invertert leverage: judgen auto-scorer lav-risiko stabile påstander; de volatile (som faktisk råtner) forblir operatør-gated uansett.
+- Korrigerte kostnaden: ikke batchbar, ~2700 MCP-fetch per full-pass (ikke «$20–40 Batch»).
+- Avslørte at grunnings-ankeret nesten ikke finnes (3 URL-er med `authority_source`, 7 filer med Source-header) — gjør judgen bak-tung.
+- Reduserte frontmatter til én type-tag (sidecar/konvensjon), ikke full YAML-migrasjon.
+- Reduserte TOC til de ~20–29 største filene, ikke alle 384.
+- Satte adr-template-splitt på vent (betinget av umålt lastemønster + Cosmo-kollisjon).
+
+---
+
+## Billigste høyverdi-grep først (rangert)
+
+1. **Stratifisert manuell stikkprøve mot live MS Learn (~30–40 filer, 1 sesjon, null ny infrastruktur).** Vekt mot volatile påstander (Status=Preview, pris/SKU, versjon, GA-datoer) på tvers av alle 5 skills. Noter feilraten. Dette er det manglende inputet som avgjør hele programmet — lav rate (~few %) ⇒ judge ikke berettiget, staleness+stikkprøver holder; høy rate ⇒ evidens-basert begrunnelse *og* settet dobler som judge-kalibreringssett. Som sidegevinst retter samme pass de få volatile feilene som faktisk finnes — nettopp flaten judgen per design aldri ville auto-scoret.
+2. **TOC på de ~20–29 filene >800 linjer.** Eneste rene struktur-fiks verdt å gjøre uavhengig av målingen; billig forsikring mot partial-read der den faktisk er plausibel. Skript det for konsistent format.
+3. **Registry-herding (konfig-justering).** Legg de ~5 manglende sitemap-prefiksene, fang de 2 skjemaløse siteringene, følg redirect for legacy-stier. Retnings-uavhengig; forbedrer ferskhets-dekningen uansett senere valg. Ikke haster-kritisk.
+4. **Type-tag for `reference` vs `template`/`methodology`/`regulatory`** (sidecar/konvensjon, ikke full frontmatter). Lavt-kost skille som hindrer at de 83 kildeløse filene straffes urettferdig av en evt. korrekthets-sjekk. Gjør først når #2/#3 er besluttet.
+5. **(Betinget på måling) Bygg #2-på-#3-judgen** — kun hvis stikkprøven viser en reell feil-restklasse uten lastmod-endring. Forutsetter da: backfill av per-fil autoritets-binding (lag 3), full frontmatter med `source`+`verified`, kalibrering mot operatør-merket subset, og *rapporterende* (ikke hard SessionStart-gate) gulv inntil judgen er kalibrert.
+
+---
+
+## Åpne valg for operatør
+
+- **Bygge judge eller ikke?** Avgjøres av stikkprøvens feilrate. Operatøren markerte korrekthets-sporet som viktigst å gjøre skikkelig — form (enhet, substrat, autoritets-backfill-rekkefølge) skal godkjennes FØR bygging, ikke utledes underveis.
+- **Sekvenserings-risiko mot Cosmo-utfasing.** Cosmo-fjerning er godkjent og «gjøres sist», og treffer `ms-ai-advisor` — den lavest-scorende skillen (91) og hjemmet til `adr-template`. Enhver frontmatter-/split-/TOC-jobb på advisor-filer kolliderer med imminent Cosmo-fjerning. Operatør må bestemme: vent med advisor-arbeid til Cosmo er ute, eller koordiner.
+- **De 83 kildeløse filene.** Hvilke er legitimt kildeløse (maler/metodikk: `decision-trees`, `cost-models`) vs. MS-faktapåstander uten sporbar kilde? Krever dømmekraft (Opus-batch), ikke blind skripting. Dette er uansett første steg i en korrekthets-audit.
+- **N4-re-vekting.** Skal TOC-regelen håndheves reelt (re-vekt N4 eller skaler sub-score med filstørrelse)? Det vil midlertidig dra dagens 91–96 under 90-gulvet og utløse Spor D-alarmer — en policy-beslutning, ikke en defekt, som må kommuniseres som sådan.
+- **Frontmatter-omfang.** Full YAML-migrasjon (kun berettiget hvis judge bygges) vs. minimal type-tag. `category`-feltet: fjern (krever refaktor av `taxonomy.getCategorySkill` til mappesti-utledning) eller behold (redundant mot mappestruktur)?
+
+---
+
+## Verifiseringslogg
+
+| Påstand | Kilde / ground truth | Status |
+|---|---|---|
+| 389 ref-filer (advisor 62, engineering 153, governance 78, infra 34, security 62); median 481 / snitt 507 linjer; 183 >500; største 1265 | Audit-fakta (filsystem-skann) | Verifisert |
+| 384/387 filer >100 linjer mangler TOC; N4 vekt 1/23, ikke gulv | Audit + `skill-score.mjs` | Verifisert |
+| 500-linjers-regel gjelder SKILL.md-body; ref-filer har «no context penalty until accessed»; TOC anbefalt >100 linjer | platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices | Verifisert (Anthropic) |
+| Spor D scorer per SKILL strukturelt; K8 sjekker header-*tilstedeværelse*, ikke sannhet; scorer 91–96, 0 stale | `skill-score.mjs`, `change-report.json` | Verifisert |
+| Kun 7/389 filer har `**Source:**`-header; kun 3 URL-er har `authority_source` | `authority.mjs` / registry (adversariell kritikk) | Verifisert |
+| 306/389 filer dekket av ≥1 pollet URL; 83 uten kilde; 309 URL-er `not_in_sitemap`; median 7 kilder/fil | `url-registry.json`, Akse 4 | Verifisert |
+| `report-changes` er ren lastmod-aritmetikk; fetch er separat Claude-i-loop apply-steg mot ÉN kilde | `run-weekly-update.mjs`, `report-changes.mjs`, `transform-prompt.md` | Verifisert |
+| Groundedness/faithfulness = dekomponer i påstander + entailment mot kilde | RAGAS (docs.ragas.io), Azure Content Safety Groundedness (learn.microsoft.com) | Verifisert (WebSearch) |
+| sitemap `<lastmod>` er upålitelig; innhold kan endres uten bump | yoast.com/lastmod-xml-sitemaps-google-bing | Verifisert |
+| `microsoft_docs_fetch` er Claude-i-loop MCP, ikke Batch-API ⇒ ikke −50 %-batchbar | microsoft-learn MCP tool-instruksjoner; Akse 4 ~2700 fetch-estimat | Verifisert — korrigerer Akse 2s «$20–40 Batch» |
+| Anthropic foreskriver ingen ref-fil-metadata; «avoid time-sensitive information» | Anthropic best-practices | Verifisert |
+| **Base-raten av faktiske korrekthets-feil** | Ingen — aldri målt | **IKKE VERIFISERT** — dette er det avgjørende manglende inputet |
+| ROI av judge *over* eksisterende staleness-loop (feil uten lastmod-endring) | Ingen tallfesting i noen akse | **IKKE VERIFISERT** |
+| Premiss-avvik: «navngitt 169 / mappe 220» (audit) vs «151 navngitt / 238 mappe-only» (Akse 1) | `ref-file-audit.py` re-kjørt 2026-06-26 → reproduserbart 169/220/0 | RECONCILED — 169/220/0 autoritativt; 151/238 (ikke-reproduserbart engangsanslag) forkastet. Immaterielt: intet tiltak kjører på named/folder-grensen, kun «0 orphans» (begge enige) |

docs/ref-kb-gold-reconciliation-2026-06.md

@@ -0,0 +1,123 @@
+# Gull-rekonsiliering (Spor 2b) — herding av fasiten før korpus-skala
+
+_Opprettet 2026-06-30. Utfører Spor 2(b) i `ref-kb-correctness-program-2026-06.md` §3: «løs hver judge-vs-gull-uenighet (v2: 6 FP + 6 FN) mot live kilde. Hver er enten judge-feil ELLER gull-feil; å løse dem kalibrerer judgen OG retter fasiten. Mål: 0 uløste uenigheter.» Gjøres FØR Spor 1 (korpus-pass) — bunnsolid fasit før vi skalerer målingen (§6 avhengighet)._
+
+## Sammendrag
+
+12 uenigheter mellom v2-judgen og gull-settet (`gold-correctness-set.json`) ble løst ved fersk re-henting av hver siterte kilde (Opus 4.8-subagenter, `microsoft_docs_fetch`, read-only). Resultat:
+
+- **4 gull-feil** (gull-verdikt rettet) + **1 note-fiks** (verdikt beholdt).
+- **8 judge-feil** (gull sto; dokumentert som kalibreringsmål for Spor 2a / judge-prompt-v3).
+- **0 uløste uenigheter** — hver av de 12 er adjudisert til en definitiv side med verbatim live-belegg.
+
+Effekt på målingen (judgen var **bedre** enn rå-bakeoffen viste — fasiten var kontaminert):
+
+| | TP | FP | FN | TN | presisjon | recall | F1 |
+|---|---|---|---|---|---|---|---|
+| v2 rå fasit (`judge-bakeoff-report-v2`) | 32 | 6 | 6 | 196 | 84,2 % | 84,2 % | 0,842 |
+| **v2 herdet fasit (`-v2-reconciled`)** | **35** | **3** | **5** | **197** | **92,1 %** | **87,5 %** | **0,897** |
+
+Den frosne `judge-bakeoff-report-v2` beholdes urørt som gate-beslutnings-artefakt (pre-registrert gate ble vurdert på den fasiten). `judge-bakeoff-report-v2-reconciled` viser herdet fasit.
+
+## Resolusjonsprinsipp (konservativt — tillit-bærende fasit)
+
+For hver uenighet: finn den **sanne** verdikten mot live kilde.
+- Sann ≠ gull → **gull-feil**: rett gull-verdikt.
+- Sann = gull → **judge-feil**: gull står, judge føres som kalibreringsmål.
+- Flytt gull **kun** der den sanne verdikten genuint avviker. En påstand som er *substansielt korrekt men upresis* (rett størrelsesorden / rett kjerneatferd) blir stående `correct`, og judge-flagget føres som over-streng.
+
+Verdikt-vokabular: `correct` (matcher dagens kilde) · `outdated` (var sant, kilden viser nå annet) · `wrong` (aldri sant / motsier kilden uten historisk grunnlag) · `unsourced` (kilden oppgir ikke verdien).
+
+## Nedre-grense-policy (§3-kjennelse, godkjent av operatør 2026-06-30)
+
+§3 ber gull avgjøre om nedre-grense-påstander («100+», «200k+») teller som feil. **Vedtatt policy:** grov understatement (>~2×, beslutnings-endrende) teller som feil; en *stram* nedre grense (sann verdi i samme størrelsesorden) blir stående `correct`. Anvendt på FN2 (200k+ vs ~1M ⇒ `outdated`).
+
+## De 12 adjudiseringene
+
+### FP-er (judge flagget `not_grounded`, gull var `correct`)
+
+| ID | Live ground truth (verbatim-belagt) | Sann | Resolusjon |
+|---|---|---|---|
+| **FP1** `azure-ai-foundry.md#2` (taxonomy) | `what-is-foundry`: «over 1,900 models from Microsoft, OpenAI, Anthropic…» = HELE katalogen; «sold by Azure» er en delmengde. «11000+» og «40+ regioner» finnes ikke (kun «most regions where Foundry Tools are available») | **wrong** | 🔴 GULL-FEIL `correct→wrong` |
+| **FP2** `multimodal-prompt-design.md#7` (taxonomy) | `multimodal-search-overview`: image-to-vector ved query krever multimodal-embedding-vectorizer, men TO veier — AML-skill ELLER Azure Vision. «kun» utelukker AML-veien | **wrong** | 🔴 GULL-FEIL `correct→wrong` |
+| **FP3** `rag-cost-optimization.md#8` (taxonomy) | `vector-search-how-to-quantization`: «up to 96% reduction» / «up to 28 times» (claim 96,875% = teoretisk 32x ≈). «92,5%» = MS blogg-tittel (reell MS-figur, kombinerte teknikker) | **correct** (substansielt; begge tall sporer til MS) | 🟡 JUDGE-FEIL (eksakt-streng-pedanteri) |
+| **FP4** `multi-region-ai-gateway-design.md#2` (taxonomy) | `deployment-types`: 3 kjerne-residency-atferder bekreftet (Standard=deployment-region, DataZone=US/EU-sone, Global Standard=any region). Global Provisioned=any region (ikke single-region) | **correct** (men note «alle fire ordrett» overdrev) | 🟡 JUDGE-FEIL + note-fiks |
+| **FP5** `service-level-documentation-dr.md#6` (taxonomy) | `distribute-data-globally`: «Build global active-active apps… every region supports both writes and reads» — multi-region-write reell | **correct** | 🟡 JUDGE-FEIL (ekte FP — kapabilitet-bom) |
+| **FP6** `ai-foundry-disaster-recovery-planning.md#9` (status) | `openai/concepts/models`: Global training = GA (per-modell), ikke Public Preview; «billigere» + «ingen residency» stemmer; men Norway East er en GLOBAL trenings-region, ikke residency-regional | **outdated** | 🔴 GULL-FEIL `correct→outdated` |
+
+### FN-er (judge `grounded`/`source_silent`, gull var feil)
+
+| ID | Live ground truth | Sann | Resolusjon |
+|---|---|---|---|
+| **FN1** `real-time-reasoning-performance.md#5` (region) | `realtime-audio` + WebRTC/SIP/WebSockets-søsken: Realtime = global deployment-type i NØYAKTIG East US 2 + Sweden Central. To-region-grensen IKKE avløst — gull misleste «global deployments» | **correct** | 🔴 GULL-FEIL `outdated→correct` |
+| **FN2** `rag-context-windows.md#2` (version) | `models-sold-directly-by-azure`: GPT-4.1 = **1 047 576** (~1M); praktisk 300k std. «200k+» sann nedre grense men understater ~5× | **outdated** (nedre-grense-policy) | 🟡 JUDGE-FEIL |
+| **FN3** `llm-evaluation-production.md#3` (sku) | Databricks `mlflow3/.../judges`: Completeness/Fluency/Equivalence finnes ikke i dagens built-in-liste (`ConversationCompleteness` er en distinkt multi-turn-judge) | **outdated** | 🟡 JUDGE-FEIL (`source_silent` maskerte fravær) |
+| **FN4** `endpoint-health-and-capacity-planning.md#3` (tpm) | `openai/quotas-limits`: «1 Unit Capacity»-rammen borte → Quota Tiers (Free/Tier 0–6, absolutte RPM/TPM). Ratioene overlever i tier-tabellene | **outdated** | 🟡 JUDGE-FEIL (ramme-skifte, tall overlever) |
+| **FN5** `capacity-planning-dr-configurations.md#3` (status) | `reliability-ai-search` + `cognitive-search-common-errors-warnings`: ingen 99,99%-nivå — SLA er 99,9%; 2 vs 3 replikaer = lese vs lese-skrive (begge 99,9%) | **wrong** | 🟡 JUDGE-FEIL (`source_silent` maskerte faktafeil) |
+| **FN6** `rag-query-cost-reduction.md#2` (sku) | `search-limits-quotas-capacity`: claim-tallene matcher kun «Before April 3, 2024»-raden; nå Basic 15/S1 160/S2 512/S3 1024 GB | **outdated** | 🟡 JUDGE-FEIL (matchet legacy-rad) |
+
+## Gull-endringer (anvendt 2026-06-30)
+
+| ID | Før | Etter | Begrunnelse (kort) |
+|---|---|---|---|
+| `azure-ai-foundry.md#2` | correct | **wrong** | «11000+» motsier live «1900+ totalt»; «sold by Azure» mis-tilskriver totalen |
+| `multimodal-prompt-design.md#7` | correct | **wrong** | «kun» utelukker AML-skill (dokumentert annen vectorizer) |
+| `ai-foundry-disaster-recovery-planning.md#9` | correct | **outdated** | Global training er GA, ikke Public Preview; Norway-East-framing feil |
+| `real-time-reasoning-performance.md#5` | outdated | **correct** | to-region-grensen står; gull misleste kilden |
+| `multi-region-ai-gateway-design.md#2` | correct | _correct_ (note-fiks) | fjernet «alle fire ordrett»; noterte Global-Provisioned-unntaket |
+
+Hver endret claim bærer en `RECONCILED 2026-06-30 (Spor 2b)`-tag i `notes` med live-belegg + fil-fiks-peker for Spor 0/1.
+
+## 8 judge-kalibreringsmål (mater Spor 2a / judge-prompt-v3)
+
+Disse er **ikke** gull-endringer — gull sto, judgen bommet. Grupperte feilmoduser:
+
+1. **Eksakt-streng-pedanteri (FP3):** judge flagget fordi eksakt-strengene (96,875% / 92,5%) ikke sto verbatim, selv om størrelsesorden og kilde-sporing var rett. → Judge bør tillate dokumentert teoretisk-vs-benchmark-ekvivalens.
+2. **Taksonomi-nyanse / over-streng (FP4):** kjerneatferden var grunnet; judge flagget på en utelatt under-kategori. → Judge bør skille «kjernen grunnet, detalj utelatt» fra «kjernen ugrunnet».
+3. **Kapabilitet-bom (FP5):** judge hentet evidence-URL (continuous-backup) som ikke nevner kapabiliteten prominent, og kunne ikke grunne en reell kapabilitet. → Judge bør følge kapabilitet til kanonisk side; ikke straffe illustrative tall (~0 RTO/RPO) når kapabiliteten er solid.
+4. **Nedre-grense-understatement (FN2):** judge sa `grounded` fordi 1M ≥ 200k. → Judge bør flagge nedre grenser som grovt understater (>~2×), ikke bare sjekke ≥.
+5. **`source_silent` maskerer fravær (FN3, FN5):** judge hentet siden, fant ikke de påståtte entitetene/tallene, og returnerte `source_silent` (ikke et flagg). For «X finnes i listen»-påstander er fravær på autoritativ side bevis FOR feil. → Behandle `source_silent` på eksistens-påstander som svakt not_grounded-signal.
+6. **Ramme-skifte, tall overlever (FN4):** judge pattern-matchet overlevende ratioer og overså at organiserings-rammen (1 Unit Capacity → Quota Tiers) var avløst. → Judge bør detektere når påstandens ramme/enhet er erstattet selv om avledede tall holder.
+7. **Legacy-rad-match (FN6):** judge matchet mot en tids-stemplet historisk tabellrad («Before April 3, 2024») og kalte det grunnet. → Judge må sammenligne mot GJELDENDE rad, ikke en hvilken som helst historisk rad.
+
+(FP3, FP4, FP5 = 3 FP; FN2, FN3, FN4, FN5, FN6 = 5 FN.)
+
+## Verifiseringslogg (nøkkelpåstander → kilder)
+
+| Påstand | Kilde (live, 2026-06-30) |
+|---|---|
+| 1900+ = hele katalogen, ikke «sold by Azure» | learn.microsoft.com/azure/foundry/what-is-foundry |
+| image-to-vector: AML-skill ELLER Azure Vision | learn.microsoft.com/azure/search/multimodal-search-overview |
+| binary quant «up to 96% / 28x»; 92,5% = blogg-tittel | learn.microsoft.com/azure/search/vector-search-how-to-quantization |
+| Global Provisioned = any region | learn.microsoft.com/azure/foundry/foundry-models/concepts/deployment-types |
+| Cosmos multi-region writes (active-active) | learn.microsoft.com/azure/cosmos-db/distribute-data-globally |
+| Global training = GA; Norway East = global-region | learn.microsoft.com/azure/ai-foundry/openai/concepts/models |
+| Realtime = East US 2 + Sweden Central (global type) | learn.microsoft.com/azure/foundry/openai/how-to/realtime-audio (+ WebRTC/SIP/WebSockets) |
+| GPT-4.1 kontekst = 1 047 576 | learn.microsoft.com/azure/foundry/foundry-models/concepts/models-sold-directly-by-azure |
+| MLflow built-in judges (ingen Completeness/Fluency/Equivalence) | learn.microsoft.com/azure/databricks/mlflow3/genai/eval-monitor/concepts/judges/ |
+| Quota Tiers erstatter Unit Capacity | learn.microsoft.com/azure/foundry/openai/quotas-limits |
+| AI Search SLA = 99,9% (ingen 99,99%); 2 vs 3 = lese vs lese-skrive | learn.microsoft.com/azure/reliability/reliability-ai-search (+ cognitive-search-common-errors-warnings) |
+| AI Search storage nå Basic 15/S1 160/S2 512/S3 1024 | learn.microsoft.com/azure/search/search-limits-quotas-capacity |
+
+## Hva som IKKE ble gjort (scope-grense)
+
+Spor 2b retter **fasiten** (gull-settet), ikke reference-`.md`-filene. Fil-fiksene (FP1 11000+/40+, FP2 «kun», FP6 Public-Preview/Norway-East, FN2–FN6 utdaterte tall) er **Spor 0/1**-arbeid og er pekt ut i hver claims `notes`. Mange av FN-ene er reelle korpus-feil som hører til Spor 0-manifestet / Spor 1-korpus-passet.
+
+## Addendum — etterfølgende gull-friskhets-flips (G5 + G5b, kanonisk logg i programdok §8)
+
+Spor 2b var ikke siste ord: gull-fasiten eldes (G5-gapet). Senere friskhets-passes (full logg + belegg i `ref-kb-correctness-program-2026-06.md` §8 lukke-logg) flyttet ytterligere **6 gull-verdikt** mot live MS Learn. Samlet flip-ledger for komplett sporbarhet:
+
+| Pass | Claim | Før | Etter | Retning |
+|---|---|---|---|---|
+| 2b | `azure-ai-foundry.md#2` | correct | wrong | for streng gull → feil avslørt |
+| 2b | `multimodal-prompt-design.md#7` | correct | wrong | — |
+| 2b | `ai-foundry-disaster-recovery-planning.md#9` | correct | outdated | — |
+| 2b | `real-time-reasoning-performance.md#5` | outdated | correct | gull for streng → rettet |
+| **G5** | `genaiops-llm-specific-practices.md#2` | outdated | **correct** | aldrende gull (1600+ vs live 1900, tett nedre grense) |
+| **G5** | `model-selection-price-performance.md#8` | outdated | **correct** | aldrende gull (Model Router GA nov 2025) |
+| **G5b** | `adr-template.md#1` | correct | **wrong** | stale gull (Graph connectors krever ACL) |
+| **G5b** | `multi-region-azure-openai-deployment.md#2` | correct | **outdated** | stale gull (gpt-35-turbo retired) |
+| **G5b** | `network-resilience-patterns-ai.md#4` | correct | **wrong** | stale gull («obligatorisk» vs «recommended») |
+| **G5b** | `vector-storage-cost-optimization.md#7` | correct | **wrong** | stale gull (GA-dato 2024-07-01, ikke 2024-11-01-preview) |
+
+**Mønster:** gull-friskhet inverterte adopsjonskonklusjonen **to ganger** (G5 og G5b). Re-adjudering av omstridt gull mot live FØR en baseline stoles på er nå fast disiplin ([[gold-freshness-can-invert-adoption]]), knyttet til §7 friskt utvalg. Effekt på adoptert baseline: v3 målt **P 100 % / R 92,9 % / 0 FP** på G5b-korrigert gull (`judge-bakeoff-report-v3-g5bgold.{json,md}`).

docs/ref-kb-workflow-plan-2026-06.md

@@ -0,0 +1,179 @@
+# Plan — Reference-fil-kvalitet + hele workflowen rundt den (de 389 skill-refs)
+
+> **SUPERSEDED (2026-07-03):** Videreført av `docs/ref-kb-correctness-program-2026-06.md` (kanonisk program: fire spor + mekanismen + §8 gap-register) og sekvensert av `docs/plugin-roadmap-2026-07.md` (R0–R18). Dette dokumentet beholdes som historisk grunnlag (Fase 0–4-analysen + roadmap-utledningen) — ikke oppdatert etter 2026-06.
+
+_Opprettet 2026-06-26. Dette er KJERNEN i ms-ai-architect: innholdet i skills' reference-filer + maskineriet som lager og oppdaterer dem. Kvalitetsbar: svært høy. Operatør-rettesnor: «brukerverdi > teknologi; oppdateringsmekanismene må fungere veldig bra; ta god tid; faktabasert.» Grunnlag: `docs/ref-kb-audit-2026-06.md` (verifisert ground truth), `docs/ref-kb-direction-note-2026-06.md` (workflow-analyse + adversariell kritikk)._
+
+## Avgjorte premisser (ikke re-litiger — bekreftet 2026-06-26)
+1. **De 389 forblir Claude Code skill-references.** Skills-vs-OKF-bake-off for MS Learn-kunnskapen er DREPT som kaninhull — Anthropic-best-practice ER den flate skill-ref-strukturen; ingen indikasjon på at OKF slår skills. Begrunnelse: direction-note + [[okf-scope-second-brain-only]].
+2. **OKF gjelder kun brukerens «second brain»** (eget spor, senere — `docs/okf-second-brain-brief-2026-06.md`).
+3. **#1 (utvid Spor D med korrekthets-kriterium) er forkastet** — kategorifeil (Spor D scorer per skill; korrekthet er per-fil/per-påstand).
+4. **Struktur er allerede sunn** (skills 91–96, 0 stale). Det umålte er INNHOLDS-korrekthet. Derfor: ikke masseoppdel filer; store on-demand-filer er Anthropic-sanksjonert.
+
+## Mål (suksesskriterium — måles mot brukerverdi, ikke teknologi)
+Reference-innholdet er **korrekt + ferskt + godt strukturert**, og create-/update-workflowen holder det slik **pålitelig og automatisk**. Konkret: (a) en bruker som chatter får korrekte, oppdaterte MS-svar; (b) oppdateringsmekanismen fanger reell drift, ikke bare lastmod-bump; (c) nye ref-filer fødes best-practice-konforme (workflowen regresserer ikke).
+
+---
+
+## Fase 0 — Gull-testsett + base-rate-måling (FUNDAMENT — gater Fase 3)
+**Hvorfor først:** alle fem analyse-akser hoppet fra «vi måler ikke korrekthet» til «bygg system» uten å vite om korrektheten faktisk er dårlig. KB scorer 91–96 med 0 stale — null bevis for et korrekthets-problem, kun fravær av bevis. Å bygge en $-per-kjøring-detektor før base-raten er kjent er feilallokering.
+
+**Gjør:**
+- Trekk et **stort nok, stratifisert** utvalg ref-filer/påstander (start ~30–40 filer; vurder utvidelse), **vektet mot volatile påstander** (pris/SKU, GA/preview, versjoner, regioner) på tvers av alle 5 skills.
+- Verifiser hver manuelt mot **live MS Learn** (microsoft_docs_fetch/search). Merk per påstand: korrekt / utdatert / feil / ikke-kildegrunnet.
+- Persister som **gjenbrukbart gull-sett** (det dobler som evaluerings-harness for en evt. bake-off + judge-kalibreringssett).
+
+**Verifisering (testbart):**
+- ≥30 filer merket, feilrate beregnet med usikkerhetsbånd; gull-settet lagret som artefakt (f.eks. `scripts/kb-eval/data/gold-correctness-set.json`).
+- Eksplisitt funn: hvor mange feil finnes UTEN lastmod-endring (= den eneste klassen en judge fanger over eksisterende staleness-loop).
+
+**Beslutnings-gate ut av Fase 0:**
+- Lav feilrate (~few %) ⇒ judge IKKE berettiget; staleness + periodisk stikkprøve holder. Hopp over Fase 3.
+- Høy feilrate ⇒ evidensbasert grunnlag for Fase 3; gull-settet er allerede kalibreringssettet.
+
+### Utførelses-spec (LOCKED 2026-06-26 — operatør-beslutning; fersk sesjon eksekverer)
+_Fase 0-verifiseringen er bevisst utsatt til en uthvilt sesjon (retnings-avgjørende; var økt #20 da den ble planlagt). Denne spec'en er forankret så den ferske sesjonen kjører deterministisk uten å re-derivere. Sample-frame-scriptet er IKKE bygd ennå — det er steg 1 i den ferske sesjonen (TDD)._
+
+**Recon-funn (ground truth 2026-06-26 — ikke re-verifiser, men bekreft mot `git`/registry hvis tvil):**
+- **Verifiserbar populasjon = 306/389 ref-filer** (de som siterer ≥1 MS Learn-URL). De resterende **83 er kildeløse** (maler/metodikk) → utenfor korrekthets-scope.
+- **Kilde-mapping uten authority-backfill:** inverter `scripts/kb-update/data/url-registry.json` → `urls{}` (1353 entries), hver med `reference_files[]`. Invertert gir **fil → [siterte URL-er]** (median 7/fil). Verifiser en påstand mot filens egne siterte kilder; fall tilbake på `microsoft_docs_search` om ingen treffer påstanden. (Kun 3 entries har `authority_source` satt — IKKE en blokker for Fase 0.)
+- **Volatile påstander er tette i:** `cost-optimization/`, `platforms/`, og SKU/TPM/PTU/pris/region/versjon/«preview»/«GA»-tette filer. Eksempel verifisert: `ptu-vs-paygo-economics.md` (GPT-5 4750 TPM/PTU, PTU-minimums per modell, deployment-taksonomier — hver med *selv-erklært* `✅ Verified`, aldri eksternt sjekket).
+- **Gjenbruk K9-grensen** i `scripts/kb-eval/judge-prompt.md` for å klassifisere påstand som volatil vs. stabil identifikator (forordningsår, OWASP-versjonsnavn, MADR v3.0, lovsaksnr er IKKE volatile).
+
+**Locked beslutninger:**
+- **Utvalg: ~45 filer volatil-vektet + kontroll-stratum** (~8–10 stabile-påstand-filer). Rapporter BÅDE volatil feilrate (øvre grense — der feilene bor) OG stabil sanity-rate.
+- **Stratifisering:** balansert på tvers av de 5 skills, oversample de volatil-tette (security/engineering/advisor-cost+platforms), kontroll-stratum fra methodology/regulatory.
+
+**Metode (4 steg):**
+1. **Sample-frame** (`scripts/kb-eval/build-sample-frame.mjs`, NY, TDD-først): scor de 306 filene på volatilitets-signaler (sti + innholds-tetthet av SKU/pris/TPM/region/versjon/preview/GA), stratifiser → skriv `scripts/kb-eval/data/fase0-sample-frame.json` (45 volatile + kontroll, deterministisk/seedet rekkefølge — ingen `Math.random`). Verifisering: gjenkjørbar, samme input → samme utvalg.
+2. **Per-fil verifisering via subagenter** (Opus 4.8 xhigh, parallelt — agent-strategi; subagenter committer ALDRI): hver subagent får en batch (~4–5 filer). Per fil: ekstraher volatile påstander → hent siterte kilde(r) via `microsoft_docs_fetch`/`_search` → entailment-sjekk hver påstand → merk verdict + bevis. Returner strukturert JSON (schema under).
+3. **Aggreger** (`scripts/kb-eval/compute-base-rate.mjs`, NY, TDD-først): feilrate + **Wilson score-intervall** (95 %), brutt ned per skill + per volatilitets-klasse, OG **delmengden feil UTEN lastmod-endring** (= eneste klasse en judge fanger over staleness-loopen). Skriv base-rate-rapport.
+4. **Gate-beslutning** (over) → noter i STATE + plan.
+
+**Gold-set JSON-schema** (`scripts/kb-eval/data/gold-correctness-set.json`, gjenbrukbart — dobler som Fase 3-kalibreringssett):
+```
+{ "_meta": { "created": "...", "method": "...", "sample_frame": "fase0-sample-frame.json" },
+  "claims": [ {
+    "id": "<skill>/<relpath>#<n>", "file": "<relpath>", "skill": "...",
+    "claim": "<ordrett påstand>", "claim_type": "sku|price|tpm|region|version|status|taxonomy|stable",
+    "stratum": "volatile|control",
+    "verdict": "correct|outdated|wrong|unsourced",
+    "evidence_url": "<MS Learn URL brukt>", "evidence_quote": "<sitat som av-/bekrefter>",
+    "lastmod_changed": true|false,   // har filens siterte kilde endret sitemap_lastmod siden filens dato?
+    "notes": "..." } ] }
+```
+
+**Eksklusjoner (teller IKKE som feil):** påstander eksplisitt merket illustrative («forenklede tall», eksempel-NOK), og stabile identifikatorer (K9-grensen).
+
+**Verifisering (testbart, fra planen + locked):** ≥45 volatile-filer merket; Wilson-bånd beregnet; gull-sett + sample-frame lagret som artefakter; eksplisitt tall for «feil uten lastmod-endring»; begge nye scripts har failing-test-først (Iron Law).
+
+### Fase 0 → GATE (BESLUTTET 2026-06-26): **BYGG Fase 3 — scoped/hybrid**
+
+Rapport: `scripts/kb-eval/data/base-rate-report.{json,md}` (deterministisk fra `gold-correctness-set.json`, 373 påstander, via testet `lib/base-rate.mjs`). Beslutningen følger gate-kriteriet (over) + per-claim_type-konsentrasjonen:
+
+1. **Feilraten klarer baren.** Verifiserbar feilrate **13,4 % (40/299)**, Wilson 95 % **[10,0 %, 17,7 %]**. Nedre bånd 10 % ≫ «~few %» ⇒ «lav feilrate ⇒ hopp over Fase 3»-grenen er utelukket med 95 % konfidens.
+2. **Det billige alternativet fanger ingenting.** Staleness-recall = **0/40 = 0 %**. Ingen av de 40 reelle feilene har `lastmod_changed=true` (false=37, null=3) — de er bakt inn ved fil-skriving, eller MS Learn sitemap_lastmod er for grovt til å fange endringen. En korrekthets-judge er ENESTE automatiske mekanisme som fanger dem. **CAVEAT løst:** registry `last_poll=2026-06-23` er ferskere enn 32/40 fildatoer (ville fanget en post-fildato sitemap-endring om den fantes); de 8 feilene i filer dat. 2026-06-24 er ~2 dager gamle ⇒ kan ikke ha drevet ennå. `true=0` er reelt signal, ikke stale-registry-artefakt.
+3. **Feilene konsentreres der en fetch-judge virker.** Per claim_type: **sku 36,4 % (8/22), version 25,0 % (8/32), tpm 20,0 % (5/25)** — alle nær fullt hentbare (sku 0 unsourced, version 1, tpm 5). Høyt utbytte + høy rekkevidde.
+4. **Pris er ute av scope — av data, ikke antakelse.** 76 pris-påstander, **56 unsourced (74 %)**. «0/20 = 0 %» pris-feilrate er en **falsk null** (74 % kunne ikke sjekkes — ikke at de er korrekte). JS-rendrede Azure-prissider beseirer `microsoft_docs_fetch` ⇒ en fetch-basert judge når dem heller ikke. Pris er 56 av 74 unsourced (76 %); resten av korpuset er 18/297 unsourced (**6 %**) ⇒ den uverifiserbare massen er **isolert til pris**, ikke spredt.
+
+**Scope for Fase 3-judgen:** kun fetchbare claim_types — `taxonomy|status|version|tpm|sku|region` (297 påstander, 94 % hentbare, bærer 100 % av de verifiserbare feilene). `claim_type=price` flagges «ikke maskinverifiserbar» ⇒ **operatør-gated, ikke judge-gated**. Forutsetningene i Fase 3-seksjonen (autoritets-backfill, full frontmatter/Fase 2, judge-kalibrering mot dette gull-settet før tallene stoles på) gjelder uendret før judgen tas i bruk. Gull-settet (373 påstander) er kalibreringssettet.
+
+---
+
+## Fase 1 — Trygge, retnings-uavhengige grep (kan kjøres parallelt med Fase 0)
+Lav risiko, forbedrer workflowen uansett senere valg. **NB: koordiner advisor-filer mot Cosmo-utfasing** (samme skill — se gating-valg).
+
+### 1a. Update-mekanisme: registry-herding (operatørs prioritet)
+- ✅ **A — LEVERT (`e74646d`, 2026-06-26):** la `graph`/`ai-builder`/`power-apps`/`power-automate`/`microsoftsearch` i sitemap-prefiksene (taxonomy `sitemap_prefixes`, 18→23 — alle 5 docsets ett child-sitemap, verifisert live mot indeksen). **Bevist read-only: 21/24 not_in_sitemap-URL-er i disse docsetene blir tracked.**
+- ✅ **B — LEVERT (`e74646d`):** `extractUrls`/`normalizeUrl` fanger skjemaløse siteringer (krever `/path` etter domenet → avviser bare-domene-prosa + JSON-eksempler; kanonikaliserer scheme til https). **Bevist: +19 URL-er ekstraherbare.** Bonus-bugfix: backtick-lekkasje fra inline-kode-citat. TDD: ny `test-url-normalize` (14) + taxonomy-test 18→23. Suite 338/338.
+- ⏸️ **C — UTSATT → Cosmo (operatør 2026-06-26):** redirect-følging for 44 legacy `/microsoft-365-copilot/...` + 3 omdøpte microsoftsearch. 20/21 filer er advisor → foldet inn i Cosmo-utfasingen (root-cause citat-fiks, ikke ny redirect-map-mekanisme). Se `docs/cosmo-removal-brief-2026-06.md`. Slug-rename verifisert → krever ekte redirect-resolusjon, ikke streng-rewrite.
+- ⏸️ **Registry-refresh utsatt til kadens (operatør 2026-06-26):** A+Bs +21/+19 lander når neste `build-registry --merge` + poll kjører; effekten er allerede empirisk bevist read-only. Unngår 552KB re-order-churn nå.
+
+### 1b. Create/struktur: TOC på de største filene
+- Legg innholdsfortegnelse i de **~20–29 filene >800 linjer** (ikke alle 384 — partial-read er kun plausibelt på de største under whole-file-routing). Skript for konsistent TOC-format.
+- **Verifisering:** `eval.mjs checkN4 hasToc` = true for de filene; ingen diff-churn på små filer.
+
+### 1c. Create-time: hindre regresjon i generatoren
+- Oppdater `scripts/kb-update/lib/transform.mjs buildKbHeader`/`validateKbFile` (og evt. `generate-skills`) så NYE/regenererte filer fødes best-practice-konforme (TOC hvis stor; konsistent header). **MÅ gjøres før/sammen med 1b**, ellers regenererer neste KB-update prosa-headere og reverserer arbeidet (write-path-regresjon).
+- **Verifisering:** kjør generatoren på en testfil; output har TOC + kanonisk header.
+
+---
+
+## Fase 2 — Metadata-substrat (minimal; full versjon betinget av Fase 3)
+- **Minimal type-tag** for hver fil: `reference` | `template` | `methodology` | `regulatory`. Formål: skille de 83 «kildeløse» legitimt (maler/metodikk som `decision-trees`, `cost-models` skal ALDRI ha MS-kilde) fra MS-faktapåstander-uten-kilde (maskin-detekterbart defekt). Kan være sidecar-manifest eller mappekonvensjon — IKKE full YAML-frontmatter ennå.
+- **Full frontmatter** (`type`/`source`/`verified`, OKF-kompatibel form) bygges KUN hvis Fase 3-judgen skal bygges (da trenger den per-fil `source`+`verified` deterministisk). Over-engineering ellers — `report-changes` tolererer alt 3 dato-mønstre i dag.
+- **Verifisering:** hver av 389 filer klassifisert; de 83 kildeløse delt i to bøtter; judge (hvis bygd) skipper `template`/`methodology`.
+
+---
+
+## Fase 3 — Korrekthets-mekanisme (GATED av Fase 0; bygg kun hvis berettiget)
+**Retning (hvis bygd): #2 som enhet (per-fil korrekthetsdom) på #3s substrat (KB-refresh-pipelinen) — aldri #1.**
+- Per-fil groundedness-judge (Opus 4.8 xhigh): hent filens utpekte autoritet → `microsoft_docs_fetch` → dekomponer i påstander → entailment-sjekk hver mot kilden (RAGAS/Azure Groundedness-mønster) → score = supported/total + liste over ugrunnede/motstridende påstander. Persister analogt til `skill-score-report.json`, men per fil, med «sist verifisert korrekt»-stempel.
+- **Forutsetninger før bygging:** (a) autoritets-backfill — kun 3 URL-er har `authority_source`, 7 filer har `**Source:**`-header i dag; (b) full frontmatter (Fase 2); (c) kalibrer judgen mot Fase 0-gull-settet før tallene stoles på (judge claim-dekomponering er brittle — verifiseringsplikt).
+- **«Bygg begge og mål»** (operatørs metodikk) er tilgjengelig her: staleness-flagg vs judge vs hybrid, målt på gull-settet — men **kun på den volatile populasjonen** (der feilene bor; ikke kår en vinner på stabile påstander).
+- **Kjente feller (fra kritikk):** invertert leverage (judgen auto-scorer stabile lav-risiko-påstander; volatile forblir operatør-gated); kostnad er ~2700 ikke-batchbare `microsoft_docs_fetch` per full-pass (IKKE «$20–40 Batch»); judgen fjerner ikke verifiseringsplikten (flytter den fra «stikkprøv KB» til «kalibrer judge»).
+- **Verifisering:** judge presisjon/recall mot gull-settet ≥ avtalt terskel; staleness-gated inkrement + periodisk full-pass; volatile påstander forblir operatør-gated.
+
+---
+
+## Fase 4 — Integrasjon & styring
+- Fold valgt mekanisme inn i KB-refresh-kadens (ikke SessionStart — for dyrt). Spor D viser en tynn PEKER til innholds-scoren, ikke et sammenslått tall. CT5 (sourcedness) ERSTATTER K8s rolle (ikke parallelt).
+- Judge-gulv skal være **rapporterende** (worstFile + countBelow), ikke en hard SessionStart-gate, før judgen er kalibrert — ellers alarm-tretthet/waiver-spam på et brittle signal.
+- **Verifisering:** SessionStart-hook surfacer innholds-signal uten falske regresjons-alarmer; operatør-waiver-sti finnes.
+
+---
+
+## Noterte rester (uavhengig av fase-gating)
+- **✅ `✅ Verified`-trust-hazard — LØST 2026-06-26 (`83fd9b5`).** Premiss-sjekk myknet og innsnevret hazardet: «Verified» var **for det meste provenansbærende**, ikke et tomt stempel. To populasjoner: (a) **101 `✅ Verified`-konfidens-celler i 13 filer** — grønn hake + «Verified» uten nabokilde = det reelle (men myke) over-signalet; legend i `m365-copilot-plugins-ecosystem.md` definerte det faktisk som «hentet fra MS Learn via MCP» = `Documented`. (b) **142 plain `Verified`-celler i 31 kilde-attribusjons-tabeller** — nabokolonnen ER kilden (proveniens til stede). **Operatør valgte smal fix (A):** (a) → `✅ Documented` + 5 kolonne-overskrifter + skill-gen-taksonomien (`Verified/Baseline/Assumed` → `Documented/Baseline/Assumed`); (b) LA STÅ (degraderer ærlige celler). Suite 509/509. **Åpent (operatør):** versjonsbump/release for denne content-endringen — se under.
+- **Versjonsbump for `83fd9b5`?** Ref-fil-innhold er user-facing flate, men dette er label-ærlighet (ikke kapabilitet). Anbefaling: ingen bump nå; batch release med neste substansielle endring (Fase 0-utfall / Cosmo). Operatør avgjør.
+
+## Gating-valg for operatør (avklares før relevante faser)
+1. **Mål-først (anbefalt) vs bygg-begge-direkte.** ✅ LØST av Fase 0-gaten: bygg-begge-og-mål på volatil populasjon i **S3** (se roadmap under). Begge krevde gull-settet — nå levert (373 påstander, frosset).
+2. **Cosmo-sekvensering.** Struktur-/tag-arbeid på `ms-ai-advisor` (lavest score 91 + hjem til `adr-template`) kolliderer med godkjent Cosmo-utfasing (samme skill). Vente til Cosmo er ute, eller koordinere? Påvirker Fase 1b/1c/2 for advisor-filer.
+3. **N4-revekting.** Håndheve TOC-regelen reelt (re-vekt N4 / skaler med filstørrelse)? Drar 91–96 midlertidig under 90 → Spor D-alarm. Policy, ikke defekt.
+
+## Premiss reconciled (AVKLART 2026-06-26)
+«Navngitt 169 / mappe 220» (audit) vs «151 navngitt / 238 mappe-only» (workflow akse 1). **Løst:** `ref-file-audit.py` kjørt på nytt gir reproduserbart **169 / 220 / 0 orphans** — autoritativt (transparent heuristikk: `basename ∈ SKILL.md + agents/*.md`). 151/238 var et ikke-reproduserbart engangs-agentanslag med strammere «named»-definisjon; forkastet. Begge summerer 389 og er enige om **0 orphans** — avviket er kun named/folder-grensen og er **immaterielt**: intet tiltak (Fase 0–3) kjører på den grensen, kun «0 død vekt» (begge bekrefter).
+
+## Fler-sesjons-eksekveringsplan (roadmap — etablert 2026-06-26, etter Fase 0-gaten)
+
+Fase 0 ✅ lukket; gaten sa **BYGG Fase 3 (scoped)**. Gjenstående arbeid har **én kritisk sti** (Fase 2 → Fase 3-forutsetninger → judge/bake-off → Fase 4) + **to uavhengige side-spor** (TOC-håndverk, Cosmo) + **ett lav-prio** (OKF). Hver sesjon har en **kjørbar gate** (autonomi-vennlig — gå ikke videre før kriteriet er grønt). Premiss-tall (389/306/83) er recon-funn over; eksekverende sesjon **re-verifiserer mot ground truth FØR den muterer** (premiss-verifiseringsplikt).
+
+**Dependensgraf (kort) — mål-FØRST:**
+- `1c → 1b` (ellers reverserer generatoren TOC-arbeidet ved neste KB-update).
+- **Bake-off (S1) bruker det FROSNE gull-settet (373, `evidence_url` per påstand finnes allerede)** ⇒ uavhengig av frontmatter/backfill ⇒ judgen kan **de-rises FØR** scaffolding bygges. Dette er den retnings-avgjørende målingen, ikke type-tag.
+- Fase 2 type-tag (S2): judge-uavhengig, nyttig uansett utfall (trengs selv for staleness-only sourcedness). Backfill + full frontmatter (S3): **KUN hvis S1 passerer** — ellers wasted, judge-spesifikk scaffolding.
+- Fase 3-mekanisme `→` Fase 4.
+- Cosmo berører `ms-ai-advisor` ⇒ kolliderer med strukturarbeid på advisor-filer (løses ved scoping, se beslutning 2).
+
+### Kritisk sti (mål-først: de-risk judgen før du bygger scaffolding rundt den)
+
+**S1 — Judge-prototype + bake-off på frosset gull-sett (DE-RISK, retnings-avgjørende).** Bygg en minimal per-påstands groundedness-judge (Opus 4.8 xhigh) og kjør den mot de 373 gull-påstandene (hver har allerede `evidence_url` + ordrett påstand). Mål **staleness vs judge vs hybrid** på volatil populasjon, scoped til fetchbare claim_types (`taxonomy/status/version/tpm/sku/region`; `price` ekskludert). Trenger **ingen** backfill/frontmatter — gull-settet er selvbærende. **Gate:** judge presisjon/recall mot gull ≥ avtalt terskel OG slår staleness (recall 0/40); kjent felle adressert (invertert leverage — judgen «vinner» ikke ved å auto-score stabile lav-risiko-påstander). **HVIS FAIL:** stopp — judge ikke berettiget; fall tilbake på staleness + operatør-gating; **bygg IKKE S3**. ~1 sesjon de-risker hele kritisk sti.
+
+> **FORHÅNDSREGISTRERT GATE (låst 2026-06-26, operatørvalg, FØR fan-out):** judge **recall ≥ 0,80 OG presisjon ≥ 0,70** (punktestimat), målt på den verifiserbare evaluerings-populasjonen P = volatil + fetchbar claim_type (price ekskl.) = **240 påstander, 38 positive**. PLUSS nødvendig betingelse: judge-recall > staleness-recall (staleness = 0/38). Wilson 95 %-bånd rapporteres som kontekst (n=38 → bredt bånd); grensetilfeller flagges for operatør, ikke mekanisk avvist. Strengt nivå valgt: bygg S3 KUN hvis judgen er svært sterk. **Harness (testet, 14 tester):** `lib/judge-bakeoff.mjs` + `extract-judge-claims.mjs` (blind manifest, 0 label-lekkasje) + `judge-claim-prompt.md` (blind per-påstands-judge) + `run-judge-bakeoff.mjs --min-recall 0.80 --min-precision 0.70`. Blindhet: judgen ser aldri gull-verdict; join på `id` i koden etterpå.
+
+> **S1-v2-RESULTAT (2026-06-26, målrettet iterasjon — operatørvalg (c)): GATE ✅ PASS — recall 84,2 %, presisjon 84,2 %.** v2-prompt `judge-claim-prompt-v2.md` (eksakt-verdi-entailment, prinsipiell fiks på diagnostisert grounded-men-feil-feilmode; terskel uendret). Rapport: `judge-bakeoff-report-v2.{json,md}`; resultater: `judge-bakeoff-results-v2.json`. **Judge: recall 84,2 % (32/38, ✅ ≥0,80, Wilson [69,6–92,6 %]), presisjon 84,2 % (✅ ≥0,70), F1 0,842, slår staleness 0/38.** Fiksen løste målet: **sku 37,5 %→75,0 %, taxonomy 66,7 %→100 % recall**; +6 ekte fangster (26→32) UTEN netto nye FP (6→6) ⇒ recall OG presisjon opp samtidig (mekanistisk koherent, ikke støy). **Ærlige forbehold:** (1) andre måling på samme frosne gull-sett etter v1 (åpent erkjent; v1 frosset); (2) Wilson nedre grense 69,6 % < 0,80 (n=38) ⇒ sann recall ≥0,80 ikke statistisk garantert; (3) region 50 % (n=2) for lite. **Gate-logikk ⇒ vei mot S3 (scoped/hybrid).** NESTE OPERATØR-BESLUTNING: gå til S2 (type-tag) + S3 (backfill/frontmatter)? (stoppet her — eskalerer ikke selv.)
+
+> **S1-RESULTAT (2026-06-26, blind fan-out 15 batcher Opus xhigh, 255 påstander dekket): GATE ❌ FAIL — recall 68,4 % < 0,80.** Rapport: `scripts/kb-eval/data/judge-bakeoff-report.{json,md}`; resultater: `judge-bakeoff-results.json`. **Judge: presisjon 81,3 % (✅ ≥0,70), recall 68,4 % (❌ <0,80, Wilson [52,5–80,9 %]), fanget 26/38, slår staleness 0/38 desisivt.** Recall-draget er **konsentrert**: sku 37,5 % (3/8) + taxonomy 66,7 % + region 50 % (n=2); version/status/tpm er allerede 80–86 % recall ved 75–100 % presisjon. 10 av 12 bommer var «grounded»-men-feil (brittle claim-dekomponering, isolert til sku/taxonomy). Per pre-registrert gate ⇒ **STOPP, bygg IKKE S3.** **ÅPEN FORK (operatør):** (a) honorer FAIL — fall tilbake på staleness + operatør-gating [ren pre-registrering]; (b) scoped judge — auto-flag kun sterke typer (version/status/tpm), operatør-gate sku/taxonomy [data-støttet mellomvei]; (c) én målrettet prompt-iterasjon på sku/taxonomy + re-kjør [flagg p-hacking-risiko: frys v1 som ærlig pre-registrert utfall].
+
+**S2 — Fase 2: minimal type-tag (judge-uavhengig, nyttig uansett).** Klassifiser ~389 filer `reference|template|methodology|regulatory` (sidecar-manifest el. mappekonvensjon — IKKE full YAML ennå). Skiller de ~83 kildeløse legitimt (mal/metodikk: `decision-trees`, `cost-models`) fra MS-fakta-uten-kilde. NY `scripts/kb-eval/classify-ref-type.mjs` (TDD-først). Kan kjøres før/parallelt med S1 (billig). **Scope:** klassifiser advisor-filer, men MUTÉR dem ikke (Cosmo-kollisjon). **Gate:** hver fil har én type; kildeløse delt i to bøtter; reproduserbar; suite grønn.
+
+**S3 — Fase 3-forutsetning (a)+(b): backfill + full frontmatter (KUN hvis S1 passerte).** Produksjons-scaffolding for judgen: gi hver verifiserbar fil (~306 som siterer ≥1 MS Learn-URL, **EKSKL. advisor**) en `authority_source` + full frontmatter (`type/source/verified`, OKF-form). Advisor folder inn i **S-Cosmo**. Gated bak S1 fordi dette er judge-spesifikt og wasted hvis judgen feilet. **Gate:** hver ikke-advisor verifiserbar fil har `authority_source`; frontmatter validerer; suite grønn.
+
+**S4 — Produksjons-judge-utrulling + Fase 4-integrasjon.** Rull judgen over korpuset (4 skills; advisor post-Cosmo). Fold valgt mekanisme inn i KB-refresh-kadens (IKKE SessionStart — for dyrt; ~2700 ikke-batchbare `microsoft_docs_fetch`/full-pass). Rapporterende gulv (Spor D peker, ikke hard gate, før kalibrert). CT5 (sourcedness) **ERSTATTER** K8s rolle. **Gate:** SessionStart surfacer innholds-signal uten falske regresjons-alarmer; operatør-waiver-sti finnes.
+
+### Side-spor (uavhengig — interleaves når kritisk sti venter)
+
+**SH — Fase 1b/1c: TOC + generator-guard.** Trygt håndverk. **1c FØR 1b** (ellers reverserer neste KB-update headerne — write-path-regresjon). ~20–29 filer >800 linjer. Ekskluder advisor-filer (Cosmo). Avhenger av operatør-beslutning 3 (N4-revekting). **Gate:** `eval.mjs checkN4 hasToc=true` på målfilene; generator føder TOC + kanonisk header; ingen diff-churn på små filer.
+
+**S-Cosmo — Cosmo-utfasing (GODKJENT, gjøres SIST).** Fjern persona helt. Absorbér i samme pass: 1a-C (44+3 redirects), advisor-filenes frontmatter/backfill (fra S2) + TOC (fra SH). LES `docs/cosmo-removal-brief-2026-06.md`. Aldri ny Cosmo-innhold. **Gate:** 0 Cosmo-referanser igjen; advisor judged etter Cosmo.
+
+**S-OKF — OKF auto-inbox-pipeline (LAV PRIO, EKSTERNT BLOKKERT).** Skjul OKF fra bruker. `docs/okf-second-brain-brief-2026-06.md`. **Tooling bygges IKKE her** — leveres av `~/repos/llm-ingestion-okf` fase 4 (`node/`, vendres per plugin); vi er greenfield-konsument og akseptanse-skisse for API-flaten. **Gate:** avklaring B2 (guard-distribusjonskanal, operatørbeslutning) → fase 2 → 3 → 4 levert `node/` → sign-off-kjedens punkt 5. Ikke start før den kjeden er grønn. Sikkerhet eies alltid av `llm-ingestion-guard`, aldri av dette sporet.
+
+### Operatør-beslutninger låst inn av denne planen
+1. **Mål-først vs bygg-begge** → ✅ LØST av gaten: bygg-begge-og-mål på volatil populasjon (S3).
+2. **Cosmo-sekvensering** → **ANBEFALT resolusjon:** advisor-strukturarbeid folder inn i S-Cosmo; Fase 3-bake-off bruker frosset gull-sett (uavhengig av advisor-frontmatter); produksjons-judge dekker 4 skills først, advisor post-Cosmo. Respekterer «Cosmo sist» UTEN å blokkere kritisk sti.
+3. **N4-revekting** → avgjøres ved SH (policy, ikke defekt; TOC-håndheving drar 91–96 midlertidig < 90 → Spor D-alarm).
+4. **Versjonsbump `83fd9b5`** → batch med S3- eller S-Cosmo-release.
+
+**Anbefalt neste sesjon: S1** (judge-prototype + bake-off på frosset gull-sett — den retnings-avgjørende de-risk-målingen; krever ingen scaffolding, slår staleness-recall 0/40 eller stopper kritisk sti). S2 (type-tag) er judge-uavhengig og kan tas i samme/tidligere slot om ønskelig. Trygt alternativ: SH (TOC), men avklar beslutning 3 først.

docs/skill-eval-routine-improvement-2026-06.md

@@ -0,0 +1,95 @@
+# Skill-eval-rutinen — forbedringsspor (Pocock-lens + best-practice-triangulering)
+
+_Task-brief. Skrevet 2026-06-30. Stier relative til plugin-rot. Durabel (overlever `/clear`); STATE.md peker hit._
+
+> **Status:** SPEC / ikke startet. Lagt inn på operatørs eksplisitte forespørsel (utgangspunkt: Matt Pococks «Writing Great Skills»-talk). Forbedringen kjøres som eget spor — IKKE bland med KB-korrekthets-sprinten (judge v3.1). Research-grunnet 2026-06-30 (to Opus-agenter: offisiell Anthropic + community-triangulering).
+
+---
+
+## 0. Mål / hvorfor
+
+Forbedre **rutinen som scorer skill-kvalitet og deres referansefiler** — `scripts/kb-eval/lib/skill-score.mjs` (ren rubrikk) + `scripts/kb-eval/eval.mjs` (deterministiske sjekker) + judge-laget — ved å folde inn Matt Pococks «Writing Great Skills»-rammeverk som en **ny lens**, triangulert mot offisiell Anthropic-guidance og eksisterende community-lintere. Pluginen er **showcase** ([[showcase-reusable-patterns]]); korrekthets-mekanismen (judge + gold + målt adopsjon) fra KB-sporet er **det samme mønsteret** som de nye judge-kriteriene under skal bruke — porter den, ikke gjenoppfinn.
+
+**Nordstjerne:** høyest mulig kvalitet på skills + refs, målt objektivt, med klare forbedringspekere. Ikke flere kriterier for kriterienes skyld — hvert nytt punkt må enten fange en reell feilklasse rubrikken slipper i dag, eller erstatte et svakere signal.
+
+## 1. Nåværende rutine (grounded — verifisert, ikke gjettet)
+
+16-kriteriers vektet rubrikk med **hardt gulv** på de to last-bærende (K1 trigger-presisjon, K10 søsken-overlapp); score `< 90` ⇒ under mål. Allerede grunnet i Anthropics offisielle «Skill authoring best practices» (nær 1:1 med deres deterministiske sjekkliste). Spec: `docs/skill-quality-scoring-plan.md`.
+
+| Dekket i dag (K/N/CT) | Kort |
+|---|---|
+| K1 trigger-presisjon (judge, gulv, v3) · K2 description-format · K10 søsken-overlapp (det, gulv) | trigger + scope |
+| K3 body ≤500 linjer · K5 progressiv disclosure · K6 routing · N3 refs én nivå · N4 TOC >100 linjer | struktur |
+| K4 ingen duplisering (judge) · K7 imperativ stil (judge) · K9 ingen volatil tid-info (judge) | steering/pruning-snitt |
+| CT5 sourcedness (dormant til Port 1) · refCount · N1 name · N2 desc ≤1024 · N5 forward-slash | refs/hygiene |
+
+**Fase 2 (allerede på roadmap, ikke bygget):** uplift-eval — «hjelper skillen vs. ingen-skill-baseline» (with-skill vs baseline pass-rate-delta). Skill-eval-plan §5.
+
+## 2. Tre kilde-lag (research 2026-06-30)
+
+**A. Anthropic offisiell (høyest autoritet, deterministisk ryggrad).** «Skill authoring best practices», `skill-creator`, `plugin-dev:skill-development`, engineering-blogg. Bekrefter dagens rubrikk + avdekker offisielt-belagte signaler vi IKKE bruker ennå (se §3). Viktig: **ingen offisiell 0–100-rubrikk finnes** — vi fyller et reelt gap, men hvert punkt skal spores til en checklist-regel, ikke oppfinnes.
+
+**B. Matt Pocock «Writing Great Skills» (én sterk praktiker; opinion, ikke spec).** Faktiske skill-seksjoner: *Invocation · Writing the description · Information hierarchy · When to split · Pruning · Leading words · Failure modes*. **Premiss-korreksjon (verifiseringsplikt):** talens «vertical slice»- og «grill-with-docs vs to-PRD»-eksempler finnes IKKE i den faktiske skillen — reelle leading-word-eksempler er *lesson, fog of war, tracer bullets*, samt refactors *«fast, deterministic, low-overhead» → tight* og *«a loop you believe in» → red*. Bruk de verifiserte, ikke talens parafrase.
+
+**C. Community + eksisterende lintere (sekundært — HØST sjekklistene, ikke gjenoppfinn).** `superpowers` (TDD-for-skills, ord-budsjett per tier, «description = trigger-only»); og ferdige 0–100-scorere: `skillcheck` (description-score 0–100), `skillscore`, `rubric-evaluator` (to-lags BLOCKER/MAJOR/MINOR-gate + judge), `agnix` (156-regel-linter). Vårt høyeste løft: kopier deres deterministiske sjekker der de er bedre enn våre.
+
+## 3. Gap-analyse: Pocock × nåværende rubrikk
+
+| Pocock-dimensjon | Dekket i dag? | Gap (ny verdi) | Automatiserbar? |
+|---|---|---|---|
+| **Invocation** — user- vs model-invoked design; context-load (model-desc koster tokens hver request) vs cognitive-load | Nei (K1 scorer kun *presisjon*, ikke *design-valget*) | Side-effekt-skill (deploy/commit/push/send/delete) UTEN `disable-model-invocation` = warn (offisielt belagt, CC); kombinert `description`+`when_to_use` ≤1536 listing-cap; `context: fork` uten reell oppgave | **Delvis** (verb-heuristikk + lengde = det; «er model-invocation berettiget?» = judge) |
+| **Information hierarchy / when to split** — steps m/ completion-criterion; reference i to lag; flytt én-grens-materiale bak context-pointer | Delvis (K3/K5/K6/N3/N4 = størrelse/lenker, ikke gren-bevissthet) | Step uten observerbart completion-criterion; én-grens-ref inlinet i SKILL.md; **orphan-ref** (fil i mappe ikke lenket fra SKILL.md); context-pointer mangler trigger-frase | **Delvis** (orphan/depth/size = det; «bør splittes?» / «criterion observerbart?» = judge) |
+| **Leading words** — kompakt pretrent konsept agenten ekko-er i reasoning | Nei | Konsistens-proxy: et myntet begrep brukt konsistent + i description (det); høy-signal-kvalitet (judge) | **Delvis** (konsistens = det; «ekte leading word?» = judge) |
+| **Legwork / split-by-sequence** — krevende criterion driver grundighet; skjul fremtidige steg | Nei | Vag gate-språk («make sure it works», «looks good») som ikke er binært; premature-completion | **Judge** (kjernen) |
+| **Pruning — no-ops / deletion-test** — «endrer denne setningen atferd vs default?» | Delvis (K4 = duplisering) | Boilerplate-denylist (det, grovt); ekte no-op-test (judge); **sediment** (stale lag) (judge) | **Mest judge** (denylist fanger kun det åpenbare) |
+| **Massive skills / DRY på tvers** | Delvis (K3 + K4 per-skill) | Nær-duplikat på tvers av HELE skill-korpuset (hashing/embedding) | **Det** (cross-corpus near-dup) |
+
+## 4. Foreslåtte forbedringer
+
+**4a. Nye deterministiske kriterier (eval.mjs + skill-score.mjs, TDD, billig):**
+- **Side-effekt-uten-gate-vakt:** name/description matcher destruktive verb (deploy/commit/push/send/delete/publish) OG `disable-model-invocation` ikke satt → warn. (CC-belagt.)
+- **Listing-cap:** kombinert `description`+`when_to_use` ≤ 1536 tegn (Claude Code-spesifikk). Separat fra dagens N2 (1024 = hard felt-maks).
+- **Body token-budsjett:** body < 5k tokens (offisielt, i tillegg til <500 linjer).
+- **Orphan-ref-deteksjon:** ref-fil i skill-mappe ikke lenket fra SKILL.md = smell.
+- **ALL-CAPS-vegg / rigid MUST:** `ALWAYS`/`NEVER`-all-caps + tette `MUST`-vegger = `skill-creator` «yellow flag».
+- **Cross-corpus near-duplicate:** duplisert blokk/setning på tvers av skills (DRY-brudd over korpuset, ikke bare per-skill).
+- **Vurder:** ToC-terskel-konflikt (BP 100 vs SC 300 linjer — velg 100 som strengere, warn på 300); deskriptive filnavn (`doc2.md`/`file1.md`-denylist); fully-qualified MCP `Server:tool`.
+
+**4b. Nye judge-kriterier (utvider EKSISTERENDE judge-lag — samme mønster som KB-judge):**
+- **No-op / deletion-test:** per setning, «endrer dette atferd vs default?» → kandidat for kutt. Pococks kjerneteknikk; ikke regex-reduserbar.
+- **Leading-word-kvalitet:** er et myntet begrep et ekte høy-signal pretrent konsept, brukt konsistent?
+- **Completion-criterion-observerbarhet:** er hvert stegs sluttbetingelse binær/observerbar vs fuzzy?
+- **Sediment:** stale/irrelevant akkumulert materiale.
+- **(divergens-nøytral):** «model-invocation berettiget?» — IKKE belønn `disable-model-invocation`-tilstedeværelse per se (se §5).
+
+**4c. Arkitektur — adopter to-lags-mønsteret eksplisitt (`rubric-evaluator`-mønster, speiler vårt eget):**
+Deterministiske sjekker = gate/severity (vi har gulv-mekanismen); judge scorer den semantiske resten. **Port judge-bake-off-disiplinen fra KB-sporet:** bygg et lite gull-sett for skill-kvalitet, kalibrer judge-prompten mot dokumenterte feilmoduser, MÅL adopsjon (slå forrige) — IKKE ad-hoc-patch. [[gold-freshness-can-invert-adoption]] gjelder også her: et skill-kvalitets-gull eldes.
+
+## 5. Divergenser å håndtere (ikke hardkod én side)
+
+1. **Description: «what + when» (Anthropic) vs «trigger-only» (superpowers).** Superpowers MÅLTE at workflow-oppsummering i description får agenten til å hoppe over å lese skillen. → Ikke straff utelatt «what» som hard regel; gjør konfigurerbar.
+2. **Invocation-default: 1%-regel/model-default (superpowers) vs berettig-model-invocation (Pocock).** → Ikke belønn `disable-model-invocation` per se; belønn berettiget valg (judge) eller vær nøytral.
+3. **Lengde-enhet: 500 linjer (Anthropic) vs 150/200/500 ord per tier (superpowers).** → Velg én enhet; eksponer terskel som config; hyppig-lastede skills tåler strengere.
+4. **Cross-surface-konflikter (linter MÅ vite hvilken flate):** `name`/`description` required (platform/spec) vs optional (Claude Code); `allowed-tools` restriktiv (spec experimental) vs IKKE-restriktiv i Claude Code; `when_to_use` kun Claude Code. Ikke hard-fail på feil flate.
+
+## 6. Sekvensering
+
+0. **(valgfritt, men anbefalt FØRST)** Dypere research hvis ønsket: `/deep-research` eller `/trekresearch` på de eksisterende linterne (`skillcheck`/`skillscore`/`rubric-evaluator`/`agnix`) — høst konkrete regel-lister + se hva de scorer som vi ikke gjør. Denne briefen har allerede triangulert hovedrammeverkene; en full deep-research-pass er for å hente *implementerings-detaljer* fra de eksisterende verktøyene.
+1. **Velg scope:** hvilke §4a/§4b-kriterier gir mest signal? Start med §4a (billig, deterministisk, høy tillit) + ett judge-kriterium (no-op-test, høyest Pocock-verdi).
+2. **TDD (Iron Law):** failing test først (fixtures i `tests/kb-eval/`), så implementer i `eval.mjs` (disk) + `skill-score.mjs` (ren scoring).
+3. **Re-score korpuset** + kalibrer vekter (ikke la nye kriterier tanke alle skills under 90 % ukontrollert — degrader nye judge-kriterier til `available:false` til de er kalibrert, slik CT5 gjør i dag).
+4. **Judge-bake-off** for §4b-kriteriene (gull + kalibrert prompt + målt adopsjon, §4c).
+5. **Wire** i `score-skill.mjs --write`-cachen → Spor D SessionStart-surfacing.
+
+## 7. Verifisering (kjørbare kriterier)
+
+- `node --test tests/kb-eval/*.test.mjs` grønn etter hver ny sjekk (nye fixtures: side-effekt-uten-gate, orphan-ref, ALL-CAPS-vegg, cross-corpus-dup, listing-cap >1536).
+- `node scripts/kb-eval/score-skill.mjs --json` kjører uten regresjon på de 5 nåværende skills; nye kriterier vises i forbedringsrapporten med konkret `fix`.
+- Hvert nytt deterministisk kriterium: vis at det FANGER en injisert feil-fixture OG ikke flagger en ren fixture (presisjon + recall, som G3-linten).
+- Judge-kriterier: bake-off mot skill-kvalitets-gull slår forrige judge (P OG R), ellers ikke adoptert (§4c, samme gate som KB-judge).
+- Ingen regresjon: full suite + `validate` grønn.
+
+## 8. Kilder (verifisert 2026-06-30)
+
+Offisielt: [Skill authoring best practices](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices) · [Agent Skills overview](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview) · [Extend Claude with skills (Claude Code)](https://code.claude.com/docs/en/skills) · [skill-creator SKILL.md](https://github.com/anthropics/skills/blob/main/skills/skill-creator/SKILL.md) · [Equipping agents for the real world](https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills) · [Agent Skills open standard](https://agentskills.io/specification).
+Community: [mattpocock/skills — writing-great-skills](https://github.com/mattpocock/skills/blob/main/skills/productivity/writing-great-skills/SKILL.md) · [obra/superpowers — writing-skills](https://github.com/obra/superpowers/blob/main/skills/writing-skills/SKILL.md) · [halfmoon-mind/rubric-evaluator](https://github.com/halfmoon-mind/rubric-evaluator) · [thedaviddias/skill-check](https://github.com/thedaviddias/skill-check) · [skillscore](https://dev.to/sayed_ali_alkamel/skillscore-a-cli-that-scores-your-ai-agents-skillmd-0-100-48l1) · [Test any skill without an LLM judge](https://medium.com/@nemadesumit/how-to-test-any-claude-code-skill-without-an-llm-judge-3da402de7146) · [MLflow — Evaluating Skills](https://mlflow.org/blog/evaluating-skills-mlflow/).

docs/skill-validation-routine-brief-2026-07.md

@@ -0,0 +1,174 @@
+# Skill-valideringsrutinen — hvordan den er tenkt å virke (AI-Engineer-lens)
+
+_Task-brief. Skrevet 2026-07-01. Stier relative til plugin-rot. Durabel (overlever `/clear`). Grunnlaget er verifisert mot disk (to Opus-speidere), ikke gjettet — se §8 verifiseringslogg._
+
+> **Status:** BRIEF / ikke startet. Beskriver hvordan rutinen for å validere **én skill** er tenkt å virke ende-til-ende, og bærer **AI-Engineer-perspektivet** (behandle en skill som en ML-komponent: valider på atferd/effekt, ikke bare form) som forbedringsaksen.
+>
+> **Forhold til søsken-doc:** `docs/skill-eval-routine-improvement-2026-06.md` fordyper **Trinn 1 (form-scoringen)** via Pocock-lens. Denne briefen legger til **Trinn 2–3 (atferd/effekt)** + den samlende «valider én skill»-rutinen. De to overlapper ikke; de dekker hvert sitt lag. `docs/skill-quality-scoring-plan.md` er den bindende spec-en for Trinn 1.
+
+---
+
+## 0. Mål / hvorfor
+
+**Nordstjerne:** en skill anses ikke som «gyldig» fordi artefaktet er velformet, men fordi den **måles** å (a) trigge når den skal og bare da, og (b) faktisk forbedre modellens output på representative oppgaver — med statistisk sikkerhet og regresjonsvern. I dag måler den kjørende rutinen kun (a) som en proxy og (b) ikke i det hele tatt.
+
+Dette er **AI-Engineer-perspektivet**: du sender ikke en ML-komponent i produksjon fordi config-filen er velformet — du sender den på målt atferd mot et held-out eval-sett, med varians-tall, gated av regresjonstester. Pluginen har allerede en `ms-ai-engineering`-skill som lærer bort nettopp «MLOps for generativ AI / evals»; den forbedrede valideringsrutinen skal **praktisere det pluginen forkynner** (dogfooding), og mekanismen skal være portabel til søster-plugins ([[showcase-reusable-patterns]]).
+
+**Anti-mål for briefen:** ikke flere kriterier for kriterienes skyld. Hvert nytt trinn må enten fange en reell feilklasse dagens rutine slipper, eller erstatte et svakere signal med et sterkere.
+
+---
+
+## 1. Kontekst — de to valideringslagene (verifisert)
+
+Det finnes to helt separate ting som begge kalles «validere en skill». Å blande dem er den vanligste feilkilden.
+
+| Lag | Spørsmål | Hvor det bor i dag |
+|---|---|---|
+| **KB-/referansefil-korrekthet** | Er påstandene i `references/*.md` sanne mot kilde? | `generate-skills` «født-verifisert»-judge (v3.1) + `validate-kb-file.mjs` create-guard |
+| **Skill-kvalitet/triggering** | Er `SKILL.md` godt formet, trigger den riktig, overlapper den søsken, **hjelper den**? | `scripts/kb-eval/` (K1–K10 + N1–N5 → 0–100-score) |
+
+Denne briefen handler om **det andre laget** — men KB-korrekthet er en *forutsetning* (Trinn 0 under), så den nevnes eksplisitt, ikke utdypes.
+
+### 1a. Hva den kjørende rutinen måler i dag (Trinn 1 — form)
+
+Kilde: `scripts/kb-eval/eval.mjs` (deterministiske sjekker) + `lib/skill-score.mjs` (ren scoring) + CLI `score-skill.mjs`. Bindende spec: `docs/skill-quality-scoring-plan.md`.
+
+- **16-kriteriers vektet rubrikk → én 0–100-score per skill.** `TARGET = 90`, `FLOOR_CAP = 89`.
+- **Hardt gulv** på to last-bærende kriterier — **K1 trigger-presisjon** (vekt 3) og **K10 søsken-overlapp** (vekt 3): feiler en av dem, kappes scoren til ≤89 og skillen kan aldri passere, uansett formatering.
+- Aggregering: `Σ(vekt · delpoeng for TILGJENGELIGE kriterier) / Σ(vekt tilgjengelige) × 100`.
+- Øvrige: K3 body ≤500 linjer, K4 ingen duplisering (judge), K9 ingen volatil tid-info (judge), K2 description-format, K5 progressiv disclosure, K6 routing, K7 imperativ stil (judge), CT5 sourcedness, refCount, N1 name-validitet (≤64, `[a-z0-9-]`, ingen `claude`/`anthropic`), N2 description ≤1024, N3 refs én nivå dypt, N4 TOC i ref-filer >100 linjer, N5 forward-slash-stier.
+- **Gate:** `node scripts/kb-eval/score-skill.mjs --gate 90` → exit≠0 hvis noen skill <90. Kjøres etter skill-mutasjon i `apply-skill-op.mjs`, og signaleres ved sesjonsstart (Spor D-hook, viser skills <90 %).
+- **Cache:** `scripts/kb-eval/data/skill-score-report.json`.
+- **Nåværende status:** advisor=91, de fire andre=96, alle `meetsTarget`. Toppfiks stort sett N4 (TOC).
+
+### 1b. Hvordan K1 «trigger-presisjon» faktisk måles i dag — og hvorfor det er en proxy
+
+- Operatør-kuratert **20-prompt-sett per skill** (`data/k1-trigger-prompts.json`): 10 in-domain + 10 adversarielle out-of-domain (søsken-domene-prompter valgt for å teste over-trigging-grensen). PASS = ≥90 % hits / ≤10 % falske positive.
+- Avgjøres av en **blindet judge** (`judge-prompt.md`) som resonnerer **kun fra `description`-teksten** — ikke ved å faktisk kjøre prompten gjennom modellen.
+- Judge-kriteriene (K1/K4/K7/K9) krever et **manuelt, operatør-gated subagent-steg** (Opus, én dommer per skill). Uten fersk judge merkes scoren `provisional` og K1-gulvet kan ikke håndheves.
+
+Dette fungerer og har fanget ekte feil (governance K1 var 0.85 før Schrems-II-recall-fiksen; advisors NOT-liste validert som over-trigging-fiks). Men det er en **proxy**: en dommer som vurderer teksten, ikke atferd. Den fanger ikke at Claude i praksis *undertrigger* enkle queries — fordi modellen kun konsulterer en skill for oppgaver den ikke lett løser selv.
+
+---
+
+## 2. Problemet — AI-Engineer-gapet
+
+Dagens kjørende rutine er i praksis **strukturell hygiene + en trigger-proxy**. Seks konkrete hull, alle verifisert:
+
+1. **Form vs. effekt.** Rutinen måler kun *form*, aldri *uplift*: hjelper skillen faktisk vs. en ingen-skill-baseline? Dokumentert som eksplisitt roadmap-hull (skill-quality-scoring-plan §Fase 2), men ikke bygget.
+2. **K1 er en proxy, ikke live triggering.** En judge resonnerer om description-teksten; ingen query kjøres gjennom modellen. Fanger ikke undertrigging.
+3. **Ingen varians-analyse.** Judge kjøres **én gang** per skill. Ingen mean±stddev, ingen flaky-deteksjon, ingen repetisjon. LLM-output er stokastisk; ett kall er ett sample.
+4. **Judge er manuell og kan bli stale.** Ingen automatisk re-judge når `description` endres; scoren faller stille til `provisional`.
+5. **`generate-skills` validerer aldri skill-kvalitet.** Kommandoen som produserer mest innhold gater kun referansefil-korrekthet — aldri K1/K10/score. En skill kan drifte i triggering uten at noe fanger det.
+6. **Ingen samlende «valider én skill»-rutine.** I dag er det 3–4 uavhengige spor (født-verifisert KB-judge, create-guard, kb-eval-score, ekstern skill-reviewer/skill-creator). Ingen enkelt inngang binder KB-korrekthet + form + atferd sammen til én verdikt.
+
+**Nøkkelfunn:** mekanismene for hull #1–#3 finnes **ferdig-designet** i Anthropics `skill-creator`-skill, men er **ikke adoptert** i dette repoet:
+- **Effekt-eval (3a):** spawn with-skill OG baseline i samme tur → assertions + timing → grader → `aggregate_benchmark` gir pass-rate/tid/tokens med **mean±stddev + delta**; analyzer flagger ikke-diskriminerende og høy-varians-evals.
+- **Triggering-optimizer (3b):** 20 eval-queries (should/should-not, near-miss-negative), `run_loop.py` splitter **60/40 train/held-out**, kjører **hver query 3× for pålitelig trigger-rate** via live `claude -p`, og velger `best_description` **på test-score, ikke train** (unngår overfitting).
+
+Briefen finner altså ikke opp noe — den **adopterer og binder sammen** eksisterende byggeklosser under AI-Engineer-lensen.
+
+---
+
+## 3. Hvordan rutinen er tenkt å virke — mål-tilstand
+
+Én inngang, `validate-skill <name>`, kjører fem trinn i rekkefølge og emitterer én verdikt. Billige/deterministiske trinn først (fail-fast), dyre atferds-trinn sist.
+
+```
+validate-skill <name>
+  Trinn 0  KB-korrekthet (forutsetning)      ── født-verifisert + create-guard grønn?
+  Trinn 1  Form/hygiene-score (FINNES)        ── K1–N5 → 0–100, --gate 90
+  Trinn 2  Live triggering (NY · AI-Eng)      ── precision + recall, N× repetisjon, varians, train/held-out
+  Trinn 3  Effekt / uplift (NY · AI-Eng)      ── with-skill vs baseline, mean±stddev + delta
+  Trinn 4  Gate + regresjon                    ── behavioral gate ved siden av form-gate; auto re-run ved endring
+  → verdikt: PASS / NEEDS-WORK / FAIL  +  forbedringspekere
+```
+
+### Trinn 0 — KB-korrekthet (forutsetning, finnes)
+Referansefilene skal være født-verifisert (`Verified by: judge-v3.1`) og bestå create-guard (`validate-kb-file.mjs`: Source, TOC, kontrakt-header). Ikke en del av skill-*kvaliteten*, men må være grønt før atferds-evals gir mening — en skill kan ikke «hjelpe» hvis KB-en den ruter til er feil.
+
+### Trinn 1 — Form/hygiene-score (finnes; fordypes av Pocock-doc)
+Behold uendret som den **billige, deterministiske gaten**: K1–N5 → 0–100, `--gate 90`, hardt gulv på K1/K10. Dette er raskt, kjører i CI, og fanger regresjoner i struktur/scope uten modell-kall. Pocock-doc'et (`skill-eval-routine-improvement-2026-06.md`) utvider dette trinnet — ikke reforhandlet her.
+
+### Trinn 2 — Live triggering (NY · kjernen i AI-Eng-løftet)
+Erstatt/suppler K1-judge-proxyen med **behavioral triggering-måling**:
+- Utvid det kuraterte 20-prompt-settet til et **merket eval-sett** med should-trigger + should-not-trigger, der negative er **near-misses** (deler nøkkelord med skillen, men trenger noe annet — typisk en søster-skill).
+- Kjør hver query **N× (default 3) gjennom modellen live** og mål **trigger-rate**, ikke ja/nei. Rapporter **precision OG recall** (dagens K1 måler i praksis kun presisjon/over-trigging; recall/undertrigging er ugated).
+- **60/40 train/held-out-splitt**; velg/juster description på **held-out-score** for å unngå å overfitte teksten til eval-settet.
+- Rapporter **varians** (mean±stddev per query); flagg høy-varians-queries som flaky.
+- Mekanisme: adopter/wrap `skill-creator` `run_loop.py`, eller reimplementer i repoets `mjs`/TDD-stil (se §7 åpen beslutning).
+
+### Trinn 3 — Effekt / uplift (NY · AI-Eng)
+Svar på det rubrikken aldri svarer på: **gjør skillen output bedre enn ingen skill?**
+- For hvert eval-case: spawn **with-skill OG baseline i samme tur** (adopter `skill-creator` 3a — ikke sekvensielt).
+- Objektivt verifiserbare **assertions** der oppgaven tillater det; kvalitativ grading der den ikke gjør det (skriv aldri kunstige assertions for subjektiv kvalitet).
+- Aggregér til **pass-rate + tid + tokens med mean±stddev og delta** vs. baseline.
+- **Analyzer-pass:** flagg ikke-diskriminerende assertions (består med ELLER uten skill → måler ingenting) og høy-varians/flaky-evals.
+
+### Trinn 4 — Gate + regresjon
+- **Behavioral gate ved siden av form-gaten:** en skill-/description-/KB-endring som senker trigger-recall eller uplift-delta under terskel **feiler gaten** (i dag gates kun form via `--gate 90`).
+- **Auto re-run ved endring:** når `SKILL.md`/`description` eller rutet KB endres, re-kjør minst Trinn 1–2 (Trinn 3 er dyrere — periodisk/på forespørsel). Fjerner stale-judge-problemet (hull #4).
+- **Wire inn i `generate-skills`** (lukker hull #5): batch-genereringen kaller `validate-skill` for berørte skills, ikke bare KB-korrekthet.
+- Resultater caches med provenans (som dagens `judge-results.json` / `skill-score-report.json`), slik at Spor D-signalet og gatene leser ferske tall.
+
+---
+
+## 4. AI-Engineer-perspektivet — disiplin → hull → mekanisme
+
+| AI-Eng-prinsipp | Dagens hull | Importert mekanisme |
+|---|---|---|
+| **Evals er sannheten, ikke lint** — en komponent vurderes på målt atferd, ikke på at config er velformet | Kun form måles (#1) | Trinn 3 uplift-benchmark (`skill-creator` 3a) |
+| **Triggering = en klassifikator → mål precision OG recall, live** | K1 = judge-proxy, kun presisjon (#2) | Trinn 2 live `run_loop` (`skill-creator` 3b) |
+| **Stokastisk output → repetisjon + varians** | Judge kjøres 1×, ingen stddev (#3) | 3× repetisjon, mean±stddev, flaky-flag |
+| **Unngå overfitting til eval-settet** | Judge ser hele settet | 60/40 train/held-out, velg på test-score |
+| **Regresjonsvern i CI** | Kun form gated (#4/#5) | Behavioral gate + auto re-run, wired i `generate-skills` |
+| **Ikke-diskriminerende evals er verdiløse** | Ingen sjekk | Analyzer-pass (flagger no-op-assertions) |
+| **Én reproduserbar pipeline, ikke spredte spor** | 3–4 uavhengige spor (#6) | Samlende `validate-skill <name>` → én verdikt |
+
+---
+
+## 5. Suksesskriterier (testbare)
+
+En implementasjon av denne rutinen er ferdig når:
+
+1. `validate-skill <name>` finnes, kjører Trinn 0→4 sekvensielt, og emitterer én verdikt (PASS/NEEDS-WORK/FAIL) + rangerte forbedringspekere. **Test:** kjør mot en skill, verifiser exit-kode + strukturert output.
+2. **Trinn 2 måler live trigger-rate** (ikke judge-proxy) med **både precision og recall**, hver query kjørt ≥3×, med mean±stddev per query. **Test:** output inneholder recall-tall og stddev; en bevisst under-triggende description gir recall < terskel.
+3. **Trinn 3 produserer with-skill-vs-baseline-delta** med mean±stddev. **Test:** en skill med kjent uplift viser positiv delta; en no-op-skill viser ~0 delta og flagges av analyzer.
+4. **Behavioral gate håndhever regresjon:** en description-endring som knuser recall/uplift gir exit≠0. **Test:** injiser en dårlig description, verifiser at gaten feiler.
+5. **`generate-skills` kaller `validate-skill`** for berørte skills. **Test:** kjør batch, verifiser at valideringen trigges (ikke bare create-guard).
+6. **Alt TDD-gated:** nye moduler har failing test først; suiten (`node --test tests/kb-eval/*.test.mjs …`) grønn. **Test:** exit-kode, ikke glyph-grep.
+7. **Ingen regresjon i eksisterende Trinn 1:** dagens 5 skills scorer fortsatt ≥90 og `skill-score-report.json`-skjemaet er uendret (eller versjonert bevisst).
+
+---
+
+## 6. Non-Goals (scope-grenser)
+
+- **Ikke** endre/reforhandle Trinn 1-rubrikken (K1–N5) — det eies av Pocock-doc'et og scoring-planen.
+- **Ikke** bygge KB-korrekthets-judgen (Trinn 0 finnes; det er Spor 1 / judge v3.1-territorium).
+- **Ikke** røre Cosmo-persona eller legacy-generatorer (S-Cosmo-sporet).
+- **Ikke** auto-fikse en skill basert på eval-resultat — rutinen **måler og flagger**; menneske bekrefter og endrer (samme disiplin som «aldri auto-fiks KB»).
+- **Ikke** bestemme build-vs-adopt for `skill-creator`-verktøyene her — det er en åpen beslutning (§7), ikke en del av briefen.
+
+---
+
+## 7. Åpne beslutninger (trenger operatør)
+
+1. **Adopter vs. reimplementer `skill-creator`-verktøyene.** De er Python (`run_loop.py`, `aggregate_benchmark`); repoet er `mjs` + TDD. *Anbefaling:* wrap/adopter først for å **måle verdien** på de 5 skillene, reimplementer i `mjs` kun hvis adoptert og verdt vedlikeholdet ([[faktabasert-build-both-measure]]).
+2. **Kostnad for live triggering.** Full Trinn-2-kjøring ≈ 20 queries × 3 repetisjoner × 5 skills = ~300 live modell-kall; Trinn 3 kommer i tillegg. Pris er operatør-gated. *Anbefaling:* behold den billige K1-judge-proxyen som CI-gate hver commit; kjør de dyre live-trinnene periodisk / før release / ved description-endring.
+3. **Behold K1-proxy eller erstatt?** *Anbefaling:* behold begge — proxy = billig hyppig gate, live triggering = dypere periodisk sannhet. To signaler, ikke ett erstatter det andre.
+
+---
+
+## 8. Verifiseringslogg + løse tråder
+
+**Grunnlaget** er verifisert 2026-07-01 av to Opus-speidere mot disk (ikke STATE-påstander):
+- Rubrikk/vekter/gulv/aggregering: `scripts/kb-eval/lib/skill-score.mjs`, `eval.mjs`, `score-skill.mjs` + `tests/kb-eval/*` (invariantene asserteres).
+- K1-metoden: `judge-prompt.md` + `data/k1-trigger-prompts.json` + `data/judge-results.json` (alle 5 precision 1.0).
+- `skill-creator`-rutinen: `plugins/skill-creator/skills/skill-creator/SKILL.md` §163–404 (effekt-eval + triggering-optimizer).
+- Roadmap-hullet: `docs/skill-quality-scoring-plan.md` §Fase 2 + `docs/skill-eval-routine-improvement-2026-06.md`.
+
+**Løse tråder å adressere i planen (ikke her):**
+- **Doc-drift:** `skill-quality-scoring-plan.md` §2-tabellen lister fortsatt **K8**; koden har erstattet K8 med den deterministiske **CT5**. Koden er kilden; planen bør oppdateres.
+- **Git-inkonsistens:** `skill-score-report.json` er både `.gitignore`-matchet OG faktisk tracked (committet før den ble ignorert). Hook-kommentaren i `session-start-context.mjs` antar «gitignored ⇒ fraværende i fresh clone» — som ikke stemmer. Trivielt, men verdt å rydde når rutinen røres.
+
+**Neste steg:** operatør-review av denne briefen → `/trekplan --brief docs/skill-validation-routine-brief-2026-07.md` for implementeringsplan (TDD-gated, sesjons-dekomponert).

docs/spor1-authority-selection.md

@@ -0,0 +1,202 @@
+# Spor 1 — Authority-URL-valg per reference-fil (Step 6 audit-logg)
+
+**Type:** methodology
+**Status:** Stable
+**Kategori:** Spor 1 korpus-migrering
+**Sist oppdatert:** 2026-07-04
+**Produsert av:** trekexecute Session 2, Step 6 (to-lags hovedkontekst — operatørvalg 2026-07-04)
+
+---
+
+Denne loggen dokumenterer valget av **THE authority `learn.microsoft.com`-URL** per non-advisor `reference`-fil, persistert som `source` i `scripts/kb-update/data/ref-type-manifest.json` (gitignored/regenererbar; den varige posten er denne loggen + `**Source:**`-headerne Step 9 stempler). Metode: **deterministiske tie-breaks først** (single citation → concept/overview over how-to → mest-sitert i korpus), deretter **hovedkontekst-vurdering** for gjenstående likestilte kandidater. Ingen gjetning: en fil uten forsvarlig MS-autoritet settes `deferred:true` (defer-not-guess, jf. `authority.mjs`).
+
+## Sammendrag
+
+| Bøtte | Antall | Metode |
+|---|---:|---|
+| Sourced (non-advisor reference) | 243 | header 6 · concept 64 · most-cited 141 · top-score 1 · residual-judgment 31 |
+| Deferred — ingen MS-sitering | 59 | `no-ms-citation` (typet reference på innhold i Step 4, men siterer 0 `learn.microsoft.com`-URL) |
+| Deferred — advisor-scope | 50 | `advisor-scope` (utenfor Step 6 sitt non-advisor-mandat; aldri mutert av applier; S-Cosmo) |
+| **Sum reference-entries** | **352** | |
+
+### Premiss-korreksjoner mot plan-estimatene (verifisert mot manifest, 2026-07-04)
+
+- Planen anslo «~253 reference / ~246 uten source». Ground truth: **302 non-advisor reference** (+ 50 advisor reference = 352 totalt).
+- Planen sa «7 filer har allerede `**Source:**`». Ground truth: **6** (header-metoden under).
+- **Advisor-håndtering (scope-avgjørelse):** Step 6-teksten scoper til «non-advisor», men Verify-predikatet skanner ALLE reference-entries. De 50 advisor reference-entriene settes derfor `deferred:true` (`advisor-scope`) — ikke gjettede kilder — så predikatet holder uten å utvide arbeidet inn på advisor-flaten (som uansett aldri muteres og er merket for Cosmo-fjerning).
+
+## Hovedkontekst-adjudikasjon — 31 residual-likestillinger
+
+Disse hadde flere kandidater likestilt på både score og korpus-sitering. Valgt URL er den primær-tema-kanoniske autoriteten, plukket FRA filens egen siteringsmengde (skriptet asserterer medlemskap).
+
+| Fil | Valgt authority | Begrunnelse |
+|---|---|---|
+| ms-ai-engineering / agent-orchestration/agent-365-governance-and-deployment.md | https://learn.microsoft.com/copilot/microsoft-365/agent-essentials/m365-agents-blueprint | M365 agents blueprint governs deployment |
+| ms-ai-engineering / agent-orchestration/agent-memory-and-context-management.md | https://learn.microsoft.com/azure/foundry/agents/concepts/what-is-memory | canonical "what is memory" for Foundry agents |
+| ms-ai-engineering / agent-orchestration/semantic-kernel-agents-implementation.md | https://learn.microsoft.com/agent-framework/overview/agent-framework-overview | Agent Framework overview = authoritative agent-implementation entry |
+| ms-ai-engineering / azure-ai-services/ai-services-api-best-practices.md | https://learn.microsoft.com/azure/architecture/patterns/rate-limiting-pattern | rate-limiting architecture pattern anchors API resilience best-practices |
+| ms-ai-engineering / azure-ai-services/document-intelligence-custom-models.md | https://learn.microsoft.com/azure/ai-services/document-intelligence/train/custom-model | parent custom-model doc (sub-types derive from it) |
+| ms-ai-engineering / azure-ai-services/language-services-question-answering.md | https://learn.microsoft.com/azure/ai-services/language-service/question-answering/overview | question-answering overview is the canonical entry |
+| ms-ai-engineering / azure-ai-services/translator-custom-neural-models.md | https://learn.microsoft.com/azure/ai-services/translator/custom-translator/overview | custom-translator overview is the canonical entry |
+| ms-ai-engineering / azure-ai-services/translator-document-translation.md | https://learn.microsoft.com/azure/ai-services/translator/document-translation/overview | document-translation overview (on-topic) over the generic translator overview |
+| ms-ai-engineering / data-engineering/cross-cloud-data-integration.md | https://learn.microsoft.com/fabric/governance/external-data-sharing-overview | external data sharing = cross-cloud integration authority |
+| ms-ai-engineering / data-engineering/data-sampling-labeling.md | https://learn.microsoft.com/azure/machine-learning/how-to-label-data | canonical data-labeling doc (all-howto pool) |
+| ms-ai-engineering / data-engineering/data-versioning-lineage.md | https://learn.microsoft.com/fabric/governance/lineage | Fabric governance lineage = canonical lineage authority |
+| ms-ai-engineering / data-engineering/microsoft-purview-governance.md | https://learn.microsoft.com/purview/unified-catalog | Purview Unified Catalog is the governance hub |
+| ms-ai-engineering / data-engineering/real-time-streaming-ai.md | https://learn.microsoft.com/fabric/real-time-intelligence/overview | broadest Real-Time Intelligence overview |
+| ms-ai-engineering / data-engineering/zero-etl-fabric-patterns.md | https://learn.microsoft.com/fabric/mirroring/overview | Fabric mirroring = zero-ETL authority |
+| ms-ai-engineering / mlops-genaiops/mlops-security-access-control.md | https://learn.microsoft.com/azure/machine-learning/concept-enterprise-security | ML enterprise-security concept anchors access-control |
+| ms-ai-engineering / rag-architecture/contextual-retrieval.md | https://learn.microsoft.com/azure/search/cognitive-search-custom-skill-interface | current custom-skill interface over the previous-versions variant |
+| ms-ai-engineering / rag-architecture/metadata-management-filtering.md | https://learn.microsoft.com/azure/search/search-what-is-an-index | index schema is the root authority for filterable metadata |
+| ms-ai-governance / monitoring-observability/alerting-strategies-escalation.md | https://learn.microsoft.com/azure/azure-monitor/alerts/best-practices-alerts | alerts best-practices = alerting-strategy authority |
+| ms-ai-governance / monitoring-observability/distributed-tracing-ai-pipelines.md | https://learn.microsoft.com/azure/azure-monitor/app/opentelemetry-overview | OpenTelemetry overview = distributed-tracing authority |
+| ms-ai-governance / monitoring-observability/observability-for-copilot-extensions.md | https://learn.microsoft.com/microsoft-cloud/dev/copilot/isv/observability-for-ai | directly "observability for AI" (Copilot ISV) |
+| ms-ai-governance / norwegian-public-sector-governance/accessibility-requirements-wcag-norway.md | https://learn.microsoft.com/compliance/regulatory/offering-wcag-2-1 | WCAG 2.1 compliance offering = accessibility authority |
+| ms-ai-governance / norwegian-public-sector-governance/digdir-ai-governance-structure.md | https://learn.microsoft.com/azure/cloud-adoption-framework/scenarios/ai/govern | CAF AI Govern = canonical AI-governance authority |
+| ms-ai-governance / norwegian-public-sector-governance/digital-accessibility-action-plan.md | https://learn.microsoft.com/compliance/regulatory/offering-wcag-2-1 | WCAG 2.1 compliance offering = accessibility standards authority |
+| ms-ai-governance / norwegian-public-sector-governance/ros-analyse-ai-systems.md | https://learn.microsoft.com/azure/well-architected/security/threat-model | Well-Architected threat-model = risk-analysis authority |
+| ms-ai-infrastructure / bcdr/compliance-requirements-bcdr.md | https://learn.microsoft.com/azure/compliance | Azure compliance hub = compliance-requirements authority |
+| ms-ai-infrastructure / bcdr/data-replication-patterns-ai.md | https://learn.microsoft.com/azure/reliability/concept-redundancy-replication-backup | reliability redundancy/replication concept = replication-patterns authority |
+| ms-ai-infrastructure / bcdr/network-resilience-patterns-ai.md | https://learn.microsoft.com/azure/ddos-protection/ddos-protection-overview | DDoS protection = primary network-resilience authority in pool |
+| ms-ai-security / ai-security-engineering/entra-agent-id-zero-trust.md | https://learn.microsoft.com/entra/id-governance/agent-id-governance-overview | Entra Agent ID governance overview (directly on-topic) |
+| ms-ai-security / ai-security-engineering/zero-trust-ai-services.md | https://learn.microsoft.com/security/zero-trust/apply-zero-trust-azure-services-overview | apply Zero Trust to Azure services overview = canonical |
+| ms-ai-security / cost-optimization/licensing-compliance-cost-avoidance.md | https://learn.microsoft.com/azure/cloud-adoption-framework/scenarios/ai/plan | CAF AI Plan = broad licensing/cost authority |
+| ms-ai-security / performance-scalability/rate-limit-management.md | https://learn.microsoft.com/azure/foundry/openai/quotas-limits | Azure OpenAI quotas-limits = rate-limit authority |
+
+## Deterministisk-løste (212)
+
+**Header (beholdt eksisterende `**Source:**`, 6):**
+
+- ms-ai-engineering / rag-architecture/late-chunking-patterns.md → https://learn.microsoft.com/azure/foundry/openai/tutorials/embeddings
+- ms-ai-security / ai-security-engineering/ai-red-team-operations-practical.md → https://learn.microsoft.com/security/ai-red-team/training
+- ms-ai-security / cost-optimization/batch-processing-cost-reduction.md → https://learn.microsoft.com/azure/foundry/openai/how-to/batch
+- ms-ai-security / cost-optimization/model-selection-price-performance.md → https://learn.microsoft.com/azure/foundry/foundry-models/concepts/models-sold-directly-by-azure
+- ms-ai-security / cost-optimization/ptu-vs-paygo-economics.md → https://learn.microsoft.com/azure/foundry/openai/concepts/provisioned-throughput
+- ms-ai-security / performance-scalability/batch-api-usage-optimization.md → https://learn.microsoft.com/azure/foundry/openai/how-to/batch-blob-storage
+
+**Deterministiske tie-breaks (206):** single/concept/top-score/most-cited — full liste i manifestets `authorityMethod`-felt per entry. Metode-fordeling over.
+
+## Deferred — ingen MS-sitering (59, `unsourced`-bøtte)
+
+Reference-typet på innhold (Step 4), men uten inline `learn.microsoft.com`-sitering å binde autoritet til. Ingen gjetning — corpus judge-pass (neste brief) henter + verifiserer + kilde-setter disse.
+
+- ms-ai-engineering / agent-orchestration/agent-compliance-and-audit-trails.md
+- ms-ai-engineering / agent-orchestration/agent-cost-optimization-strategies.md
+- ms-ai-engineering / agent-orchestration/agent-ecosystem-and-plugin-marketplace.md
+- ms-ai-engineering / agent-orchestration/agent-feedback-and-learning-loops.md
+- ms-ai-engineering / agent-orchestration/agent-latency-optimization.md
+- ms-ai-engineering / agent-orchestration/agent-monitoring-observability.md
+- ms-ai-engineering / agent-orchestration/agent-routing-and-specialization.md
+- ms-ai-engineering / agent-orchestration/agent-security-threat-modeling.md
+- ms-ai-engineering / agent-orchestration/copilot-agent-integration-patterns.md
+- ms-ai-engineering / agent-orchestration/declarative-vs-imperative-agent-design.md
+- ms-ai-engineering / agent-orchestration/multi-tenant-agent-isolation.md
+- ms-ai-engineering / api-management/circuit-breaker-ai-resilience.md
+- ms-ai-engineering / api-management/load-balancing-openai-instances.md
+- ms-ai-engineering / api-management/semantic-caching-apim.md
+- ms-ai-engineering / api-management/token-rate-limiting-policies.md
+- ms-ai-engineering / multi-modal/accessibility-multimodal-ai.md
+- ms-ai-engineering / multi-modal/audio-video-transcription-workflow.md
+- ms-ai-engineering / multi-modal/azure-video-indexer-patterns.md
+- ms-ai-engineering / multi-modal/cv-llm-integration.md
+- ms-ai-engineering / multi-modal/dalle-image-generation.md
+- ms-ai-engineering / multi-modal/document-vision-processing.md
+- ms-ai-engineering / multi-modal/gpt4o-vision-architecture.md
+- ms-ai-engineering / multi-modal/image-classification-understanding.md
+- ms-ai-engineering / multi-modal/multimodal-content-safety.md
+- ms-ai-engineering / multi-modal/multimodal-evaluation-metrics.md
+- ms-ai-engineering / multi-modal/multimodal-prompt-engineering.md
+- ms-ai-engineering / multi-modal/multimodal-rag-architecture.md
+- ms-ai-engineering / multi-modal/ocr-pipeline-architecture.md
+- ms-ai-engineering / multi-modal/real-time-audio-api.md
+- ms-ai-engineering / multi-modal/speech-to-ai-pipelines.md
+- ms-ai-engineering / multi-modal/text-to-speech-citizen.md
+- ms-ai-engineering / multi-modal/video-analysis-patterns.md
+- ms-ai-engineering / multi-modal/whisper-speech-recognition.md
+- ms-ai-governance / monitoring-observability/application-insights-llm-monitoring.md
+- ms-ai-governance / monitoring-observability/azure-monitor-setup-ai-workloads.md
+- ms-ai-governance / norwegian-public-sector-governance/norwegian-nlp-benchmarks.md
+- ms-ai-governance / responsible-ai/ai-act-microsoft-tools-mapping.md
+- ms-ai-infrastructure / hybrid-edge/azure-arc-ai-management.md
+- ms-ai-infrastructure / hybrid-edge/azure-confidential-computing-ai.md
+- ms-ai-infrastructure / hybrid-edge/azure-iot-hub-ai-pipeline.md
+- ms-ai-infrastructure / hybrid-edge/azure-local-ai-workloads.md
+- ms-ai-infrastructure / hybrid-edge/data-sovereignty-norway-public-sector.md
+- ms-ai-infrastructure / hybrid-edge/edge-ai-inferencing-patterns.md
+- ms-ai-infrastructure / hybrid-edge/edge-to-cloud-data-synchronization.md
+- ms-ai-infrastructure / hybrid-edge/hybrid-rag-architecture.md
+- ms-ai-infrastructure / hybrid-edge/iot-operations-ai-integration.md
+- ms-ai-infrastructure / hybrid-edge/kubernetes-edge-aks-edge.md
+- ms-ai-infrastructure / hybrid-edge/network-constrained-ai-deployment.md
+- ms-ai-infrastructure / hybrid-edge/offline-first-ai-applications.md
+- ms-ai-infrastructure / hybrid-edge/on-premises-slm-phi-deployment.md
+- ms-ai-infrastructure / hybrid-edge/onnx-runtime-edge-deployment.md
+- ms-ai-infrastructure / hybrid-edge/regulatory-compliance-edge-ai.md
+- ms-ai-infrastructure / hybrid-edge/sovereign-cloud-norway.md
+- ms-ai-infrastructure / hybrid-edge/windows-ai-apc-capabilities.md
+- ms-ai-security / ai-security-engineering/secure-model-deployment-hardening.md
+- ms-ai-security / performance-scalability/auto-scaling-ai-infrastructure.md
+- ms-ai-security / performance-scalability/cdn-edge-caching-ai.md
+- ms-ai-security / performance-scalability/latency-optimization-azure-openai.md
+- ms-ai-security / performance-scalability/streaming-response-patterns.md
+
+## Deferred — advisor-scope (50)
+
+Advisor reference-entries. Utenfor Step 6 sitt non-advisor-mandat; applier (Step 9) muterer dem aldri (hard advisor-fence). Kilde-valg utsatt (evt. mooted av Cosmo-fjerning R13/R14).
+
+- ms-ai-advisor / architecture/cost-models.md
+- ms-ai-advisor / architecture/licensing-matrix.md
+- ms-ai-advisor / architecture/migration-patterns.md
+- ms-ai-advisor / architecture/regional-availability-verification.md
+- ms-ai-advisor / architecture/security.md
+- ms-ai-advisor / copilot-extensibility/adaptive-cards-copilot-responses.md
+- ms-ai-advisor / copilot-extensibility/copilot-analytics-and-usage-insights.md
+- ms-ai-advisor / copilot-extensibility/copilot-api-rate-limiting-resilience.md
+- ms-ai-advisor / copilot-extensibility/copilot-connectors-design-patterns.md
+- ms-ai-advisor / copilot-extensibility/copilot-context-window-optimization.md
+- ms-ai-advisor / copilot-extensibility/copilot-dlp-and-governance.md
+- ms-ai-advisor / copilot-extensibility/copilot-extensibility-security-patterns.md
+- ms-ai-advisor / copilot-extensibility/copilot-orchestration-multi-agent.md
+- ms-ai-advisor / copilot-extensibility/copilot-prompt-engineering-governance.md
+- ms-ai-advisor / copilot-extensibility/copilot-studio-localization-globalization.md
+- ms-ai-advisor / copilot-extensibility/copilot-studio-nlp-configuration.md
+- ms-ai-advisor / copilot-extensibility/copilot-studio-topics-and-entities.md
+- ms-ai-advisor / copilot-extensibility/custom-engine-agents-development.md
+- ms-ai-advisor / copilot-extensibility/declarative-agents-fundamentals.md
+- ms-ai-advisor / copilot-extensibility/declarative-agents-grounding-strategies.md
+- ms-ai-advisor / copilot-extensibility/enterprise-governance-copilot-deployment.md
+- ms-ai-advisor / copilot-extensibility/m365-copilot-plugins-ecosystem.md
+- ms-ai-advisor / copilot-extensibility/mcp-protocol-copilot-studio.md
+- ms-ai-advisor / copilot-extensibility/microsoft-graph-api-copilot-integration.md
+- ms-ai-advisor / copilot-extensibility/power-automate-copilot-integration.md
+- ms-ai-advisor / copilot-extensibility/sharepoint-copilot-agents.md
+- ms-ai-advisor / copilot-extensibility/teams-copilot-message-extensions.md
+- ms-ai-advisor / development/agent-framework.md
+- ms-ai-advisor / platforms/azure-ai-foundry.md
+- ms-ai-advisor / platforms/copilot-studio.md
+- ms-ai-advisor / platforms/m365-copilot.md
+- ms-ai-advisor / platforms/model-catalog-2026.md
+- ms-ai-advisor / platforms/power-platform.md
+- ms-ai-advisor / prompt-engineering/adversarial-prompting-and-jailbreaks.md
+- ms-ai-advisor / prompt-engineering/chain-of-thought-prompting.md
+- ms-ai-advisor / prompt-engineering/domain-specific-prompt-optimization.md
+- ms-ai-advisor / prompt-engineering/error-handling-and-fallback-prompting.md
+- ms-ai-advisor / prompt-engineering/few-shot-learning-techniques.md
+- ms-ai-advisor / prompt-engineering/function-calling-and-tool-use.md
+- ms-ai-advisor / prompt-engineering/grounding-and-knowledge-injection.md
+- ms-ai-advisor / prompt-engineering/multi-turn-conversation-management.md
+- ms-ai-advisor / prompt-engineering/multimodal-prompt-design.md
+- ms-ai-advisor / prompt-engineering/prompt-testing-and-evaluation.md
+- ms-ai-advisor / prompt-engineering/real-time-reasoning-performance.md
+- ms-ai-advisor / prompt-engineering/reasoning-models-o1-o3-optimization.md
+- ms-ai-advisor / prompt-engineering/role-playing-and-persona-techniques.md
+- ms-ai-advisor / prompt-engineering/structured-output-formatting.md
+- ms-ai-advisor / prompt-engineering/system-message-design-patterns.md
+- ms-ai-advisor / prompt-engineering/temperature-sampling-and-parameters.md
+- ms-ai-advisor / prompt-engineering/token-optimization-and-efficiency.md
+
+## Reproduserbarhet
+
+- Deterministiske valg reproduseres av `scripts/kb-update/lib/url-normalize.extractUrls` + tie-break-reglene over mot samme korpus + `url-registry.json`.
+- De 31 residual-valgene er menneske-adjudikert (låst i denne loggen + manifestets `authorityMethod:"residual-judgment"` + `authoritySelectedBy`).
+- Manifestet er gitignored (regenererbart); den varige autoritetsposten er denne loggen og — etter Step 9 — `**Source:**`-headerne i korpuset.

docs/spor1-classification-review.md

@@ -0,0 +1,136 @@
+# Spor 1 — Edge-Set Classification Review (Step 4)
+
+**Date:** 2026-07-03
+**Scope:** every manifest entry flagged `reviewFlag:true` by the mechanical classifier (106 of 389)
+**Mechanism:** main-context executor content review, two tiers — (1) title + section headings + intro per file, (2) full-text sampling where tier 1 was inconclusive (6 files). The plan prescribed read-only subagent fan-out; the executor's Agent tool is disabled during plan execution (trekexecute Hard Rule 10), so adjudication ran in the main context against the same criteria. Recorded as `resolvedBy: executor-content-review-2026-07-03`.
+
+## Criteria (Port-1 closed type set)
+
+- **reference** — dominant substance is machine-verifiable Microsoft product/service claims (verifiable against learn.microsoft.com); will carry a `**Source:**` URL.
+- **template** — reusable fill-in scaffold; must never carry an MS source.
+- **methodology** — reusable process/framework guidance; must never carry an MS source.
+- **regulatory** — law/standard text or obligations derived directly from it.
+
+Judged by content substance, not filename. No file was deferred — every flagged file had a defensible type.
+
+## Outcome
+
+Resolved: **106/106** (0 deferred). Distribution within the edge set: {"template":8,"methodology":20,"reference":69,"regulatory":9}.
+Corpus-wide (389): reference 352 · methodology 20 · regulatory 9 · template 8.
+
+Notable calls:
+- `ms-ai-advisor/development/agent-framework.md` → **reference** (pure MS API fact base; the path heuristic tripped on 'framework').
+- `responsible-ai/ai-ethics-in-public-sector.md` → **reference** (substance = MS RAI standard + Foundry capabilities) while `norwegian-public-sector-governance/public-sector-ai-ethics-framework.md` → **methodology** (substance = Norwegian governance landscape). Same theme, different dominant substance.
+- `norwegian-public-sector-governance/norwegian-nlp-benchmarks.md` → **reference** with zero MS citations — expected to land in the honest `unsourced/deferred` bucket in Step 6.
+- The 67 zero-MS engineering/infrastructure files (multi-modal, hybrid-edge, api-management, agent-orchestration, performance-scalability) are Azure product-fact files written without citations — all **reference**; Step 6 will defer them unless a defensible MS authority exists.
+
+## Per-file adjudication
+
+| File (under skills/) | Type | Classifier signal | Rationale |
+|---|---|---|---|
+| `ms-ai-advisor/references/architecture/adr-template.md` | template | ms-citation+path-conflict | MADR fill-in scaffold; MS citations are illustrative |
+| `ms-ai-advisor/references/architecture/ai-utredning-template.md` | template | ms-citation+path-conflict | utredningsmal (fill-in document skeleton) grounded in utredningsinstruksen |
+| `ms-ai-advisor/references/architecture/alternativanalyse-methodology.md` | methodology | path-heuristic | weighted MCA scoring process for architecture comparison |
+| `ms-ai-advisor/references/architecture/capacity-feasibility-benchmarks.md` | methodology | path-heuristic | feasibility assessment framework (gap matrices, timeline validation) |
+| `ms-ai-advisor/references/architecture/decision-trees.md` | methodology | path-heuristic | platform decision frameworks; embedded MS facts are supporting |
+| `ms-ai-advisor/references/architecture/diagram-prompt-templates.md` | template | path-heuristic | prompt templates for Imagen 3 diagram generation |
+| `ms-ai-advisor/references/architecture/poc-template.md` | template | ms-citation+path-conflict | POC plan/rubric/checklist scaffolds |
+| `ms-ai-advisor/references/architecture/public-sector-checklist.md` | template | ms-citation+path-conflict | comprehensive fill-in checklist for public-sector adoption |
+| `ms-ai-advisor/references/architecture/rag-maturity-model.md` | methodology | path-heuristic | maturity model + level-selection decision framework |
+| `ms-ai-advisor/references/architecture/recommended-mcp-servers.md` | methodology | path-heuristic | advisory tool-selection guidance with matrix |
+| `ms-ai-advisor/references/architecture/source-traceability-assumption-register.md` | methodology | path-heuristic | traceability/assumption-register process framework |
+| `ms-ai-advisor/references/development/agent-framework.md` | reference | ms-citation+path-conflict | MS Agent Framework API facts, verified against MS Learn |
+| `ms-ai-advisor/references/prompt-engineering/regulatory-and-compliance-prompting.md` | methodology | ms-citation+path-conflict | reusable compliance-aware prompting patterns |
+| `ms-ai-engineering/references/agent-orchestration/agent-compliance-and-audit-trails.md` | reference | path-heuristic | Azure agent audit/compliance product patterns |
+| `ms-ai-engineering/references/agent-orchestration/agent-cost-optimization-strategies.md` | reference | path-heuristic | Foundry/Azure cost-optimization product facts |
+| `ms-ai-engineering/references/agent-orchestration/agent-ecosystem-and-plugin-marketplace.md` | reference | path-heuristic | agent ecosystem/marketplace platform patterns |
+| `ms-ai-engineering/references/agent-orchestration/agent-evaluation-testing-frameworks.md` | reference | ms-citation+path-conflict | Azure AI Evaluation SDK facts (GA/Preview status) |
+| `ms-ai-engineering/references/agent-orchestration/agent-feedback-and-learning-loops.md` | reference | path-heuristic | Foundry continuous-evaluation product facts |
+| `ms-ai-engineering/references/agent-orchestration/agent-latency-optimization.md` | reference | path-heuristic | Azure agent latency/performance product patterns |
+| `ms-ai-engineering/references/agent-orchestration/agent-monitoring-observability.md` | reference | path-heuristic | Azure tracing/observability product patterns |
+| `ms-ai-engineering/references/agent-orchestration/agent-routing-and-specialization.md` | reference | path-heuristic | Semantic Kernel/Azure routing product patterns |
+| `ms-ai-engineering/references/agent-orchestration/agent-security-threat-modeling.md` | reference | path-heuristic | Azure agent security product patterns |
+| `ms-ai-engineering/references/agent-orchestration/copilot-agent-integration-patterns.md` | reference | path-heuristic | Copilot Studio integration product facts |
+| `ms-ai-engineering/references/agent-orchestration/declarative-vs-imperative-agent-design.md` | reference | path-heuristic | MS agent-platform design tradeoff facts |
+| `ms-ai-engineering/references/agent-orchestration/multi-tenant-agent-isolation.md` | reference | path-heuristic | Azure OpenAI isolation model facts |
+| `ms-ai-engineering/references/api-management/circuit-breaker-ai-resilience.md` | reference | path-heuristic | APIM circuit-breaker configuration facts |
+| `ms-ai-engineering/references/api-management/load-balancing-openai-instances.md` | reference | path-heuristic | APIM backend-pool/load-balancing facts |
+| `ms-ai-engineering/references/api-management/semantic-caching-apim.md` | reference | path-heuristic | APIM semantic-caching policy facts |
+| `ms-ai-engineering/references/api-management/token-rate-limiting-policies.md` | reference | path-heuristic | APIM token-rate-limit policy facts |
+| `ms-ai-engineering/references/data-engineering/data-quality-ai-frameworks.md` | reference | ms-citation+path-conflict | MS data-quality tooling (Purview/Fabric) facts |
+| `ms-ai-engineering/references/mlops-genaiops/model-evaluation-frameworks.md` | reference | ms-citation+path-conflict | Azure ML/Foundry evaluation tooling facts |
+| `ms-ai-engineering/references/multi-modal/accessibility-multimodal-ai.md` | reference | path-heuristic | Azure AI accessibility product facts (WCAG tooling) |
+| `ms-ai-engineering/references/multi-modal/audio-video-transcription-workflow.md` | reference | path-heuristic | Azure Speech batch-transcription product facts |
+| `ms-ai-engineering/references/multi-modal/azure-video-indexer-patterns.md` | reference | path-heuristic | Azure Video Indexer product facts |
+| `ms-ai-engineering/references/multi-modal/cv-llm-integration.md` | reference | path-heuristic | Azure vision+LLM integration product facts |
+| `ms-ai-engineering/references/multi-modal/dalle-image-generation.md` | reference | path-heuristic | Azure OpenAI DALL-E product facts |
+| `ms-ai-engineering/references/multi-modal/document-vision-processing.md` | reference | path-heuristic | Document Intelligence product facts |
+| `ms-ai-engineering/references/multi-modal/gpt4o-vision-architecture.md` | reference | path-heuristic | GPT-4o vision capability/token-model facts |
+| `ms-ai-engineering/references/multi-modal/image-classification-understanding.md` | reference | path-heuristic | Azure vision model selection/training facts |
+| `ms-ai-engineering/references/multi-modal/multimodal-content-safety.md` | reference | path-heuristic | Azure AI Content Safety product facts |
+| `ms-ai-engineering/references/multi-modal/multimodal-evaluation-metrics.md` | reference | path-heuristic | multimodal evaluation metric/tooling facts |
+| `ms-ai-engineering/references/multi-modal/multimodal-prompt-engineering.md` | reference | path-heuristic | multimodal prompting capability facts (GPT-4o) |
+| `ms-ai-engineering/references/multi-modal/multimodal-rag-architecture.md` | reference | path-heuristic | Azure multimodal embedding/RAG product facts |
+| `ms-ai-engineering/references/multi-modal/ocr-pipeline-architecture.md` | reference | path-heuristic | Azure OCR engine/pipeline product facts |
+| `ms-ai-engineering/references/multi-modal/real-time-audio-api.md` | reference | path-heuristic | Azure OpenAI Realtime API product facts |
+| `ms-ai-engineering/references/multi-modal/speech-to-ai-pipelines.md` | reference | path-heuristic | Azure Speech recognition pipeline facts |
+| `ms-ai-engineering/references/multi-modal/text-to-speech-citizen.md` | reference | path-heuristic | Azure neural TTS product facts |
+| `ms-ai-engineering/references/multi-modal/video-analysis-patterns.md` | reference | path-heuristic | Azure video analysis product facts |
+| `ms-ai-engineering/references/multi-modal/whisper-speech-recognition.md` | reference | path-heuristic | Whisper on Azure product facts |
+| `ms-ai-engineering/references/rag-architecture/rag-evaluation-frameworks.md` | reference | ms-citation+path-conflict | RAG evaluation tooling/SDK facts |
+| `ms-ai-governance/references/monitoring-observability/application-insights-llm-monitoring.md` | reference | path-heuristic | Application Insights LLM telemetry facts |
+| `ms-ai-governance/references/monitoring-observability/azure-monitor-setup-ai-workloads.md` | reference | path-heuristic | Azure Monitor configuration facts (Portal/PS/CLI) |
+| `ms-ai-governance/references/norwegian-public-sector-governance/anskaffelser-ai-procurement-framework.md` | methodology | ms-citation+path-conflict | procurement process framework (lovgrunnlag + DFØ + SSA) |
+| `ms-ai-governance/references/norwegian-public-sector-governance/dpia-norwegian-methodology-ai.md` | methodology | ms-citation+path-conflict | Datatilsynet DPIA process methodology for AI |
+| `ms-ai-governance/references/norwegian-public-sector-governance/gevinstrealisering-dfo-methodology.md` | methodology | path-heuristic | DFØ 5-step benefit-realization process |
+| `ms-ai-governance/references/norwegian-public-sector-governance/norwegian-nlp-benchmarks.md` | reference | path-heuristic | factual benchmark/model-comparison content; no MS authority → expected unsourced/deferred in Step 6 |
+| `ms-ai-governance/references/norwegian-public-sector-governance/public-sector-ai-ethics-framework.md` | methodology | ms-citation+path-conflict | Norwegian ethics governance landscape/framework guidance |
+| `ms-ai-governance/references/norwegian-public-sector-governance/ros-ai-threat-library.md` | methodology | path-heuristic | reusable AI threat catalog for ROS assessment (OWASP-anchored) |
+| `ms-ai-governance/references/norwegian-public-sector-governance/ros-dpia-security-integration.md` | methodology | path-heuristic | assessment sequencing/integration process guide |
+| `ms-ai-governance/references/norwegian-public-sector-governance/ros-maestro-multiagent.md` | methodology | path-heuristic | MAESTRO 7-layer assessment framework + checklist |
+| `ms-ai-governance/references/norwegian-public-sector-governance/ros-methodology-ns5814-iso31000.md` | regulatory | path-heuristic | NS 5814/ISO 31000/ISO 23894/AI Act Art.9 standard-text mapping |
+| `ms-ai-governance/references/norwegian-public-sector-governance/ros-report-templates.md` | template | path-heuristic | Quick/Full ROS report fill-in scaffolds |
+| `ms-ai-governance/references/norwegian-public-sector-governance/ros-scoring-rubrics-7x5.md` | methodology | path-heuristic | 7x5 scoring rubric framework for ROS |
+| `ms-ai-governance/references/norwegian-public-sector-governance/ros-sector-checklists.md` | template | path-heuristic | sector fill-in checklists (helse/transport/finans/...) |
+| `ms-ai-governance/references/norwegian-public-sector-governance/samfunnsokonomisk-analyse-nnv.md` | methodology | path-heuristic | NNV/samfunnsøkonomisk analysis process (DFØ) |
+| `ms-ai-governance/references/norwegian-public-sector-governance/statistical-ethics-ssa-methodology.md` | methodology | ms-citation+path-conflict | SSB statistical-ethics application methodology |
+| `ms-ai-governance/references/norwegian-public-sector-governance/utredningsinstruksen-ai-methodology.md` | methodology | ms-citation+path-conflict | utredningsinstruksen applied as AI assessment process |
+| `ms-ai-governance/references/responsible-ai/ai-act-annex-iii-checklist.md` | regulatory | ms-citation+path-conflict | Annex III high-risk categories/checkpoints (obligations from the Act) |
+| `ms-ai-governance/references/responsible-ai/ai-act-classification-methodology.md` | regulatory | path-heuristic | classification per the Act’s own rules (Annex III, provider/deployer roles) |
+| `ms-ai-governance/references/responsible-ai/ai-act-compliance-guide.md` | regulatory | ms-citation+path-conflict | the Act’s risk classes + obligations are the substance; MS tooling is a section |
+| `ms-ai-governance/references/responsible-ai/ai-act-conformity-assessment.md` | regulatory | path-heuristic | Art. 43/47 + Annex IV conformity obligations |
+| `ms-ai-governance/references/responsible-ai/ai-act-deployer-obligations.md` | regulatory | path-heuristic | Art. 26/27 deployer obligations |
+| `ms-ai-governance/references/responsible-ai/ai-act-fria-template.md` | template | path-heuristic | FRIA fill-in scaffold (7 sections) grounded in Art. 27 |
+| `ms-ai-governance/references/responsible-ai/ai-act-microsoft-tools-mapping.md` | reference | path-heuristic | MS tool capabilities mapped to AI Act articles (Purview/Compliance Manager facts) |
+| `ms-ai-governance/references/responsible-ai/ai-act-provider-obligations.md` | regulatory | path-heuristic | Art. 9–15 provider obligations |
+| `ms-ai-governance/references/responsible-ai/ai-act-transparency-notices.md` | regulatory | path-heuristic | Art. 13/50 transparency obligations (maler secondary) |
+| `ms-ai-governance/references/responsible-ai/ai-ethics-in-public-sector.md` | reference | ms-citation+path-conflict | MS RAI standard + Foundry capability facts are the substance |
+| `ms-ai-governance/references/responsible-ai/ai-governance-structure-framework.md` | methodology | ms-citation+path-conflict | organizational governance framework guidance |
+| `ms-ai-governance/references/responsible-ai/ai-impact-assessment-framework.md` | methodology | ms-citation+path-conflict | impact assessment process framework |
+| `ms-ai-governance/references/responsible-ai/gdpr-compliance-ai-systems.md` | regulatory | ms-citation+path-conflict | GDPR obligations applied to AI systems |
+| `ms-ai-governance/references/responsible-ai/model-explainability-interpretability.md` | reference | ms-citation+path-conflict | Azure ML RAI dashboard/InterpretML product facts dominate |
+| `ms-ai-governance/references/responsible-ai/responsible-ai-framework-overview.md` | reference | ms-citation+path-conflict | Microsoft RAI framework facts, MS-verifiable |
+| `ms-ai-infrastructure/references/hybrid-edge/azure-arc-ai-management.md` | reference | path-heuristic | Azure Arc product facts |
+| `ms-ai-infrastructure/references/hybrid-edge/azure-confidential-computing-ai.md` | reference | path-heuristic | Azure Confidential Computing product facts |
+| `ms-ai-infrastructure/references/hybrid-edge/azure-iot-hub-ai-pipeline.md` | reference | path-heuristic | Azure IoT Hub product facts |
+| `ms-ai-infrastructure/references/hybrid-edge/azure-local-ai-workloads.md` | reference | path-heuristic | Azure Local product facts |
+| `ms-ai-infrastructure/references/hybrid-edge/data-sovereignty-norway-public-sector.md` | reference | path-heuristic | Azure data residency/EUDB/sovereign cloud facts |
+| `ms-ai-infrastructure/references/hybrid-edge/edge-ai-inferencing-patterns.md` | reference | path-heuristic | edge inference product patterns (IoT Edge, quantization) |
+| `ms-ai-infrastructure/references/hybrid-edge/edge-to-cloud-data-synchronization.md` | reference | path-heuristic | edge-cloud sync product patterns |
+| `ms-ai-infrastructure/references/hybrid-edge/hybrid-rag-architecture.md` | reference | path-heuristic | hybrid RAG architecture product patterns |
+| `ms-ai-infrastructure/references/hybrid-edge/iot-operations-ai-integration.md` | reference | path-heuristic | Azure IoT Operations product facts |
+| `ms-ai-infrastructure/references/hybrid-edge/kubernetes-edge-aks-edge.md` | reference | path-heuristic | AKS Edge Essentials product facts |
+| `ms-ai-infrastructure/references/hybrid-edge/network-constrained-ai-deployment.md` | reference | path-heuristic | constrained-network deployment product patterns |
+| `ms-ai-infrastructure/references/hybrid-edge/offline-first-ai-applications.md` | reference | path-heuristic | offline-first AI application product patterns |
+| `ms-ai-infrastructure/references/hybrid-edge/on-premises-slm-phi-deployment.md` | reference | path-heuristic | Phi-3/Phi-4 on-prem deployment facts |
+| `ms-ai-infrastructure/references/hybrid-edge/onnx-runtime-edge-deployment.md` | reference | path-heuristic | ONNX Runtime product facts |
+| `ms-ai-infrastructure/references/hybrid-edge/regulatory-compliance-edge-ai.md` | reference | path-heuristic | MS compliance tooling for edge (Arc/Purview/Defender/Compliance Manager) is the substance |
+| `ms-ai-infrastructure/references/hybrid-edge/sovereign-cloud-norway.md` | reference | path-heuristic | MS sovereign cloud capability facts |
+| `ms-ai-infrastructure/references/hybrid-edge/windows-ai-apc-capabilities.md` | reference | path-heuristic | Windows ML/NPU/Copilot+ PC facts |
+| `ms-ai-security/references/ai-security-engineering/ai-security-scoring-framework.md` | reference | ms-citation+path-conflict | documents Microsoft’s AI Risk Assessment Framework (MS-verifiable) |
+| `ms-ai-security/references/ai-security-engineering/secure-model-deployment-hardening.md` | reference | path-heuristic | Azure ML/ACR/Defender/Key Vault hardening facts |
+| `ms-ai-security/references/performance-scalability/auto-scaling-ai-infrastructure.md` | reference | path-heuristic | Azure Container Apps scaling facts |
+| `ms-ai-security/references/performance-scalability/cdn-edge-caching-ai.md` | reference | path-heuristic | Azure Front Door/CDN product facts |
+| `ms-ai-security/references/performance-scalability/latency-optimization-azure-openai.md` | reference | path-heuristic | Azure OpenAI latency optimization facts |
+| `ms-ai-security/references/performance-scalability/performance-benchmarking-frameworks.md` | reference | ms-citation+path-conflict | azure-openai-benchmark/Azure Load Testing/Foundry eval facts |
+| `ms-ai-security/references/performance-scalability/streaming-response-patterns.md` | reference | path-heuristic | SSE/streaming implementation facts for Azure OpenAI |

docs/spor1-migration-outcome.md

@@ -0,0 +1,91 @@
+# Spor 1 — Corpus-migrasjon: utfall og policy-delta (R4, Steg 9–11)
+
+_Datert 2026-07-04. Kilde: `migrate-corpus.mjs --write` over de 4 ikke-advisor-skills +
+`build-registry --merge` → `score-skill --write` → `report-full-pass-worklist`._
+
+Denne noten registrerer det målte utfallet av Port-1-substrat-migrasjonen (Type/Source/TOC
++ stale-verified-fjerning) og skiller **verifisert** fra **antatt**, per verifiseringsplikten.
+
+## Hva migrasjonen gjorde (verifisert mot ground truth)
+
+| Felt | Antall | Kilde |
+|------|--------|-------|
+| Filer mutert (ikke-advisor) | 327 / 327 | applier-output + `git diff --name-only` |
+| `**Type:**` stemplet | 327 | manifest (alle typer) |
+| `**Source:**` backfilt | 243 | manifest (sourced reference; deferred = ingen source) |
+| `## Innhold` TOC innsatt | 325 | store filer (≥100 linjer) |
+| stale `**Verified:** MCP` fjernet | 14 header + 9 body-dup (i 500B-vinduet) | normalizer + parser |
+| advisor-filer rørt | 0 | `git diff --stat -- skills/ms-ai-advisor/` |
+| prosa-kropper endret (fra første `##`) | 0 | per-fil `git show HEAD:` diff |
+| `verified` satt | null (uendret) | migrasjonen stempler ALDRI verified |
+
+Slettelinjer i diffen: 25 totalt, **alle `**Verified:**`-relaterte** (21 Verified-linjer + 4
+tilhørende tomlinjer) — ingen prosa slettet.
+
+## To applier-fixes oppdaget under kjøring (TDD, RED→GREEN)
+
+Migrasjonen avdekket to reelle feil i de testede primitivene. Begge fikset med failing
+test først; suiten 728/728 grønn.
+
+1. **`insertHeaderFields` anker-overshoot (2 filer).** `agentic-rag-patterns.md` og
+   `gpt5-gpt41-pricing-models.md` pakker et helt avsnitt inn i én `**Status:**`-linje
+   (>500 B). Ankeret satte innsettingspunktet ETTER den linja → Type/Source landet forbi
+   500-byte-scan-vinduet. Applierens post-write-assertion fanget det og restaurerte hele
+   korpuset fra backup (sikkerhetsmekanismen virket). Fix: ankeret faller tilbake til
+   siste meta-linje som fortsatt ligger innenfor vinduet.
+
+2. **`normalizeStaleVerified` body-dup poison (9 filer, alle `mlops-genaiops/`).** Etter at
+   header-`**Verified:** MCP` ble fjernet, leste `parseVerifiedHeader` fortsatt en stray
+   duplikat-`**Verified:** MCP`-linje rett under `---` men innenfor 500 B → filene ble
+   falskt lest som "verified" → droppet til `fresh`, utenfor worklisten. Fix (operatør-
+   godkjent utvidelse av carve-out): normalizer fjerner nå ALLE stale non-date
+   `**Verified:**` i 500B-vinduet, uansett `---`-posisjon; kun stray metadata-linjer,
+   aldri prosa. Alt forbi 500 B er ekte kropp og røres ikke.
+
+## Skill-score-delta (pre → post)
+
+| Skill | Score | CT5 available | N4 (sub / pass) |
+|-------|-------|---------------|-----------------|
+| ms-ai-engineering | 95 → **99** | false → **true** | 0 → **1.000 / pass** |
+| ms-ai-governance | 96 → **100** | false → **true** | 0.013 → **1.000 / pass** |
+| ms-ai-infrastructure | 95 → **98** | false → **true** | 0 → **1.000 / pass** |
+| ms-ai-security | 95 → **100** | false → **true** | 0 → **1.000 / pass** |
+| ms-ai-advisor | 91 → 91 | (uendret) | (uendret) |
+
+CT5 `pass=false` på engineering + infrastructure er forventet: full CT5-pass krever
+`verified`-stempler, som settes først i corpus-judge-pass (fremtidig). CT5 er nå
+**available** (evaluert) på alle 4 fordi reference-filene bærer Type+Source.
+
+## Policy-artefakt: forventet dip inntraff IKKE
+
+Planen (Risks) forhåndsdeklarerte en **transient sub-90 dip** (CT5/N4-aktivering kunne
+dra de 4 skills under 90 midlertidig) som et **policy-artefakt** å ikke reagere på.
+**Målt utfall: dip inntraff ikke** — scorene STEG (95→98–100). N4 gikk 0→1.000 (TOC lagt
+til), CT5 ble available. Advarselen var altså konservativ; ingen skill falt under target.
+Registrert her for å hindre at en senere sesjon leter etter en dip som ikke finnes.
+
+## Worklist-transisjon (verifisert)
+
+Post-migrasjon + poison-fix (`report-full-pass-worklist.mjs`):
+
+| Bøtte | Antall | Merknad |
+|-------|--------|---------|
+| `due` | 243 | aktivert (var 0 pre-migrasjon); +9 etter poison-fix |
+| `fresh` | 0 | var 9 (body-dup poison) → 0 etter fix |
+| `unsourced` | 59 | deferred no-citation reference (dokumentert follow-up) |
+| `unmigrated` | 62 | advisor (bevisst utenfor scope) |
+| `outOfScope` | 25 | — |
+| **sum** | **389** | 243 + 59 + 62 + 25 = 389 ✅ |
+
+## Base-felt-restanse (dokumentert follow-up — utenfor dette substratet)
+
+Substrat-migrasjonen normaliserer IKKE base-feltene (worklist/CT5/N4 leser dem ikke):
+
+- `**Status:**` mangler: **29 filer** (planen anslo 31).
+- `**Last updated:**` (engelsk RE) mangler: **0** (planen fryktet 45 norske — ikke reelt).
+- `**Source:**` mangler: 59 (deferred no-ms-citation — trenger kilde før stempling).
+- `verified`/`verified_by` mangler: 302 (= `verified` null; settes i corpus-judge-pass).
+- TOC mangler: 0.
+
+Base-felt-normalisering (Status på de 29) er en egen, senere oppgave — ikke nødvendig for
+Port-1-substratet.

docs/v3.1-fanout-runbook.md

@@ -0,0 +1,92 @@
+# 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.
+
+## Forutsetning 0 (R7-gate — FØR alt annet)
+
+Denne kjøringen fetcher untrusted innhold (MS Learn → judge-subagenter). **Layer A-aktiveringsprotokollen `docs/ingestion-security-brief-2026-07.md` §5b (pkt. 1–5) MÅ være grønn før første fetch** — den er en hard R7-gate, ikke bare en aktiveringsregel. Kort: aktiver `post-mcp-verify`-hooken, verifiser at den fyrer på ÉN foreground-fetch (ellers kompenserende foreground-skann), og bekreft at `llm-security`-substratet løser (ellers fail-closer Layer B og BLOCKer alt).
+
+**Untrusted-data-ramme (hvorfor judgen IKKE fences):** det fetchede innholdet prompt-fences **ikke** inn i den frosne v3.1-judgen. Å legge fencing rundt `<FILE>`/`<CLAIMS>` (som ligger *inne i* den frosne malen — det finnes intet skall utenfor judgens synsfelt) ville endre teksten judgen prosesserer = en judge-bump (Non-goal §7, ville kreve re-måling av P/R). De kompenserende kontrollene er i stedet: (a) **foreground-fetch obligatorisk** (lar Layer A-hooken + operatørens øye se innholdet før judgen), og (b) **Layer B ved commit-grensen** — `scripts/kb-update/pre-commit-scan.mjs` kjører den deterministiske adversarial-skannen over stagede `skills/**/*.md` og BLOCKer commit på BLOCK/WARN, uansett modell-adferd. Judgen forblir frosset.
+
+## 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».

hooks/scripts/session-start-context.mjs

@@ -12,6 +12,7 @@ import {
   summarizeSkillLifecycle,
   summarizeCourses,
   summarizeSkillQuality,
+  summarizeTrustFreshness,
 } from '../../scripts/kb-update/lib/detection-schedule.mjs';
 import {
   resolveOrgDir,
@@ -19,6 +20,7 @@ import {
   FREE_CONTEXT_FILE,
   buildOrgSummary,
 } from '../../scripts/kb-update/lib/user-data.mjs';
+import { loadAiActDeadlines } from '../../scripts/kb-update/lib/ai-act-deadlines.mjs';
 
 const pluginRoot = process.env.CLAUDE_PLUGIN_ROOT || join(process.cwd());
 const cwd = process.cwd();
@@ -92,20 +94,12 @@ if (shouldRunDetection(scheduleConfig, lastPollDaysAgo).run) {
   }
 }
 
-// --- 3. Check EU AI Act deadlines ---
+// --- 3. Check EU AI Act deadlines (single source: scripts/kb-update/data/ai-act-deadlines.json) ---
-const AI_ACT_DEADLINES = [
+const aiActSource = loadAiActDeadlines();
-  // NB: Digital Omnibus (prov. enighet 2026-05-07) utsatte høyrisiko; datoer foreløpige til OJ-publisering.
-  { date: new Date('2025-02-02'), label: 'Forbudte AI-praksiser (Art. 5)' },
-  { date: new Date('2025-08-02'), label: 'GPAI-krav + governance/sanksjoner (Art. 99)' },
-  { date: new Date('2026-08-02'), label: 'Transparens Art. 50 (syntetisk innhold)' },
-  { date: new Date('2026-12-02'), label: 'Art. 50(2) merking — frist for eksisterende generative systemer (Omnibus)' },
-  { date: new Date('2027-12-02'), label: 'Annex III høyrisiko (provisorisk, Omnibus — utsatt fra 2026-08-02)' },
-  { date: new Date('2028-08-02'), label: 'Annex I høyrisiko innebygd (provisorisk, Omnibus)' },
-];
 
 let nearestDeadline = null;
-for (const dl of AI_ACT_DEADLINES) {
+for (const dl of aiActSource ? aiActSource.deadlines : []) {
-  const daysLeft = Math.ceil((dl.date.getTime() - now) / DAY_MS);
+  const daysLeft = Math.ceil((new Date(dl.date).getTime() - now) / DAY_MS);
   if (daysLeft > 0 && daysLeft <= 180) {
     if (!nearestDeadline || daysLeft < nearestDeadline.daysLeft) {
       nearestDeadline = { ...dl, daysLeft };
@@ -219,6 +213,21 @@ if (existsSync(scoreCachePath)) {
   }
 }
 
+// KB-trust reporting floor (Spor 3 Port 3 / P3b) — read-only one-liner; never
+// judges live. Reads the CACHED verified-staleness-report.json (written by
+// report-verified-staleness.mjs on the KB-refresh cadence). Gitignored => absent
+// in a fresh clone; summarizeTrustFreshness tolerates the missing/malformed case
+// → null. Surfaces only drift + contract breaches (§4c — a floor, not a gate).
+const stalenessCachePath = join(pluginRoot, 'scripts', 'kb-update', 'data', 'verified-staleness-report.json');
+if (existsSync(stalenessCachePath)) {
+  try {
+    const trustSummary = summarizeTrustFreshness(JSON.parse(readFileSync(stalenessCachePath, 'utf8')));
+    if (trustSummary) parts.push(trustSummary);
+  } catch {
+    // Ignore — advisory only
+  }
+}
+
 if (nearestDeadline) {
   parts.push(`EU AI Act: ${nearestDeadline.daysLeft} dager til ${nearestDeadline.label}. Kjør /architect:classify`);
 }

hooks/scripts/stop-assessment-reminder.mjs

@@ -5,6 +5,7 @@
 
 import { readdirSync, statSync, existsSync } from 'node:fs';
 import { join } from 'node:path';
+import { loadAiActDeadlines } from '../../scripts/kb-update/lib/ai-act-deadlines.mjs';
 
 const cwd = process.cwd();
 const workDir = join(cwd, '.work');
@@ -60,12 +61,18 @@ const suggestions = [
   '/architect:summary — lag beslutningsnotat',
 ];
 
-// Add AI Act suggestion if deadline is within 180 days
+// Add AI Act suggestion if the nearest deadline (from the shared source) is within 180 days
 const DAY_MS = 24 * 60 * 60 * 1000;
-const gpaiDeadline = new Date('2026-08-02');
+const aiActSource = loadAiActDeadlines();
-const daysToGpai = Math.ceil((gpaiDeadline.getTime() - now) / DAY_MS);
+let nearestDeadline = null;
-if (daysToGpai > 0 && daysToGpai <= 180) {
+for (const dl of aiActSource ? aiActSource.deadlines : []) {
-  suggestions.push(`/architect:classify — EU AI Act-klassifisering (${daysToGpai}d til GPAI-frist)`);
+  const daysLeft = Math.ceil((new Date(dl.date).getTime() - now) / DAY_MS);
+  if (daysLeft > 0 && daysLeft <= 180 && (!nearestDeadline || daysLeft < nearestDeadline.daysLeft)) {
+    nearestDeadline = { ...dl, daysLeft };
+  }
+}
+if (nearestDeadline) {
+  suggestions.push(`/architect:classify — EU AI Act-klassifisering (${nearestDeadline.daysLeft}d til ${nearestDeadline.label})`);
 }
 
 const sessionList = recentSessions.join(', ');

playground/ms-ai-architect-playground.html

@@ -246,11 +246,11 @@
       "reports": {
         "classify": {
           "input": {},
-          "raw_markdown": "# EU AI Act — Klassifisering: Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nBeskrivelse: AI-system som identifiserer objekter som krever oppfølging via sensordata + objektregister\n\n## Risikonivå\n\nRisk-level: høy\n\n## Rolle\n\nRolle: Provider og Deployer (utvikler internt + drifter selv)\n\n## Begrunnelse\n\nReasoning: Systemet brukes av offentlig myndighet for håndheving av lov, og påvirker individers rettigheter direkte gjennom automatisert beslutningsstøtte for håndtering. Dette plasserer systemet under Annex III, punkt 6 (rettshåndhevelse) og krever full høyrisiko-compliance per Art. 6(2).\n\n## Forpliktelser\n\n- Risk management system per Art. 9\n- Data governance og -kvalitet per Art. 10\n- Teknisk dokumentasjon per Art. 11\n- Logging og sporbarhet per Art. 12\n- Transparens overfor deployer per Art. 13\n- Menneskelig oversikt per Art. 14\n- Robusthet, sikkerhet og nøyaktighet per Art. 15\n- FRIA (Fundamental Rights Impact Assessment) per Art. 27 — obligatorisk for offentlig sektor\n- Registrering i EU-database per Art. 49\n- Conformity assessment per Art. 43\n\n## Frist\n\nFull compliance innen 2027-08-02 (Annex III høyrisiko full compliance).\n"
+          "raw_markdown": "# EU AI Act — Klassifisering: Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nBeskrivelse: AI-system som identifiserer objekter som krever oppfølging via sensordata + objektregister\n\n## Risikonivå\n\nRisk-level: høy\n\n## Rolle\n\nRolle: Provider og Deployer (utvikler internt + drifter selv)\n\n## Begrunnelse\n\nReasoning: Systemet brukes av offentlig myndighet for håndheving av lov, og påvirker individers rettigheter direkte gjennom automatisert beslutningsstøtte for håndtering. Dette plasserer systemet under Annex III, punkt 6 (rettshåndhevelse) og krever full høyrisiko-compliance per Art. 6(2).\n\n## Forpliktelser\n\n- Risk management system per Art. 9\n- Data governance og -kvalitet per Art. 10\n- Teknisk dokumentasjon per Art. 11\n- Logging og sporbarhet per Art. 12\n- Transparens overfor deployer per Art. 13\n- Menneskelig oversikt per Art. 14\n- Robusthet, sikkerhet og nøyaktighet per Art. 15\n- FRIA (Fundamental Rights Impact Assessment) per Art. 27 — obligatorisk for offentlig sektor\n- Registrering i EU-database per Art. 49\n- Conformity assessment per Art. 43\n\n## Frist\n\nFull compliance innen 2027-12-02 (Annex III høyrisiko full compliance, utsatt fra 2026-08-02).\n"
         },
         "requirements": {
           "input": {},
-          "raw_markdown": "# EU AI Act — Krav for høyrisiko provider+deployer\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nKlassifisering: høy risiko, rolle Provider+Deployer\n\n## Krav\n\n| Krav | Status | Kilde |\n|------|--------|-------|\n| Risk Management System etablert og dokumentert | partial | Art. 9 |\n| Treningsdata-governance med kvalitetssjekker | met | Art. 10 |\n| Teknisk dokumentasjon (Annex IV) komplett | partial | Art. 11 |\n| Automatisk logging av hendelser implementert | met | Art. 12 |\n| Transparens-instruksjoner for deployer skrevet | missing | Art. 13 |\n| Human-in-the-loop på alle sanksjonsavgjørelser | met | Art. 14 |\n| Nøyaktighetsmål med stratifisert testing | partial | Art. 15 |\n| Cybersikkerhetstiltak verifisert (NSM Grunnprinsipper) | met | Art. 15 |\n| FRIA gjennomført før idriftsettelse | missing | Art. 27 |\n| Registrering i EU-database planlagt | missing | Art. 49 |\n| Conformity assessment per Annex VI gjennomført | missing | Art. 43 |\n| CE-merking utført før markedsføring | missing | Art. 48 |\n| Post-market monitoring system etablert | partial | Art. 72 |\n| Avviksrapportering til myndigheter rutinert | partial | Art. 73 |\n\n## Sammendrag\n\n- 4 krav er møtt (met)\n- 4 krav er delvis møtt (partial)\n- 6 krav mangler implementering (missing)\n\nPrioritering: FRIA og transparens-instruksjoner må adresseres før idriftsettelse 2027-08-02.\n"
+          "raw_markdown": "# EU AI Act — Krav for høyrisiko provider+deployer\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nKlassifisering: høy risiko, rolle Provider+Deployer\n\n## Krav\n\n| Krav | Status | Kilde |\n|------|--------|-------|\n| Risk Management System etablert og dokumentert | partial | Art. 9 |\n| Treningsdata-governance med kvalitetssjekker | met | Art. 10 |\n| Teknisk dokumentasjon (Annex IV) komplett | partial | Art. 11 |\n| Automatisk logging av hendelser implementert | met | Art. 12 |\n| Transparens-instruksjoner for deployer skrevet | missing | Art. 13 |\n| Human-in-the-loop på alle sanksjonsavgjørelser | met | Art. 14 |\n| Nøyaktighetsmål med stratifisert testing | partial | Art. 15 |\n| Cybersikkerhetstiltak verifisert (NSM Grunnprinsipper) | met | Art. 15 |\n| FRIA gjennomført før idriftsettelse | missing | Art. 27 |\n| Registrering i EU-database planlagt | missing | Art. 49 |\n| Conformity assessment per Annex VI gjennomført | missing | Art. 43 |\n| CE-merking utført før markedsføring | missing | Art. 48 |\n| Post-market monitoring system etablert | partial | Art. 72 |\n| Avviksrapportering til myndigheter rutinert | partial | Art. 73 |\n\n## Sammendrag\n\n- 4 krav er møtt (met)\n- 4 krav er delvis møtt (partial)\n- 6 krav mangler implementering (missing)\n\nPrioritering: FRIA og transparens-instruksjoner må adresseres før idriftsettelse 2027-12-02.\n"
         },
         "transparency": {
           "input": {},
@@ -262,7 +262,7 @@
         },
         "conformity": {
           "input": {},
-          "raw_markdown": "# Samsvarsvurdering (Art. 43) — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nVurderingsprosedyre: Annex VI (intern kontroll)\n\n## Sjekkliste\n\n| Krav | Status | Bevis |\n|------|--------|-------|\n| Risk Management System dokumentert | bestått | RMS-rapport v2.1 (2026-04-15) |\n| Treningsdata-governance med kvalitetskriterier | bestått | Data-governance handbook §4.2 |\n| Teknisk dokumentasjon Annex IV komplett | betinget | Mangler ytelsesmål per stratum |\n| Logging av hendelser implementert | bestått | OpenTelemetry-spans i Azure Monitor |\n| Transparens-instruksjoner skrevet | avvist | Skal leveres innen 2026-09-01 |\n| Menneskelig oversikt på saksbehandler | bestått | Workflow-design godkjent av juridisk |\n| Nøyaktighetsmål dokumentert | betinget | 96.3% overall, men ikke per objekt-ID-region |\n| Robusthet under adversarielle forhold | betinget | Test-suite mangler skitne plater og natt-scenarier |\n| Cybersikkerhetstiltak per Art. 15 | bestått | NSM Grunnprinsipper-vurdering bestått |\n| Conformity assessment underskrevet | avvist | Avhengig av FRIA-resultat |\n| EU declaration of conformity utstedt | avvist | Avhenger av Art. 47 |\n| CE-merking påført | avvist | Markedsplassering ikke aktuell (intern bruk) — vurder om Art. 48 gjelder |\n\n## Frister\n\n| Dato | Milepæl | Status |\n|------|---------|--------|\n| 2026-08-02 | GPAI-krav + Annex III høyrisiko | upcoming |\n| 2026-09-01 | Transparens-instruksjoner ferdigstilt | upcoming |\n| 2027-02-01 | FRIA og DPIA-revisjon | upcoming |\n| 2027-08-02 | Full Annex III høyrisiko-compliance | upcoming |\n\n## Konklusjon\n\n5 av 12 krav er fullt møtt; 4 er delvis møtt; 3 mangler implementering. Critical path: transparens-instruksjoner (Art. 13) blokkerer conformity declaration.\n"
+          "raw_markdown": "# Samsvarsvurdering (Art. 43) — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nVurderingsprosedyre: Annex VI (intern kontroll)\n\n## Sjekkliste\n\n| Krav | Status | Bevis |\n|------|--------|-------|\n| Risk Management System dokumentert | bestått | RMS-rapport v2.1 (2026-04-15) |\n| Treningsdata-governance med kvalitetskriterier | bestått | Data-governance handbook §4.2 |\n| Teknisk dokumentasjon Annex IV komplett | betinget | Mangler ytelsesmål per stratum |\n| Logging av hendelser implementert | bestått | OpenTelemetry-spans i Azure Monitor |\n| Transparens-instruksjoner skrevet | avvist | Skal leveres innen 2026-09-01 |\n| Menneskelig oversikt på saksbehandler | bestått | Workflow-design godkjent av juridisk |\n| Nøyaktighetsmål dokumentert | betinget | 96.3% overall, men ikke per objekt-ID-region |\n| Robusthet under adversarielle forhold | betinget | Test-suite mangler skitne plater og natt-scenarier |\n| Cybersikkerhetstiltak per Art. 15 | bestått | NSM Grunnprinsipper-vurdering bestått |\n| Conformity assessment underskrevet | avvist | Avhengig av FRIA-resultat |\n| EU declaration of conformity utstedt | avvist | Avhenger av Art. 47 |\n| CE-merking påført | avvist | Markedsplassering ikke aktuell (intern bruk) — vurder om Art. 48 gjelder |\n\n## Frister\n\n| Dato | Milepæl | Status |\n|------|---------|--------|\n| 2026-08-02 | Transparens (Art. 50) | upcoming |\n| 2026-09-01 | Transparens-instruksjoner ferdigstilt | upcoming |\n| 2027-02-01 | FRIA og DPIA-revisjon | upcoming |\n| 2027-12-02 | Full Annex III høyrisiko-compliance (utsatt fra 2026-08-02) | upcoming |\n\n## Konklusjon\n\n5 av 12 krav er fullt møtt; 4 er delvis møtt; 3 mangler implementering. Critical path: transparens-instruksjoner (Art. 13) blokkerer conformity declaration.\n"
         },
         "dpia": {
           "input": {},
@@ -278,7 +278,7 @@
         },
         "review": {
           "input": {},
-          "raw_markdown": "# Arkitekturgjennomgang — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nVurderingsdato: 2026-04-30\nReviewers: AI-arkitekt, sikkerhetsarkitekt, Datatilsynet\n\n## Funn\n\n| ID | Severity | Status | Lokasjon | Anbefaling |\n|----|----------|--------|----------|------------|\n| F-01 | critical | remove | Authentication layer | Tilgang til AI-forklaringer mangler attribute-based access control — alle saksbehandler ser alle saker. Implementer ABAC basert på sak-tildeling. |\n| F-02 | high | review | Data pipeline | Treningsdata oppdateres månedlig, men ingen formell drift-deteksjon. Etabler statistisk drift-monitoring i Azure Monitor. |\n| F-03 | high | review | Model serving | Modellen serves fra en enkelt regional endpoint uten failover. Replikér til en sekundær region for RTO < 1t. |\n| F-04 | high | review | Logging | Audit-logg lagres 30 dager — under arkivlovens krav for sak-relevant info. Endre retensjon til 7 år for sak-knyttede oppslag. |\n| F-05 | medium | keep | Cost management | Ingen budsjettalarmer på Azure AI Services — prediction-kostnaden kan øke med 4× ved belastnings-topper uten varsel. |\n| F-06 | medium | review | Compliance | FRIA-rapport ikke vedlikeholdt etter modell-endring 2026-03-12. Re-evaluering trengs. |\n| F-07 | medium | keep | UX | saksbehandler-grensesnitt viser ikke konfidensgrad tydelig nok — risiko for over-trust på AI-output. |\n| F-08 | low | suppressed | Documentation | README mangler oppdatert arkitekturdiagram (siste fra 2025-11). |\n| F-09 | low | suppressed | Testing | Manglende E2E-test for utenlandske objekt-ID. |\n\n## Sammendrag\n\nCritical (1): ABAC mangler — må fikses før idriftsettelse.\nHigh (3): Drift-deteksjon, failover, logg-retensjon — må fikses innen 6 mnd.\nMedium (3): Budsjett, FRIA-revisjon, UX-konfidens — bør fikses innen 12 mnd.\nLow (2): Dokumentasjon, testing — opportunity-quality.\n\n## Anbefaling\n\nIdriftsettelse anbefales IKKE før F-01 er løst. F-02 til F-04 må adresseres innen 2026-09-01 for å holde 2027-08-02-fristen.\n"
+          "raw_markdown": "# Arkitekturgjennomgang — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nVurderingsdato: 2026-04-30\nReviewers: AI-arkitekt, sikkerhetsarkitekt, Datatilsynet\n\n## Funn\n\n| ID | Severity | Status | Lokasjon | Anbefaling |\n|----|----------|--------|----------|------------|\n| F-01 | critical | remove | Authentication layer | Tilgang til AI-forklaringer mangler attribute-based access control — alle saksbehandler ser alle saker. Implementer ABAC basert på sak-tildeling. |\n| F-02 | high | review | Data pipeline | Treningsdata oppdateres månedlig, men ingen formell drift-deteksjon. Etabler statistisk drift-monitoring i Azure Monitor. |\n| F-03 | high | review | Model serving | Modellen serves fra en enkelt regional endpoint uten failover. Replikér til en sekundær region for RTO < 1t. |\n| F-04 | high | review | Logging | Audit-logg lagres 30 dager — under arkivlovens krav for sak-relevant info. Endre retensjon til 7 år for sak-knyttede oppslag. |\n| F-05 | medium | keep | Cost management | Ingen budsjettalarmer på Azure AI Services — prediction-kostnaden kan øke med 4× ved belastnings-topper uten varsel. |\n| F-06 | medium | review | Compliance | FRIA-rapport ikke vedlikeholdt etter modell-endring 2026-03-12. Re-evaluering trengs. |\n| F-07 | medium | keep | UX | saksbehandler-grensesnitt viser ikke konfidensgrad tydelig nok — risiko for over-trust på AI-output. |\n| F-08 | low | suppressed | Documentation | README mangler oppdatert arkitekturdiagram (siste fra 2025-11). |\n| F-09 | low | suppressed | Testing | Manglende E2E-test for utenlandske objekt-ID. |\n\n## Sammendrag\n\nCritical (1): ABAC mangler — må fikses før idriftsettelse.\nHigh (3): Drift-deteksjon, failover, logg-retensjon — må fikses innen 6 mnd.\nMedium (3): Budsjett, FRIA-revisjon, UX-konfidens — bør fikses innen 12 mnd.\nLow (2): Dokumentasjon, testing — opportunity-quality.\n\n## Anbefaling\n\nIdriftsettelse anbefales IKKE før F-01 er løst. F-02 til F-04 må adresseres innen 2026-09-01 for å holde 2027-12-02-fristen.\n"
         },
         "cost": {
           "input": {},
@@ -294,11 +294,11 @@
         },
         "adr": {
           "input": {},
-          "raw_markdown": "# ADR-001 — Velg Azure AI Foundry som primær AI-plattform for Acme Kunde-chatbot\n\nStatus: accepted\nDate: 2026-04-30\nDeciders: AI-arkitekt, sikkerhetsarkitekt, seksjonsleder\nConsulted: Datatilsynet, juridisk rådgiver, Drift\nInformed: prosjekteierskap, AI-teamet\n\n## Context and Problem Statement\n\nAcme Kommune skal modernisere Acme Kunde-chatbot fra on-prem OCR-løsning til skybasert AI-plattform. Plattformen må støtte custom modell-trening, audit-logging på inferens-nivå, real-time inferens (<100ms P95), og full compliance med EU AI Act + GDPR + sikkerhetsloven.\n\n## Decision Drivers\n\n- Compliance med EU AI Act høyrisiko-krav (Art. 9-15)\n- Norsk dataresidens-krav\n- Customer-managed keys og Private Endpoints\n- Custom modell-trening kapabilitet\n- Total cost of ownership over 3 år\n- Driftbarhet for AI-teamet\n\n## Considered Options\n\n1. **Azure AI Foundry** — Enterprise AI-plattform med full compliance-pakke\n2. **Azure ML + AKS** — Mer kontroll, men høyere driftskost\n3. **AWS SageMaker** — Konkurransedyktig, men mangler norske compliance-sertifiseringer\n4. **On-prem GPU-cluster** — Maks kontroll, men krever betydelig CapEx og driftskompetanse\n\n## Decision Outcome\n\nChosen option: **Azure AI Foundry**, fordi det balanserer compliance, driftbarhet, og fleksibilitet best for vår bemanning og tidsramme.\n\n### Consequences\n\n- Good: full compliance-pakke for leverandøren, raskere time-to-prod, integrert med eksisterende Entra ID\n- Good: customer-managed keys og Customer Lockbox tilgjengelig\n- Bad: lock-in til Azure, men mitigert via standardiserte modell-formater (ONNX) og data-portabilitet\n- Bad: høyere månedlig kostnad enn ren Azure ML — kompenseres ved redusert egen-drift\n\n## Validation\n\nBeslutning evalueres etter 12 måneder mot KPI-er:\n- Saksbehandlingstid (mål: -40%)\n- Modell-nøyaktighet (mål: ≥96% F1)\n- Total cost (mål: ≤ NOK 1.7M/år)\n- Compliance-status (mål: 100% av krav dekket innen 2027-08-02)\n\n## More Information\n\n- Compare-rapport: see `compare-foundry-vs-aml.md`\n- Cost-analyse: see `cost-tco-3year.md`\n- Security-vurdering: see `security-foundry-baseline.md`\n"
+          "raw_markdown": "# ADR-001 — Velg Azure AI Foundry som primær AI-plattform for Acme Kunde-chatbot\n\nStatus: accepted\nDate: 2026-04-30\nDeciders: AI-arkitekt, sikkerhetsarkitekt, seksjonsleder\nConsulted: Datatilsynet, juridisk rådgiver, Drift\nInformed: prosjekteierskap, AI-teamet\n\n## Context and Problem Statement\n\nAcme Kommune skal modernisere Acme Kunde-chatbot fra on-prem OCR-løsning til skybasert AI-plattform. Plattformen må støtte custom modell-trening, audit-logging på inferens-nivå, real-time inferens (<100ms P95), og full compliance med EU AI Act + GDPR + sikkerhetsloven.\n\n## Decision Drivers\n\n- Compliance med EU AI Act høyrisiko-krav (Art. 9-15)\n- Norsk dataresidens-krav\n- Customer-managed keys og Private Endpoints\n- Custom modell-trening kapabilitet\n- Total cost of ownership over 3 år\n- Driftbarhet for AI-teamet\n\n## Considered Options\n\n1. **Azure AI Foundry** — Enterprise AI-plattform med full compliance-pakke\n2. **Azure ML + AKS** — Mer kontroll, men høyere driftskost\n3. **AWS SageMaker** — Konkurransedyktig, men mangler norske compliance-sertifiseringer\n4. **On-prem GPU-cluster** — Maks kontroll, men krever betydelig CapEx og driftskompetanse\n\n## Decision Outcome\n\nChosen option: **Azure AI Foundry**, fordi det balanserer compliance, driftbarhet, og fleksibilitet best for vår bemanning og tidsramme.\n\n### Consequences\n\n- Good: full compliance-pakke for leverandøren, raskere time-to-prod, integrert med eksisterende Entra ID\n- Good: customer-managed keys og Customer Lockbox tilgjengelig\n- Bad: lock-in til Azure, men mitigert via standardiserte modell-formater (ONNX) og data-portabilitet\n- Bad: høyere månedlig kostnad enn ren Azure ML — kompenseres ved redusert egen-drift\n\n## Validation\n\nBeslutning evalueres etter 12 måneder mot KPI-er:\n- Saksbehandlingstid (mål: -40%)\n- Modell-nøyaktighet (mål: ≥96% F1)\n- Total cost (mål: ≤ NOK 1.7M/år)\n- Compliance-status (mål: 100% av krav dekket innen 2027-12-02)\n\n## More Information\n\n- Compare-rapport: see `compare-foundry-vs-aml.md`\n- Cost-analyse: see `cost-tco-3year.md`\n- Security-vurdering: see `security-foundry-baseline.md`\n"
         },
         "summary": {
           "input": {},
-          "raw_markdown": "# Beslutningsnotat — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nDato: 2026-04-30\nTil: Direktør for Digital og IT\nFra: AI-teamet\n\n## Verdict\n\nVerdict: warning\nSub: Pilot anbefalt med betingelser\n\n## Rationale\n\nArkitekturen er teknisk solid og økonomisk forsvarlig (P50 NOK 1.7M/år), men compliance-arbeidet ligger 6 måneder bak ideell tidslinje. Pilot kan starte etter at FRIA og transparens-instruksjoner er ferdigstilt; full produksjonssetting krever lukking av alle critical funn fra arkitekturgjennomgang.\n\n## Key Metrics\n\n| Metric | Verdi | Mål |\n|--------|-------|-----|\n| Compliance-dekning | 33% (4/12 fullt møtt) | 100% innen 2027-08-02 |\n| Sikkerhetsscore | 22/30 (73%) | ≥27/30 (90%) |\n| TCO 3 år | NOK 6.7M | ≤ NOK 7M |\n| Saksbehandlingstid (pilot) | -32% (estimert) | -40% |\n| ROS-restrisiko | medium | low-medium |\n\n## Next Steps\n\n- Lukk F-01 (ABAC) innen 2026-06-15\n- Gjennomfør FRIA innen 2026-07-15 (Art. 27-frist)\n- Produksjonsdokumentere transparens-instruksjoner innen 2026-09-01\n- Pilot 3 regioner (Oslo, Bergen, Trondheim) Q4 2026\n- Full utrulling Q2 2027\n\n## Restrisiko\n\nEtter foreslåtte tiltak: medium. Hovedeksponering: bias mot utenlandske objekt-ID krever løpende monitoring.\n\n## Anbefaling\n\nGodkjenn pilot-fase med tydelig stage-gate til full produksjonssetting. Avstem med Datatilsynet før fase 4.\n"
+          "raw_markdown": "# Beslutningsnotat — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nDato: 2026-04-30\nTil: Direktør for Digital og IT\nFra: AI-teamet\n\n## Verdict\n\nVerdict: warning\nSub: Pilot anbefalt med betingelser\n\n## Rationale\n\nArkitekturen er teknisk solid og økonomisk forsvarlig (P50 NOK 1.7M/år), men compliance-arbeidet ligger 6 måneder bak ideell tidslinje. Pilot kan starte etter at FRIA og transparens-instruksjoner er ferdigstilt; full produksjonssetting krever lukking av alle critical funn fra arkitekturgjennomgang.\n\n## Key Metrics\n\n| Metric | Verdi | Mål |\n|--------|-------|-----|\n| Compliance-dekning | 33% (4/12 fullt møtt) | 100% innen 2027-12-02 |\n| Sikkerhetsscore | 22/30 (73%) | ≥27/30 (90%) |\n| TCO 3 år | NOK 6.7M | ≤ NOK 7M |\n| Saksbehandlingstid (pilot) | -32% (estimert) | -40% |\n| ROS-restrisiko | medium | low-medium |\n\n## Next Steps\n\n- Lukk F-01 (ABAC) innen 2026-06-15\n- Gjennomfør FRIA innen 2026-07-15 (Art. 27-frist)\n- Produksjonsdokumentere transparens-instruksjoner innen 2026-09-01\n- Pilot 3 regioner (Oslo, Bergen, Trondheim) Q4 2026\n- Full utrulling Q2 2027\n\n## Restrisiko\n\nEtter foreslåtte tiltak: medium. Hovedeksponering: bias mot utenlandske objekt-ID krever løpende monitoring.\n\n## Anbefaling\n\nGodkjenn pilot-fase med tydelig stage-gate til full produksjonssetting. Avstem med Datatilsynet før fase 4.\n"
         },
         "poc": {
           "input": {},

scripts/kb-eval/apply-o2-ratified.mjs

@@ -0,0 +1,149 @@
+#!/usr/bin/env node
+// apply-o2-ratified.mjs — R11 §9.4. Applies the O2 subtractions the operator
+// ratified 2026-08-03, and only those.
+//
+// Ratified: idx 17, 19, 33 as attested; idx 14 as the REDUCED subtraction
+// (`/ SharePoint` only). Deliberately NOT ratified and therefore absent from
+// RATIFIED: idx 26 (renumbering artifact unresolved), idx 27 (cond 3 still
+// `human_must_confirm`), idx 36 (needs the out-of-envelope companion edit at
+// line 310, now owned by gap G7), idx 18 (no reduction exists — also G7).
+//
+// Every string comes from the tracked evidence in data/r11-o2-returns/, never
+// from transcription. The one amendment (idx 14) is expressed as a derivation
+// over the attested verbatim and asserts its own effect, so a drifted record
+// aborts rather than silently writing something else.
+//
+// Anchoring is on `file_text_verbatim`, NEVER on a line number: `line` differs
+// from `real_line` in 9 of 17 records, and idx 17 shifts idx 19's lines in the
+// file they share. The verbatim must occur EXACTLY once or the run aborts.
+//
+// Recovery contract: writes are crash-safe (atomicWriteSync tmp+rename — a reader
+// sees the old file or the new one, never a partial). An interrupted run is
+// recovered by re-running: an already-applied edit no longer finds its verbatim,
+// which aborts the run, writing nothing, rather than corrupting the file.
+//
+// Usage:  node scripts/kb-eval/apply-o2-ratified.mjs [--dry]
+import { readFileSync, readdirSync, realpathSync } from 'node:fs';
+import { join, dirname } from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+import { isDeletionOnly, novelWordForms } from './lib/o2-return-check.mjs';
+import { atomicWriteSync } from '../kb-update/lib/atomic-write.mjs';
+
+const __dirname = dirname(fileURLToPath(import.meta.url));
+const PLUGIN_ROOT = join(__dirname, '..', '..');
+const RETURNS = join(PLUGIN_ROOT, 'scripts/kb-eval/data/r11-o2-returns');
+
+/**
+ * The ratified reduction for idx 14: delete only the `/ SharePoint` alternative.
+ * `Automatically` MUST survive — line 566 of the same file restates automaticity
+ * in Norwegian, so deleting it would leave a remainder the file contradicts.
+ * @param {string} verbatim
+ * @returns {string}
+ */
+export function reduceSharePointOnly(verbatim) {
+  const out = verbatim.replace('Dataverse / SharePoint', 'Dataverse');
+  if (out === verbatim) throw new Error('idx 14 reduction is a no-op — record drifted');
+  if (!out.includes('Automatically add')) throw new Error('idx 14: `Automatically` must survive');
+  return out;
+}
+
+// Frozen manifest — the operator's ratification, 2026-08-03. `amend: null` means
+// apply the attested `proposed_remainder` byte-for-byte.
+export const RATIFIED = [
+  { idx: 17, amend: null },
+  { idx: 19, amend: null },
+  { idx: 33, amend: null },
+  { idx: 14, amend: reduceSharePointOnly },
+];
+
+/**
+ * The remainder actually written for a record: attested, or the ratified amendment.
+ * @param {object} row
+ * @param {{amend: ((v: string) => string) | null}} entry
+ * @returns {string}
+ */
+export function amendedRemainder(row, entry) {
+  return entry.amend ? entry.amend(row.file_text_verbatim) : row.proposed_remainder;
+}
+
+/**
+ * Replace the anchored block with its remainder. Pure — no I/O. Throws on any
+ * condition that would make the write unsafe rather than writing something else.
+ * @param {string} content
+ * @param {string} verbatim
+ * @param {string} remainder
+ * @returns {string}
+ */
+export function applyEdit(content, verbatim, remainder) {
+  const occurrences = content.split(verbatim).length - 1;
+  if (occurrences !== 1) {
+    throw new Error(`ABORT — anchor occurs ${occurrences} times, expected exactly 1`);
+  }
+  if (!isDeletionOnly(verbatim, remainder)) {
+    throw new Error('ABORT — remainder is not deletion-only w.r.t. the anchor');
+  }
+  const novel = novelWordForms(verbatim, remainder);
+  if (novel.length) {
+    throw new Error(`ABORT — remainder introduces novel word form(s): ${novel.join(', ')}`);
+  }
+  return content.replace(verbatim, remainder);
+}
+
+function loadRows() {
+  return readdirSync(RETURNS).filter((f) => f.endsWith('.json')).sort()
+    .flatMap((f) => JSON.parse(readFileSync(join(RETURNS, f), 'utf8')));
+}
+
+export function run({ dry = false } = {}) {
+  const byIdx = new Map(loadRows().map((r) => [r.idx, r]));
+
+  // Group by file so two edits sharing a file compose in memory and write once.
+  const perFile = new Map();
+  for (const entry of RATIFIED) {
+    const row = byIdx.get(entry.idx);
+    if (!row) throw new Error(`ABORT — no return record for idx ${entry.idx}`);
+    if (row.verdict !== 'O2_CANDIDATE') {
+      throw new Error(`ABORT — idx ${entry.idx} is ${row.verdict}, not an O2 candidate`);
+    }
+    if (!perFile.has(row.file)) perFile.set(row.file, []);
+    perFile.get(row.file).push({ entry, row });
+  }
+
+  const planned = [];
+  for (const [rel, edits] of perFile) {
+    const abs = join(PLUGIN_ROOT, rel);
+    const before = readFileSync(abs, 'utf8');
+    let out = before;
+    for (const { entry, row } of edits) {
+      out = applyEdit(out, row.file_text_verbatim, amendedRemainder(row, entry));
+    }
+    // Post-condition: every anchor is gone, and the file actually changed.
+    for (const { row } of edits) {
+      if (out.includes(row.file_text_verbatim)) {
+        throw new Error(`ABORT — idx ${row.idx} anchor still present after edit`);
+      }
+    }
+    if (out === before) throw new Error(`ABORT — ${rel} unchanged`);
+    planned.push({ rel, abs, out, idxs: edits.map((e) => e.entry.idx) });
+  }
+
+  console.log(`Ratified edits: ${RATIFIED.length} across ${planned.length} files`);
+  for (const p of planned) console.log(`  ~ ${p.rel}  (idx ${p.idxs.join(', ')})`);
+  if (dry) {
+    console.log('\n(dry run — no writes)');
+    return planned;
+  }
+  for (const p of planned) atomicWriteSync(p.abs, p.out);
+  console.log(`\nWrote ${planned.length} files.`);
+  return planned;
+}
+
+const isMain = (() => {
+  try {
+    return realpathSync(process.argv[1]) === realpathSync(fileURLToPath(import.meta.url));
+  } catch {
+    return false;
+  }
+})();
+if (isMain) run({ dry: process.argv.includes('--dry') });

scripts/kb-eval/build-gold-set.mjs

@@ -0,0 +1,139 @@
+#!/usr/bin/env node
+// build-gold-set.mjs — Fase 0, steg 2/3 glue: assemble the gold correctness set.
+//
+// Consolidates the per-batch verification returns (scripts/kb-eval/data/
+// fase0-returns/batch-*.json — produced by Opus 4.8 subagents that checked each
+// volatile claim against live MS Learn) into a single, reusable gold set, and
+// joins the DETERMINISTIC lastmod_changed signal in code (never an LLM call):
+// for each file, did any cited source change on the MS Learn sitemap after the
+// file's own "last updated" date? That is exactly what the existing KB staleness
+// loop sees, so it tells us which genuine errors a correctness judge would catch
+// that the staleness loop would miss.
+//
+// The non-trivial logic (date parse, lastmod comparison) lives in tested
+// lib/base-rate.mjs; this CLI is thin wiring over it.
+//
+// Usage:  node scripts/kb-eval/build-gold-set.mjs [--write]
+//   (default: print summary; --write: persist gold-correctness-set.json)
+
+import fs from 'node:fs';
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+import { parseLastUpdated, fileLastmodChanged } from './lib/base-rate.mjs';
+import { lintGoldConsistency } from './lib/gold-consistency.mjs';
+
+const __dirname = path.dirname(fileURLToPath(import.meta.url));
+const ROOT = path.resolve(__dirname, '..', '..');
+const DATA = path.join(__dirname, 'data');
+const RETURNS = path.join(DATA, 'fase0-returns');
+
+const frame = JSON.parse(fs.readFileSync(path.join(DATA, 'fase0-sample-frame.json'), 'utf8'));
+const registry = JSON.parse(
+  fs.readFileSync(path.join(ROOT, 'scripts/kb-update/data/url-registry.json'), 'utf8'),
+);
+
+// file -> citedUrls (from the deterministic sample frame)
+const citedByFile = {};
+for (const e of [...frame.volatile, ...frame.control]) citedByFile[e.file] = e.citedUrls;
+
+// file -> { date, lastmod_changed } (read each file once)
+const fileMeta = {};
+function metaFor(file) {
+  if (fileMeta[file]) return fileMeta[file];
+  let date = null;
+  try {
+    date = parseLastUpdated(fs.readFileSync(path.join(ROOT, file), 'utf8'));
+  } catch {
+    date = null;
+  }
+  const changed = fileLastmodChanged(citedByFile[file] || [], registry, date);
+  return (fileMeta[file] = { date, lastmod_changed: changed });
+}
+
+// relpath after skills/<skill>/references/ for a compact, stable claim id
+function relOf(file, skill) {
+  const prefix = `skills/${skill}/references/`;
+  return file.startsWith(prefix) ? file.slice(prefix.length) : file;
+}
+
+const claims = [];
+const batchFiles = fs.readdirSync(RETURNS).filter((f) => /^batch-\d+\.json$/.test(f)).sort();
+for (const bf of batchFiles) {
+  const batch = JSON.parse(fs.readFileSync(path.join(RETURNS, bf), 'utf8'));
+  for (const c of batch.claims) {
+    const meta = metaFor(c.file);
+    claims.push({
+      id: `${c.skill}/${relOf(c.file, c.skill)}#${c.n}`,
+      file: c.file,
+      skill: c.skill,
+      stratum: c.stratum,
+      claim: c.claim,
+      claim_type: c.claim_type,
+      verdict: c.verdict,
+      evidence_url: c.evidence_url ?? null,
+      lastmod_changed: meta.lastmod_changed,
+      file_last_updated: meta.date,
+      notes: c.notes ?? '',
+    });
+  }
+}
+
+const goldSet = {
+  _meta: {
+    created: '2026-06-26',
+    method:
+      'Per-file volatile-claim verification against live MS Learn by Opus 4.8 subagents (strict v2 evidence rule: correct/outdated/wrong require a fetched learn.microsoft.com quote; otherwise unsourced). lastmod_changed joined deterministically in code from url-registry sitemap_lastmod vs the file last-updated date.',
+    sample_frame: 'fase0-sample-frame.json',
+    raw_returns: 'fase0-returns/batch-*.json',
+    note_evidence_quote:
+      'Per-claim evidence_quote omitted here to bound size; full verbatim quotes live in the session transcript. notes + evidence_url capture each verdict basis.',
+    // G4 (programdok §8 / §3-kjennelse 2026-06-30): nedre-grense-policy for
+    // subagenter som bygger fremtidig gull. En nedre-grense-påstand («100+»,
+    // «200k+») teller som FEIL (outdated/wrong) hvis den GROVT understater
+    // (>~2x, beslutnings-endrende) den sanne verdien; en STRAM nedre grense (sann
+    // verdi i samme størrelsesorden) blir stående correct. Anvendt på FN2 (Spor 2b).
+    lower_bound_policy:
+      'Lower-bound claims (e.g. "100+", "200k+"): verdict=outdated/wrong if the bound grossly understates (>~2x, decision-changing) the true value; a tight bound (true value within the same order of magnitude) stays correct.',
+    // G3 (programdok §8): gull-intern-konsistens. Et verdict=correct-claim hvis
+    // egen `notes` innrømmer at verdien ikke er bekreftet mot kilden («uverifisert
+    // / illustrativ / ikke i kilden») MÅ enten relabel-es ELLER bære et
+    // `consistency_waiver` med begrunnelse. Håndhevet av lint-gold-consistency.mjs.
+    consistency_policy:
+      'verdict=correct claims whose notes admit the value is unverified/illustrative/not-in-source must be relabeled OR carry a consistency_waiver. Enforced by lint-gold-consistency.mjs.',
+    claim_count: claims.length,
+  },
+  claims,
+};
+
+// G3 (programdok §8): gull fødes konsistent. Hard gate kun på --write — et
+// nybygget gull med uwaived selvmotsigende correct-claims (verdict=correct mens
+// noten innrømmer ikke-bekreftet: «uverifisert/illustrativ/ikke i kilden») nektes
+// SKREVET; relabel eller waiver først. Dry-run forhåndsviser (advarer, blokkerer
+// ikke). Escape-hatch --allow-inconsistent (samme idiom som
+// run-judge-bakeoff --allow-incomplete) for bevisst override.
+const consistency = lintGoldConsistency(goldSet);
+
+if (process.argv.includes('--write')) {
+  if (!consistency.ok && !process.argv.includes('--allow-inconsistent')) {
+    console.error(`error: ${consistency.flagged.length} uwaived selvmotsigende correct-claim(s) — gull nektes skrevet (G3):`);
+    for (const f of consistency.flagged) console.error(`  - ${f.id} [${f.markers.join(', ')}]: ${f.notes}`);
+    console.error('Resolver hver (relabel ELLER consistency_waiver), eller --allow-inconsistent for å overstyre.');
+    process.exit(2);
+  }
+  const out = path.join(DATA, 'gold-correctness-set.json');
+  fs.writeFileSync(out, JSON.stringify(goldSet, null, 2) + '\n');
+  console.log(`wrote ${out} (${claims.length} claims)`);
+} else {
+  const filesWithChange = Object.entries(fileMeta).filter(([, m]) => m.lastmod_changed === true).length;
+  const filesNoChange = Object.entries(fileMeta).filter(([, m]) => m.lastmod_changed === false).length;
+  const filesUnknown = Object.entries(fileMeta).filter(([, m]) => m.lastmod_changed === null).length;
+  console.log(`claims: ${claims.length} | files: ${Object.keys(fileMeta).length}`);
+  console.log(`file lastmod_changed: true=${filesWithChange} false=${filesNoChange} unknown(null date)=${filesUnknown}`);
+  if (consistency.ok) {
+    console.log('G3 gull-konsistens: OK (0 uwaived selvmotsigende correct-claims)');
+  } else {
+    console.log(`G3 gull-konsistens: ⚠ ${consistency.flagged.length} uwaived selvmotsigende correct-claim(s) — --write vil nektes:`);
+    for (const f of consistency.flagged) console.log(`  - ${f.id} [${f.markers.join(', ')}]`);
+  }
+  console.log('(dry run — pass --write to persist gold-correctness-set.json)');
+}

scripts/kb-eval/build-judge-payloads.mjs

@@ -0,0 +1,98 @@
+#!/usr/bin/env node
+// build-judge-payloads.mjs — deterministic fan-out prep for the per-claim
+// groundedness judge bake-off. Turns the blind claim manifest + a judge prompt
+// template into 45 ready-to-dispatch subagent payloads (one per file), so the
+// fan-out is reproducible instead of hand-assembled in main context.
+//
+// The v3 fan-out grouped claims by file MANUALLY at dispatch time; that made the
+// exact payloads non-reproducible. This script fixes the construction: same prompt,
+// same per-file claim grouping, every run — so v3.1 (and any future arm) is
+// apples-to-apples and a fresh session can resume with one command, no improvising.
+//
+// Pure string assembly — no LLM, no network, no math. Reads:
+//   <--claims> (default data/judge-bakeoff-claims.json — the bake-off blind manifest;
+//               R7–R10 corpus batches pass their per-batch extracted claims manifest here)
+//   <--prompt>                        (judge-claim-prompt-vN.md, with <FILE>/<CLAIMS>)
+// Writes (with --write):
+//   data/<--out>                      (array of {file, claim_count, prompt})
+//
+// Usage:
+//   node scripts/kb-eval/build-judge-payloads.mjs --prompt judge-claim-prompt-v3.1.md \
+//        [--claims <path>] --out judge-bakeoff-payloads-v3.1.json [--write]
+//   (default: print per-file claim counts + a sanity sample; --write persists)
+
+import fs from 'node:fs';
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+const __dirname = path.dirname(fileURLToPath(import.meta.url));
+const DATA = path.join(__dirname, 'data');
+
+function flag(name, def) {
+  const i = process.argv.indexOf(name);
+  return i >= 0 ? process.argv[i + 1] : def;
+}
+
+const promptName = flag('--prompt');
+if (!promptName) {
+  console.error('error: --prompt <judge-claim-prompt-vN.md> is required');
+  process.exit(2);
+}
+const promptPath = path.isAbsolute(promptName) ? promptName : path.join(__dirname, promptName);
+if (!fs.existsSync(promptPath)) {
+  console.error(`error: prompt template not found: ${promptPath}`);
+  process.exit(2);
+}
+const template = fs.readFileSync(promptPath, 'utf8');
+if (!template.includes('<FILE>') || !template.includes('<CLAIMS>')) {
+  console.error('error: prompt template must contain both <FILE> and <CLAIMS> placeholders');
+  process.exit(2);
+}
+
+const claimsFlag = flag('--claims');
+const claimsPath = claimsFlag
+  ? (path.isAbsolute(claimsFlag) ? claimsFlag : path.resolve(process.cwd(), claimsFlag))
+  : path.join(DATA, 'judge-bakeoff-claims.json');
+if (!fs.existsSync(claimsPath)) {
+  console.error(`error: claims manifest not found: ${claimsPath}`);
+  process.exit(2);
+}
+const manifest = JSON.parse(fs.readFileSync(claimsPath, 'utf8'));
+const claims = manifest.claims || [];
+
+// Group by file, preserving manifest order (deterministic).
+const byFile = new Map();
+for (const c of claims) {
+  if (!byFile.has(c.file)) byFile.set(c.file, []);
+  byFile.get(c.file).push({
+    id: c.id,
+    claim: c.claim,
+    claim_type: c.claim_type,
+    evidence_url: c.evidence_url || null,
+  });
+}
+
+const payloads = [];
+for (const [file, fileClaims] of byFile) {
+  const claimsBlock = JSON.stringify(fileClaims, null, 2);
+  const prompt = template.split('<FILE>').join(file).split('<CLAIMS>').join(claimsBlock);
+  payloads.push({ file, claim_count: fileClaims.length, prompt });
+}
+
+const totalClaims = payloads.reduce((s, p) => s + p.claim_count, 0);
+
+if (process.argv.includes('--write')) {
+  const outName = flag('--out', `judge-bakeoff-payloads-${path.basename(promptName).replace(/^judge-claim-prompt-/, '').replace(/\.md$/, '')}.json`);
+  const outPath = path.join(DATA, outName);
+  fs.writeFileSync(outPath, JSON.stringify(payloads, null, 2) + '\n');
+  console.log(`wrote ${outPath}`);
+  console.log(`${payloads.length} per-file payloads, ${totalClaims} claims total, prompt=${promptName}`);
+} else {
+  console.log(`prompt template: ${promptName}`);
+  console.log(`${payloads.length} files, ${totalClaims} claims total`);
+  console.log('per-file claim counts:');
+  for (const p of payloads) console.log(`  ${p.claim_count.toString().padStart(2)}  ${p.file}`);
+  console.log(`\nsample payload[0] head (file=${payloads[0].file}):`);
+  console.log(payloads[0].prompt.slice(0, 200) + ' …');
+  console.log('\n(dry run — pass --write to persist)');
+}

scripts/kb-eval/build-sample-frame.mjs

@@ -0,0 +1,265 @@
+#!/usr/bin/env node
+// build-sample-frame.mjs — Fase 0, steg 1: deterministic volatility-weighted,
+// stratified sample frame for ref-file correctness verification.
+//
+// Selects ~45 volatile-dense reference files (oversampling cost/platform/SKU/
+// price/TPM/region/version/preview-dense files across all 5 skills) plus a
+// control stratum of low-volatility methodology/regulatory files. Selection is
+// DETERMINISTIC — same input yields the same frame (no Math.random).
+//
+// The volatility scorer is a RANKING heuristic for sample SELECTION, not the
+// correctness classifier (that is the subagent step against live MS Learn).
+// Its signal set + stable-identifier boundary follow the K9 rule in
+// scripts/kb-eval/judge-prompt.md: regulation years, case numbers, standard
+// version names (OWASP ... 2025, MADR v3.0) and filenames are NOT volatile.
+//
+// Verifiable population = the 306 ref files that cite >=1 MS Learn URL, derived
+// by inverting scripts/kb-update/data/url-registry.json (urls{}.reference_files[]).
+//
+// Usage:
+//   node scripts/kb-eval/build-sample-frame.mjs           # human-readable summary
+//   node scripts/kb-eval/build-sample-frame.mjs --json    # frame JSON to stdout
+//   node scripts/kb-eval/build-sample-frame.mjs --write   # persist data/fase0-sample-frame.json
+//
+// Zero dependencies. Reuses kb-update/lib/atomic-write.mjs for the gated write.
+
+import { readFileSync, existsSync } from 'node:fs';
+import { join, dirname } from 'node:path';
+import { fileURLToPath } from 'node:url';
+import { atomicWriteJson } from '../kb-update/lib/atomic-write.mjs';
+
+const __dirname = dirname(fileURLToPath(import.meta.url));
+const PLUGIN_ROOT = join(__dirname, '..', '..');
+const REGISTRY = join(PLUGIN_ROOT, 'scripts/kb-update/data/url-registry.json');
+const OUT_FILE = join(__dirname, 'data', 'fase0-sample-frame.json');
+
+// --- volatility signal patterns (ranking heuristic; K9 boundary) -------------
+// Stable identifiers deliberately do NOT match: regulation years (2024/1689),
+// case numbers (C-311/18), standard version names (MADR v3.0, OWASP LLM Top 10
+// 2025) and filenames — see judge-prompt.md K9.
+const SIGNAL_PATTERNS = {
+  tpmPtu: /\b(TPM|PTU|tokens?[ -]per[ -]minute|provisioned throughput)\b/gi,
+  price:
+    /(\bNOK\b|\bUSD\b|\bEUR\b|\$\s?\d|\bkr\b|per\s?1[ ,.]?0{3,}\s?tokens|per\s?1\s?[MK]\b|\/month|\/m[åa]ned)/gi,
+  sku: /\b(SKU|GlobalStandard|DataZoneStandard|DataZone|Pay-?as-?you-?go|PayGo|provisioned deployment|deployment type)\b/gi,
+  region:
+    /\b(East US|West US|West Europe|North Europe|Sweden Central|Norway East|norwayeast|swedencentral|region(?:al)? availability|available in (?:the )?following regions)\b/gi,
+  version:
+    /\b(GPT-[0-9](?:\.[0-9])?|GPT-4o|o1|o3|o4-mini|Claude\s?[0-9]|Gemini\s?[0-9]|text-embedding-[0-9]|api-version=\d{4}-\d{2}-\d{2})\b/gi,
+  previewGa: /(public preview|private preview|in preview|\(preview\)|generally available|now available)/gi,
+};
+const SIGNAL_WEIGHTS = { tpmPtu: 3, price: 2, sku: 2, region: 2, version: 3, previewGa: 2 };
+const PATH_BOOST = { 'cost-optimization': 5, platforms: 5 };
+
+/** Skill name from a `skills/<skill>/references/...` path, else ''. */
+export function skillOf(relpath) {
+  const m = /^skills\/([^/]+)\/references\//.exec(relpath);
+  return m ? m[1] : '';
+}
+
+/** Immediate folder under `references/`, else '' (file sits directly in references/). */
+export function topFolder(relpath) {
+  const m = /^skills\/[^/]+\/references\/([^/]+)\//.exec(relpath);
+  return m ? m[1] : '';
+}
+
+/** Count volatility-signal hits in text; weighted sum = ranking score. */
+export function scoreVolatility(text) {
+  const signals = {};
+  let score = 0;
+  for (const [key, pat] of Object.entries(SIGNAL_PATTERNS)) {
+    const matches = text.match(pat);
+    const n = matches ? matches.length : 0;
+    signals[key] = n;
+    score += n * SIGNAL_WEIGHTS[key];
+  }
+  return { score, signals };
+}
+
+/** Path-based boost for volatility-dense folders (cost-optimization, platforms). */
+export function pathBoost(relpath) {
+  return PATH_BOOST[topFolder(relpath)] || 0;
+}
+
+/** Total ranking score for a file = content volatility + path boost. */
+export function fileScore({ relpath, text }) {
+  return scoreVolatility(text).score + pathBoost(relpath);
+}
+
+/**
+ * Apportion `total` selections across skills: a floor per skill (balance) plus
+ * the remainder distributed by volatility mass (oversample dense skills), using
+ * largest-remainder apportionment. Deterministic — ties broken by skill name.
+ */
+export function allocateQuota(massBySkill, total, floorPerSkill) {
+  const skills = Object.keys(massBySkill).sort();
+  const quotas = {};
+  for (const s of skills) quotas[s] = floorPerSkill;
+  let remaining = total - floorPerSkill * skills.length;
+  if (remaining <= 0) return quotas;
+  const totalMass = skills.reduce((sum, s) => sum + massBySkill[s], 0);
+  if (totalMass <= 0) {
+    // no mass signal — distribute round-robin deterministically by skill name
+    let i = 0;
+    while (remaining > 0) {
+      quotas[skills[i % skills.length]] += 1;
+      remaining--;
+      i++;
+    }
+    return quotas;
+  }
+  const shares = skills.map((s) => {
+    const exact = (massBySkill[s] / totalMass) * remaining;
+    const base = Math.floor(exact);
+    return { s, base, frac: exact - base };
+  });
+  for (const sh of shares) {
+    quotas[sh.s] += sh.base;
+    remaining -= sh.base;
+  }
+  shares.sort((a, b) => b.frac - a.frac || (a.s < b.s ? -1 : 1));
+  for (let i = 0; i < shares.length && remaining > 0; i++) {
+    quotas[shares[i].s] += 1;
+    remaining--;
+  }
+  return quotas;
+}
+
+const byScoreThenPath = (a, b) =>
+  b.score - a.score || (a.file < b.file ? -1 : a.file > b.file ? 1 : 0);
+
+/**
+ * Split scored files into a volatile stratum (~volatileTarget, balanced across
+ * skills, oversampling dense ones) and a control stratum (low-volatility files
+ * from controlFolders). Deterministic.
+ */
+export function stratify(scored, cfg) {
+  const controlSet = new Set();
+  const control = scored
+    .filter((f) => cfg.controlFolders.includes(f.topFolder) && f.score <= cfg.controlMaxScore)
+    .sort((a, b) => a.score - b.score || (a.file < b.file ? -1 : a.file > b.file ? 1 : 0))
+    .slice(0, cfg.controlTarget)
+    .map((f) => {
+      controlSet.add(f.file);
+      return { ...f, stratum: 'control' };
+    });
+
+  const pool = scored.filter((f) => !controlSet.has(f.file) && f.skill);
+  const bySkill = {};
+  const massBySkill = {};
+  for (const f of pool) {
+    (bySkill[f.skill] ||= []).push(f);
+    massBySkill[f.skill] = (massBySkill[f.skill] || 0) + f.score;
+  }
+  const quotas = allocateQuota(massBySkill, cfg.volatileTarget, cfg.floorPerSkill);
+  const volatile = [];
+  for (const skill of Object.keys(bySkill).sort()) {
+    for (const f of bySkill[skill].sort(byScoreThenPath).slice(0, quotas[skill] || 0)) {
+      volatile.push({ ...f, stratum: 'volatile' });
+    }
+  }
+  volatile.sort(byScoreThenPath);
+  return { volatile, control };
+}
+
+// --- CLI / frame assembly ----------------------------------------------------
+const CFG = {
+  volatileTarget: 45,
+  floorPerSkill: 5,
+  // Control = stable-claim folders (the real analogues of the contract's
+  // "methodology/regulatory"): responsible-AI principles, Norwegian public-sector
+  // governance/law, and architecture methodology. Filtered to low volatility score
+  // so the control stratum measures the stable-claim sanity rate, not volatile churn.
+  controlFolders: ['responsible-ai', 'norwegian-public-sector-governance', 'architecture'],
+  controlMaxScore: 4,
+  controlTarget: 10,
+};
+
+/** Invert url-registry → Map(reference_file -> sorted unique cited URLs). */
+function invertRegistry() {
+  const reg = JSON.parse(readFileSync(REGISTRY, 'utf8'));
+  const inv = new Map();
+  for (const [url, meta] of Object.entries(reg.urls || {})) {
+    for (const rf of meta.reference_files || []) {
+      if (!inv.has(rf)) inv.set(rf, new Set());
+      inv.get(rf).add(url);
+    }
+  }
+  return inv;
+}
+
+function scoreSourcedFiles() {
+  const inv = invertRegistry();
+  const scored = [];
+  for (const [relpath, urlSet] of inv) {
+    const abs = join(PLUGIN_ROOT, relpath);
+    if (!existsSync(abs)) continue; // sourced file since deleted — skip
+    const text = readFileSync(abs, 'utf8');
+    const { score, signals } = scoreVolatility(text);
+    scored.push({
+      file: relpath,
+      skill: skillOf(relpath),
+      topFolder: topFolder(relpath),
+      score: score + pathBoost(relpath),
+      signals,
+      citedUrls: [...urlSet].sort(),
+    });
+  }
+  return scored;
+}
+
+function buildFrame() {
+  const scored = scoreSourcedFiles();
+  const { volatile, control } = stratify(scored, CFG);
+  const stamp = new Date().toISOString();
+  return {
+    _meta: {
+      created: stamp,
+      method:
+        'volatility-weighted stratified selection; deterministic (no random). ' +
+        'Scorer is a ranking heuristic for sample selection, not the correctness classifier.',
+      population: scored.length,
+      volatile_count: volatile.length,
+      control_count: control.length,
+      config: CFG,
+      signal_weights: SIGNAL_WEIGHTS,
+    },
+    volatile,
+    control,
+  };
+}
+
+function summarize(frame) {
+  const perSkill = {};
+  for (const f of [...frame.volatile, ...frame.control]) {
+    const k = `${f.skill}/${f.stratum}`;
+    perSkill[k] = (perSkill[k] || 0) + 1;
+  }
+  console.log(`Sourced population: ${frame._meta.population} files`);
+  console.log(`Volatile stratum:   ${frame.volatile.length}`);
+  console.log(`Control stratum:    ${frame.control.length}`);
+  console.log('\nPer skill / stratum:');
+  for (const k of Object.keys(perSkill).sort()) console.log(`  ${k.padEnd(34)} ${perSkill[k]}`);
+  console.log('\nTop 10 volatile (score · file):');
+  for (const f of frame.volatile.slice(0, 10)) {
+    console.log(`  ${String(f.score).padStart(4)}  ${f.file}`);
+  }
+}
+
+function main() {
+  const args = process.argv.slice(2);
+  const frame = buildFrame();
+  if (args.includes('--json')) {
+    process.stdout.write(JSON.stringify(frame, null, 2) + '\n');
+    return;
+  }
+  summarize(frame);
+  if (args.includes('--write')) {
+    atomicWriteJson(OUT_FILE, frame);
+    console.log(`\nWrote ${OUT_FILE}`);
+  } else {
+    console.log('\n(dry run — pass --write to persist data/fase0-sample-frame.json)');
+  }
+}
+
+if (import.meta.url === `file://${process.argv[1]}`) main();

scripts/kb-eval/check-g7-queue.mjs

@@ -0,0 +1,64 @@
+#!/usr/bin/env node
+/**
+ * Check the G7 review queue against the live corpus.
+ *
+ * Exit 0 = every open entry still anchors to real text; exit 1 = drift or a
+ * schema fault. Drift is a finding, never a silent pass: an entry that stops
+ * matching is exactly the case G7 exists to prevent — a real defect leaving the
+ * programme unnoticed because someone edited around it.
+ *
+ * Read-only. Nothing in the queue is machine-appliable; resolution is a human
+ * review act (form b, ratified 2026-08-03).
+ *
+ *   node scripts/kb-eval/check-g7-queue.mjs [--json]
+ */
+import { readFileSync } from 'node:fs';
+import { validateQueue } from './lib/g7-queue.mjs';
+
+const QUEUE = 'scripts/kb-eval/data/g7-review-queue.json';
+
+const asJson = process.argv.includes('--json');
+
+let queue;
+try {
+  queue = JSON.parse(readFileSync(QUEUE, 'utf8'));
+} catch (err) {
+  console.error(`cannot read ${QUEUE}: ${err.message}`);
+  process.exit(1);
+}
+
+const entries = queue.entries ?? [];
+const { ok, findings } = validateQueue(entries, (p) => readFileSync(p, 'utf8'));
+
+const open = entries.filter((e) => e.status === 'open');
+const resolved = entries.filter((e) => e.status === 'resolved');
+
+if (asJson) {
+  console.log(JSON.stringify({ ok, open: open.length, resolved: resolved.length, findings }, null, 2));
+  process.exit(ok ? 0 : 1);
+}
+
+console.log(`G7 review queue — ${open.length} open, ${resolved.length} resolved\n`);
+
+const byClass = (cls) => open.filter((e) => e.class === cls);
+for (const cls of ['multi-locator', 'replacement']) {
+  const rows = byClass(cls);
+  if (rows.length === 0) continue;
+  console.log(`  ${cls} (${rows.length}):`);
+  for (const e of rows) {
+    console.log(`    ${e.id.padEnd(8)} ${e.file.split('/').pop()}`);
+  }
+  console.log();
+}
+
+if (findings.length > 0) {
+  console.log(`FINDINGS (${findings.length}):`);
+  for (const f of findings) {
+    console.log(`  [${f.kind}] ${f.id ?? ''} ${f.message}`);
+  }
+  console.log('\nA drifted anchor means the file changed under a queued defect.');
+  console.log('Re-derive the anchor from the live file — do not delete the entry.');
+  process.exit(1);
+}
+
+console.log('All open entries still anchor to live corpus text. exit 0');

scripts/kb-eval/check-o2-returns.mjs

@@ -0,0 +1,74 @@
+#!/usr/bin/env node
+// check-o2-returns.mjs — R11 §10 measurement #2: verify and tally the O2/O3
+// classification returns. READ-ONLY; writes nothing.
+//
+//   node scripts/kb-eval/check-o2-returns.mjs
+//
+// Runs the V1/V2/V2b/V3 checks (scripts/kb-eval/lib/o2-return-check.mjs) over
+// scripts/kb-eval/data/r11-o2-returns/*.json and prints the measurement: the
+// O2/O3 split, the machine-clean candidate count, and — the actionable part —
+// WHICH of §5's three conditions forecloses each O3. The top-level split alone
+// says nothing; the blocking condition is where the decision lives.
+
+import { readFileSync, readdirSync } from 'node:fs';
+import { join, dirname, resolve } from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+import { checkRow } from './lib/o2-return-check.mjs';
+
+const REPO = resolve(dirname(fileURLToPath(import.meta.url)), '../..');
+const RETURNS = join(REPO, 'scripts/kb-eval/data/r11-o2-returns');
+
+const cache = new Map();
+const readRepoFile = (rel) => {
+  if (!cache.has(rel)) cache.set(rel, readFileSync(join(REPO, rel), 'utf8'));
+  return cache.get(rel);
+};
+
+const files = readdirSync(RETURNS).filter((f) => f.endsWith('.json')).sort();
+const rows = files.flatMap((f) =>
+  JSON.parse(readFileSync(join(RETURNS, f), 'utf8')).map((r) => ({ ...r, _batch: f })));
+
+const findings = rows.flatMap((r) =>
+  checkRow(r, readRepoFile).map((f) => ({ ...f, idx: r.idx, file: r.file, line: r.line, batch: r._batch })));
+
+const flaggedIdx = new Set(findings.map((f) => f.idx));
+const o2 = rows.filter((r) => r.verdict === 'O2_CANDIDATE');
+const o3 = rows.filter((r) => r.verdict === 'O3');
+const clean = o2.filter((r) => !flaggedIdx.has(r.idx));
+
+// Which condition forecloses O2. "human_must_confirm" counts as NOT held: the
+// point of the tri-state is that an unresolved condition is not a satisfied one.
+const held = (v) => v === true || v === 'yes';
+const blockTally = {};
+for (const r of o3) {
+  const failed = [
+    !held(r.cond1_strictly_less?.holds) && 'cond1',
+    !held(r.cond2_remainder_not_misleading?.holds) && 'cond2',
+    !held(r.cond3_nothing_confirmed_removed?.holds) && 'cond3',
+  ].filter(Boolean);
+  const key = failed.length ? failed.join('+') : 'none-stated';
+  blockTally[key] = (blockTally[key] || 0) + 1;
+}
+const cond3Blocked = o3.filter((r) => !held(r.cond3_nothing_confirmed_removed?.holds)).length;
+
+const tally = (xs, key) => xs.reduce((a, x) => ({ ...a, [x[key]]: (a[x[key]] || 0) + 1 }), {});
+const pct = (n) => `${((n / rows.length) * 100).toFixed(1)} %`;
+
+console.log(`R11 §10 #2 — R8 multi-part claims (pilot): ${rows.length} items from ${files.length} batches`);
+console.log(`  O2_CANDIDATE ${o2.length} (${pct(o2.length)}) · O3 ${o3.length} (${pct(o3.length)})`);
+console.log(`  locator_failed: ${rows.filter((r) => r.locator_failed).length}`);
+console.log(`  machine-clean O2 candidates: ${clean.length}/${o2.length}`);
+console.log(`  O2 confidence: ${JSON.stringify(tally(o2, 'confidence'))}`);
+console.log(`\nO3 blocking conditions: ${JSON.stringify(blockTally)}`);
+console.log(`O3 where condition 3 fails (source supplies a corrected value → swap/rewrite): ${cond3Blocked}/${o3.length}`);
+
+console.log(`\nmachine findings: ${findings.length}`);
+for (const f of findings) console.log(`  [${f.check}] idx=${f.idx} ${f.file}:${f.line} — ${f.detail}`);
+
+console.log('\nO2 candidates (review-grade — conditions 2 and 3 are human-confirmed):');
+for (const r of o2) {
+  console.log(`  ${r.idx}. ${r.file}:${r.real_line ?? r.line}${flaggedIdx.has(r.idx) ? '  [MACHINE-FLAGGED]' : ''}`);
+}
+
+process.exitCode = 0;

scripts/kb-eval/classify-fix-ops.mjs

@@ -0,0 +1,205 @@
+#!/usr/bin/env node
+// classify-fix-ops.mjs — R11 pilot runner (docs/r11-tiered-fix-design.md §10).
+//
+// Runs the fix-operation classifier over the pilot population: the files
+// carrying >= 7 `not_grounded` flags, the densest available sample. Produces the
+// four §10 measurements — the O1/O3 split, the R8 breakdown, the typed abort
+// distribution, and the per-flag record needed to re-analyse without re-running.
+//
+// READ-ONLY over the corpus and the ledger. It never edits a KB file and never
+// touches judge-pass-manifest.json — §8's single-writer state is untouched. The
+// only write is its own report, and only with --write.
+//
+// Usage:  node scripts/kb-eval/classify-fix-ops.mjs [--write] [--threshold N] [--examples N]
+
+import fs from 'node:fs';
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+import { ABORT_CODES, classifyFlag } from './lib/fix-op.mjs';
+
+const __dirname = path.dirname(fileURLToPath(import.meta.url));
+const REPO = path.resolve(__dirname, '..', '..');
+const DATA = path.join(__dirname, 'data');
+
+const argv = process.argv.slice(2);
+const flagArg = (name, fallback) => {
+  const i = argv.indexOf(name);
+  return i === -1 ? fallback : Number(argv[i + 1]);
+};
+const THRESHOLD = flagArg('--threshold', 7);
+const EXAMPLES = flagArg('--examples', 3);
+
+const ledger = JSON.parse(fs.readFileSync(path.join(DATA, 'judge-pass-manifest.json'), 'utf8'));
+
+const ng = (rec) => (rec.flags || []).filter((f) => f.judge_verdict === 'not_grounded');
+const population = ledger.files.filter((rec) => ng(rec).length >= THRESHOLD);
+
+// Two passes over the same population. The canonical one applies the context
+// condition; the §4-only pass exists purely to MEASURE what that condition
+// removes — it is never a source of proposals, because four of the six swaps it
+// admits on this population are wrong edits (see lib/fix-op.mjs).
+const items = [];
+const s4Only = [];
+for (const rec of population) {
+  const text = fs.readFileSync(path.join(REPO, rec.file), 'utf8');
+  for (const flag of ng(rec)) {
+    const verdict = classifyFlag(flag, text);
+    s4Only.push(classifyFlag(flag, text, { contextCheck: false }));
+    items.push({
+      id: flag.id,
+      file: flag.file,
+      line: flag.line,
+      rule: flag.rule || '(none)',
+      claim: flag.claim,
+      evidence_url: flag.evidence_url,
+      evidence_quote: flag.evidence_quote,
+      reason: flag.reason,
+      op: verdict.op,
+      code: verdict.code,
+      detail: verdict.detail,
+      proposal: verdict.proposal,
+    });
+  }
+}
+
+// ------------------------------------------------------------------ measurements
+
+const tally = (rows, key) =>
+  rows.reduce((acc, r) => {
+    const k = typeof key === 'function' ? key(r) : r[key];
+    acc[k] = (acc[k] || 0) + 1;
+    return acc;
+  }, {});
+
+const o1 = items.filter((i) => i.op === 'O1');
+const o3 = items.filter((i) => i.op === 'O3');
+const byCode = tally(o3, 'code');
+const byRule = tally(items, 'rule');
+const r8 = items.filter((i) => i.rule === 'R8');
+
+// LOCATOR_MISS / LOCATOR_AMBIGUOUS are a FIXABLE engineering gap (the locator did
+// not find the value the claim asserts). Every other abort is intrinsic to the
+// flag: no swappable value, no same-type replacement in the cited quote, or a
+// claim that is not a value swap at all. The distinction is what tells the
+// operator whether more engineering would move the O1 number.
+const LOCATOR_CODES = new Set([ABORT_CODES.LOCATOR_MISS, ABORT_CODES.LOCATOR_AMBIGUOUS]);
+const locatorAborts = o3.filter((i) => LOCATOR_CODES.has(i.code)).length;
+
+// §4-as-written is a NUMERIC-path measurement: it is the baseline the context
+// condition (§4a) was added against. §4b status swaps do not run through the
+// context condition at all, so counting them here would silently inflate the
+// baseline and break the comparison with the pilot's hand-verified 6.
+const isStatus = (v) => v.op === 'O1' && v.proposal.type === 'status';
+const s4O1 = s4Only.filter((v) => v.op === 'O1' && !isStatus(v)).length;
+const o1Numeric = o1.filter((i) => i.proposal.type !== 'status').length;
+
+// §4b (ratified 2026-08-03): the STATUS_SYNONYM class, split into what the closed
+// synonym table proves and why the remainder still aborts. The abort REASON
+// sub-distribution is the actionable part — NO_COMPLETE_FILE_LABEL is a corpus
+// shape, SOURCE_STATUS_AMBIGUOUS is a quote shape, FILE_ALREADY_MATCHES means the
+// flag was never a status mismatch in the first place.
+const statusProposals = items.filter((i) => i.op === 'O1' && i.proposal.type === 'status');
+const statusAborts = o3.filter((i) => i.code === ABORT_CODES.STATUS_SYNONYM);
+
+// O1 precision is NOT uniform across token types, and this split is the pilot's
+// operational conclusion. Hand-verified over the whole not_grounded population:
+// every iso_date swap is an `api-version=` bump in a URL or code sample and all
+// were correct; the number/version swaps mutilated identifiers instead
+// ("AI-900" -> "AI-901", "gpt-4o" -> "gpt-5.1o" twice, a Java agent DOWNgrade),
+// because a matching identifier prefix ("AI-", "gpt-") satisfies the context
+// condition while the digit is part of a name rather than a quantity.
+const O1_HAND_VERIFIED_TYPES = new Set(['iso_date']);
+const byType = tally(o1, (i) => i.proposal.type);
+const recommended = o1.filter((i) => O1_HAND_VERIFIED_TYPES.has(i.proposal.type));
+const pct = (n) => `${((n / items.length) * 100).toFixed(1)} %`;
+
+const report = {
+  _meta: {
+    purpose:
+      'R11 pilot measurement (§10): fix-operation classification over the densest not_grounded sample. Read-only — no KB file and no ledger record was written.',
+    contract: 'docs/r11-tiered-fix-design.md §3/§4/§10',
+    classifier: 'scripts/kb-eval/lib/fix-op.mjs (the O1 driver with writes disabled)',
+    ledger: 'scripts/kb-eval/data/judge-pass-manifest.json',
+    ledger_records: ledger.files.length,
+    threshold: `not_grounded >= ${THRESHOLD} (source_silent excluded, per §10)`,
+    generated_from: 'ledger snapshot at run time — counts are re-derived, never read from a plan',
+    disclaimer_two_202s:
+      "This population is 202 flags. §3's '202 flags whose claim and quote contain a numeric token' is a DIFFERENT 202, measured over the full 712-flag population. Do not conflate them.",
+  },
+  population: { files: population.length, flags: items.length },
+  s4_as_written: {
+    O1: s4O1,
+    note:
+      'What §4 exactly as written would admit on the NUMERIC path (§4b status swaps excluded — they never run through the context condition). NOT a source of proposals: on the >=7 pilot all 6 were hand-verified and 4 were wrong edits (unit crossing, metric crossing, two mutilated identifiers) — measured precision 2/6. Runs at other thresholds carry no hand-verification.',
+  },
+  status_synonym: {
+    contract: '§4b — the closed synonym table, ratified 2026-08-03',
+    class_total: statusProposals.length + statusAborts.length,
+    proven: statusProposals.length,
+    aborts: tally(statusAborts, (i) => (i.detail && i.detail.reason) || '(unspecified)'),
+    hand_verified:
+      THRESHOLD === 7
+        ? 'All 5 hand-judged 2026-08-03 (docs/r11-pilot-results.md appendix B). Four carry the source phrasing on the row\'s OWN subject and are correct. One (security-copilot-integration.md:94) harvests a "(Preview)" marker that belongs to a DIFFERENT agent in an enumerated quote — the same provenance-without-referent defect that falsified §4. Its outcome is plausibly right; its proof is not.'
+        : 'hand-verification was done on the >=7 pilot only',
+    applicability:
+      'REVIEW-GRADE, NOT APPLY-GRADE. status is deliberately absent from o1_recommended: §4b binds the table, the completeness of the file label and the written value, and nothing about whether the source phrasing refers to the row\'s subject. A referent condition is an open operator decision.',
+  },
+  o1_by_type: byType,
+  o1_recommended: {
+    count: recommended.length,
+    types: [...O1_HAND_VERIFIED_TYPES],
+    note:
+      'The only O1 class that survived hand-verification: iso_date, which in this corpus is always an api-version bump inside a URL or code sample. number/version proposals are NOT safe to apply — they mutilate product, model and certification identifiers.',
+  },
+  split: { O1: o1.length, O2: 0, O3: o3.length, O2_note: 'O2 requires operator ratification (§5); until then every non-O1 item is O3 by design.' },
+  abort_codes: byCode,
+  locator_aborts: { count: locatorAborts, note: 'fixable engineering gap — every other abort is intrinsic to the flag' },
+  by_rule: byRule,
+  r8: { total: r8.length, O1: r8.filter((i) => i.op === 'O1').length, codes: tally(r8.filter((i) => i.op === 'O3'), 'code') },
+  items,
+};
+
+// ---------------------------------------------------------------------- output
+
+console.log(`R11 pilot — ${population.length} files / ${items.length} not_grounded flags (threshold >= ${THRESHOLD})`);
+console.log(`ledger: ${ledger.files.length} records\n`);
+console.log(`O1 (provable value swap): ${o1.length}  (${pct(o1.length)})`);
+console.log(`O3 (human):              ${o3.length}  (${pct(o3.length)})`);
+console.log(`O2:                      0  (unratified — §5)`);
+const handNote =
+  THRESHOLD === 7
+    ? ' — all 6 hand-verified: 4 are wrong edits (unit crossing, metric crossing, two mutilated identifiers)'
+    : ' (hand-verification was done on the >=7 pilot only)';
+console.log(`\n§4 as written would admit ${s4O1} on the numeric path${handNote}. Context condition removes ${s4O1 - o1Numeric}.`);
+console.log(
+  `§4b status class: ${report.status_synonym.class_total} flags -> ${report.status_synonym.proven} proven, ` +
+    `${JSON.stringify(report.status_synonym.aborts)} — REVIEW-grade, not applied by any driver.\n`,
+);
+console.log('abort codes:');
+for (const [code, n] of Object.entries(byCode).sort((a, b) => b[1] - a[1])) {
+  console.log(`  ${code.padEnd(20)} ${String(n).padStart(4)}  ${pct(n)}`);
+}
+console.log(`\nO1 by token type: ${JSON.stringify(byType)}`);
+console.log(`O1 hand-verified-safe class (iso_date / api-version): ${recommended.length}  — the rest mutilate identifiers, do NOT apply`);
+console.log(`\nlocator aborts (fixable): ${locatorAborts}   intrinsic aborts: ${o3.length - locatorAborts}`);
+console.log(`\nrule distribution: ${JSON.stringify(byRule)}`);
+console.log(`R8: ${r8.length} flags — O1 ${report.r8.O1}, aborts ${JSON.stringify(report.r8.codes)}`);
+
+if (EXAMPLES > 0 && o1.length > 0) {
+  console.log(`\n--- ${Math.min(EXAMPLES, o1.length)} proven O1 proposals ---`);
+  for (const i of o1.slice(0, EXAMPLES)) {
+    console.log(`\n${i.file}:${i.proposal.line}  [${i.rule}]  ${i.token || i.proposal.token} -> ${i.proposal.replacement}`);
+    console.log(`  - ${i.proposal.before}`);
+    console.log(`  + ${i.proposal.after}`);
+    console.log(`  quote: ${i.proposal.evidence_quote.slice(0, 160)}`);
+  }
+}
+
+if (argv.includes('--write')) {
+  const out = path.join(DATA, 'r11-pilot-classification.json');
+  fs.writeFileSync(out, JSON.stringify(report, null, 2) + '\n');
+  console.log(`\nwrote ${out}`);
+} else {
+  console.log('\n(dry run — pass --write to persist r11-pilot-classification.json)');
+}

scripts/kb-eval/compute-base-rate.mjs

@@ -0,0 +1,102 @@
+#!/usr/bin/env node
+// compute-base-rate.mjs — Fase 0, steg 3 glue: turn the gold correctness set into
+// a defensible base-rate report (the directional input for the Fase 3 gate).
+//
+// All non-trivial math (verifiable error rate, Wilson bands, the staleness-
+// catchable vs judge-unique split) lives in tested lib/base-rate.mjs. This CLI is
+// thin wiring: read gold-correctness-set.json -> computeBaseRate() -> write a
+// machine-readable .json and a human-readable .md. Same shape as build-gold-set.mjs.
+//
+// Usage:  node scripts/kb-eval/compute-base-rate.mjs [--write]
+//   (default: print the overall + per-stratum summary; --write persists
+//    data/base-rate-report.json and data/base-rate-report.md)
+
+import fs from 'node:fs';
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+import { computeBaseRate } from './lib/base-rate.mjs';
+
+const __dirname = path.dirname(fileURLToPath(import.meta.url));
+const DATA = path.join(__dirname, 'data');
+
+const gold = JSON.parse(fs.readFileSync(path.join(DATA, 'gold-correctness-set.json'), 'utf8'));
+const claims = gold.claims;
+const report = computeBaseRate(claims);
+
+const pct = (x) => `${(x * 100).toFixed(1)}%`;
+const band = (w) => `[${pct(w.low)}, ${pct(w.high)}]`;
+
+// One row of the per-dimension tables. b = a finalized bucket from the lib.
+function row(key, b) {
+  const v = b.byVerdict;
+  return `| ${key} | ${b.total} | ${v.correct} | ${v.outdated} | ${v.wrong} | ${v.unsourced} | ${b.errors}/${b.verifiable} = ${pct(b.errorRate)} | ${band(b.errorRateWilson)} | ${b.errorsJudgeUnique} |`;
+}
+const HEAD =
+  '| key | n | correct | outdated | wrong | unsourced | err-rate (verifiable) | Wilson 95% | judge-unique |\n' +
+  '|---|---|---|---|---|---|---|---|---|';
+
+// Sort dimension entries by descending total so the heaviest buckets read first.
+function table(title, byKey) {
+  const rows = Object.entries(byKey)
+    .sort((a, b) => b[1].total - a[1].total)
+    .map(([k, b]) => row(k, b));
+  return `### ${title}\n\n${HEAD}\n${rows.join('\n')}\n`;
+}
+
+const o = report.overall;
+const md = `# Base-rate-rapport — Fase 0 (KB korrekthet)
+
+_Generert deterministisk av \`compute-base-rate.mjs\` over \`gold-correctness-set.json\`. Tall fra testet \`lib/base-rate.mjs\` (15 tester). Ikke rediger for hånd — regenerer._
+
+**Gull-sett:** ${claims.length} påstander · metode: ${gold._meta?.method ? 'se gold-correctness-set.json `_meta.method`' : 'n/a'}
+
+## Verdict-vokabular
+
+- **correct** — en hentet learn.microsoft.com-side oppgir den påståtte verdien
+- **outdated** — hentet kilde viser en annen, erstattet verdi (tidsdrift)
+- **wrong** — hentet kilde motsier påstanden; den var aldri korrekt
+- **unsourced** — ingen hentbar MS Learn-side oppgir verdien (kan ikke verifiseres)
+
+«Reelle feil» = outdated + wrong. **unsourced er IKKE en feil** — det er den uverifiserbare massen (priser på JS-rendrede Azure-sider som en fetch-basert judge heller ikke når). Den verifiserbare feilraten ekskluderer derfor unsourced fra nevneren.
+
+## Overall
+
+| metrikk | verdi |
+|---|---|
+| Påstander totalt | ${o.total} |
+| correct / outdated / wrong / unsourced | ${o.byVerdict.correct} / ${o.byVerdict.outdated} / ${o.byVerdict.wrong} / ${o.byVerdict.unsourced} |
+| Reelle feil (outdated+wrong) | ${o.errors} |
+| Verifiserbare påstander (nevner) | ${o.verifiable} |
+| **Verifiserbar feilrate** | **${o.errors}/${o.verifiable} = ${pct(o.errorRate)}** |
+| Wilson 95 % | ${band(o.errorRateWilson)} |
+| Unsourced-andel | ${o.unsourced}/${o.total} = ${pct(o.unsourcedRate)} |
+| Feil staleness-loopen fanger (lastmod_changed=true) | ${o.errorsStalenessCatchable} |
+| **Feil kun en korrekthets-judge fanger (judge-unique)** | **${o.errorsJudgeUnique}** |
+
+> **Gate-kritisk:** \`errorsJudgeUnique\` = reelle feil hvis siterte kilde-lastmod IKKE endret seg etter fildato — den eneste klassen en korrekthets-judge fanger som den eksisterende staleness-loopen bommer på. Staleness-recall på de reelle feilene = ${o.errors ? `${o.errorsStalenessCatchable}/${o.errors} = ${pct(o.errorsStalenessCatchable / o.errors)}` : 'n/a'}.
+
+## Per stratum
+
+${table('Stratum', report.byStratum)}
+## Per skill
+
+${table('Skill', report.bySkill)}
+## Per claim_type
+
+${table('Claim type', report.byClaimType)}
+`;
+
+if (process.argv.includes('--write')) {
+  const jsonOut = path.join(DATA, 'base-rate-report.json');
+  const mdOut = path.join(DATA, 'base-rate-report.md');
+  fs.writeFileSync(jsonOut, JSON.stringify({ _meta: { source: 'gold-correctness-set.json', claim_count: claims.length }, ...report }, null, 2) + '\n');
+  fs.writeFileSync(mdOut, md);
+  console.log(`wrote ${jsonOut}`);
+  console.log(`wrote ${mdOut}`);
+} else {
+  console.log(`claims: ${o.total} | correct=${o.byVerdict.correct} outdated=${o.byVerdict.outdated} wrong=${o.byVerdict.wrong} unsourced=${o.byVerdict.unsourced}`);
+  console.log(`verifiable error rate: ${o.errors}/${o.verifiable} = ${pct(o.errorRate)}  Wilson ${band(o.errorRateWilson)}`);
+  console.log(`unsourced: ${o.unsourced}/${o.total} = ${pct(o.unsourcedRate)}`);
+  console.log(`staleness-catchable=${o.errorsStalenessCatchable}  judge-unique=${o.errorsJudgeUnique}`);
+  console.log('(dry run — pass --write to persist base-rate-report.json + .md)');
+}

scripts/kb-eval/data/base-rate-report.json

@@ -0,0 +1,333 @@
+{
+  "_meta": {
+    "source": "gold-correctness-set.json",
+    "claim_count": 373
+  },
+  "overall": {
+    "total": 373,
+    "byVerdict": {
+      "correct": 259,
+      "outdated": 29,
+      "wrong": 11,
+      "unsourced": 74
+    },
+    "errors": 40,
+    "verifiable": 299,
+    "unsourced": 74,
+    "errorsStalenessCatchable": 0,
+    "errorsJudgeUnique": 40,
+    "errorRate": 0.13377926421404682,
+    "errorRateWilson": {
+      "p": 0.13377926421404682,
+      "low": 0.0998039899711332,
+      "high": 0.17704568986149216
+    },
+    "unsourcedRate": 0.19839142091152814
+  },
+  "bySkill": {
+    "ms-ai-advisor": {
+      "total": 79,
+      "byVerdict": {
+        "correct": 59,
+        "outdated": 7,
+        "wrong": 2,
+        "unsourced": 11
+      },
+      "errors": 9,
+      "verifiable": 68,
+      "unsourced": 11,
+      "errorsStalenessCatchable": 0,
+      "errorsJudgeUnique": 9,
+      "errorRate": 0.1323529411764706,
+      "errorRateWilson": {
+        "p": 0.1323529411764706,
+        "low": 0.07122163958543326,
+        "high": 0.2328027696704853
+      },
+      "unsourcedRate": 0.13924050632911392
+    },
+    "ms-ai-engineering": {
+      "total": 86,
+      "byVerdict": {
+        "correct": 54,
+        "outdated": 9,
+        "wrong": 4,
+        "unsourced": 19
+      },
+      "errors": 13,
+      "verifiable": 67,
+      "unsourced": 19,
+      "errorsStalenessCatchable": 0,
+      "errorsJudgeUnique": 13,
+      "errorRate": 0.19402985074626866,
+      "errorRateWilson": {
+        "p": 0.19402985074626866,
+        "low": 0.11705063857457099,
+        "high": 0.3041933762415822
+      },
+      "unsourcedRate": 0.22093023255813954
+    },
+    "ms-ai-governance": {
+      "total": 76,
+      "byVerdict": {
+        "correct": 52,
+        "outdated": 5,
+        "wrong": 2,
+        "unsourced": 17
+      },
+      "errors": 7,
+      "verifiable": 59,
+      "unsourced": 17,
+      "errorsStalenessCatchable": 0,
+      "errorsJudgeUnique": 7,
+      "errorRate": 0.11864406779661017,
+      "errorRateWilson": {
+        "p": 0.11864406779661017,
+        "low": 0.058675082779140006,
+        "high": 0.22523875773415053
+      },
+      "unsourcedRate": 0.2236842105263158
+    },
+    "ms-ai-infrastructure": {
+      "total": 36,
+      "byVerdict": {
+        "correct": 29,
+        "outdated": 1,
+        "wrong": 2,
+        "unsourced": 4
+      },
+      "errors": 3,
+      "verifiable": 32,
+      "unsourced": 4,
+      "errorsStalenessCatchable": 0,
+      "errorsJudgeUnique": 3,
+      "errorRate": 0.09375,
+      "errorRateWilson": {
+        "p": 0.09375,
+        "low": 0.032400962626319516,
+        "high": 0.24218499335778831
+      },
+      "unsourcedRate": 0.1111111111111111
+    },
+    "ms-ai-security": {
+      "total": 96,
+      "byVerdict": {
+        "correct": 65,
+        "outdated": 7,
+        "wrong": 1,
+        "unsourced": 23
+      },
+      "errors": 8,
+      "verifiable": 73,
+      "unsourced": 23,
+      "errorsStalenessCatchable": 0,
+      "errorsJudgeUnique": 8,
+      "errorRate": 0.1095890410958904,
+      "errorRateWilson": {
+        "p": 0.1095890410958904,
+        "low": 0.0565860416101191,
+        "high": 0.20162825897706282
+      },
+      "unsourcedRate": 0.23958333333333334
+    }
+  },
+  "byStratum": {
+    "volatile": {
+      "total": 331,
+      "byVerdict": {
+        "correct": 222,
+        "outdated": 28,
+        "wrong": 10,
+        "unsourced": 71
+      },
+      "errors": 38,
+      "verifiable": 260,
+      "unsourced": 71,
+      "errorsStalenessCatchable": 0,
+      "errorsJudgeUnique": 38,
+      "errorRate": 0.14615384615384616,
+      "errorRateWilson": {
+        "p": 0.14615384615384616,
+        "low": 0.1083692375274728,
+        "high": 0.1942426326249217
+      },
+      "unsourcedRate": 0.21450151057401812
+    },
+    "control": {
+      "total": 42,
+      "byVerdict": {
+        "correct": 37,
+        "outdated": 1,
+        "wrong": 1,
+        "unsourced": 3
+      },
+      "errors": 2,
+      "verifiable": 39,
+      "unsourced": 3,
+      "errorsStalenessCatchable": 0,
+      "errorsJudgeUnique": 2,
+      "errorRate": 0.05128205128205128,
+      "errorRateWilson": {
+        "p": 0.05128205128205128,
+        "low": 0.014177657646399527,
+        "high": 0.1688593904563791
+      },
+      "unsourcedRate": 0.07142857142857142
+    }
+  },
+  "byClaimType": {
+    "version": {
+      "total": 33,
+      "byVerdict": {
+        "correct": 24,
+        "outdated": 6,
+        "wrong": 2,
+        "unsourced": 1
+      },
+      "errors": 8,
+      "verifiable": 32,
+      "unsourced": 1,
+      "errorsStalenessCatchable": 0,
+      "errorsJudgeUnique": 8,
+      "errorRate": 0.25,
+      "errorRateWilson": {
+        "p": 0.25,
+        "low": 0.13252243982621553,
+        "high": 0.4210689177024662
+      },
+      "unsourcedRate": 0.030303030303030304
+    },
+    "tpm": {
+      "total": 30,
+      "byVerdict": {
+        "correct": 20,
+        "outdated": 4,
+        "wrong": 1,
+        "unsourced": 5
+      },
+      "errors": 5,
+      "verifiable": 25,
+      "unsourced": 5,
+      "errorsStalenessCatchable": 0,
+      "errorsJudgeUnique": 5,
+      "errorRate": 0.2,
+      "errorRateWilson": {
+        "p": 0.2,
+        "low": 0.08860454100652485,
+        "high": 0.3913133553653825
+      },
+      "unsourcedRate": 0.16666666666666666
+    },
+    "region": {
+      "total": 20,
+      "byVerdict": {
+        "correct": 15,
+        "outdated": 2,
+        "wrong": 0,
+        "unsourced": 3
+      },
+      "errors": 2,
+      "verifiable": 17,
+      "unsourced": 3,
+      "errorsStalenessCatchable": 0,
+      "errorsJudgeUnique": 2,
+      "errorRate": 0.11764705882352941,
+      "errorRateWilson": {
+        "p": 0.11764705882352941,
+        "low": 0.03287908001292092,
+        "high": 0.3433684249770991
+      },
+      "unsourcedRate": 0.15
+    },
+    "status": {
+      "total": 70,
+      "byVerdict": {
+        "correct": 58,
+        "outdated": 4,
+        "wrong": 3,
+        "unsourced": 5
+      },
+      "errors": 7,
+      "verifiable": 65,
+      "unsourced": 5,
+      "errorsStalenessCatchable": 0,
+      "errorsJudgeUnique": 7,
+      "errorRate": 0.1076923076923077,
+      "errorRateWilson": {
+        "p": 0.1076923076923077,
+        "low": 0.05315354431925606,
+        "high": 0.20601533031468616
+      },
+      "unsourcedRate": 0.07142857142857142
+    },
+    "price": {
+      "total": 76,
+      "byVerdict": {
+        "correct": 20,
+        "outdated": 0,
+        "wrong": 0,
+        "unsourced": 56
+      },
+      "errors": 0,
+      "verifiable": 20,
+      "unsourced": 56,
+      "errorsStalenessCatchable": 0,
+      "errorsJudgeUnique": 0,
+      "errorRate": 0,
+      "errorRateWilson": {
+        "p": 0,
+        "low": 0,
+        "high": 0.16113012549493322
+      },
+      "unsourcedRate": 0.7368421052631579
+    },
+    "taxonomy": {
+      "total": 122,
+      "byVerdict": {
+        "correct": 108,
+        "outdated": 7,
+        "wrong": 3,
+        "unsourced": 4
+      },
+      "errors": 10,
+      "verifiable": 118,
+      "unsourced": 4,
+      "errorsStalenessCatchable": 0,
+      "errorsJudgeUnique": 10,
+      "errorRate": 0.0847457627118644,
+      "errorRateWilson": {
+        "p": 0.0847457627118644,
+        "low": 0.046682191106169606,
+        "high": 0.14899481904471476
+      },
+      "unsourcedRate": 0.03278688524590164
+    },
+    "sku": {
+      "total": 22,
+      "byVerdict": {
+        "correct": 14,
+        "outdated": 6,
+        "wrong": 2,
+        "unsourced": 0
+      },
+      "errors": 8,
+      "verifiable": 22,
+      "unsourced": 0,
+      "errorsStalenessCatchable": 0,
+      "errorsJudgeUnique": 8,
+      "errorRate": 0.36363636363636365,
+      "errorRateWilson": {
+        "p": 0.36363636363636365,
+        "low": 0.19732972772607899,
+        "high": 0.5704865065628195
+      },
+      "unsourcedRate": 0
+    }
+  },
+  "_verdicts": [
+    "correct",
+    "outdated",
+    "wrong",
+    "unsourced"
+  ]
+}

scripts/kb-eval/data/base-rate-report.md

@@ -0,0 +1,66 @@
+# Base-rate-rapport — Fase 0 (KB korrekthet)
+
+_Generert deterministisk av `compute-base-rate.mjs` over `gold-correctness-set.json`. Tall fra testet `lib/base-rate.mjs` (15 tester). Ikke rediger for hånd — regenerer._
+
+**Gull-sett:** 373 påstander · metode: se gold-correctness-set.json `_meta.method`
+
+## Verdict-vokabular
+
+- **correct** — en hentet learn.microsoft.com-side oppgir den påståtte verdien
+- **outdated** — hentet kilde viser en annen, erstattet verdi (tidsdrift)
+- **wrong** — hentet kilde motsier påstanden; den var aldri korrekt
+- **unsourced** — ingen hentbar MS Learn-side oppgir verdien (kan ikke verifiseres)
+
+«Reelle feil» = outdated + wrong. **unsourced er IKKE en feil** — det er den uverifiserbare massen (priser på JS-rendrede Azure-sider som en fetch-basert judge heller ikke når). Den verifiserbare feilraten ekskluderer derfor unsourced fra nevneren.
+
+## Overall
+
+| metrikk | verdi |
+|---|---|
+| Påstander totalt | 373 |
+| correct / outdated / wrong / unsourced | 259 / 29 / 11 / 74 |
+| Reelle feil (outdated+wrong) | 40 |
+| Verifiserbare påstander (nevner) | 299 |
+| **Verifiserbar feilrate** | **40/299 = 13.4%** |
+| Wilson 95 % | [10.0%, 17.7%] |
+| Unsourced-andel | 74/373 = 19.8% |
+| Feil staleness-loopen fanger (lastmod_changed=true) | 0 |
+| **Feil kun en korrekthets-judge fanger (judge-unique)** | **40** |
+
+> **Gate-kritisk:** `errorsJudgeUnique` = reelle feil hvis siterte kilde-lastmod IKKE endret seg etter fildato — den eneste klassen en korrekthets-judge fanger som den eksisterende staleness-loopen bommer på. Staleness-recall på de reelle feilene = 0/40 = 0.0%.
+
+## Per stratum
+
+### Stratum
+
+| key | n | correct | outdated | wrong | unsourced | err-rate (verifiable) | Wilson 95% | judge-unique |
+|---|---|---|---|---|---|---|---|---|
+| volatile | 331 | 222 | 28 | 10 | 71 | 38/260 = 14.6% | [10.8%, 19.4%] | 38 |
+| control | 42 | 37 | 1 | 1 | 3 | 2/39 = 5.1% | [1.4%, 16.9%] | 2 |
+
+## Per skill
+
+### Skill
+
+| key | n | correct | outdated | wrong | unsourced | err-rate (verifiable) | Wilson 95% | judge-unique |
+|---|---|---|---|---|---|---|---|---|
+| ms-ai-security | 96 | 65 | 7 | 1 | 23 | 8/73 = 11.0% | [5.7%, 20.2%] | 8 |
+| ms-ai-engineering | 86 | 54 | 9 | 4 | 19 | 13/67 = 19.4% | [11.7%, 30.4%] | 13 |
+| ms-ai-advisor | 79 | 59 | 7 | 2 | 11 | 9/68 = 13.2% | [7.1%, 23.3%] | 9 |
+| ms-ai-governance | 76 | 52 | 5 | 2 | 17 | 7/59 = 11.9% | [5.9%, 22.5%] | 7 |
+| ms-ai-infrastructure | 36 | 29 | 1 | 2 | 4 | 3/32 = 9.4% | [3.2%, 24.2%] | 3 |
+
+## Per claim_type
+
+### Claim type
+
+| key | n | correct | outdated | wrong | unsourced | err-rate (verifiable) | Wilson 95% | judge-unique |
+|---|---|---|---|---|---|---|---|---|
+| taxonomy | 122 | 108 | 7 | 3 | 4 | 10/118 = 8.5% | [4.7%, 14.9%] | 10 |
+| price | 76 | 20 | 0 | 0 | 56 | 0/20 = 0.0% | [0.0%, 16.1%] | 0 |
+| status | 70 | 58 | 4 | 3 | 5 | 7/65 = 10.8% | [5.3%, 20.6%] | 7 |
+| version | 33 | 24 | 6 | 2 | 1 | 8/32 = 25.0% | [13.3%, 42.1%] | 8 |
+| tpm | 30 | 20 | 4 | 1 | 5 | 5/25 = 20.0% | [8.9%, 39.1%] | 5 |
+| sku | 22 | 14 | 6 | 2 | 0 | 8/22 = 36.4% | [19.7%, 57.0%] | 8 |
+| region | 20 | 15 | 2 | 0 | 3 | 2/17 = 11.8% | [3.3%, 34.3%] | 2 |
+

scripts/kb-eval/data/g7-review-queue.json

@@ -0,0 +1,191 @@
+{
+  "_meta": {
+    "gap": "G7",
+    "form": "(b) named queue into the human review phase",
+    "ratified": "2026-08-03",
+    "rationale": "Measured in R11 §9.6: 2 of the 4 subtractions applied in 957ebef left a residue, so residues are the normal by-product of a delete-only envelope rather than an exception. Two of the members are replacements, not multi-locator cases, which a deletion-oriented O4 class would not have fixed. A queue absorbs both classes; an O4 return contract would have been mis-sized against the evidence.",
+    "contract": "Anchors are verbatim strings, never line numbers (line ≠ real_line in 9 of 17 R11 records). An open entry whose anchor no longer occurs in its file is drift, and check-g7-queue.mjs fails rather than passing it silently. Nothing in this queue is machine-appliable by definition — every entry is outside the O2 envelope. Resolution is a human review act.",
+    "evidence": "docs/r11-pilot-results.md §9.4, §9.5, §9.6; docs/ref-kb-correctness-program-2026-06.md §8 G7"
+  },
+  "entries": [
+    {
+      "id": "idx-17",
+      "file": "skills/ms-ai-engineering/references/rag-architecture/rag-caching-optimization.md",
+      "class": "replacement",
+      "status": "resolved",
+      "raised": "2026-08-03",
+      "summary": "The idx 17 subtraction (957ebef) deleted the three score-threshold bands but left the lead-in ending in a colon, promising an enumeration that no longer existed, immediately followed by a **Verified** stamp. The subtraction was correct; the paragraph it left was not. V1/V2/V2b/V3 are string invariants over deleted text and cannot see document coherence, so the machine could not have caught it.",
+      "evidence": "docs/r11-pilot-results.md §9.6",
+      "anchors": [],
+      "resolution": "Operator-ratified 2026-08-03: colon changed to a period, making the lead-in a complete and independently true sentence that the **Verified** stamp correctly covers. Corpus swept for the same defect shape (bold lead-in ending in colon, blank line, **Verified**) — no other occurrence."
+    },
+    {
+      "id": "idx-33",
+      "file": "skills/ms-ai-security/references/ai-security-engineering/ai-threat-modeling-stride.md",
+      "class": "replacement",
+      "status": "open",
+      "raised": "2026-08-03",
+      "summary": "The idx 33 subtraction removed AI asset inventory via Azure Resource Graph and the Purview Insider Risk Management bullet from an unsupported Defender for Cloud AISPM attribution. Correct — but the same capabilities survive in this file under Cloud Adoption Framework Secure AI attribution, stamped 'Verified MCP 2026-04', and are asserted in four other corpus files. The edit's benefit is corpus-wide smaller than the single line suggested. Whether the CAF attribution is itself supported has not been checked.",
+      "evidence": "docs/r11-pilot-results.md §9.5 (cross-corpus check), §9.6",
+      "anchors": [
+        "Oppdatert 2026-04: inkluderer nå AI asset inventory via Azure Resource Graph"
+      ]
+    },
+    {
+      "id": "idx-26",
+      "file": "skills/ms-ai-governance/references/responsible-ai/transparency-documentation-standards.md",
+      "class": "multi-locator",
+      "status": "resolved",
+      "raised": "2026-08-03",
+      "summary": "The Responsible AI Scorecard component list names Error analysis (item 4) and Counterfactual analysis (item 5). Both were measured false against first-party docs 2026-08-03: the canonical scorecard segments are summary/model overview, data analysis, model performance, cohorts, top important factors, fairness insights and causal insights; Error analysis and Counterfactual analysis are Responsible AI *dashboard* components. The delete-only reduction could only remove item 5, because line 300 asserts Error analysis as scorecard content too — so a partial fix would have left a known-false claim standing while introducing a renumbering artifact (1,2,3,4,6,7). Operator declined the partial fix 2026-08-03 and sent the whole case here. Correct repair spans both locators.",
+      "evidence": "docs/r11-pilot-results.md §9.6; https://learn.microsoft.com/azure/machine-learning/how-to-responsible-ai-scorecard",
+      "anchors": [
+        "4. **Error analysis**: Error rates per cohort, confusion matrices",
+        "| **Risk assessment** | Responsible AI Scorecard: Error analysis, fairness assessment |"
+      ],
+      "resolution": "Operator-ratified 2026-08-03, form (b) — relabel rather than remove. Both source pages were re-fetched live this session and confirm the measurement independently of §9.6: how-to-responsible-ai-scorecard enumerates summary/model overview, data analysis, model performance, cohorts, top important factors, fairness insights and causal insights; concept-responsible-ai-dashboard lists Error analysis and Counterfactual what-if among the dashboard components. Locator 1: items 4 and 5 removed from the numbered scorecard list, which renumbers cleanly to 1-5 — the 1,2,3,4,6,7 artifact was forced only inside the delete-only envelope and does not apply to an ordinary Edit. The two capabilities are retained in a blockquote explicitly marked as dashboard components rather than scorecard segments, so genuine source-confirmed information survives and the reader is warned off precisely the conflation that produced the defect. Locator 2: the Risk assessment row now reads 'fairness insights' alone. The **Confidence:** Verified stamp twelve lines below vouched for the false list and was silently outside every machine check (V1/V2/V2b/V3 are string invariants; check-g7-queue only tests anchors); it is kept but dated to 2026-08-03 to record the re-verification. Document coherence around both locators was read after the edit, per the c569bdc lesson. A neighbouring defect surfaced by the file sweep is booked separately as idx-26b rather than folded in here."
+    },
+    {
+      "id": "idx-26c",
+      "file": "skills/ms-ai-governance/references/responsible-ai/transparency-documentation-standards.md",
+      "class": "replacement",
+      "status": "resolved",
+      "raised": "2026-08-03",
+      "summary": "The scorecard enumeration is incomplete, and idx 26's repair made that assertion active rather than latent. The live fetch performed for idx 26 lists seven canonical segments: summary/model overview, data analysis, model performance, cohorts, top important factors, fairness insights, causal insights. The list after the idx 26 edit carries five — model overview, fairness assessment, model interpretability, causal inference, data quality — so **model performance** and **cohorts** are absent. Note for whoever repairs this: 'Cohort analysis' does appear a few lines below, but inside the *Customization* block, not as an enumerated segment, so it does not cure the omission. This was a latent incompleteness under an undated stamp before 2026-08-03; dating the stamp to 2026-08-03 as part of idx 26 turned it into a positive claim that this enumeration was verified that day, over content the same day's verification showed to be missing two members — the same class of defect §9.7 describes, where an anchor-correct edit leaves a false claim where no check reaches. Booked rather than folded into idx 26, whose ratified scope was the falsity of items 4 and 5, not the completeness of the list. The date on the stamp is deliberately NOT re-litigated here: the relabel it covers WAS verified 2026-08-03, and the operator may keep it once this entry closes the completeness gap. Adding the two missing segments is a content change requiring its own operator ratification.",
+      "evidence": "docs/r11-pilot-results.md §9.7; https://learn.microsoft.com/azure/machine-learning/how-to-responsible-ai-scorecard",
+      "anchors": [
+        "5. **Data quality**: Dataset statistics, missing values, outlier analysis"
+      ],
+      "resolution": "Operator-ratified 2026-08-03, form (a) - add the two missing segments rather than downgrade the list to a selection. The source was re-fetched live this session and enumerates seven segments in order: summary/model overview, data analysis, model performance, cohorts, top important factors, fairness insights, causal insights. Model performance and Cohorts were appended as items 6 and 7; the existing five were left untouched, so the change is confined to the measured gap. Appending rather than inserting in source order was a free choice, not a machine-forced one: STATE asserted that a resolved entry anchor must stop matching or the check fails, and that is wrong - lib/g7-queue.mjs:69-75 returns before the anchor check for resolved entries, so resolved is fully exempt and anchor drift only bites an entry left open. The list carries no ordering claim, and the existing five were already not in source order, so appending introduces no new falsity. Item 7 is worded \"automatisk uttrukket av scorecard-en\" to keep it distinct from the Cohort analysis bullet in the Customization block, which is operator-defined and does not enumerate a segment. The **Confidence:** Verified (MCP: microsoft-learn, 2026-08-03) stamp closing §3 (Responsible AI Scorecard) is kept unchanged and its scope was checked explicitly rather than left implicit: it now vouches for a complete seven-member enumeration re-verified against the live source on the date it already carries. Post-edit sweep of both regions found the surrounding prose coherent; the paraphrase drift it did surface is booked as idx-26d, not folded in. Correction 2026-08-03 (same session, later pass): this resolution originally located that stamp at \"line 129\". It is not there - line 129 is the **Status:** Public preview line, and the **Confidence:** stamp is line 131. The claim about the stamp was true; the locator was false, and it was written into a tracked artefact. Same class as the row count corrected in a9d4724, and the reason the queue contract forbids line numbers as anchors - the prohibition applies to prose inside an entry too, not only to the anchors array."
+    },
+    {
+      "id": "idx-26b",
+      "file": "skills/ms-ai-governance/references/responsible-ai/transparency-documentation-standards.md",
+      "class": "replacement",
+      "status": "resolved",
+      "raised": "2026-08-03",
+      "summary": "Surfaced by the post-edit file sweep for idx 26, in the same compliance-mapping table as idx 26's second locator, but outside both of its anchors — so booked separately rather than folded in (gap discipline; operator-ratified 2026-08-03). The Accuracy metrics row attributes 'Quantitative analyses' to the Responsible AI Scorecard. That is not a scorecard segment name: how-to-responsible-ai-scorecard calls the corresponding segment 'model performance'. The defect is a cross-attribution between two different standards rather than mere imprecision — 'Quantitative Analyses' is a canonical Model Card section, and this same file lists it as one at line 77. Repair is a replacement, so it is outside the delete-only envelope. Whether the right fix is to rename the segment or to drop the row is not yet decided.",
+      "evidence": "docs/r11-pilot-results.md §9.6; https://learn.microsoft.com/azure/machine-learning/how-to-responsible-ai-scorecard",
+      "anchors": [
+        "| **Accuracy metrics** | Responsible AI Scorecard: Quantitative analyses |"
+      ],
+      "resolution": "Operator-ratified 2026-08-03, form (a) - rename rather than drop the row. The source page was re-fetched live this session (how-to-responsible-ai-scorecard) rather than taken from §9.6 as a premise, and it names the segment model performance: \"The model performance segment displays your model most important metrics and characteristics of your predictions and how well they satisfy your desired target values.\" The Accuracy metrics row now reads \"Responsible AI Scorecard: model performance\". Rename was chosen over deletion because the EU AI Act accuracy-metrics mapping is genuine and source-supported; dropping the row would have removed true information to repair a naming defect. Line 77 keeps Quantitative analyses as a Model Card section, which is correct there and is what made the cross-attribution visible. The **Confidence:** Verified (Baseline + MCP-inferred) stamp at the foot of the compliance table was deliberately NOT upgraded: it covers all six rows and only one was measured against the source this session, so re-dating or strengthening it would have extended a verification claim over unmeasured content - the §9.7 defect class."
+    },
+    {
+      "id": "idx-27",
+      "file": "skills/ms-ai-governance/references/responsible-ai/transparency-documentation-standards.md",
+      "class": "replacement",
+      "status": "resolved",
+      "raised": "2026-08-03",
+      "summary": "Failed out of O2 on cond 3 (§9.6): the cited source DOES establish the mechanism — faqs-generative-orchestration states 'Makers can require user confirmation before executing tools that modify data' — so deleting the Plugin-actions row would destroy source-confirmed information. The defect is modality, not fabrication: the file presents confirmation prompts as a built-in disclosure, whereas the source makes them maker-configured. The Chat-interface row in the same table is imprecise for the same reason: the FAQ documents a default transparency message ('Just so you are aware, I sometimes use AI to answer your questions.'), not a 'Powered by AI' badge. Repair is a replacement, outside the delete-only envelope.",
+      "evidence": "docs/r11-pilot-results.md §9.6; https://learn.microsoft.com/microsoft-copilot-studio/faqs-generative-orchestration; https://learn.microsoft.com/microsoft-copilot-studio/faqs-generative-answers",
+      "anchors": [
+        "| **Plugin actions** | Confirmation prompts før sensitive actions (send email, delete file) |",
+        "| **Chat interface** | \"Powered by AI\" badge i chat window |"
+      ],
+      "resolution": "Operator-ratified 2026-08-03. Open question #8 (does a hub page's linked children count as \"the source\") was answered NO - the strict reading R11 has held throughout stands, and no new standing grounding rule was introduced. idx-27 was instead resolved by making the child a CITED source: the Responsible AI FAQ block now lists both the hub (responsible-ai-overview) and faqs-generative-orchestration, naming the latter as the source for the two repaired claims. The FAQ was fetched live before writing; both quotes are verbatim from it. Chat-interface row: \"Powered by AI\" badge replaced with the default transparency message the source actually documents - \"Just so you are aware, I sometimes use AI to answer your questions.\" - which the source states agents include, so it belongs under Built-in disclosures. Plugin-actions row: the source says \"Makers can require user confirmation before executing tools that modify data\", a configurable safeguard, so the row was MOVED OUT of the Built-in disclosures table into a new \"Maker-konfigurerte kontroller (ikke innebygde disclosures)\" block. Repairing the text in place would have left the false modality asserted by the table heading; weakening the heading instead was rejected because it would have silently restated the modality of the two unmeasured rows (Generative answers, Data usage), and adding a modality column would have asserted \"built-in\" about them outright - creating new unverified claims to fix an old one. The deleted \"(send email, delete file)\" examples were not carried over: the source names neither. The same \"Powered by AI\" imprecision at line 218, in the Azure implementasjon list of Mønster 3, is outside this entry's anchors and is booked as idx-27b rather than swept in - the idx-26c/26d precedent. No **Confidence:** stamp covers the Copilot Studio section, so no marker obligation was triggered by this edit. Scope addendum, same session, after an adversarial read of the resolution above: both repaired claims were taken from a FAQ whose own scope line reads \"the AI impact of generative orchestration for custom agents built in Copilot Studio\", and they were written into a section headed Microsoft Copilot Studio with no qualifier - the same widening class this entry was raised for. Re-checked against the docs rather than reasoned about, and the two claims came apart. The maker-confirmation safeguard occurs ONLY in the generative-orchestration FAQ, in a safeguards list about tool execution, so it is orchestration-scoped and the bullet now says so explicitly (\"for agenter med generativ orkestrering\"). The default transparency message occurs in that FAQ AND, verbatim, in faqs-generative-answers under \"What protections are in place within Copilot Studio for responsible AI?\", framed there as a general best practice rather than an orchestration feature. Two independent feature FAQs stating it without a feature qualifier is why the Built-in disclosures row carries no scope qualifier; faqs-generative-answers was added as a third cited source so the reader can check that reasoning rather than take it on trust. Neither FAQ is a Copilot-Studio-wide statement of record, so this is grounded-as-cited, not established-for-all-agents - if a stronger claim is ever wanted, it needs a source that says so."
+    },
+    {
+      "id": "idx-36",
+      "file": "skills/ms-ai-security/references/ai-security-engineering/ai-threat-modeling-stride.md",
+      "class": "multi-locator",
+      "status": "open",
+      "raised": "2026-08-03",
+      "summary": "Applying idx 36 alone yields a severity table more precise than the prose that cites it, so a companion edit is required for the prose to match the narrowed table. Held back from 957ebef as out of envelope.",
+      "evidence": "docs/r11-pilot-results.md §9.4, §9.5",
+      "anchors": [
+        "Øker severity bar; krever mer robust adversarial defenses"
+      ]
+    },
+    {
+      "id": "idx-18",
+      "file": "skills/ms-ai-engineering/references/rag-architecture/rag-caching-optimization.md",
+      "class": "multi-locator",
+      "status": "open",
+      "raised": "2026-08-03",
+      "summary": "No reduction exists. The surviving claim is a whole titled section on Azure AI Search built-in caching plus a **Verified** row in the verification table, so no deletion confined to a single locator can repair the file. This is the member that most clearly motivated G7.",
+      "evidence": "docs/r11-pilot-results.md §9.3, §9.4",
+      "anchors": [
+        "**Automatic Caching Behavior:**",
+        "| Azure AI Search caching | **Verified** | Microsoft Learn docs (4, 6) |"
+      ]
+    },
+    {
+      "id": "idx-26d",
+      "file": "skills/ms-ai-governance/references/responsible-ai/transparency-documentation-standards.md",
+      "class": "replacement",
+      "status": "resolved",
+      "raised": "2026-08-03",
+      "summary": "Surfaced by the post-edit sweep for idx-26c. The five original members of the scorecard component list carry paraphrased names rather than the source segment names, and idx-26c added two members that DO carry source names, so the list is now mixed. Concretely: item 5 Data quality maps to the source segment data analysis; item 3 Model interpretability maps to top important factors; item 1 Model overview is described as \"Architecture, training data, intended use\", which is Model Card content - the source summary segment is a model overview plus the key target values the user set. That last one is the same cross-attribution class as idx-26b rather than mere imprecision, since Model details / Intended use / Training data are canonical Model Card sections listed in this same file at lines 71-76. Full canonicalisation was offered to the operator as part of the idx-26c decision and was NOT chosen; the ratified scope there was completeness only, so this is booked rather than folded in. Open choice: rename the five to the source segment names in source order, or rewrite item 1 alone (the only member where the drift produces a false attribution rather than a recognisable paraphrase) and leave the rest.",
+      "evidence": "docs/r11-pilot-results.md §9.8; https://learn.microsoft.com/azure/machine-learning/how-to-responsible-ai-scorecard",
+      "anchors": [
+        "1. **Model overview**: Architecture, training data, intended use"
+      ],
+      "resolution": "Operator-ratified 2026-08-03, full canonicalisation. The source was re-fetched live before writing (how-to-responsible-ai-scorecard) and enumerates seven segments: summary/model overview, data analysis, model performance, cohorts, top important factors, fairness insights, causal insights. All five original member NAMES were renamed to the source segment names, closing the defect this entry was actually booked under - that the list mixed two dialects after idx-26c added two source-named members. Rewriting item 1 alone was rejected for exactly that reason: it removes the false attribution but leaves the booked defect standing. DESCRIPTIONS were rewritten for two members only: item 1 (was \"Architecture, training data, intended use\", which is Model Card content - Model details / Intended use / Training data are canonical Model Card sections listed in this same file at lines 71-76 - now \"Modelloversikt og de target-verdiene du har satt\", matching the source summary segment) and item 3 (was \"Feature importance (global/local explanations)\", RAI *dashboard* vocabulary inside a scorecard enumeration, contradicting this file's own callout that dashboard components are not scorecard segments - now \"Faktorene som påvirker modellens prediksjoner mest\"). Descriptions of items 2, 4 and 5 were deliberately left UNTOUCHED even though they carry specifics the source does not state, because that is a distinct defect class (unsourced specificity under a verification marker) booked as idx-26f; rewriting them here would have silently resolved an entry raised the same session and left the queue incoherent. Source order was NOT imposed: idx-26c established the list carries no ordering claim and the five were already not in source order, so reordering would be a larger diff with no measured defect behind it. Cross-file check run before editing: the five names occur elsewhere in the corpus, but in dashboard/interpretability contexts, not as a mirror of this enumeration - except stakeholder-communication-ai-decisions.md:57-62, which is a parallel five-member list in the same paraphrase dialect and is booked as idx-26e rather than swept in. What the **Confidence:** Verified (MCP: microsoft-learn, 2026-08-03) stamp closing §3 now vouches for, stated explicitly rather than left implicit: a seven-member enumeration whose NAMES are all the source's own segment names and whose descriptions for items 1, 3, 6 and 7 were verified against the live source on the date the stamp already carries. Items 2, 4 and 5 descriptions are NOT covered by that widening - idx-26f is open against them. [Superseded 2026-08-03 by idx-26f's closure: items 2 and 5 were rewritten to source wording and item 4 adjudicated a recognisable paraphrase; see idx-26f's resolution for what the stamp covers now.]"
+    },
+    {
+      "id": "idx-27b",
+      "file": "skills/ms-ai-governance/references/responsible-ai/transparency-documentation-standards.md",
+      "class": "replacement",
+      "status": "resolved",
+      "raised": "2026-08-03",
+      "summary": "Surfaced by the neighbourhood sweep for idx-27. The Mønster 3 \"Azure implementasjon\" list asserts a Copilot Studio \"Powered by AI\" disclosure in the chat interface - the same claim idx-27 removed from the Copilot Studio section, and false for the same reason: faqs-generative-orchestration documents a default transparency message (\"Just so you are aware, I sometimes use AI to answer your questions.\"), not a badge. Different section, outside idx-27's anchors, so booked separately rather than swept in. Repair is a replacement, outside the delete-only envelope. Note for whoever repairs this: after idx-27 the corrected wording already exists a few hundred lines below, so the repair is a copy of an already-ratified formulation rather than a fresh judgement.",
+      "evidence": "docs/r11-pilot-results.md §9.6; https://learn.microsoft.com/microsoft-copilot-studio/faqs-generative-orchestration",
+      "anchors": [
+        "- **Copilot Studio**: \"Powered by AI\" disclosure i chat interface"
+      ],
+      "resolution": "Operator-ratified 2026-08-03. The Moenster 3 \"Azure implementasjon\" bullet was replaced with exactly what the already-ratified row at the Copilot Studio section asserts: the standard transparency message \"Just so you are aware, I sometimes use AI to answer your questions.\" delivered in the chat interface. This is a copy of a formulation ratified earlier the same session (idx-27), not a fresh judgement, and the quote was grep-verified byte-for-byte against that row after the edit - hand-copying a verbatim string is where quote-style drift enters. Deliberately NOT carried over: any audience-tiering or layered-disclosure language from the surrounding Moenster 3 pattern. The bullet sits under an audience-layering table while the source row sits under \"Built-in disclosures\"; adding reach the source does not state is exactly the scope class caught in 66fb567, and this repair would have inherited it. Standing matches idx-27's addendum: the standard message is documented in both faqs-generative-orchestration and faqs-generative-answers (the latter with the broader \"best practice to communicate to users that the agent uses artificial intelligence\" framing), so it carries no scope qualifier - unlike the confirmation safeguard, which does. Cross-file grep before editing: \"Powered by AI\" occurred nowhere else in the corpus. Two neighbours were checked and deliberately NOT swept in - the Foundry agent-transparency bullet asserting a \"This chatbot uses AI\" embeddable component, and the scenario-1 tooling line naming a \"Copilot Studio disclosure widget\" where this file's own Copilot Studio section documents a pre-built \"AI disclosure\" topic in the generative AI toolkit, not a widget. Both are unverified product artefacts in other sections against other sources; they are booked as idx-27c and idx-27d rather than repaired here."
+    },
+    {
+      "id": "idx-26e",
+      "file": "skills/ms-ai-governance/references/responsible-ai/stakeholder-communication-ai-decisions.md",
+      "class": "replacement",
+      "status": "open",
+      "raised": "2026-08-03",
+      "summary": "Surfaced by the cross-file grep run before the idx-26d edit. This file carries a parallel five-member list describing the Responsible AI Scorecard under the heading \"Konfigurerbare elementer\", in the same paraphrase dialect idx-26d just removed from transparency-documentation-standards.md: Dataset-helse, Modell-ytelse, Target values, Fortolkningsevne, Fairness assessment. Two problems, and they are distinguishable. First, the names are paraphrases of the source's scorecard SEGMENTS (data analysis, model performance, top important factors, fairness insights), so the list is the same drift class as idx-26d. Second, and separately, the heading claims these are CONFIGURABLE elements; the source page enumerates seven scorecard segments and does not enumerate a set of configurable elements, so the framing itself is unsupported. The list sits under a *Confidence: Verified (MCP microsoft-learn)* stamp carrying no date. Booked, not folded into idx-26d: idx-26d's ratified scope was one list in one file, and this file was not re-verified against the live source this session.",
+      "evidence": "docs/r11-pilot-results.md §9.8; https://learn.microsoft.com/azure/machine-learning/how-to-responsible-ai-scorecard",
+      "anchors": [
+        "**Konfigurerbare elementer**:",
+        "- **Fortolkningsevne**: Global/lokal feature importance"
+      ]
+    },
+    {
+      "id": "idx-26f",
+      "file": "skills/ms-ai-governance/references/responsible-ai/transparency-documentation-standards.md",
+      "class": "replacement",
+      "status": "resolved",
+      "raised": "2026-08-03",
+      "summary": "Surfaced while writing idx-26d, and deliberately excluded from it. Items 2 and 5 of the scorecard enumeration carry specifics the live source does not state: the fairness insights segment is described with \"(gender, ethnicity, age)\" where the source says only \"your desired sensitive groups\", and the data analysis segment with \"missing values, outlier analysis\" where the source says only that it \"shows you characteristics of your data\". Neither is false on its face - both are plausible instances - but both sit under the **Confidence:** Verified (MCP: microsoft-learn, 2026-08-03) stamp, which now vouches for an enumeration re-verified against the live source. This is a distinct class from idx-26d's name drift and idx-26b's cross-attribution: unsourced SPECIFICITY under a verification marker, where the defect is the marker's reach rather than the sentence. idx-26d's resolution states explicitly that its widening of the stamp does not cover items 2, 4 and 5, so the stamp is currently honest only because that exclusion is written down - closing this entry is what would make it honest on its own terms. Item 4's description was checked in the same pass and is a recognisable paraphrase of the source, not added specificity, so it is named here as checked-and-clear rather than left ambiguous.",
+      "evidence": "docs/r11-pilot-results.md §9.8; https://learn.microsoft.com/azure/machine-learning/how-to-responsible-ai-scorecard",
+      "anchors": [
+        "2. **Fairness insights**: Performance disparities across sensitive groups (gender, ethnicity, age)",
+        "5. **Data analysis**: Dataset statistics, missing values, outlier analysis"
+      ],
+      "resolution": "Operator-ratified 2026-08-03, form (a): descriptions rewritten to the source's own wording, NOT surgical deletion of the named parentheticals. The source was re-fetched live before writing (how-to-responsible-ai-scorecard) and states only \"how well your model is satisfying the fairness target values you set for your desired sensitive groups\" and \"The data analysis segment shows you characteristics of your data\". Item 2 is now \"Hvor godt modellen moeter fairness-maalverdiene du har satt for de sensitive gruppene du velger\" and item 5 \"Karakteristikker ved dataene dine\" (both written with correct Norwegian diacritics in the corpus file). Deleting only the specificity this entry NAMED was rejected on two counts, each of which would have made the repair inherit the defect class it was raised against: it leaves item 5 as \"Dataset statistics\", which the source does not state either and which this entry did NOT adjudicate as checked-and-clear the way it did item 4; and it leaves item 2 as \"across sensitive groups\", dropping the you-choose-them agency and stranding item 2 in the pre-idx-26d dialect while items 1, 3, 6 and 7 carry \"du har satt\" - reopening the mixed-dialect defect idx-26d was booked under, in the file idx-26d had just canonicalised. Form (b) - narrowing the stamp's stated reach in the file instead - was put to the operator and declined: it is honest-by-annotation relocated from this queue's resolution field into the corpus, i.e. the same mechanism this entry exists to remove the need for. Item 4 was left untouched per this entry's own adjudication. Cross-file grep before editing: \"gender, ethnicity, age\", \"outlier analysis\" and \"Dataset statistics\" occurred nowhere else in the corpus. The enumeration was re-read whole after the edit for coherence, not just for the two edited strings. SUPERSEDES the closing clause of idx-26d's resolution: what the **Confidence:** Verified (MCP: microsoft-learn, 2026-08-03) stamp vouches for is now a seven-member enumeration whose names are all the source's own segment names, whose descriptions for items 2 and 5 were re-verified against the live source THIS session and whose descriptions for items 1, 3, 6 and 7 were verified against the live source under idx-26d earlier the same day - the same stamp date and the same page, but an inherited verification rather than one re-run here, stated separately so the artefact is honest about its own provenance, and whose item 4 description was adjudicated a recognisable paraphrase of the source's causal-insights passage. No exception is written down anywhere for the stamp to remain honest. POST-EDIT CORRECTION, same session: item 2 first landed as \"fairness-target values\", a hybrid compound that is neither language and that broke the very dialect consistency this repair was justified by - item 1 renders the same source concept as \"target-verdiene\". Corrected to \"fairness-maalverdiene\". The operator-ratified LABEL was \"kildens ordlyd i idx-26d-dialekten\"; the illustrative preview carried the defective form, and the label is the ratified object, so the correction needed no re-ratification. The coherence re-read after the first edit checked the enumeration for CONTENT alignment and passed it - it did not check compound forms, which is the axis that failed."
+    },
+    {
+      "id": "idx-27c",
+      "file": "skills/ms-ai-governance/references/responsible-ai/transparency-documentation-standards.md",
+      "class": "replacement",
+      "status": "open",
+      "raised": "2026-08-03",
+      "summary": "Surfaced by the neighbourhood sweep for idx-27b and deliberately excluded from it. The Microsoft Foundry \"Agent transparency\" list asserts \"Disclosure widgets: \\\"This chatbot uses AI\\\" embeddable component\" - a named product artefact carrying a verbatim-looking user-facing string. Same class as idx-27 and idx-27b (a plausible disclosure phrasing asserted as a built-in surface), but a different platform section against a different source, so it cannot be repaired by copying the ratified Copilot Studio formulation. Needs its own live fetch against Foundry documentation to establish whether an embeddable disclosure widget exists and, if so, what string it actually carries. Repair is a replacement, outside the delete-only envelope.",
+      "evidence": "docs/r11-pilot-results.md §9.10",
+      "anchors": [
+        "- Disclosure widgets: \"This chatbot uses AI\" embeddable component"
+      ]
+    },
+    {
+      "id": "idx-27d",
+      "file": "skills/ms-ai-governance/references/responsible-ai/transparency-documentation-standards.md",
+      "class": "replacement",
+      "status": "open",
+      "raised": "2026-08-03",
+      "summary": "Surfaced by the neighbourhood sweep for idx-27b and deliberately excluded from it. The scenario 1 tooling line names a \"Copilot Studio disclosure widget\", but this same file's Copilot Studio section documents a pre-built \"AI disclosure\" TOPIC in the generative AI toolkit - not a widget. This is intra-file name drift of the same shape as idx-26d, not a source-attribution error: the file contradicts itself about what the artefact is called. Note the context differs from idx-27/idx-27b - this line sits inside a worked scenario recommendation rather than a product-capability claim, so the repair should decide whether to name the toolkit topic or drop the artefact name, not merely restate a source. Repair is a replacement, outside the delete-only envelope.",
+      "evidence": "docs/r11-pilot-results.md §9.10",
+      "anchors": [
+        "**Tooling:** Azure OpenAI Transparency Note + Copilot Studio disclosure widget"
+      ]
+    }
+  ]
+}

scripts/kb-eval/data/judge-bakeoff-report-v2-g5bgold.json

@@ -0,0 +1,234 @@
+{
+  "_meta": {
+    "source": "gold-correctness-set.json + judge-bakeoff-results.json",
+    "thresholds": {
+      "minRecall": 0.7,
+      "minPrecision": 0.6
+    },
+    "judged": 255
+  },
+  "population": {
+    "total": 255,
+    "verifiable": 240,
+    "positives": 42,
+    "negatives": 198,
+    "unsourcedInP": 15
+  },
+  "arms": {
+    "staleness": {
+      "tp": 0,
+      "fp": 0,
+      "fn": 42,
+      "tn": 198,
+      "positives": 42,
+      "negatives": 198,
+      "flagged": 0,
+      "precision": null,
+      "recall": 0,
+      "f1": null,
+      "recallWilson": {
+        "p": 0,
+        "low": 0,
+        "high": 0.08380161250916199
+      },
+      "precisionWilson": null
+    },
+    "judge": {
+      "tp": 33,
+      "fp": 5,
+      "fn": 9,
+      "tn": 193,
+      "positives": 42,
+      "negatives": 198,
+      "flagged": 38,
+      "precision": 0.868421052631579,
+      "recall": 0.7857142857142857,
+      "f1": 0.825,
+      "recallWilson": {
+        "p": 0.7857142857142857,
+        "low": 0.6405986210195627,
+        "high": 0.8829433146894876
+      },
+      "precisionWilson": {
+        "p": 0.868421052631579,
+        "low": 0.7267282994850112,
+        "high": 0.9424621712426856
+      }
+    },
+    "hybrid": {
+      "tp": 33,
+      "fp": 5,
+      "fn": 9,
+      "tn": 193,
+      "positives": 42,
+      "negatives": 198,
+      "flagged": 38,
+      "precision": 0.868421052631579,
+      "recall": 0.7857142857142857,
+      "f1": 0.825,
+      "recallWilson": {
+        "p": 0.7857142857142857,
+        "low": 0.6405986210195627,
+        "high": 0.8829433146894876
+      },
+      "precisionWilson": {
+        "p": 0.868421052631579,
+        "low": 0.7267282994850112,
+        "high": 0.9424621712426856
+      }
+    }
+  },
+  "sourceSilent": {
+    "onVerifiableNegative": 1,
+    "onVerifiableError": 4,
+    "agreesWithUnsourced": 5,
+    "disagreesWithUnsourced": 10
+  },
+  "byClaimType": {
+    "version": {
+      "tp": 6,
+      "fp": 0,
+      "fn": 1,
+      "tn": 21,
+      "positives": 7,
+      "negatives": 21,
+      "flagged": 6,
+      "precision": 1,
+      "recall": 0.8571428571428571,
+      "f1": 0.923076923076923,
+      "recallWilson": {
+        "p": 0.8571428571428571,
+        "low": 0.4868654966809701,
+        "high": 0.9743210440510252
+      },
+      "precisionWilson": {
+        "p": 1,
+        "low": 0.6096569663469354,
+        "high": 0.9999999999999999
+      }
+    },
+    "tpm": {
+      "tp": 4,
+      "fp": 0,
+      "fn": 1,
+      "tn": 20,
+      "positives": 5,
+      "negatives": 20,
+      "flagged": 4,
+      "precision": 1,
+      "recall": 0.8,
+      "f1": 0.888888888888889,
+      "recallWilson": {
+        "p": 0.8,
+        "low": 0.3755282641185388,
+        "high": 0.9637768390302125
+      },
+      "precisionWilson": {
+        "p": 1,
+        "low": 0.5100999795960008,
+        "high": 1
+      }
+    },
+    "region": {
+      "tp": 1,
+      "fp": 0,
+      "fn": 1,
+      "tn": 13,
+      "positives": 2,
+      "negatives": 13,
+      "flagged": 1,
+      "precision": 1,
+      "recall": 0.5,
+      "f1": 0.6666666666666666,
+      "recallWilson": {
+        "p": 0.5,
+        "low": 0.09452865480086614,
+        "high": 0.9054713451991339
+      },
+      "precisionWilson": {
+        "p": 1,
+        "low": 0.2065432914738929,
+        "high": 1
+      }
+    },
+    "status": {
+      "tp": 6,
+      "fp": 1,
+      "fn": 4,
+      "tn": 42,
+      "positives": 10,
+      "negatives": 43,
+      "flagged": 7,
+      "precision": 0.8571428571428571,
+      "recall": 0.6,
+      "f1": 0.7058823529411764,
+      "recallWilson": {
+        "p": 0.6,
+        "low": 0.3126695474501863,
+        "high": 0.8318224187964902
+      },
+      "precisionWilson": {
+        "p": 0.8571428571428571,
+        "low": 0.4868654966809701,
+        "high": 0.9743210440510252
+      }
+    },
+    "taxonomy": {
+      "tp": 11,
+      "fp": 3,
+      "fn": 0,
+      "tn": 83,
+      "positives": 11,
+      "negatives": 86,
+      "flagged": 14,
+      "precision": 0.7857142857142857,
+      "recall": 1,
+      "f1": 0.88,
+      "recallWilson": {
+        "p": 1,
+        "low": 0.7411599827511859,
+        "high": 1
+      },
+      "precisionWilson": {
+        "p": 0.7857142857142857,
+        "low": 0.5241027622679172,
+        "high": 0.9242875166308363
+      }
+    },
+    "sku": {
+      "tp": 5,
+      "fp": 1,
+      "fn": 2,
+      "tn": 14,
+      "positives": 7,
+      "negatives": 15,
+      "flagged": 6,
+      "precision": 0.8333333333333334,
+      "recall": 0.7142857142857143,
+      "f1": 0.7692307692307692,
+      "recallWilson": {
+        "p": 0.7142857142857143,
+        "low": 0.35892909014821267,
+        "high": 0.9177828342909844
+      },
+      "precisionWilson": {
+        "p": 0.8333333333333334,
+        "low": 0.43649056343635395,
+        "high": 0.9699474141282697
+      }
+    }
+  },
+  "gate": {
+    "pass": true,
+    "recallOk": true,
+    "precisionOk": true,
+    "beatsStaleness": true,
+    "thresholds": {
+      "minRecall": 0.7,
+      "minPrecision": 0.6
+    },
+    "reasons": [
+      "all criteria met"
+    ]
+  }
+}

scripts/kb-eval/data/judge-bakeoff-report-v2-g5bgold.md

@@ -0,0 +1,54 @@
+# Judge bake-off-rapport — S1 (Fase 3 de-risk)
+
+_Generert deterministisk av `run-judge-bakeoff.mjs` over `gold-correctness-set.json` + `judge-bakeoff-results.json`. Tall fra testet `lib/judge-bakeoff.mjs`. Ikke rediger for hånd — regenerer._
+
+**Forhåndsregistrert gate (låst FØR fan-out):** recall ≥ 0.7, presisjon ≥ 0.6, OG judge-recall > staleness-recall.
+
+## Evaluerings-populasjon (P)
+
+Volatil stratum + fetchbare claim_types (price ekskludert) — der feilene bor; unngår «invertert leverage».
+
+| metrikk | verdi |
+|---|---|
+| P totalt | 255 |
+| Verifiserbare (correct/outdated/wrong) | 240 |
+| Positive (reelle feil å fange) | 42 |
+| Negative (correct) | 198 |
+| Unsourced i P (kjørt, men utenfor P/R) | 15 |
+
+## Arm-sammenligning (detektering over de 240 verifiserbare)
+
+| arm | TP | FP | FN | TN | presisjon | recall | recall Wilson 95% | F1 |
+|---|---|---|---|---|---|---|---|---|
+| staleness (billig baseline) | 0 | 0 | 42 | 198 | n/a | 0.0% | [0.0%, 8.4%] | n/a |
+| judge (per-påstand groundedness) | 33 | 5 | 9 | 193 | 86.8% | 78.6% | [64.1%, 88.3%] | 0.825 |
+| hybrid (union) | 33 | 5 | 9 | 193 | 86.8% | 78.6% | [64.1%, 88.3%] | 0.825 |
+
+## Judge per claim_type (verifiserbar delmengde)
+
+| claim_type | positive | TP | FP | FN | presisjon | recall |
+|---|---|---|---|---|---|---|
+| taxonomy | 11 | 11 | 3 | 0 | 78.6% | 100.0% |
+| status | 10 | 6 | 1 | 4 | 85.7% | 60.0% |
+| version | 7 | 6 | 0 | 1 | 100.0% | 85.7% |
+| sku | 7 | 5 | 1 | 2 | 83.3% | 71.4% |
+| tpm | 5 | 4 | 0 | 1 | 100.0% | 80.0% |
+| region | 2 | 1 | 0 | 1 | 100.0% | 50.0% |
+
+## source_silent-diagnostikk
+
+Judgen hentet siden men fant ikke verdien. Diagnostisk, ikke et flagg.
+
+| signal | antall | tolkning |
+|---|---|---|
+| På verifiserbar feil | 4 | judge-bom: reell feil oversett via «kan ikke verifisere» |
+| På verifiserbar correct | 1 | judge reproduserte ikke et korrekt faktum mennesket fant |
+| Enig med unsourced | 5 | judge reproduserer den uverifiserbare grensen (godt) |
+| Uenig med unsourced | 10 | judge hevdet grunnet/ugrunnet der mennesket ikke fant kilde |
+
+## GATE: ✅ PASS — bygg S3
+
+- recall 0.786 ≥ 0.7? **ja**
+- presisjon 0.868 ≥ 0.6? **ja**
+- slår staleness (recall 0.000)? **ja**
+- begrunnelse: all criteria met

scripts/kb-eval/data/judge-bakeoff-report-v2-g5gold.json

@@ -0,0 +1,234 @@
+{
+  "_meta": {
+    "source": "gold-correctness-set.json + judge-bakeoff-results.json",
+    "thresholds": {
+      "minRecall": 0.7,
+      "minPrecision": 0.6
+    },
+    "judged": 255
+  },
+  "population": {
+    "total": 255,
+    "verifiable": 240,
+    "positives": 38,
+    "negatives": 202,
+    "unsourcedInP": 15
+  },
+  "arms": {
+    "staleness": {
+      "tp": 0,
+      "fp": 0,
+      "fn": 38,
+      "tn": 202,
+      "positives": 38,
+      "negatives": 202,
+      "flagged": 0,
+      "precision": null,
+      "recall": 0,
+      "f1": null,
+      "recallWilson": {
+        "p": 0,
+        "low": 0,
+        "high": 0.09181293258383999
+      },
+      "precisionWilson": null
+    },
+    "judge": {
+      "tp": 33,
+      "fp": 5,
+      "fn": 5,
+      "tn": 197,
+      "positives": 38,
+      "negatives": 202,
+      "flagged": 38,
+      "precision": 0.868421052631579,
+      "recall": 0.868421052631579,
+      "f1": 0.868421052631579,
+      "recallWilson": {
+        "p": 0.868421052631579,
+        "low": 0.7267282994850112,
+        "high": 0.9424621712426856
+      },
+      "precisionWilson": {
+        "p": 0.868421052631579,
+        "low": 0.7267282994850112,
+        "high": 0.9424621712426856
+      }
+    },
+    "hybrid": {
+      "tp": 33,
+      "fp": 5,
+      "fn": 5,
+      "tn": 197,
+      "positives": 38,
+      "negatives": 202,
+      "flagged": 38,
+      "precision": 0.868421052631579,
+      "recall": 0.868421052631579,
+      "f1": 0.868421052631579,
+      "recallWilson": {
+        "p": 0.868421052631579,
+        "low": 0.7267282994850112,
+        "high": 0.9424621712426856
+      },
+      "precisionWilson": {
+        "p": 0.868421052631579,
+        "low": 0.7267282994850112,
+        "high": 0.9424621712426856
+      }
+    }
+  },
+  "sourceSilent": {
+    "onVerifiableNegative": 3,
+    "onVerifiableError": 2,
+    "agreesWithUnsourced": 5,
+    "disagreesWithUnsourced": 10
+  },
+  "byClaimType": {
+    "version": {
+      "tp": 6,
+      "fp": 0,
+      "fn": 1,
+      "tn": 21,
+      "positives": 7,
+      "negatives": 21,
+      "flagged": 6,
+      "precision": 1,
+      "recall": 0.8571428571428571,
+      "f1": 0.923076923076923,
+      "recallWilson": {
+        "p": 0.8571428571428571,
+        "low": 0.4868654966809701,
+        "high": 0.9743210440510252
+      },
+      "precisionWilson": {
+        "p": 1,
+        "low": 0.6096569663469354,
+        "high": 0.9999999999999999
+      }
+    },
+    "tpm": {
+      "tp": 4,
+      "fp": 0,
+      "fn": 1,
+      "tn": 20,
+      "positives": 5,
+      "negatives": 20,
+      "flagged": 4,
+      "precision": 1,
+      "recall": 0.8,
+      "f1": 0.888888888888889,
+      "recallWilson": {
+        "p": 0.8,
+        "low": 0.3755282641185388,
+        "high": 0.9637768390302125
+      },
+      "precisionWilson": {
+        "p": 1,
+        "low": 0.5100999795960008,
+        "high": 1
+      }
+    },
+    "region": {
+      "tp": 1,
+      "fp": 0,
+      "fn": 0,
+      "tn": 14,
+      "positives": 1,
+      "negatives": 14,
+      "flagged": 1,
+      "precision": 1,
+      "recall": 1,
+      "f1": 1,
+      "recallWilson": {
+        "p": 1,
+        "low": 0.2065432914738929,
+        "high": 1
+      },
+      "precisionWilson": {
+        "p": 1,
+        "low": 0.2065432914738929,
+        "high": 1
+      }
+    },
+    "status": {
+      "tp": 6,
+      "fp": 1,
+      "fn": 1,
+      "tn": 45,
+      "positives": 7,
+      "negatives": 46,
+      "flagged": 7,
+      "precision": 0.8571428571428571,
+      "recall": 0.8571428571428571,
+      "f1": 0.8571428571428571,
+      "recallWilson": {
+        "p": 0.8571428571428571,
+        "low": 0.4868654966809701,
+        "high": 0.9743210440510252
+      },
+      "precisionWilson": {
+        "p": 0.8571428571428571,
+        "low": 0.4868654966809701,
+        "high": 0.9743210440510252
+      }
+    },
+    "taxonomy": {
+      "tp": 11,
+      "fp": 3,
+      "fn": 0,
+      "tn": 83,
+      "positives": 11,
+      "negatives": 86,
+      "flagged": 14,
+      "precision": 0.7857142857142857,
+      "recall": 1,
+      "f1": 0.88,
+      "recallWilson": {
+        "p": 1,
+        "low": 0.7411599827511859,
+        "high": 1
+      },
+      "precisionWilson": {
+        "p": 0.7857142857142857,
+        "low": 0.5241027622679172,
+        "high": 0.9242875166308363
+      }
+    },
+    "sku": {
+      "tp": 5,
+      "fp": 1,
+      "fn": 2,
+      "tn": 14,
+      "positives": 7,
+      "negatives": 15,
+      "flagged": 6,
+      "precision": 0.8333333333333334,
+      "recall": 0.7142857142857143,
+      "f1": 0.7692307692307692,
+      "recallWilson": {
+        "p": 0.7142857142857143,
+        "low": 0.35892909014821267,
+        "high": 0.9177828342909844
+      },
+      "precisionWilson": {
+        "p": 0.8333333333333334,
+        "low": 0.43649056343635395,
+        "high": 0.9699474141282697
+      }
+    }
+  },
+  "gate": {
+    "pass": true,
+    "recallOk": true,
+    "precisionOk": true,
+    "beatsStaleness": true,
+    "thresholds": {
+      "minRecall": 0.7,
+      "minPrecision": 0.6
+    },
+    "reasons": [
+      "all criteria met"
+    ]
+  }
+}

scripts/kb-eval/data/judge-bakeoff-report-v2-g5gold.md

@@ -0,0 +1,54 @@
+# Judge bake-off-rapport — S1 (Fase 3 de-risk)
+
+_Generert deterministisk av `run-judge-bakeoff.mjs` over `gold-correctness-set.json` + `judge-bakeoff-results.json`. Tall fra testet `lib/judge-bakeoff.mjs`. Ikke rediger for hånd — regenerer._
+
+**Forhåndsregistrert gate (låst FØR fan-out):** recall ≥ 0.7, presisjon ≥ 0.6, OG judge-recall > staleness-recall.
+
+## Evaluerings-populasjon (P)
+
+Volatil stratum + fetchbare claim_types (price ekskludert) — der feilene bor; unngår «invertert leverage».
+
+| metrikk | verdi |
+|---|---|
+| P totalt | 255 |
+| Verifiserbare (correct/outdated/wrong) | 240 |
+| Positive (reelle feil å fange) | 38 |
+| Negative (correct) | 202 |
+| Unsourced i P (kjørt, men utenfor P/R) | 15 |
+
+## Arm-sammenligning (detektering over de 240 verifiserbare)
+
+| arm | TP | FP | FN | TN | presisjon | recall | recall Wilson 95% | F1 |
+|---|---|---|---|---|---|---|---|---|
+| staleness (billig baseline) | 0 | 0 | 38 | 202 | n/a | 0.0% | [0.0%, 9.2%] | n/a |
+| judge (per-påstand groundedness) | 33 | 5 | 5 | 197 | 86.8% | 86.8% | [72.7%, 94.2%] | 0.868 |
+| hybrid (union) | 33 | 5 | 5 | 197 | 86.8% | 86.8% | [72.7%, 94.2%] | 0.868 |
+
+## Judge per claim_type (verifiserbar delmengde)
+
+| claim_type | positive | TP | FP | FN | presisjon | recall |
+|---|---|---|---|---|---|---|
+| taxonomy | 11 | 11 | 3 | 0 | 78.6% | 100.0% |
+| version | 7 | 6 | 0 | 1 | 100.0% | 85.7% |
+| status | 7 | 6 | 1 | 1 | 85.7% | 85.7% |
+| sku | 7 | 5 | 1 | 2 | 83.3% | 71.4% |
+| tpm | 5 | 4 | 0 | 1 | 100.0% | 80.0% |
+| region | 1 | 1 | 0 | 0 | 100.0% | 100.0% |
+
+## source_silent-diagnostikk
+
+Judgen hentet siden men fant ikke verdien. Diagnostisk, ikke et flagg.
+
+| signal | antall | tolkning |
+|---|---|---|
+| På verifiserbar feil | 2 | judge-bom: reell feil oversett via «kan ikke verifisere» |
+| På verifiserbar correct | 3 | judge reproduserte ikke et korrekt faktum mennesket fant |
+| Enig med unsourced | 5 | judge reproduserer den uverifiserbare grensen (godt) |
+| Uenig med unsourced | 10 | judge hevdet grunnet/ugrunnet der mennesket ikke fant kilde |
+
+## GATE: ✅ PASS — bygg S3
+
+- recall 0.868 ≥ 0.7? **ja**
+- presisjon 0.868 ≥ 0.6? **ja**
+- slår staleness (recall 0.000)? **ja**
+- begrunnelse: all criteria met

scripts/kb-eval/data/judge-bakeoff-report-v2-reconciled.json

@@ -0,0 +1,234 @@
+{
+  "_meta": {
+    "source": "gold-correctness-set.json + judge-bakeoff-results.json",
+    "thresholds": {
+      "minRecall": 0.8,
+      "minPrecision": 0.7
+    },
+    "judged": 255
+  },
+  "population": {
+    "total": 255,
+    "verifiable": 240,
+    "positives": 40,
+    "negatives": 200,
+    "unsourcedInP": 15
+  },
+  "arms": {
+    "staleness": {
+      "tp": 0,
+      "fp": 0,
+      "fn": 40,
+      "tn": 200,
+      "positives": 40,
+      "negatives": 200,
+      "flagged": 0,
+      "precision": null,
+      "recall": 0,
+      "f1": null,
+      "recallWilson": {
+        "p": 0,
+        "low": 0,
+        "high": 0.08762453925039232
+      },
+      "precisionWilson": null
+    },
+    "judge": {
+      "tp": 35,
+      "fp": 3,
+      "fn": 5,
+      "tn": 197,
+      "positives": 40,
+      "negatives": 200,
+      "flagged": 38,
+      "precision": 0.9210526315789473,
+      "recall": 0.875,
+      "f1": 0.8974358974358975,
+      "recallWilson": {
+        "p": 0.875,
+        "low": 0.7388757932976187,
+        "high": 0.9454058022645873
+      },
+      "precisionWilson": {
+        "p": 0.9210526315789473,
+        "low": 0.792003210797347,
+        "high": 0.972785898605735
+      }
+    },
+    "hybrid": {
+      "tp": 35,
+      "fp": 3,
+      "fn": 5,
+      "tn": 197,
+      "positives": 40,
+      "negatives": 200,
+      "flagged": 38,
+      "precision": 0.9210526315789473,
+      "recall": 0.875,
+      "f1": 0.8974358974358975,
+      "recallWilson": {
+        "p": 0.875,
+        "low": 0.7388757932976187,
+        "high": 0.9454058022645873
+      },
+      "precisionWilson": {
+        "p": 0.9210526315789473,
+        "low": 0.792003210797347,
+        "high": 0.972785898605735
+      }
+    }
+  },
+  "sourceSilent": {
+    "onVerifiableNegative": 3,
+    "onVerifiableError": 2,
+    "agreesWithUnsourced": 5,
+    "disagreesWithUnsourced": 10
+  },
+  "byClaimType": {
+    "version": {
+      "tp": 6,
+      "fp": 0,
+      "fn": 1,
+      "tn": 21,
+      "positives": 7,
+      "negatives": 21,
+      "flagged": 6,
+      "precision": 1,
+      "recall": 0.8571428571428571,
+      "f1": 0.923076923076923,
+      "recallWilson": {
+        "p": 0.8571428571428571,
+        "low": 0.4868654966809701,
+        "high": 0.9743210440510252
+      },
+      "precisionWilson": {
+        "p": 1,
+        "low": 0.6096569663469354,
+        "high": 0.9999999999999999
+      }
+    },
+    "tpm": {
+      "tp": 4,
+      "fp": 0,
+      "fn": 1,
+      "tn": 20,
+      "positives": 5,
+      "negatives": 20,
+      "flagged": 4,
+      "precision": 1,
+      "recall": 0.8,
+      "f1": 0.888888888888889,
+      "recallWilson": {
+        "p": 0.8,
+        "low": 0.3755282641185388,
+        "high": 0.9637768390302125
+      },
+      "precisionWilson": {
+        "p": 1,
+        "low": 0.5100999795960008,
+        "high": 1
+      }
+    },
+    "region": {
+      "tp": 1,
+      "fp": 0,
+      "fn": 0,
+      "tn": 14,
+      "positives": 1,
+      "negatives": 14,
+      "flagged": 1,
+      "precision": 1,
+      "recall": 1,
+      "f1": 1,
+      "recallWilson": {
+        "p": 1,
+        "low": 0.2065432914738929,
+        "high": 1
+      },
+      "precisionWilson": {
+        "p": 1,
+        "low": 0.2065432914738929,
+        "high": 1
+      }
+    },
+    "status": {
+      "tp": 7,
+      "fp": 0,
+      "fn": 1,
+      "tn": 45,
+      "positives": 8,
+      "negatives": 45,
+      "flagged": 7,
+      "precision": 1,
+      "recall": 0.875,
+      "f1": 0.9333333333333333,
+      "recallWilson": {
+        "p": 0.875,
+        "low": 0.5291051942301386,
+        "high": 0.9775830911367038
+      },
+      "precisionWilson": {
+        "p": 1,
+        "low": 0.6456611570247934,
+        "high": 1
+      }
+    },
+    "taxonomy": {
+      "tp": 11,
+      "fp": 3,
+      "fn": 0,
+      "tn": 83,
+      "positives": 11,
+      "negatives": 86,
+      "flagged": 14,
+      "precision": 0.7857142857142857,
+      "recall": 1,
+      "f1": 0.88,
+      "recallWilson": {
+        "p": 1,
+        "low": 0.7411599827511859,
+        "high": 1
+      },
+      "precisionWilson": {
+        "p": 0.7857142857142857,
+        "low": 0.5241027622679172,
+        "high": 0.9242875166308363
+      }
+    },
+    "sku": {
+      "tp": 6,
+      "fp": 0,
+      "fn": 2,
+      "tn": 14,
+      "positives": 8,
+      "negatives": 14,
+      "flagged": 6,
+      "precision": 1,
+      "recall": 0.75,
+      "f1": 0.8571428571428571,
+      "recallWilson": {
+        "p": 0.75,
+        "low": 0.40926987910258916,
+        "high": 0.9285223111419724
+      },
+      "precisionWilson": {
+        "p": 1,
+        "low": 0.6096569663469354,
+        "high": 0.9999999999999999
+      }
+    }
+  },
+  "gate": {
+    "pass": true,
+    "recallOk": true,
+    "precisionOk": true,
+    "beatsStaleness": true,
+    "thresholds": {
+      "minRecall": 0.8,
+      "minPrecision": 0.7
+    },
+    "reasons": [
+      "all criteria met"
+    ]
+  }
+}

scripts/kb-eval/data/judge-bakeoff-report-v2-reconciled.md

@@ -0,0 +1,54 @@
+# Judge bake-off-rapport — S1 (Fase 3 de-risk)
+
+_Generert deterministisk av `run-judge-bakeoff.mjs` over `gold-correctness-set.json` + `judge-bakeoff-results.json`. Tall fra testet `lib/judge-bakeoff.mjs`. Ikke rediger for hånd — regenerer._
+
+**Forhåndsregistrert gate (låst FØR fan-out):** recall ≥ 0.8, presisjon ≥ 0.7, OG judge-recall > staleness-recall.
+
+## Evaluerings-populasjon (P)
+
+Volatil stratum + fetchbare claim_types (price ekskludert) — der feilene bor; unngår «invertert leverage».
+
+| metrikk | verdi |
+|---|---|
+| P totalt | 255 |
+| Verifiserbare (correct/outdated/wrong) | 240 |
+| Positive (reelle feil å fange) | 40 |
+| Negative (correct) | 200 |
+| Unsourced i P (kjørt, men utenfor P/R) | 15 |
+
+## Arm-sammenligning (detektering over de 240 verifiserbare)
+
+| arm | TP | FP | FN | TN | presisjon | recall | recall Wilson 95% | F1 |
+|---|---|---|---|---|---|---|---|---|
+| staleness (billig baseline) | 0 | 0 | 40 | 200 | n/a | 0.0% | [0.0%, 8.8%] | n/a |
+| judge (per-påstand groundedness) | 35 | 3 | 5 | 197 | 92.1% | 87.5% | [73.9%, 94.5%] | 0.897 |
+| hybrid (union) | 35 | 3 | 5 | 197 | 92.1% | 87.5% | [73.9%, 94.5%] | 0.897 |
+
+## Judge per claim_type (verifiserbar delmengde)
+
+| claim_type | positive | TP | FP | FN | presisjon | recall |
+|---|---|---|---|---|---|---|
+| taxonomy | 11 | 11 | 3 | 0 | 78.6% | 100.0% |
+| status | 8 | 7 | 0 | 1 | 100.0% | 87.5% |
+| sku | 8 | 6 | 0 | 2 | 100.0% | 75.0% |
+| version | 7 | 6 | 0 | 1 | 100.0% | 85.7% |
+| tpm | 5 | 4 | 0 | 1 | 100.0% | 80.0% |
+| region | 1 | 1 | 0 | 0 | 100.0% | 100.0% |
+
+## source_silent-diagnostikk
+
+Judgen hentet siden men fant ikke verdien. Diagnostisk, ikke et flagg.
+
+| signal | antall | tolkning |
+|---|---|---|
+| På verifiserbar feil | 2 | judge-bom: reell feil oversett via «kan ikke verifisere» |
+| På verifiserbar correct | 3 | judge reproduserte ikke et korrekt faktum mennesket fant |
+| Enig med unsourced | 5 | judge reproduserer den uverifiserbare grensen (godt) |
+| Uenig med unsourced | 10 | judge hevdet grunnet/ugrunnet der mennesket ikke fant kilde |
+
+## GATE: ✅ PASS — bygg S3
+
+- recall 0.875 ≥ 0.8? **ja**
+- presisjon 0.921 ≥ 0.7? **ja**
+- slår staleness (recall 0.000)? **ja**
+- begrunnelse: all criteria met