chore(release): bump v1.18.2 [skip-docs]

Version 1.18.2 in plugin.json, the README badge and SECURITY.md, with the changelog entry: screenshots regenerated from the current demo, older sets removed, manifest gate added. Not tagged.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "ms-ai-architect",
-  "version": "1.18.0",
+  "version": "1.18.2",
   "description": "Microsoft AI Solution Architect - structured architecture guidance for the full Microsoft AI stack",
   "author": {
     "name": "Kjell Tore Guttormsen"

.gitignore

@@ -26,12 +26,16 @@ org/
 # 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.
+# human-reviewed per entry, must survive a fresh clone) and the ratified R13 Cosmo
+# persona-gate baseline (the reference numbers check-cosmo-gate.mjs compares against —
+# a gate whose baseline is regenerated locally proves nothing) 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
+!scripts/kb-update/data/cosmo-gate-baseline.json
+!scripts/kb-update/data/cosmo-labels-baseline.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

CHANGELOG.md

@@ -7,6 +7,32 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [1.18.2] - 2026-09-23
+
+### Changed
+- Regenerated the playground screenshots from the current demo: 24 PNGs (12 surfaces × 2 themes) in `playground/screenshots/v1.15.0/`, including the dark onboarding view removed in 1.18.1. The README gallery, `docs/playground.md` and `tests/screenshot/README.md` describe this set.
+- `tests/screenshot/run.mjs` clears PNGs a previous run left behind and writes `playground/screenshots/MANIFEST.json` (sha256 per PNG and of the demo state rendered).
+- Aligned the demo project description with its reports (a housing-allowance chatbot, not building permits) and set six demo fixtures equal to the corrected AI Act deadlines already shown in the demo; `tests/kb-update/test-demo-project-description.test.mjs` keeps the demo block equal to its fixtures.
+
+### Removed
+- The v1.10.0, v1.11.0, v1.14.0 and v2-mockup screenshot sets (77 PNGs), which showed an earlier demo, and `tests/screenshot/shoot-mockup.local.mjs`, whose input file is not in the repository.
+
+### Added
+- `tests/kb-update/test-screenshots-manifest.test.mjs`: fails when a PNG in the tree is not output of the latest screenshot run, a PNG changed, the demo state changed after the run, or a doc points at another screenshot directory.
+
+## [1.18.1] - 2026-09-23
+
+### Changed
+- Replaced sector-specific example material with generic, fictitious examples in reference files, test fixtures, the playground and one design document. Legal text is unchanged, and so are test semantics.
+- The playground demo project (17 fixtures and the embedded demo state) now tells one consistent story: a municipal customer chatbot that pre-screens housing-benefit applications.
+- Cosmo persona removed from the reference corpus (R13, R13b) and from the plugin surface: skills, commands, README, CLAUDE.md and NOTICE (R14). `check-cosmo-gate.mjs` gained a G4 clause for the plugin surface; persona count in the corpus and on the plugin surface is 0.
+
+### Removed
+- Four screenshots (`01-onboarding-empty-dark.png` in the v1.10.0, v1.11.0, v1.14.0 and v1.15.0 sets) that showed outdated placeholder text.
+
+### Added
+- `tests/kb-update/test-excluded-terms.test.mjs`: a gate that fails when a tracked text file contains a term from a local-only list kept by the maintainer. Without the list the gate is skipped.
+
 ## [1.18.0] - 2026-09-12
 
 **Korrekthetsprogrammet gikk fra dormant mekanisme til utført måling.** v1.17.0 la substratet (Spor 1 — reference-kontrakten påført korpuset); denne utgivelsen *kjørte* mekanismen: hele korpus-dømmepasset (R7.1–R7.5) er utført over alle 243 aldri-verifiserte reference-filer, og flag→fiks-loopen (R11) er i eksekvering på flaggene det produserte. Sideløpende injiserte en uavhengig kryssmodell-review (2026-07-09, 7 BLOCKER / 15 MAJOR) RX-serien, som avdekket at pluginen lastet kunnskapsbasen feil i **installert** modus — relative KB-stier resolverer kun i dev-modus, så subagentene mistet KB-lasten når pluginen ble installert fra katalogen. Det er den ene endringen i denne utgivelsen som var synlig for en bruker uten å lese ledgeren.

CLAUDE.md

@@ -19,7 +19,7 @@ Tilbyr strukturert arkitekturveiledning for Microsoft AI-stakken:
 
 | Kommando | Beskrivelse |
 |----------|-------------|
-| `/architect` | Start en strukturert arkitekturrådgivning med Cosmo Skyberg |
+| `/architect` | Start en strukturert arkitekturrådgivning |
 | `/architect:help` | Vis oversikt over alle kommandoer, agenter og kunnskapsbaser |
 | `/architect:compare` | Sammenlign Microsoft AI-plattformer for et gitt scenario |
 | `/architect:security` | Sikkerhets- og compliance-vurdering (6 dimensjoner) |
@@ -70,7 +70,7 @@ Tilbyr strukturert arkitekturveiledning for Microsoft AI-stakken:
 
 | Skill | Formål | Referansefiler | BrukerIntent |
 |-------|--------|----------------|--------------|
-| `ms-ai-advisor` | Cosmo Skyberg-persona, 7-fase arbeidsflyt, plattformvalg | 62 | "Hjelp meg velge" |
+| `ms-ai-advisor` | 7-fase arbeidsflyt, plattformvalg | 62 | "Hjelp meg velge" |
 | `ms-ai-governance` | Norsk offentlig sektor-styring, EU-regelverk, ansvarlig AI | 78 | "Er dette lovlig?" |
 | `ms-ai-security` | Sikkerhetsscoring (6x5), kostnadsestimering (P10/P50/P90) | 62 | "Er dette trygt?" |
 | `ms-ai-engineering` | RAG, agenter, Azure AI Services, data, MLOps, multimodal | 153 | "Hvordan bygger jeg dette?" |

NOTICE.md

@@ -28,7 +28,7 @@ Code samples derived from Microsoft Learn documentation are used under the [MIT
 The following content is original work and not derived from Microsoft Learn:
 
 - Plugin architecture (commands, agents, hooks, orchestrator)
-- The "Cosmo Skyberg" architect persona and decision methodology
+- The architect advisory workflow and decision methodology
 - Diagram prompt templates (`architecture/diagram-prompt-templates.md`)
 - Decision trees and synthesis across multiple platform domains
 - Norwegian public sector governance analysis

README.md

@@ -2,19 +2,19 @@
 
 Microsoft AI Solution Architect — structured architecture guidance for the full Microsoft AI stack.
 
-> Your virtual Microsoft AI solution architect — meet **Cosmo Skyberg**.
+> Your virtual Microsoft AI solution architect.
 
 > **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](https://git.fromaitochitta.com/open/repo-standard/src/branch/main/GOVERNANCE.md) for the full model and what upstream provides.
 
 *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.18.0-blue)
+![Version](https://img.shields.io/badge/version-1.18.2-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)
 ![License](https://img.shields.io/badge/license-MIT-lightgrey)
 
-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.
+A Claude Code plugin that provides structured architecture guidance across the full Microsoft AI stack. It is methodical and opinionated: it 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
 
@@ -67,9 +67,9 @@ Or enable directly in `~/.claude/settings.json`:
 
 ## What Is This?
 
-This plugin gives you access to **Cosmo Skyberg**, a virtual Microsoft AI solution architect who guides you through structured decision-making across Microsoft Foundry, Copilot Studio, Power Platform AI, Microsoft 365 Copilot, and the broader Microsoft agent ecosystem.
+This plugin gives you a **virtual Microsoft AI solution architect** that guides you through structured decision-making across Microsoft Foundry, Copilot Studio, Power Platform AI, Microsoft 365 Copilot, and the broader Microsoft agent ecosystem.
 
-Unlike a chatbot that answers questions, Cosmo follows a **7-phase advisory methodology**: understand the business need, map the technical context, assess team capability, validate against live documentation, integrate domain knowledge from 380 reference documents, deliver a concrete architecture recommendation, and optionally visualize it.
+Unlike a chatbot that answers questions, it follows a **7-phase advisory methodology**: understand the business need, map the technical context, assess team capability, validate against live documentation, integrate domain knowledge from 380 reference documents, deliver a concrete architecture recommendation, and optionally visualize it.
 
 Key capabilities:
 
@@ -106,13 +106,13 @@ What this plugin deliberately does not do — worth knowing before you adopt it:
 ```
 > /architect
 
-Hei! Jeg er Cosmo Skyberg, løsningsarkitekt for Microsoft AI-økosystemet.
+Hei! Jeg er løsningsarkitekt for Microsoft AI-økosystemet.
 
 For å gi deg en god anbefaling, trenger jeg å forstå situasjonen din.
 Kan du beskrive forretningsproblemet eller behovet dere ønsker å løse?
 ```
 
-Cosmo will ask clarifying questions about your business need, licenses, data sources, and team capability before making any recommendations. Every recommendation is grounded in the 380-document knowledge base and verified against live Microsoft Learn documentation.
+It will ask clarifying questions about your business need, licenses, data sources, and team capability before making any recommendations. Every recommendation is grounded in the 380-document knowledge base and verified against live Microsoft Learn documentation.
 
 > [!NOTE]
 > Run `/architect:onboard` first for organization-specific customization (~5 minutes). This is optional but makes all subsequent assessments more relevant.
@@ -125,7 +125,7 @@ Cosmo will ask clarifying questions about your business need, licenses, data sou
 
 | Command | Description |
 |---------|-------------|
-| `/architect` | Start a structured architecture advisory session with Cosmo Skyberg |
+| `/architect` | Start a structured architecture advisory session |
 | `/architect:help` | Show all commands, agents, and knowledge bases |
 | `/architect:compare` | Compare Microsoft AI platforms for a given scenario |
 | `/architect:research` | Explore latest updates for a Microsoft AI platform via MCP |
@@ -225,7 +225,7 @@ The plugin includes **389 reference documents** organized across 5 domain-specif
 
 | Skill | Domain | Refs | User Intent |
 |-------|--------|------|-------------|
-| `ms-ai-advisor` | Cosmo persona, 7-phase workflow, platform selection | 62 | "Help me choose" |
+| `ms-ai-advisor` | 7-phase advisory workflow, platform selection | 62 | "Help me choose" |
 | `ms-ai-engineering` | RAG, agents, Azure AI Services, data, MLOps, multimodal | 153 | "How do I build this?" |
 | `ms-ai-governance` | Norwegian public sector governance, EU regulations, responsible AI, ROS | 78 | "Is this legal/safe?" |
 | `ms-ai-security` | Security scoring (6×5), cost estimation (P10/P50/P90) | 62 | "Is this safe?" |
@@ -233,7 +233,7 @@ The plugin includes **389 reference documents** organized across 5 domain-specif
 
 ### ms-ai-advisor (62 refs)
 
-Architecture decision trees, platform comparison matrices, Cosmo persona definition, cost models, migration patterns.
+Architecture decision trees, platform comparison matrices, advisory workflow definition, cost models, migration patterns.
 
 ### ms-ai-engineering (153 refs)
 
@@ -262,7 +262,7 @@ BCDR planning, hybrid and edge deployment, sovereign cloud (Norway regions), net
 
 ```
 /architect:onboard           # 5-min interview to capture org context
-/architect                   # Guided advisory with Cosmo Skyberg
+/architect                   # Guided architecture advisory
 /architect:compare           # Side-by-side platform comparison
 /architect:adr               # Formalize the decision as an ADR
 ```
@@ -439,22 +439,24 @@ node scripts/build-demo-state.mjs
 
 ### Screenshot gallery
 
-Screenshots of every surface in both themes live in `playground/screenshots/v1.11.0/` (the v1.10.0 set is preserved as historical reference). They are committed so forkers see what the plugin produces without running anything:
+Screenshots of every surface in both themes live in `playground/screenshots/v1.15.0/`, taken of the current demo project. They are committed so forkers see what the plugin produces without running anything:
 
 | # | File | What you see |
 |---|------|--------------|
 | 01 | `01-onboarding-empty-{dark,light}.png` | Onboarding surface, empty state |
-| 02 | `02-project-rapporter-regulatory-{dark,light}.png` | All 6 regulatory renderers (classify pyramid, requirements, transparency, FRIA, conformity kanban, DPIA matrix) |
-| 03 | `03-project-rapporter-security-{dark,light}.png` | 6×5 + 7×5 risk matrices, radar, top-risks, residual-pair, recommendation-card, review kanban |
-| 03 | `03-project-rapporter-economy-{dark,light}.png` | Cost distribution P10/P50/P90, license capability matrix |
-| 03 | `03-project-rapporter-documentation-{dark,light}.png` | Migrate mat-ladder, ADR critique-card, summary read-more, POC traffic-light, utredning screen-tabs, compare scenario-cards |
-| 03 | `03-project-rapporter-tool-{dark,light}.png` | 7 tool commands (no report — pipeline-string builders) |
-| 04-06 | `04-project-oversikt-{dark,light}.png` etc. | Project screen-tabs (oversikt / kontekst / eksport) |
-| 07 | `07-home-{dark,light}.png` | Home with project list + 3 entry tracks |
-| 08 | `08-catalog-{dark,light}.png` | Catalog with 29 commands in 5 expansion-grupper |
-| 09 | `09-onboarding-prefilled-{dark,light}.png` | Onboarding with state from demo |
+| 02 | `02-project-overview-{dark,light}.png` | Project view: sidebar with 17 artifacts, aggregate verdict, top risks |
+| 03 | `03-project-artifact-classify-{dark,light}.png` | EU AI Act classification (risk pyramid, role, obligations) |
+| 04 | `04-project-artifact-security-{dark,light}.png` | Security assessment (6×5 matrix) |
+| 05 | `05-project-artifact-ros-{dark,light}.png` | ROS analysis (risk matrix, radar) |
+| 06 | `06-project-artifact-cost-{dark,light}.png` | Cost estimate (P10/P50/P90 in NOK) |
+| 07 | `07-project-artifact-summary-{dark,light}.png` | Technical summary and decision note |
+| 08 | `08-project-import-modal-{dark,light}.png` | Import modal (viewport only) |
+| 09 | `09-project-search-{dark,light}.png` | Sidebar search filtering artifacts |
+| 10 | `10-home-{dark,light}.png` | Home with project list |
+| 11 | `11-catalog-{dark,light}.png` | Command catalog |
+| 12 | `12-onboarding-prefilled-{dark,light}.png` | Onboarding with state from the demo |
 
-Regenerate via `cd tests/screenshot && npm install && npx playwright install chromium && node run.mjs`.
+Regenerate via `cd tests/screenshot && npm install && npx playwright install chromium && node run.mjs`. The run also writes `playground/screenshots/MANIFEST.json`; `tests/kb-update/test-screenshots-manifest.test.mjs` fails when a screenshot in the tree is not from the latest run or the demo changed after it.
 
 ### Validation
 
@@ -712,7 +714,7 @@ Reference material in `skills/*/references/` is adapted from [Microsoft Learn](h
 
 Code samples from Microsoft Learn are used under the [MIT License](https://opensource.org/licenses/MIT).
 
-The plugin architecture, Cosmo Skyberg persona, decision methodology, and governance analysis are original work.
+The plugin architecture, advisory methodology, decision methodology, and governance analysis are original work.
 
 See [NOTICE.md](NOTICE.md) for full attribution details.
 

SECURITY.md

@@ -21,7 +21,7 @@ disclose within 90 days of the initial report.
 
 ## Supported versions
 
-The latest tagged release (currently 1.18.0) is the only supported
+The latest tagged release (currently 1.18.2) is the only supported
 version. Security fixes land on `main` and are released as a new tag;
 we do not backport fixes to older releases. See `CHANGELOG.md` for the
 release history.

agents/ros-analysis-agent.md

@@ -252,7 +252,7 @@ Bruk rapportmalene fra ros-report-templates.md:
 
 Scan system description for keywords:
 - Helse/pasient/journal -> Load health checklist
-- Veg/trafikk/transport -> Load transport checklist
+- Trafikk/transport -> Load transport checklist
 - Bank/finans/kreditt -> Load finance checklist
 - Politi/justis -> Load justice checklist
 - Skole/utdanning -> Load education checklist

commands/anskaffelse.md

@@ -8,7 +8,7 @@ model: opus
 
 # /architect:anskaffelse - AI-anskaffelse
 
-Du er Cosmo Skyberg i en anskaffelsesrolle. Hjelp brukeren å planlegge en AI-anskaffelse i norsk offentlig sektor — forankret i anskaffelsesloven/-forskriften, EØS-regelverket og DFØs veiledning for IT-anskaffelser.
+Du er en Microsoft AI-løsningsarkitekt i en anskaffelsesrolle. Hjelp brukeren å planlegge en AI-anskaffelse i norsk offentlig sektor — forankret i anskaffelsesloven/-forskriften, EØS-regelverket og DFØs veiledning for IT-anskaffelser.
 
 ## Språk og encoding
 

commands/architect.md

@@ -1,6 +1,6 @@
 ---
 name: architect
-description: Start en strukturert Microsoft AI-arkitekturrådgivning med Cosmo Skyberg
+description: Start en strukturert Microsoft AI-arkitekturrådgivning
 argument-hint: "[beskriv ditt forretningsproblem eller scenario]"
 allowed-tools: Read, Glob, Grep, Task, WebSearch, WebFetch, mcp__microsoft-learn__microsoft_docs_search
 model: opus
@@ -8,7 +8,7 @@ model: opus
 
 # /architect - Microsoft AI Architecture Advisory
 
-Du aktiverer nå **Cosmo Skyberg**, en erfaren Microsoft AI Solution Architect.
+Du aktiverer nå rollen som **Microsoft AI Solution Architect**.
 
 ## Instruksjoner
 
@@ -19,6 +19,6 @@ Du aktiverer nå **Cosmo Skyberg**, en erfaren Microsoft AI Solution Architect.
 
 ## Oppstart
 
-Start med å presentere deg som Cosmo Skyberg og spør om brukerens forretningsproblem eller behov.
+Start med å presentere rollen din kort og spør om brukerens forretningsproblem eller behov.
 
 **VIKTIG:** Ikke hopp over fase 1-3. Forstå problemet, konteksten og kapasiteten FØR du foreslår teknologi.

commands/businesscase.md

@@ -8,7 +8,7 @@ model: opus
 
 # /architect:businesscase - Forretningscase (NNV + gevinstrealisering)
 
-Du er Cosmo Skyberg i en økonomisk beslutningsrolle. Bygg et forretningscase for et AI-prosjekt i norsk offentlig sektor, forankret i samfunnsøkonomisk analyse (netto nåverdi) og DFØs gevinstrealiseringsmetodikk. Dette er beslutningsgrunnlag som skal tåle en styre- eller revisjonsgjennomgang.
+Du er en Microsoft AI-løsningsarkitekt i en økonomisk beslutningsrolle. Bygg et forretningscase for et AI-prosjekt i norsk offentlig sektor, forankret i samfunnsøkonomisk analyse (netto nåverdi) og DFØs gevinstrealiseringsmetodikk. Dette er beslutningsgrunnlag som skal tåle en styre- eller revisjonsgjennomgang.
 
 ## Språk og encoding
 

commands/classify.md

@@ -8,7 +8,7 @@ model: opus
 
 # EU AI Act — Klassifisering
 
-Du er Cosmo Skyberg, og skal lede en strukturert AI Act-klassifisering for et AI-system. EU AI Act gjelder **alle** providers og deployere — offentlig som privat sektor. Default til en sektor-nøytral vurdering og spesialiser når sektoren er kjent (offentlig sektor, finans, helse, industri, etc.).
+Du er en Microsoft AI-løsningsarkitekt, og skal lede en strukturert AI Act-klassifisering for et AI-system. EU AI Act gjelder **alle** providers og deployere — offentlig som privat sektor. Default til en sektor-nøytral vurdering og spesialiser når sektoren er kjent (offentlig sektor, finans, helse, industri, etc.).
 
 ## Språk og encoding
 

commands/compare.md

@@ -8,7 +8,7 @@ model: opus
 
 # /architect:compare - Plattformsammenligning
 
-Du er Cosmo Skyberg i en fokusert sammenligningsrolle. Hjelp brukeren å velge riktig Microsoft AI-plattform for sitt scenario.
+Du er en Microsoft AI-løsningsarkitekt i en fokusert sammenligningsrolle. Hjelp brukeren å velge riktig Microsoft AI-plattform for sitt scenario.
 
 ## Instruksjoner
 

commands/conformity.md

@@ -8,7 +8,7 @@ model: opus
 
 # Samsvarsvurdering — Conformity Assessment (Art. 43)
 
-Du er Cosmo Skyberg, og skal lede en samsvarsvurdering for et høyrisiko AI-system iht. EU AI Act Art. 43.
+Du er en Microsoft AI-løsningsarkitekt, og skal lede en samsvarsvurdering for et høyrisiko AI-system iht. EU AI Act Art. 43.
 
 ## Språk og encoding
 

commands/design.md

@@ -8,7 +8,7 @@ model: opus
 
 # /architect:design - Solution Architecture Document (SAD)
 
-Du er Cosmo Skyberg i en arkitekturdesign-rolle. Produser et strukturert, sektor-nøytralt Solution Architecture Document (SAD) for en Microsoft AI-løsning. Dette er mellombanen mellom en uformell rådgivningssamtale og en full `/architect:utredning`: et etterprøvbart designdokument uten det offentlige stillaset (utredningsinstruksen/Digdir). Egner seg for privat sektor, regulerte virksomheter og offentlige tiltak som ikke krever full utredning.
+Du er en Microsoft AI-løsningsarkitekt i en arkitekturdesign-rolle. Produser et strukturert, sektor-nøytralt Solution Architecture Document (SAD) for en Microsoft AI-løsning. Dette er mellombanen mellom en uformell rådgivningssamtale og en full `/architect:utredning`: et etterprøvbart designdokument uten det offentlige stillaset (utredningsinstruksen/Digdir). Egner seg for privat sektor, regulerte virksomheter og offentlige tiltak som ikke krever full utredning.
 
 > **Sektor:** Default sektor-nøytral. Spesialiser når sektoren er kjent (finans, helse, industri, offentlig, etc.). For et statlig tiltak som krever utredningsinstruksen, bruk `/architect:utredning` i stedet.
 

commands/dpia.md

@@ -8,7 +8,7 @@ model: opus
 
 # DPIA / Personvernkonsekvensvurdering for AI-systemer
 
-Du er Cosmo Skyberg, og skal lede en strukturert DPIA/PVK for et AI-system. DPIA-plikten (GDPR art. 35) gjelder alle behandlingsansvarlige — offentlig som privat sektor. Default til en sektor-nøytral vurdering og tilpass når sektoren er kjent (offentlig sektor, finans, helse, industri, etc.).
+Du er en Microsoft AI-løsningsarkitekt, og skal lede en strukturert DPIA/PVK for et AI-system. DPIA-plikten (GDPR art. 35) gjelder alle behandlingsansvarlige — offentlig som privat sektor. Default til en sektor-nøytral vurdering og tilpass når sektoren er kjent (offentlig sektor, finans, helse, industri, etc.).
 
 ## Språk og encoding
 

commands/frimpact.md

@@ -8,7 +8,7 @@ model: opus
 
 # FRIA — Fundamental Rights Impact Assessment (Art. 27)
 
-Du er Cosmo Skyberg, og skal lede en strukturert FRIA for et høyrisiko AI-system. FRIA (Art. 27) er obligatorisk for deployere som er (a) offentligrettslige organer, (b) private som leverer offentlige tjenester, eller (c) private deployere av høyrisiko-AI til kredittverdighet/kredittscoring av fysiske personer (unntatt svindeldeteksjon) eller til risikovurdering og prising i livs- og helseforsikring. Det er altså ikke et rent offentlig-sektor-verktøy.
+Du er en Microsoft AI-løsningsarkitekt, og skal lede en strukturert FRIA for et høyrisiko AI-system. FRIA (Art. 27) er obligatorisk for deployere som er (a) offentligrettslige organer, (b) private som leverer offentlige tjenester, eller (c) private deployere av høyrisiko-AI til kredittverdighet/kredittscoring av fysiske personer (unntatt svindeldeteksjon) eller til risikovurdering og prising i livs- og helseforsikring. Det er altså ikke et rent offentlig-sektor-verktøy.
 
 ## Språk og encoding
 

commands/generate-skills.md

@@ -8,7 +8,7 @@ model: opus
 
 # Skill Generation Command
 
-Du er Cosmo Skyberg og skal generere høykvalitets kunnskapsreferanser for architect-pluginen.
+Du er en Microsoft AI-løsningsarkitekt og skal generere høykvalitets kunnskapsreferanser for architect-pluginen.
 
 ## Designprinsipp: Minimal kontekstbruk
 
@@ -58,7 +58,7 @@ Kjør **5 agenter parallelt** i én melding. Vent på resultat, oppdater state,
 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.
+Du er en senior Microsoft AI-løsningsarkitekt. Generer en kunnskapsreferanse.
 
 ## Oppgave
 
@@ -117,7 +117,7 @@ Format (STRENGT — alle seksjoner påkrevd):
 ## Kostnad og lisensiering
 [Prismodell-oversikt, optimaliseringstips]
 
-## For arkitekten (Cosmo)
+## For arkitekten
 [5-8 spørsmål å stille, fallgruver, anbefalinger per modenhetsnivå]
 
 ## Kilder og verifisering
@@ -281,7 +281,7 @@ When invoked with `--update`, the command updates existing stale files instead o
 3. For each stale file, dispatch an update agent with this prompt:
 
 ```
-Du er Cosmo Skyberg. Oppdater en eksisterende kunnskapsreferanse.
+Du er en Microsoft AI-løsningsarkitekt. Oppdater en eksisterende kunnskapsreferanse.
 
 ## Oppgave
 Oppdater filen: {FILE_PATH}

commands/help.md

@@ -18,7 +18,7 @@ Presenter følgende oversikt til brukeren i et ryddig, tabellbasert format.
 
 | Kommando | Beskrivelse |
 |----------|-------------|
-| `/architect` | Start en strukturert arkitekturrådgivning med Cosmo Skyberg |
+| `/architect` | Start en strukturert arkitekturrådgivning |
 | `/architect:help` | Denne oversikten |
 | `/architect:compare` | Sammenlign Microsoft AI-plattformer for et gitt scenario |
 | `/architect:security` | Kjør sikkerhets- og compliance-vurdering |

commands/kb-update.md

@@ -189,7 +189,7 @@ 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. 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).
+d. **Oppdater fila:** `Edit` med endringer som er `auto-applied` eller eksplisitt godkjent av operatør i (c2). Behold "For arkitekten"-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).
 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
 

commands/migrate.md

@@ -8,7 +8,7 @@ model: opus
 
 # /architect:migrate - Migrasjonsanalyse
 
-Du er Cosmo Skyberg med fokus på migrasjonsplanlegging. Hjelp brukeren med en strukturert migrasjonsplan mellom Microsoft AI-plattformer.
+Du er en Microsoft AI-løsningsarkitekt med fokus på migrasjonsplanlegging. Hjelp brukeren med en strukturert migrasjonsplan mellom Microsoft AI-plattformer.
 
 **VIKTIG:** Migrasjoner har høy risiko. Vær grundig og ærlig om utfordringer.
 

commands/onboard.md

@@ -8,7 +8,7 @@ model: opus
 
 # Onboarding — Virksomhetstilpasning av AI Architect
 
-Du er Cosmo Skyberg, og skal starte onboarding-prosessen for å tilpasse pluginen til brukerens virksomhet.
+Du er en Microsoft AI-løsningsarkitekt, og skal starte onboarding-prosessen for å tilpasse pluginen til brukerens virksomhet.
 
 ## Språk og encoding
 

commands/poc.md

@@ -8,7 +8,7 @@ model: opus
 
 # /architect:poc - POC-planlegging
 
-Du er Cosmo Skyberg i en pragmatisk planleggingsrolle. Hjelp brukeren å lage en strukturert POC-plan for sitt Microsoft AI-prosjekt.
+Du er en Microsoft AI-løsningsarkitekt i en pragmatisk planleggingsrolle. Hjelp brukeren å lage en strukturert POC-plan for sitt Microsoft AI-prosjekt.
 
 ## Instruksjoner
 

commands/requirements.md

@@ -8,7 +8,7 @@ model: opus
 
 # EU AI Act — Krav og Forpliktelser
 
-Du er Cosmo Skyberg, og skal kartlegge konkrete AI Act-krav for et AI-system basert på dets risikoklassifisering og organisasjonens rolle.
+Du er en Microsoft AI-løsningsarkitekt, og skal kartlegge konkrete AI Act-krav for et AI-system basert på dets risikoklassifisering og organisasjonens rolle.
 
 ## Språk og encoding
 

commands/review.md

@@ -8,7 +8,7 @@ model: opus
 
 # /architect:review - Arkitekturgjennomgang
 
-Du er Cosmo Skyberg med fokus på arkitekturgjennomgang. Gjennomfør en strukturert vurdering av arkitekturforslaget mot relevante norske sektorkrav, EU-reguleringer og Microsoft-plattform best practices. Default-spesialiseringen er offentlig sektor (Digdir, utredningsinstruksen, forvaltningsloven); for privat/regulert sektor (f.eks. finans) vektlegges DORA, Finanstilsynet og sektorspesifikke rammeverk i stedet — sektoren avledes fra konteksten.
+Du er en Microsoft AI-løsningsarkitekt med fokus på arkitekturgjennomgang. Gjennomfør en strukturert vurdering av arkitekturforslaget mot relevante norske sektorkrav, EU-reguleringer og Microsoft-plattform best practices. Default-spesialiseringen er offentlig sektor (Digdir, utredningsinstruksen, forvaltningsloven); for privat/regulert sektor (f.eks. finans) vektlegges DORA, Finanstilsynet og sektorspesifikke rammeverk i stedet — sektoren avledes fra konteksten.
 
 **VIKTIG:** Arkitekturgjennomganger krever grundighet. Alle 6 dimensjoner skal vurderes. Hopp aldri over en dimensjon.
 
@@ -58,7 +58,7 @@ Les også:
 
 ### 4. Berik med arkitekturperspektiv
 
-Legg til Cosmos helhetsvurdering:
+Legg til arkitektens helhetsvurdering:
 - Arkitektonisk modenhet og teknisk gjeld
 - Strategisk alignment med virksomhetens målsettinger
 - Skaleringssti og fremtidig evolusjon

commands/ros.md

@@ -8,7 +8,7 @@ model: opus
 
 # ROS-analyse for AI-systemer
 
-Du er Cosmo Skyberg, og skal lede en strukturert ROS-analyse for et AI-system. Metodikken (NS 5814 / ISO 31000) er sektor-agnostisk — default til en sektor-nøytral analyse og spesialiser når sektoren er kjent (offentlig sektor, finans, helse, transport, industri, etc.). Sektor-sjekklister (inkl. finans: DORA, Finanstilsynet, Finansforetaksloven) aktiveres automatisk ved oppdaget sektor.
+Du er en Microsoft AI-løsningsarkitekt, og skal lede en strukturert ROS-analyse for et AI-system. Metodikken (NS 5814 / ISO 31000) er sektor-agnostisk — default til en sektor-nøytral analyse og spesialiser når sektoren er kjent (offentlig sektor, finans, helse, transport, industri, etc.). Sektor-sjekklister (inkl. finans: DORA, Finanstilsynet, Finansforetaksloven) aktiveres automatisk ved oppdaget sektor.
 
 ## Språk og encoding
 

commands/security.md

@@ -8,7 +8,7 @@ model: opus
 
 # /architect:security - Sikkerhets- og compliance-vurdering
 
-Du er Cosmo Skyberg med fokus på sikkerhet. Gjennomfør en grundig sikkerhets- og compliance-vurdering for det angitte scenarioet.
+Du er en Microsoft AI-løsningsarkitekt med fokus på sikkerhet. Gjennomfør en grundig sikkerhets- og compliance-vurdering for det angitte scenarioet.
 
 **VIKTIG:** Sikkerhetsvurderinger krever grundighet. Ikke hopp over dimensjoner eller gi overfladiske vurderinger.
 
@@ -45,7 +45,7 @@ og ${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-security/references/ai-security-engineerin
 
 ### 4. Berik med arkitekturperspektiv
 
-Legg til Cosmos vurdering:
+Legg til arkitektens vurdering:
 - Arkitektoniske implikasjoner av funnene
 - Hvordan sikkerhetsvalg påvirker arkitekturen
 - Trade-offs mellom sikkerhet og funksjonalitet

commands/summary.md

@@ -8,7 +8,7 @@ model: opus
 
 # /architect:summary — Sammendrag og beslutningsnotat
 
-Du er Cosmo Skyberg, og skal produsere et sammendrag basert på gjennomførte arkitekturvurderinger.
+Du er en Microsoft AI-løsningsarkitekt, og skal produsere et sammendrag basert på gjennomførte arkitekturvurderinger.
 
 ## Språk og encoding
 

commands/transparency.md

@@ -8,7 +8,7 @@ model: opus
 
 # EU AI Act — Transparensnotis
 
-Du er Cosmo Skyberg, og skal generere transparensnotiser i henhold til EU AI Act Art. 13 og Art. 50 for et AI-system.
+Du er en Microsoft AI-løsningsarkitekt, og skal generere transparensnotiser i henhold til EU AI Act Art. 13 og Art. 50 for et AI-system.
 
 ## Språk og encoding
 

commands/utredning.md

@@ -8,7 +8,7 @@ model: opus
 
 # /architect:utredning v2 — AI-arkitekturutredning
 
-Du er Cosmo Skyberg i en strukturert utredningsrolle. Gjennomfør en komplett AI-arkitekturutredning tilpasset norsk offentlig sektor — basert på utredningsinstruksen, Digdirs arkitekturprinsipper, rammeverk for digital samhandling og EU AI Act.
+Du er en Microsoft AI-løsningsarkitekt i en strukturert utredningsrolle. Gjennomfør en komplett AI-arkitekturutredning tilpasset norsk offentlig sektor — basert på utredningsinstruksen, Digdirs arkitekturprinsipper, rammeverk for digital samhandling og EU AI Act.
 
 > **Sektor:** Utredningen er forankret i utredningsinstruksen, som gjelder statlige tiltak. For privat sektor — eller et sektor-nøytralt Solution Architecture Document (SAD) uten det offentlige stillaset — bruk `/architect:design`.
 
@@ -25,7 +25,7 @@ Hvis kommandoen kjøres etter `/architect` (Fase 1-3), gjenbruk innsamlet kontek
 Les malen som styrer utredningen:
 - `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/references/architecture/ai-utredning-template.md`
 
-Aktiver Cosmo Skyberg-personaen fra `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/SKILL.md`.
+Aktiver arkitektrollen fra `${CLAUDE_PLUGIN_ROOT}/skills/ms-ai-advisor/SKILL.md`.
 
 ### 2. Parse input og bestem kompleksitet
 
@@ -69,7 +69,7 @@ Skriv `utredning.md` med S0 metadata-header umiddelbart. Bruk Edit med markøren
 **Virksomhet:** {virksomhet}
 **Dato:** {dato}
 **Kompleksitet:** {ENKEL|MIDDELS|KOMPLEKS}
-**Utredningsansvarlig:** Cosmo Skyberg (AI-arkitekt)
+**Utredningsansvarlig:** {utredningsansvarlig}
 
 ---
 

commands/vendor.md

@@ -8,7 +8,7 @@ model: opus
 
 # /architect:vendor - Leverandørvurdering (tredjepart/SaaS due diligence)
 
-Du er Cosmo Skyberg i en due-diligence-rolle. Vurder en ekstern tredjeparts- eller SaaS-leverandør (ikke-Microsoft AI/SaaS) som virksomheten vurderer å ta i bruk eller allerede bruker (inkludert shadow-AI). Dette er en daglig privat-enterprise-oppgave: `/architect:license` dekker Microsoft-lisenser, denne kommandoen dekker eksterne leverandører.
+Du er en Microsoft AI-løsningsarkitekt i en due-diligence-rolle. Vurder en ekstern tredjeparts- eller SaaS-leverandør (ikke-Microsoft AI/SaaS) som virksomheten vurderer å ta i bruk eller allerede bruker (inkludert shadow-AI). Dette er en daglig privat-enterprise-oppgave: `/architect:license` dekker Microsoft-lisenser, denne kommandoen dekker eksterne leverandører.
 
 > **Sektor:** Sektor-nøytral. Tilpass vekting når sektoren er kjent (finans → DORA tredjeparts-IKT-risiko + Finanstilsynets utkontrakteringskrav; helse → databehandleravtale + Normen).
 

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

@@ -37,8 +37,8 @@ Systematisk metodikk for klassifisering i fire steg:
 3. Høyrisiko-sjekk via Annex III (8 kategorier) og Annex I (produktsikkerhet)
 4. Begrenset/minimal risiko (default)
 
-For hvert steg: beslutningspunkter, terskelverdier, DDT-eksempler.  
-Inkluder: Annex III full liste på norsk med presiseringer for transport/infrastruktur-sektoren.
+For hvert steg: beslutningspunkter, terskelverdier, eksempler fra offentlig sektor.  
+Inkluder: Annex III full liste på norsk med presiseringer for offentlig forvaltning.
 
 #### 1b. `ai-act-provider-obligations.md`
 Forpliktelser for **tilbydere** (organisasjoner som utvikler/tilpasser AI-systemer):
@@ -51,7 +51,7 @@ Forpliktelser for **tilbydere** (organisasjoner som utvikler/tilpasser AI-system
 - Art. 15: Nøyaktighet, robusthet, cybersikkerhet
 - Art. 16–27: Kvalitetsstyring, samsvarsvurdering, CE-merking (relevant ved anskaffelse)
 
-DDT-kontekst: Direktoratet for digital tjenesteutvikling er typisk **deployer**, ikke provider. Men ved intern utvikling på topp av Azure AI/Copilot Studio: provider-rolle.
+Offentlig kontekst: en typisk offentlig virksomhet er **deployer**, ikke provider. Men ved intern utvikling på topp av Azure AI/Copilot Studio: provider-rolle.
 
 #### 1c. `ai-act-deployer-obligations.md`
 Forpliktelser for **deployere** (organisasjoner som tar i bruk AI-systemer):
@@ -63,7 +63,7 @@ Forpliktelser for **deployere** (organisasjoner som tar i bruk AI-systemer):
   - Informasjon til berørte parter
   - FRIA-plikt for offentlig sektor (Art. 27)
 
-DDT som deployer: Copilot Studio-agenter, Azure AI Foundry-løsninger, M365 Copilot.
+Offentlig virksomhet som deployer: Copilot Studio-agenter, Azure AI Foundry-løsninger, M365 Copilot.
 
 #### 1d. `ai-act-fria-template.md`
 Fundamental Rights Impact Assessment – **obligatorisk for offentlig sektor** (Art. 27).
@@ -98,7 +98,7 @@ Mal for transparensnotiser per Art. 13 og 52:
 - Art. 52(3): Deepfake-merking
 - Art. 50: GPAI-modeller – krav til maskinlesbar metadata
 
-DDT-eksempler: Chatbot på ddt.no, AI i saksbehandling.
+Eksempler: Chatbot på virksomhetens nettsted, AI i saksbehandling.
 
 #### 1g. `ai-act-microsoft-tools-mapping.md`
 Kartlegging av Microsoft-verktøy mot AI Act-krav:
@@ -148,7 +148,7 @@ tools:
 **Hjemmel:** Annex III, kategori X – [beskrivelse]
 
 ## Rolle
-**DDT som:** [Provider / Deployer / Begge]
+**Virksomheten som:** [Provider / Deployer / Begge]
 
 ## Forpliktelser
 ### Umiddelbart (innen 2026-08-02)
@@ -269,7 +269,7 @@ Legg til i review-sjekklisten:
 ```
 EU AI Act Conformity Check (kjøres automatisk hvis systemet er AI-basert):
 □ Er systemet klassifisert mot Annex III?
-□ Er DDTs rolle (provider/deployer) avklart?
+□ Er virksomhetens rolle (provider/deployer) avklart?
 □ Er teknisk dokumentasjon (Annex IV) påbegynt?
 □ Er Art. 14 menneskelig tilsyn implementert i arkitekturen?
 □ Er logging (Art. 12/26) designet inn – ikke ettermontering?
@@ -394,15 +394,15 @@ I eksport-formater (steg 5) – legg til AI Act-output alternativ:
 ### STEG 8: Opprett tester
 
 #### 8a. `tests/fixtures/ai-act/fixture.md`
-Test-case: Fiktivt AI-system hos DDT
+Test-case: Fiktivt AI-system hos Acme Kommune
 
 ```markdown
-# Test-system: FartsPrediksjonsagent
-Formål: Predikere trafikkfart på E6 ved hjelp av historisk og sanntids-data
+# Test-system: Energiprognoseagent
+Formål: Predikere energiforbruk i kommunale formålsbygg ved hjelp av historisk og sanntids-data
 Teknologi: Azure Machine Learning, python-modell, REST API
-Brukere: Intern trafikkovervåking, ingen direkte borgerinteraksjon
-Data: GPS-data fra biler, kameraer, sensorer (anonymisert)
-Sektor: Transport og infrastruktur
+Brukere: Interne energirådgivere, ingen direkte borgerinteraksjon
+Data: Måledata fra energimålere og bygningssensorer (ingen persondata)
+Sektor: Energi og eiendom
 ```
 
 Forventet output: Klassifisert som "Begrenset/Minimal" (ikke Annex III, ikke direkte borgerimpakt)
@@ -412,10 +412,10 @@ Test-case: Høyrisiko-system
 
 ```markdown
 # Test-system: AutomatiskSaksbehandler
-Formål: Automatisk vurdering av dispensasjonssøknader (kjøretillatelser)
+Formål: Automatisk vurdering av søknader om tilskudd
 Teknologi: Azure OpenAI GPT-4, Copilot Studio
 Brukere: Borgere sender søknad, AI gir innstilling til saksbehandler
-Data: Persondata, helseopplysninger (ved dispensasjon)
+Data: Persondata, inntektsopplysninger
 Sektor: Offentlig forvaltning
 ```
 
@@ -478,11 +478,11 @@ Verifiser at alle eksisterende tester fortsatt passerer.
 
 1. **Sekvens er uforanderlig**: AI Act → DPIA → ROS. Aldri omgå dette.
 
-2. **DDT er typisk deployer**, ikke provider. Men ved intern utvikling (Copilot Studio-agenter bygget internt): provider-rolle. Agenten skal avklare dette eksplisitt.
+2. **En offentlig virksomhet er typisk deployer**, ikke provider. Men ved intern utvikling (Copilot Studio-agenter bygget internt): provider-rolle. Agenten skal avklare dette eksplisitt.
 
 3. **FRIA er obligatorisk for offentlig sektor** ved høyrisiko-systemer. Ikke valgfritt.
 
-4. **Fristen 2026-08-02 er 162 dager unna** (per 2026-02-22). DDT må ha klassifisert alle høyrisiko-systemer og ha GPAI-compliance på plass innen da.
+4. **Fristen 2026-08-02 er 162 dager unna** (per 2026-02-22). Virksomheten må ha klassifisert alle høyrisiko-systemer og ha GPAI-compliance på plass innen da.
 
 5. **Ikke overskriv eksisterende KB-filer**: `ai-act-compliance-guide.md` og `ai-act-annex-iii-checklist.md` er komplette. Referer til dem, ikke erstatt dem.
 

docs/kb-update-apply-brief.md

@@ -16,7 +16,7 @@ Kommando-spec'en (`commands/kb-update.md`) beskriver fetch+Edit i hovedloopen. F
 2. Hent full fil→endrede-URLer-mapping fra `scripts/kb-update/data/change-report.json` (filtrer på `priority`).
 3. Grupper filene i bunter på **~6 filer som deler kilder** (hver unik URL hentes én gang per gruppe → minimer fetches).
 4. Spawn **én Opus-subagent per gruppe** (`Agent`, `subagent_type: claude`, `model: opus`), med **disjunkte fil-sett** (ingen skrivekonflikt → ingen worktree nødvendig). Hver subagent: Read → `microsoft_docs_fetch` (store sider persisteres til fil → Read den fila) → **kirurgisk** Edit → bump dato → kjøredato (behold filas eksisterende dato-label/format; footer `Sist oppdatert`→kjøredato, `Neste review`→+3 mnd hvis de finnes).
-5. **Subagent-kontrakt (kritisk):** verifiser hver faktapåstand mot kilde; fiks motsigelser til å matche kilden; **ALDRI oppfinn** — flagg uverifiserbart eksplisitt; behold «For Cosmo»/«For arkitekten»-seksjon + struktur; **ALDRI git/commit/stage**; rør KUN tildelte filer; returner kompakt per-fil-changelog + FLAGS-linje.
+5. **Subagent-kontrakt (kritisk):** verifiser hver faktapåstand mot kilde; fiks motsigelser til å matche kilden; **ALDRI oppfinn** — flagg uverifiserbart eksplisitt; behold «For arkitekten»-seksjon + struktur; **ALDRI git/commit/stage**; rør KUN tildelte filer; returner kompakt per-fil-changelog + FLAGS-linje.
 6. Gi subagentene de **binding-verifiserte faktaene** fra STATE.md (relevant utvalg per gruppe) → unngå re-verifisering + motsigelse.
 7. **Hovedkontekst verifiserer ETTER** (subagentenes egenrapport er ikke nok — fila er fasit):
    - `git diff --stat` → scope = KUN forventede filer, ingen streifende.

docs/playground.md

@@ -34,7 +34,7 @@ Erstatter v2 5-stegs-pipelinen med en multi-surface-app som persisterer state og
 
 `scripts/build-demo-state.mjs` leser alle 17 fixture-filer fra `playground/test-fixtures/` og injiserer dem som en `<script type="application/json" id="demo-state-v1">`-blokk i playground HTML (idempotent — erstatter eksisterende blokk). "Last inn demo-data"-knappen på onboarding-overflaten kaller `ACTIONS['load-demo']` som leser blokken, erstatter alle state-grener via Proxy-mutasjon, kjører `migrateDataVersion` (v2→v3 auto-parser raw_markdown til artifacts), og navigerer til project-surface. Demo viser 17 artifacts gruppert i sidebar med severity-badges, aggregate verdict (BLOKKERT), top-risks-liste, og fungerende re-importer/slett-knapper per artifact.
 
-`tests/screenshot/` inneholder en frittstående Playwright-runner med egen `package.json` (gitignored `node_modules`). `node run.mjs` produserer 24 PNG-er (12 surfaces × 2 tema) under `playground/screenshots/v1.15.0/`. v1.15.0-surfaces: onboarding-empty, project-overview, project-artifact-{classify,security,ros,cost,summary}, project-import-modal (viewport-only — modal er position:fixed overlay), project-search, home, catalog, onboarding-prefilled. v1.10.0/v1.11.0/v1.14.0 beholdt som historisk referanse. Disse committes så forkere ser pluginen uten å installere noe. Demo-org er "Acme Kommune" og demo-prosjekt er "Acme: Kunde-chatbot".
+`tests/screenshot/` inneholder en frittstående Playwright-runner med egen `package.json` (gitignored `node_modules`). `node run.mjs` produserer 24 PNG-er (12 surfaces × 2 tema) under `playground/screenshots/v1.15.0/`. v1.15.0-surfaces: onboarding-empty, project-overview, project-artifact-{classify,security,ros,cost,summary}, project-import-modal (viewport-only — modal er position:fixed overlay), project-search, home, catalog, onboarding-prefilled. Runneren sletter PNG-er en tidligere kjøring la igjen, og skriver `playground/screenshots/MANIFEST.json` (sha256 per PNG + sha256 av demo-state-blokken). `tests/kb-update/test-screenshots-manifest.test.mjs` feiler når et PNG i treet ikke er output fra siste kjøring, eller demoen er endret etter at bildene ble tatt — kjør `node run.mjs` på nytt. Eldre sett (v1.10.0, v1.11.0, v1.14.0, v2-mockup) er fjernet i 1.18.2. Disse committes så forkere ser pluginen uten å installere noe. Demo-org er "Acme Kommune" og demo-prosjekt er "Acme: Kunde-chatbot".
 
 ## Design-system 100%-adoption (v1.11.0 → v1.14.0)
 

docs/r14-persona-gate-measurement-2026-09.md

@@ -0,0 +1,218 @@
+# R14-forberedelse — persona utenfor ref-korpuset: måling og foreslått gate
+
+**Målt:** 2026-09-13 · **Status:** FORSLAG — krever operatør-ratifisering før R14-transformen skrives
+**Forgjenger:** R13 del 1 (`3a73eea`) · **Kilde-brief:** `docs/cosmo-removal-brief-2026-06.md`
+**Klassifikator:** `scripts/kb-update/lib/cosmo-persona.mjs` (R13, gjenbrukt — ikke ny)
+
+Dette dokumentet gjør to ting: det måler persona-populasjonen **utenfor** ref-korpuset, og det
+foreslår unntakssettet R14-gaten mangler. Det skriver ingen transform.
+
+---
+
+## 1. Roadmapens R14-gate er ikke uoppnåelig — den er *ubestemt*
+
+Roadmapen (`.claude/…/plugin-roadmap-2026-07.md § R14`) skriver gaten slik:
+
+> `grep -rli "cosmo" --include='*.md' .` **(unntak per cosmo-removal-brief)** → 0
+
+Unntaksklausulen finnes altså. Den delegerer til briefen. Briefens eneste tilsvarende setning er
+§4: «`grep -rc Cosmo` → 0 **(eller dokumentert restmengde)**». Briefen inneholder ingen liste
+(målt: 0 treff på «unntak», «exception», «except»; kjent-positiv: 16 treff på persona-navnet, så
+nettet kan finne). Gaten reduserer seg dermed til «0, **eller** en dokumentert restmengde» — og
+restmengden er aldri blitt dokumentert. Det er den åpne beslutningen dette dokumentet lukker.
+
+**Konsekvens:** gaten har aldri vært usann i formen. Den har vært *utfylt halvveis*.
+
+## 2. Fire klausuler målt hver for seg
+
+R13 lærte at én rettet feil ikke fredner resten. Gaten er derfor dekomponert, og hver klausul målt.
+
+### (S) Skopet — `.` og `--include='*.md'` treffer feil mengde, i begge retninger
+
+| Måling | Tall |
+|---|---|
+| `command grep -rli "cosmo" --include='*.md' .` (arbeidstreet) | **1348 filer** |
+| — herav `.kb-backup/` (lokale KB-backuper, gitignorert) | 1146 |
+| — herav `.claude/` (LOCAL-ONLY planer) + `STATE.md` | 9 |
+| Samme spørring avgrenset til `git ls-files '*.md'` | **192 filer** |
+| Tracked **ikke**-`.md`-filer som bærer strengen | **29 filer / ~429 forekomster** |
+
+To uavhengige feil: gaten **teller med** 1155 filer som aldri skal leveres (backup + local-only), og
+den **ser ikke** 29 tracked filer fordi de ikke er `.md` — blant dem R13s eget maskineri
+(`lib/cosmo-persona.mjs` 90, `test-cosmo-persona.test.mjs` 88, `check-cosmo-gate.mjs` 25) og
+`.gitignore` (3). Fire filnavn utenfor `.md` bærer strengen selv.
+
+> **Måleinstrumentet teller også.** I en Claude Code-økt er `grep` en shell-funksjon som wrapper
+> `ugrep --ignore-files` og respekterer `.gitignore`. Den gir 192 der ekte `grep` gir 1348. Enhver
+> R14-måling må kjøres med `command grep` eller via node — aldri med øktens `grep`.
+
+**Forslag:** skopet er `git ls-files '*.md'` (tracked), målt programmatisk.
+
+### (a) Referenten — strengen betyr fortsatt to ting, og diskriminatoren er målt på feil populasjon
+
+Utenfor ref-korpuset finnes **9** `Cosmos`-formede forekomster. Alle er håndsjekket:
+
+| Fil:linje | Tekst | Dom | Klassifikator |
+|---|---|---|---|
+| `commands/review.md:61` | «Legg til Cosmos helhetsvurdering» | persona (norsk genitiv) | ✅ persona |
+| `commands/security.md:48` | «Legg til Cosmos vurdering» | persona (norsk genitiv) | ✅ persona |
+| `skills/ms-ai-infrastructure/SKILL.md` ×4 | «Cosmos DB …» | produkt | ✅ produkt |
+| `skills/ms-ai-security/SKILL.md:106` | «… Blob Storage, Cosmos DB» | produkt | ✅ produkt |
+| `playground/test-fixtures/cost.md:22` | «blob + cosmos for audit» | produkt | ✅ produkt |
+| `docs/ref-kb-gold-reconciliation-2026-06.md:93` | «Cosmos multi-region writes … /azure/cosmos-db/…» | **produkt** | ❌ **persona** |
+
+**1 av 9 er feilklassifisert.** R13s genitivregel er `Cosmos <liten forbokstav>` = persona, med en
+enumerert liste norske funksjonsord som unntak. Lista ble enumerert over ref-korpuset, som ikke
+inneholder engelsk produktprosa. «Cosmos multi-region writes» treffer regelen og blir persona.
+Dommen er avgjort av URL-en i samme tabellrad. Alle tall i dette dokumentet er korrigert for den.
+
+**Forslag:** utvid `PRODUCT_FOLLOWERS` med de engelske produktordene, ELLER — enklere og
+presist — la en håndadjudisert forekomst-override bære de få tilfellene. Uansett: **klassifikatoren
+må re-valideres på R14-populasjonen før tallene konsumeres**, ikke bare på korpuset den ble født i.
+
+### (b) Rekkevidden — R13s operasjon når 3 av 145, og generatorene reverserer den
+
+R13s transform er en **heading-tabell** med 40 ratifiserte oppføringer. Utenfor ref-korpuset finnes
+bare 2 persona-headinger og 1 TOC-lenke. Av dem er 1 i tabellen; 2 er det ikke, og transformen
+**kaster** på dem (fail-safe, ikke stille feil):
+
+- `skills/ms-ai-advisor/SKILL.md:11` — `# Cosmo Skyberg - Microsoft AI Solution Architect`
+- `docs/cosmo-removal-brief-2026-06.md:1` — `# Cosmo-persona — full utfasing (brief)`
+
+R13-maskineriet er altså **ikke** en drop-in for R14. 142 av 145 forekomster er prosa, tabellceller,
+kodeblokker og fete innledninger — redaksjonelt arbeid, ikke tabelloppslag.
+
+> **Det tyngste funnet: fem steder *produserer* ny persona.** R13s gate er grønn i dag, men ikke
+> stabil — neste KB-generering re-minter nettopp headingen R13 fjernet 401 av.
+>
+> | Sted | Hva det gjør | Konsument (verifisert) |
+> |---|---|---|
+> | `scripts/kb-update/transform-prompt.md:63,82` | ber modellen skrive seksjon «8. For arkitekten (Cosmo)» | `commands/kb-update.md:129` leser den |
+> | `scripts/skill-gen/prompt-template.md:18,77` | samme seksjon i skill-generatoren | `generate-skills.sh:27` → `claude --print` |
+> | `commands/generate-skills.md:11,61,120,284` | prompt med `## For arkitekten (Cosmo)` innbakt | selve kommandoen |
+> | `commands/kb-update.md:192` | «Behold "For Cosmo"-seksjonen …» | selve kommandoen |
+> | `docs/kb-update-apply-brief.md:19` | subagent-kontrakt: «behold «For Cosmo»…-seksjon» | apply-flyten |
+>
+> Korreksjon til egen mellomregning: `lib/transform.mjs` *nevner* prompt-fila i en kommentar, den
+> leser den ikke. Konsumenten er kommandoen.
+
+### (c) Det som skal bli stående — 83 forekomster i 10 filer (116 i 11 med denne fila)
+
+Se registeret i §4. To klasser: **historikk** (CHANGELOG-rader som omtaler utfasingen sant;
+CLAUDE.md forbyr historikk-omskriving) og **derivasjonsrecord** (docs-planer og -briefer som
+dokumenterer hvorfor beslutningene ble tatt). Begge er sanne utsagn om fortiden.
+
+---
+
+## 3. Foreslått R14-gate — tre klausuler oppå R13s G1/G2/G3
+
+Skop for alle: `git ls-files '*.md'`, målt programmatisk med R13-klassifikatoren.
+
+| | Klausul | Mål | I dag |
+|---|---|---|---|
+| **G4** | persona i **leveranseflaten** | **0** | 62 i 32 filer |
+| **G5** | **produkt** urørt — pinnet **per fil**, ikke som global sum | per-fil som baseline | 459 (451 korpus + 8 utenfor) |
+| **G6** | **derivasjonsregisteret** pinnet per fil | eksakt som §4 | 83 i 10 filer |
+
+**G6 pinnes på forekomst-tall per fil, ALDRI på filnavn.** Målt: injiserer man en ny persona-linje i
+`docs/cosmo-removal-brief-2026-06.md` går tellingen 32 → 33, og et talls-pinnet unntak feller den.
+Et fil-nivå-unntak («hopp over denne fila») ser den ikke — fila er unntatt uansett innhold. Det er
+forskjellen mellom et unntak og et hull.
+
+### Nett-validering (kjørt 2026-09-13, begge veier)
+
+| Retning | Test | Utfall |
+|---|---|---|
+| kjent-positiv | `agents/adr-writer-agent.md` har 0 → injisert «Du er Cosmo Skyberg.» | ✅ 0 → 1 |
+| kjent-positiv | injisert norsk genitiv «Cosmos vurdering» | ✅ 0 → 1 |
+| kjent-positiv | injisert persona-**heading** | ✅ 0 → 1 |
+| kjent-negativ | «Cosmos DB», «cosmos for audit» | ✅ 0 persona |
+| kjent-negativ | `skills/ms-ai-infrastructure/SKILL.md` (4 produkt) | ✅ 0 persona |
+| **kjent-negativ som FEILER** | «Cosmos multi-region writes …» | ❌ klassifiseres persona — dokumentert i §2(a) |
+| unntaksform | ny persona injisert i unntatt fil | ✅ tall-pin feller · ❌ filnavn-unntak er blindt |
+
+**Blindhetstest av vokabularet:** 64 tracked filer bærer «Skyberg». **Null** av dem bærer «Skyberg»
+uten også å bære «cosmo» — verken på fil- eller linjenivå. Strengen `cosmo` er ikke blind for
+personaens etternavn. (32 utenfor korpuset + 32 i korpuset = 64; målt hver for seg fordi et identisk
+delt tall skal mistenkes.)
+
+---
+
+## 4. Det foreslåtte unntakssettet (G6-registeret)
+
+Disse 83 forekomstene skal **bli stående**. Hver linje er et pin, ikke et filnavn-hopp.
+
+| Fil | Forekomster | Klasse |
+|---|---|---|
+| `CHANGELOG.md` | 6 | historikk — omskriving forbudt (CLAUDE.md) |
+| `docs/cosmo-removal-brief-2026-06.md` | 32 | kildedokument; bærer strengen i eget **filnavn** |
+| `docs/ref-kb-workflow-plan-2026-06.md` | 25 | planrecord (S-Cosmo-sporet) |
+| `docs/ref-kb-direction-note-2026-06.md` | 6 | retningsnotat, sekvenseringsrisiko |
+| `docs/ref-kb-correctness-program-2026-06.md` | 4 | programrecord |
+| `docs/kb-refresh-backlog-2026-06.md` | 3 | backlog-peker til briefen |
+| `docs/spor1-authority-selection.md` | 3 | scope-record (advisor-fence) |
+| `docs/skill-validation-routine-brief-2026-07.md` | 2 | scope-record |
+| `docs/devils-advocate-audit-2026-06-18.md` | 1 | auditrecord |
+| `docs/kb-mechanism-redesign-brief.md` | 1 | designrecord |
+| `docs/r14-persona-gate-measurement-2026-09.md` (denne fila) | 33 | målerecord — se note under |
+| **SUM** | **116** | i 11 filer |
+
+**Dette dokumentet blir selv en oppføring — målt, ikke anslått.** Det bærer persona-strengen fordi
+det måler den: **33 persona + 8 produkt** (klassifikatoren kjørt på fila selv). R14-baselinen må
+derfor emitteres til **116 persona i 11 filer** i registeret, og produkt-pinnene må inkludere dette
+dokumentets 8. Et unntakssett som ikke er lukket under sin egen dokumentasjon, ugyldiggjør seg selv
+ved første commit — og en global produkt-sum ville blitt usann av nettopp denne fila, som er grunnen
+til at G5 pinnes per fil.
+
+**Én oppføring er flyttet på skjønn.** `docs/kb-update-apply-brief.md:19` ligger under `docs/`, men
+er ikke et record: det er en levende subagent-kontrakt som sier «behold «For Cosmo»-seksjon». Den er
+sortert på det diskriminerende trekket (operativ vs. historisk), ikke på stiprefikset, og hører
+derfor i **leveranseflaten** — ikke i registeret. Krever operatørens ja.
+
+### Leveranseflaten (G4 → 0): 62 forekomster i 32 filer
+
+`README.md` 14 · `commands/` 32 i 23 filer · `skills/ms-ai-advisor/SKILL.md` 6 ·
+`skills/ms-ai-engineering/SKILL.md` 1 · `scripts/kb-update/transform-prompt.md` 2 ·
+`scripts/skill-gen/prompt-template.md` 2 · `CLAUDE.md` 2 · `NOTICE.md` 1 ·
+`playground/A11Y-RAPPORT.md` 1 · `docs/kb-update-apply-brief.md` 1.
+
+**Roadmapens R14-scope er ufullstendig.** Den nevner «SKILL.md-er, 23 commands, 11 docs, rot-filer +
+`generate-skills.md`/`transform-prompt.md`». Målt mangler: `scripts/skill-gen/prompt-template.md`
+(2 — og den er live, lest av `generate-skills.sh`) og `playground/A11Y-RAPPORT.md` (1).
+Ordrens «13 docs» er også feil; roadmapens 11 stemmer (9 record + briefen + apply-briefen).
+
+`playground/A11Y-RAPPORT.md:15` er grensetilfellet: «| Tester | Cosmo Skyberg via Claude Code |» er
+en proveniens-linje som attribuerer en faktisk testkjøring til en oppdiktet person. Foreslått som
+leveranseflate — å nøytralisere den gjør rapporten sannere, ikke bare renere.
+
+---
+
+## 5. Den andre åpne beslutningen R14 ikke kan starte uten
+
+Briefens §1 stiller spørsmålet som aldri er besvart:
+
+> «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.»
+
+R13 ratifiserte en **heading-form** (`For Cosmo` → `For arkitekten`) i ref-korpuset. Det er ikke
+svaret på §1. `skills/ms-ai-advisor/SKILL.md` er en ~250-linjers persona-definisjon i andreperson
+(«Du ER …», «Du er … en erfaren løsningsarkitekt»), og 23 kommandoer åpner med «Du er … i en
+X-rolle». En mekanisk substitusjon gir ubrukelig norsk. §1 må besvares før R14-transformen skrives —
+den er en separat beslutning fra unntakssettet, ikke en del av det.
+
+---
+
+## 6. Tall som ble arvet og målt usanne
+
+| Arvet påstand | Kilde | Målt |
+|---|---|---|
+| «`3a73eea` er UPUSHET» | ordre + STATE.md | **pushet** (`git ls-remote origin refs/heads/main`) |
+| «briefen har ingen unntaksliste ⇒ gaten er skrevet uten unntak» | ordre | gaten **har** klausul `(unntak per cosmo-removal-brief)`; briefen har «eller dokumentert restmengde» |
+| «13 docs-filer» | ordre | **11** (roadmapens tall stemmer) |
+| «4 SKILL.md» | ordre | 4 av **5** bærer strengen — riktig, men repoet har 5 |
+| «417 filer nevner Cosmo / 956 forekomster» | briefen 2026-06-24 | historisk, pre-R13 — ikke gjenbrukbart |
+
+**Ikke målt i denne økten:** de 29 ikke-`.md`-filene er talt, men ikke persona/produkt-klassifisert
+per forekomst. De ligger utenfor gatens `--include='*.md'` og utenfor R14s ratifiserte flate; skal
+de inn, er det en egen scope-utvidelse med egen måling.

playground/A11Y-RAPPORT.md

@@ -12,7 +12,7 @@
 | Felt | Verdi |
 |------|-------|
 | Test-dato | 2026-05-04 (statisk gjennomgang) |
-| Tester | Cosmo Skyberg via Claude Code (statisk DOM-revisjon) |
+| Tester | Claude Code (statisk DOM-revisjon) |
 | Browser | Pending — `MANUAL-CHECKLIST.md` seksjon 10 instruerer Chrome + Firefox + Safari |
 | OS | macOS (utvikler-maskin) |
 | Verktøy | grep / DOM-pattern-revisjon (denne rapporten) + axe-core 4.10.0 (pending) |

playground/ms-ai-architect-playground.html

@@ -239,7 +239,7 @@
     {
       "id": "acme-kunde-chatbot",
       "name": "Acme: Kunde-chatbot",
-      "description": "AI-chatbot som hjelper innbyggere med byggesak-spørsmål. Trenger DPIA, ROS, EU AI Act-klassifisering og kostnadsestimat før beslutning. Alle 17 rapport-typer er pre-importert med eksempel-data.",
+      "description": "AI-chatbot som svarer innbyggere på henvendelser og forhåndsvurderer søknader om kommunal bostøtte ut fra opplastede vedlegg. Trenger DPIA, ROS, EU AI Act-klassifisering og kostnadsestimat før beslutning. Alle 17 rapport-typer er pre-importert med eksempel-data.",
       "scenarios": [
         "Chatbot/agent",
         "Beslutningsstøtte"
@@ -248,27 +248,27 @@
       "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-12-02 (Annex III høyrisiko full compliance, utsatt fra 2026-08-02).\n"
+          "raw_markdown": "# EU AI Act — Klassifisering: Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nBeskrivelse: Innbyggerchatbot som svarer på henvendelser og forhåndsvurderer søknader om kommunal bostøtte via vedleggstolkning + oppslag i fagsystemet\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 til å vurdere om innbyggere har rett til en offentlig ytelse, og påvirker individers rettigheter direkte gjennom automatisert beslutningsstøtte for saksbehandlingen. Dette plasserer systemet under Annex III, punkt 5(a) (tilgang til offentlige ytelser og tjenester) 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-12-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 vedtak om avslag | 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": {},
-          "raw_markdown": "# Transparensnotis — Acme Kunde-chatbot\n\nTittel: Informasjon om automatisert operasjonell analyse (Art. 13 og Art. 50)\n\n## Hva systemet gjør\n\nAcme Kommune bruker et AI-system som leser av objekt-ID (Acme Kunde-chatbot — automatisert klassifisering) fra sensordata langs produksjonsmiljøet. Systemet identifiserer objekter som har overtrådt terskelverdi gjennom å beregne gjennomsnittlig respons mellom to datapunkt.\n\n## Hvilke data som behandles\n\nBehandlede data inkluderer objekt-ID, tidsstempel, datapunkt, objektklasse og oppslag i Acme Kommune objektregister. Personlig identifiserbar informasjon kobles ikke til oppføring uten saksbehandler eksplisitte godkjenning.\n\n## Hvordan beslutninger tas\n\nSystemet er beslutningsstøtte, ikke -taker. Hver flagged hendelse går til menneskelig saksbehandler som tar endelig avgjørelse om gebyr eller anmeldelse. AI-output inkluderer konfidensgrad og forklaring av hvorfor saken ble flagget.\n\n## Dine rettigheter\n\nSom registrert har du rett til innsyn (GDPR Art. 15), retting (Art. 16), sletting (Art. 17 — med begrensninger ved lovhjemmel), og å klage til Datatilsynet. Du kan også be om manuell vurdering uten AI-bistand per GDPR Art. 22.\n\n## Kontakt\n\nPersonvernombud: pvo@Acme.no\nTilsyn: Datatilsynet — postkasse@datatilsynet.no\nEU AI Act-tilsyn: under etablering (Digitaliseringsdirektoratet er forventet)\n"
+          "raw_markdown": "# Transparensnotis — Acme Kunde-chatbot\n\nTittel: Informasjon om automatisert forhåndsvurdering av søknader (Art. 13 og Art. 50)\n\n## Hva systemet gjør\n\nAcme Kommune bruker et AI-system (Acme Kunde-chatbot) som svarer på spørsmål om kommunale tjenester og leser vedlegg du laster opp med en søknad om bostøtte. Systemet vurderer om søknaden er komplett, og om inntekt og boutgifter ser ut til å ligge innenfor vilkårene.\n\n## Hvilke data som behandles\n\nBehandlede data inkluderer det du skriver i chatten, opplastede vedlegg, saksnummer, tidsstempel og oppslag i Acme Kommunes fagsystem for bostøtte. Samtalen kobles ikke til søknaden din uten at du samtykker til det i chatten.\n\n## Hvordan beslutninger tas\n\nSystemet er beslutningsstøtte, ikke -taker. Hver flaggede søknad går til en menneskelig saksbehandler som fatter vedtaket. AI-output inkluderer konfidensgrad og forklaring av hvorfor saken ble flagget.\n\n## Dine rettigheter\n\nSom registrert har du rett til innsyn (GDPR Art. 15), retting (Art. 16), sletting (Art. 17 — med begrensninger ved lovhjemmel), og å klage til Datatilsynet. Du kan også be om manuell vurdering uten AI-bistand per GDPR Art. 22.\n\n## Kontakt\n\nPersonvernombud: pvo@Acme.no\nTilsyn: Datatilsynet — postkasse@datatilsynet.no\nEU AI Act-tilsyn: under etablering (Digitaliseringsdirektoratet er forventet)\n"
         },
         "frimpact": {
           "input": {},
-          "raw_markdown": "# FRIA (Fundamental Rights Impact Assessment) — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nHjemmel: EU AI Act Art. 27 (obligatorisk for offentlig sektor)\n\n## Vurderte rettigheter\n\n| Rettighet | Impact | Tiltak |\n|-----------|--------|--------|\n| Menneskeverd | 1 | Ingen reduksjon — saksbehandler tar endelig avgjørelse, ikke AI |\n| Rett til frihet og sikkerhet | 1 | Ingen frihetsberøvelse direkte fra AI; politi/domstol er reell beslutter |\n| Respekt for privatliv | 4 | Massiv overvåking via veikameraer — kompenseres med strenge oppbevaringsregler (90 dager), formålsbegrensning, og minimering av kobling til objektregister |\n| Personvern | 4 | DPIA gjennomført; Datatilsynet konsultert; rettslig grunnlag i interne retningslinjer §13 — likevel høy impact pga skala |\n| Ikke-diskriminering | 3 | Algoritmisk bias-testing på objekt-ID fra utenlandske registre (lavere Acme Kunde-chatbot-nøyaktighet) — kvartalsvis review |\n| Ytringsfrihet og informasjonsfrihet | 0 | Ikke berørt |\n| Forsamlingsfrihet | 0 | Ikke berørt |\n| Religionsfrihet | 0 | Ikke berørt |\n| Eiendomsrett | 2 | Gebyr/sanksjoner berører eiendomsrett — kompenseres med klagemulighet og rettslig prøving |\n| Rett til effektivt rettsmiddel | 2 | Klageadgang sikret; menneskelig review garantert; AI-forklaring tilgjengelig for klager |\n| Barns rettigheter | 1 | Lav direkte påvirkning; barn er sjelden registrerte førere |\n| Eldres rettigheter | 2 | Eldre kan ha vanskeligere for å klage digitalt — papir-klage må fortsatt være tilgjengelig |\n\n## Konklusjon\n\nTre rettigheter har høy impact (3-4): privatliv, personvern og ikke-diskriminering. Tiltakene reduserer reell risiko, men FRIA må re-evalueres årlig per Art. 27(2).\n"
+          "raw_markdown": "# FRIA (Fundamental Rights Impact Assessment) — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nHjemmel: EU AI Act Art. 27 (obligatorisk for offentlig sektor)\n\n## Vurderte rettigheter\n\n| Rettighet | Impact | Tiltak |\n|-----------|--------|--------|\n| Menneskeverd | 1 | Ingen reduksjon — saksbehandler tar endelig avgjørelse, ikke AI |\n| Rett til frihet og sikkerhet | 0 | Ikke berørt — systemet vurderer bare søknader om en økonomisk ytelse |\n| Respekt for privatliv | 4 | Samtaler og vedlegg inneholder ofte helse-, familie- og økonomiopplysninger som innbyggere oppgir fritt — kompenseres med strenge oppbevaringsregler (90 dager for samtalelogger), formålsbegrensning, og minimering av kobling til fagsystemet |\n| Personvern | 4 | DPIA gjennomført; Datatilsynet konsultert; rettslig grunnlag i interne retningslinjer §13 — likevel høy impact pga skala |\n| Ikke-diskriminering | 3 | Algoritmisk bias-testing på henvendelser og vedlegg på andre språk enn norsk (lavere tolkningsnøyaktighet) — kvartalsvis review |\n| Ytringsfrihet og informasjonsfrihet | 0 | Ikke berørt |\n| Forsamlingsfrihet | 0 | Ikke berørt |\n| Religionsfrihet | 0 | Ikke berørt |\n| Rett til sosial sikring | 2 | Feilaktig forhåndsvurdering kan forsinke en ytelse — kompenseres med at saksbehandler vurderer hver søknad, og med klagemulighet |\n| Rett til effektivt rettsmiddel | 2 | Klageadgang sikret; menneskelig review garantert; AI-forklaring tilgjengelig for klager |\n| Barns rettigheter | 1 | Lav direkte påvirkning; barn søker ikke selv, men bor i husstander som søker |\n| Eldres rettigheter | 2 | Eldre kan ha vanskeligere for å klage digitalt — papir-klage må fortsatt være tilgjengelig |\n\n## Konklusjon\n\nTre rettigheter har høy impact (3-4): privatliv, personvern og ikke-diskriminering. Tiltakene reduserer reell risiko, men FRIA må re-evalueres årlig per Art. 27(2).\n"
         },
         "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 | 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"
+          "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 språkgruppe |\n| Robusthet under adversarielle forhold | betinget | Test-suite mangler skannede, skjeve og håndskrevne vedlegg |\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": {},
-          "raw_markdown": "# DPIA / PVK — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nMetodikk: Datatilsynets veileder + ISO/IEC 29134\n\n## Risikomatrise (5×5)\n\n| Trussel | Sannsynlighet | Konsekvens | Score | Nivå |\n|---------|---------------|------------|-------|------|\n| Feilaktig objekt-ID-tolkning fører til urettmessig sanksjon | 3 | 4 | 12 | medium |\n| Massiv lokasjonsdata-lekkasje fra objektregister | 2 | 5 | 10 | medium |\n| AI-forklaring viser sensitiv kontekst om eier | 3 | 3 | 9 | medium |\n| Stratifisert bias mot utenlandske objekt-ID | 4 | 3 | 12 | medium |\n| Fysisk angrep på sensordata skaper deteksjonshull | 2 | 2 | 4 | low |\n| Insider-misbruk for sporing av enkeltpersoner | 2 | 5 | 10 | medium |\n| Auto-flagging utløser kjedereaksjon ved system-feil | 1 | 5 | 5 | low |\n| Subject Access Request (GDPR Art. 15) ignoreres | 3 | 3 | 9 | medium |\n\n## Trusler\n\n| ID | Beskrivelse | Severity | Tiltak |\n|----|-------------|----------|--------|\n| T-001 | Feilaktig OCR av objekt-ID | high | Konfidensgrad-cutoff på 0.95; saksbehandler-review under cutoff |\n| T-002 | Lokasjonsdata-lekkasje | critical | Pseudonymisering ved lagring; HSM-backed nøkler i Azure Key Vault |\n| T-003 | Kontekst-eksponering i AI-forklaring | high | Filter på sensitive felt; kontekst kun til autorisert saksbehandler |\n| T-004 | Bias mot utenlandske registre | high | Kvartalsvis stratifisert testing; juster modell ved >5% avvik |\n| T-005 | Insider-misbruk | critical | Audit-logging på alle oppslag; SIEM-deteksjon av unormale mønstre |\n\n## Tiltak\n\n| ID | Tiltak | Status | Eier |\n|----|--------|--------|------|\n| M-001 | Cutoff-konfidensgrad implementert | done | Tech Lead |\n| M-002 | Pseudonymisering pilotert | in-progress | Sikkerhetsarkitekt |\n| M-003 | Bias-test-pipeline etablert | planned | Data Scientist |\n| M-004 | Audit-logging utrullet | done | Drift |\n| M-005 | SIEM-regler kalibrert | in-progress | SOC |\n\n## Konklusjon\n\nRestrisiko: 4×3 → 2×2\n\nRestrisiko etter tiltak: medium-lav. DPIA godkjent av Datatilsynet 2026-04-22.\n"
+          "raw_markdown": "# DPIA / PVK — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nMetodikk: Datatilsynets veileder + ISO/IEC 29134\n\n## Risikomatrise (5×5)\n\n| Trussel | Sannsynlighet | Konsekvens | Score | Nivå |\n|---------|---------------|------------|-------|------|\n| Feilaktig vedleggstolkning fører til urettmessig avslag | 3 | 4 | 12 | medium |\n| Massiv lekkasje av økonomiopplysninger fra fagsystemet | 2 | 5 | 10 | medium |\n| AI-forklaring viser sensitiv kontekst om søker | 3 | 3 | 9 | medium |\n| Stratifisert bias mot henvendelser på andre språk | 4 | 3 | 12 | medium |\n| Manipulerte vedlegg skaper vurderingshull | 2 | 2 | 4 | low |\n| Insider-misbruk for oppslag på enkeltpersoner | 2 | 5 | 10 | medium |\n| Auto-flagging utløser kjedereaksjon ved system-feil | 1 | 5 | 5 | low |\n| Subject Access Request (GDPR Art. 15) ignoreres | 3 | 3 | 9 | medium |\n\n## Trusler\n\n| ID | Beskrivelse | Severity | Tiltak |\n|----|-------------|----------|--------|\n| T-001 | Feilaktig OCR av vedlegg | high | Konfidensgrad-cutoff på 0.95; saksbehandler-review under cutoff |\n| T-002 | Lekkasje av økonomiopplysninger | critical | Pseudonymisering ved lagring; HSM-backed nøkler i Azure Key Vault |\n| T-003 | Kontekst-eksponering i AI-forklaring | high | Filter på sensitive felt; kontekst kun til autorisert saksbehandler |\n| T-004 | Bias mot henvendelser på andre språk | high | Kvartalsvis stratifisert testing; juster modell ved >5% avvik |\n| T-005 | Insider-misbruk | critical | Audit-logging på alle oppslag; SIEM-deteksjon av unormale mønstre |\n\n## Tiltak\n\n| ID | Tiltak | Status | Eier |\n|----|--------|--------|------|\n| M-001 | Cutoff-konfidensgrad implementert | done | Tech Lead |\n| M-002 | Pseudonymisering pilotert | in-progress | Sikkerhetsarkitekt |\n| M-003 | Bias-test-pipeline etablert | planned | Data Scientist |\n| M-004 | Audit-logging utrullet | done | Drift |\n| M-005 | SIEM-regler kalibrert | in-progress | SOC |\n\n## Konklusjon\n\nRestrisiko: 4×3 → 2×2\n\nRestrisiko etter tiltak: medium-lav. DPIA godkjent av Datatilsynet 2026-04-22.\n"
         },
         "security": {
           "input": {},
@@ -276,23 +276,23 @@
         },
         "ros": {
           "input": {},
-          "raw_markdown": "# ROS-analyse — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nMetodikk: NS 5814 / ISO 31000 + AI-trusselbibliotek\n\n## Risikomatrise (5×5)\n\n| Trussel | Sannsynlighet | Konsekvens | Score | Nivå |\n|---------|---------------|------------|-------|------|\n| Modell-drift som degraderer nøyaktighet | 4 | 3 | 12 | medium |\n| Treningsdata-bias mot småbiler eller MC | 3 | 3 | 9 | medium |\n| Adversarielle plate-design unngår OCR | 2 | 4 | 8 | medium |\n| API-utilgjengelighet i kritisk periode | 2 | 4 | 8 | medium |\n| Klage-saksbehandling overbelastet ved skalering | 4 | 3 | 12 | medium |\n| Datatap pga manglende georedundans | 1 | 5 | 5 | low |\n| Misbruk av AI-forklaring som bevis | 3 | 4 | 12 | medium |\n| Kjedevirkning ved feil i objektregister | 2 | 5 | 10 | medium |\n\n## Radar-akser (7 dimensjoner)\n\n| Akse | Score (1-5) |\n|------|-------------|\n| Tilgjengelighet | 4 |\n| Konfidensialitet | 4 |\n| Integritet | 4 |\n| Sporbarhet | 5 |\n| Pålitelighet | 3 |\n| Robusthet | 3 |\n| Etterlevelse | 4 |\n\n## Trusler\n\n| ID | Beskrivelse | Severity | Tiltak |\n|----|-------------|----------|--------|\n| T-101 | Modell-drift over tid | high | Månedlig retraining-pipeline; alarm ved >2% nøyaktighetsfall |\n| T-102 | Bias mot småbiler/MC | high | Stratifisert evaluering ved hver release |\n| T-103 | Adversarielle plate-design | medium | Robusthetstest mot kjente angreps-mønstre |\n| T-104 | API-utilgjengelighet | medium | Multi-region failover med RTO 1t |\n| T-105 | Saksbehandlings-overbelastning | high | Automatisk batching + prioriteringsregler |\n\n## Tiltak\n\n| ID | Tiltak | Status | Eier |\n|----|--------|--------|------|\n| M-101 | Retraining-pipeline etablert | done | MLOps |\n| M-102 | Stratifisert evalueringssett bygget | in-progress | Data Scientist |\n| M-103 | Robusthetstest planlagt | planned | Sikkerhetsarkitekt |\n| M-104 | Multi-region failover testet | done | Drift |\n| M-105 | Batching-logikk implementert | in-progress | Tech Lead |\n\n## Top-risikoer\n\n| ID | Trussel | Score | Severity |\n|----|---------|-------|----------|\n| T-101 | Modell-drift over tid | 12 | high |\n| T-105 | Saksbehandlings-overbelastning | 12 | high |\n| T-107 | Misbruk av AI-forklaring som bevis | 12 | high |\n| T-108 | Kjedevirkning ved feil i objektregister | 10 | high |\n| T-103 | Bias mot småbiler/MC | 9 | medium |\n\nRestrisiko: 4×3 → 2×2\n\n## Anbefaling\n\nROS godkjent av seksjonsleder 2026-04-25 forutsatt at M-103 (robusthetstest) ferdigstilles innen 2026-06-15. Re-evaluering ved hver modell-release eller ved endring i sak-volum > 20%.\n\n## Konklusjon\n\nRestrisiko etter tiltak: medium. ROS godkjent av seksjonsleder 2026-04-25.\n"
+          "raw_markdown": "# ROS-analyse — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nMetodikk: NS 5814 / ISO 31000 + AI-trusselbibliotek\n\n## Risikomatrise (5×5)\n\n| Trussel | Sannsynlighet | Konsekvens | Score | Nivå |\n|---------|---------------|------------|-------|------|\n| Modell-drift som degraderer nøyaktighet | 4 | 3 | 12 | medium |\n| Treningsdata-bias mot nynorsk og andre språk | 3 | 3 | 9 | medium |\n| Manipulerte vedlegg unngår OCR-kontroll | 2 | 4 | 8 | medium |\n| API-utilgjengelighet i kritisk periode | 2 | 4 | 8 | medium |\n| Klage-saksbehandling overbelastet ved skalering | 4 | 3 | 12 | medium |\n| Datatap pga manglende georedundans | 1 | 5 | 5 | low |\n| Misbruk av AI-forklaring som vedtaksbegrunnelse | 3 | 4 | 12 | medium |\n| Kjedevirkning ved feil i fagsystemet | 2 | 5 | 10 | medium |\n\n## Radar-akser (7 dimensjoner)\n\n| Akse | Score (1-5) |\n|------|-------------|\n| Tilgjengelighet | 4 |\n| Konfidensialitet | 4 |\n| Integritet | 4 |\n| Sporbarhet | 5 |\n| Pålitelighet | 3 |\n| Robusthet | 3 |\n| Etterlevelse | 4 |\n\n## Trusler\n\n| ID | Beskrivelse | Severity | Tiltak |\n|----|-------------|----------|--------|\n| T-101 | Modell-drift over tid | high | Månedlig retraining-pipeline; alarm ved >2% nøyaktighetsfall |\n| T-102 | Bias mot nynorsk og andre språk | high | Stratifisert evaluering ved hver release |\n| T-103 | Manipulerte vedlegg | medium | Robusthetstest mot kjente angreps-mønstre |\n| T-104 | API-utilgjengelighet | medium | Multi-region failover med RTO 1t |\n| T-105 | Saksbehandlings-overbelastning | high | Automatisk batching + prioriteringsregler |\n\n## Tiltak\n\n| ID | Tiltak | Status | Eier |\n|----|--------|--------|------|\n| M-101 | Retraining-pipeline etablert | done | MLOps |\n| M-102 | Stratifisert evalueringssett bygget | in-progress | Data Scientist |\n| M-103 | Robusthetstest planlagt | planned | Sikkerhetsarkitekt |\n| M-104 | Multi-region failover testet | done | Drift |\n| M-105 | Batching-logikk implementert | in-progress | Tech Lead |\n\n## Top-risikoer\n\n| ID | Trussel | Score | Severity |\n|----|---------|-------|----------|\n| T-101 | Modell-drift over tid | 12 | high |\n| T-105 | Saksbehandlings-overbelastning | 12 | high |\n| T-107 | Misbruk av AI-forklaring som vedtaksbegrunnelse | 12 | high |\n| T-108 | Kjedevirkning ved feil i fagsystemet | 10 | high |\n| T-103 | Bias mot nynorsk og andre språk | 9 | medium |\n\nRestrisiko: 4×3 → 2×2\n\n## Anbefaling\n\nROS godkjent av seksjonsleder 2026-04-25 forutsatt at M-103 (robusthetstest) ferdigstilles innen 2026-06-15. Re-evaluering ved hver modell-release eller ved endring i sak-volum > 20%.\n\n## Konklusjon\n\nRestrisiko etter tiltak: medium. ROS godkjent av seksjonsleder 2026-04-25.\n"
         },
         "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-12-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 henvendelser på andre språk. |\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": {},
-          "raw_markdown": "# Kostnadsestimat — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nPeriode: 12 måneder fra produksjonssetting\nValuta: NOK\n\n## Distribusjon (P10/P50/P90)\n\n| Persentil | Månedlig (NOK) | Årlig (NOK) |\n|-----------|----------------|-------------|\n| P10 | 78 000 | 936 000 |\n| P50 | 142 000 | 1 704 000 |\n| P90 | 285 000 | 3 420 000 |\n\n## Månedlig fordeling (P50)\n\n| Komponent | Kostnad (NOK/mnd) |\n|-----------|-------------------|\n| Azure AI Services (OCR + classification) | 64 000 |\n| Azure OpenAI (forklaringsmodell) | 28 000 |\n| Azure AI Search (indeks for objektregister) | 12 000 |\n| Storage (blob + cosmos for audit) | 8 500 |\n| Compute (Container Apps for orchestration) | 11 000 |\n| Networking (Private Endpoints + egress) | 5 200 |\n| Monitoring (Sentinel + Log Analytics) | 9 800 |\n| Backup og DR | 3 500 |\n\n## TCO-tabell (3 år)\n\n| År | Capex | Opex | Total | Akkumulert |\n|----|-------|------|-------|------------|\n| År 1 | 850 000 | 1 704 000 | 2 554 000 | 2 554 000 |\n| År 2 | 120 000 | 1 875 000 | 1 995 000 | 4 549 000 |\n| År 3 | 80 000 | 2 060 000 | 2 140 000 | 6 689 000 |\n\n## Kostnadsdrivere\n\n- Datavolum: ~12 millioner Acme Kunde-chatbot-deteksjoner/mnd\n- Forklaring-prompt-tokens: ~250 tokens per flagged hendelse\n- Reservert kapasitet for 99.9% SLA\n\n## Konfidensgradering\n\nP50 er beregnet med 95% konfidens basert på 6 måneder pilot-data. P90 inkluderer 2× volum-skalering ved fullnasjonal utrulling. P10 forutsetter optimaliserte prompt-cache (>40% hit-rate).\n\n## Anbefaling\n\nBruk P50 som budsjettlinje. Sett alarm på 1.4× P50 (≈ 200 000/mnd) for tidlig varsling.\n"
+          "raw_markdown": "# Kostnadsestimat — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nPeriode: 12 måneder fra produksjonssetting\nValuta: NOK\n\n## Distribusjon (P10/P50/P90)\n\n| Persentil | Månedlig (NOK) | Årlig (NOK) |\n|-----------|----------------|-------------|\n| P10 | 78 000 | 936 000 |\n| P50 | 142 000 | 1 704 000 |\n| P90 | 285 000 | 3 420 000 |\n\n## Månedlig fordeling (P50)\n\n| Komponent | Kostnad (NOK/mnd) |\n|-----------|-------------------|\n| Azure AI Services (OCR + classification) | 64 000 |\n| Azure OpenAI (forklaringsmodell) | 28 000 |\n| Azure AI Search (indeks for regelverk og tjenesteinformasjon) | 12 000 |\n| Storage (blob + cosmos for audit) | 8 500 |\n| Compute (Container Apps for orchestration) | 11 000 |\n| Networking (Private Endpoints + egress) | 5 200 |\n| Monitoring (Sentinel + Log Analytics) | 9 800 |\n| Backup og DR | 3 500 |\n\n## TCO-tabell (3 år)\n\n| År | Capex | Opex | Total | Akkumulert |\n|----|-------|------|-------|------------|\n| År 1 | 850 000 | 1 704 000 | 2 554 000 | 2 554 000 |\n| År 2 | 120 000 | 1 875 000 | 1 995 000 | 4 549 000 |\n| År 3 | 80 000 | 2 060 000 | 2 140 000 | 6 689 000 |\n\n## Kostnadsdrivere\n\n- Datavolum: ~1,2 millioner chatbot-meldinger og vedlegg/mnd\n- Forklaring-prompt-tokens: ~250 tokens per flaggede søknad\n- Reservert kapasitet for 99.9% SLA\n\n## Konfidensgradering\n\nP50 er beregnet med 95% konfidens basert på 6 måneder pilot-data. P90 inkluderer 2× volum-skalering ved utvidelse til flere tjenesteområder. P10 forutsetter optimaliserte prompt-cache (>40% hit-rate).\n\n## Anbefaling\n\nBruk P50 som budsjettlinje. Sett alarm på 1.4× P50 (≈ 200 000/mnd) for tidlig varsling.\n"
         },
         "license": {
           "input": {},
-          "raw_markdown": "# Lisens-kapabilitetsmatrise — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nVurderingsdato: 2026-04-30\n\n## Matrise\n\n| Kapabilitet | M365 E3 | M365 E5 | Copilot for M365 | Copilot Studio | Azure AI Foundry |\n|-------------|---------|---------|------------------|----------------|------------------|\n| OCR av objekt-ID | missing | missing | missing | conditional | available |\n| Custom modell-trening | missing | missing | missing | missing | available |\n| Audit-logging på AI-input | missing | available | available | available | available |\n| Customer-managed keys | missing | available | conditional | conditional | available |\n| Private Endpoints | missing | available | missing | conditional | available |\n| saksbehandler-co-pilot UI | missing | missing | available | available | conditional |\n| Norsk språkstøtte i prompts | available | available | available | available | available |\n| Compliance-pakke for leverandøren | missing | available | conditional | conditional | available |\n| Real-time inference (<100ms) | missing | missing | missing | missing | available |\n| Batch-inference for nattlige jobber | missing | missing | missing | missing | available |\n\n## Status-betydning\n\n- available: Inkludert i lisensen, klar til bruk\n- cost: Tilgjengelig som tillegg, krever separat fakturering\n- conditional: Kan brukes med begrensninger eller add-on\n- missing: Ikke tilgjengelig på dette lisensnivået\n\n## Sammendrag\n\nAzure AI Foundry er eneste lisens som dekker alle kjernekapabiliteter. Copilot Studio passer for saksbehandler-UI men kan ikke håndtere OCR/custom modeller alene. Hybrid: Foundry (kjerne) + Copilot Studio (UI) gir best dekning.\n\n## Anbefaling\n\nBruk Azure AI Foundry for AI-tjenester (OCR, klassifisering, forklaring). Hold M365 E5 på saksbehandler-arbeidsstasjoner for audit-logging og compliance-pakke. Vurder Copilot Studio i fase 2 for saksbehandler-co-pilot.\n"
+          "raw_markdown": "# Lisens-kapabilitetsmatrise — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nVurderingsdato: 2026-04-30\n\n## Matrise\n\n| Kapabilitet | M365 E3 | M365 E5 | Copilot for M365 | Copilot Studio | Azure AI Foundry |\n|-------------|---------|---------|------------------|----------------|------------------|\n| OCR av vedlegg | missing | missing | missing | conditional | available |\n| Custom modell-trening | missing | missing | missing | missing | available |\n| Audit-logging på AI-input | missing | available | available | available | available |\n| Customer-managed keys | missing | available | conditional | conditional | available |\n| Private Endpoints | missing | available | missing | conditional | available |\n| saksbehandler-co-pilot UI | missing | missing | available | available | conditional |\n| Norsk språkstøtte i prompts | available | available | available | available | available |\n| Compliance-pakke for leverandøren | missing | available | conditional | conditional | available |\n| Real-time inference (<100ms) | missing | missing | missing | missing | available |\n| Batch-inference for nattlige jobber | missing | missing | missing | missing | available |\n\n## Status-betydning\n\n- available: Inkludert i lisensen, klar til bruk\n- cost: Tilgjengelig som tillegg, krever separat fakturering\n- conditional: Kan brukes med begrensninger eller add-on\n- missing: Ikke tilgjengelig på dette lisensnivået\n\n## Sammendrag\n\nAzure AI Foundry er eneste lisens som dekker alle kjernekapabiliteter. Copilot Studio passer for saksbehandler-UI men kan ikke håndtere OCR/custom modeller alene. Hybrid: Foundry (kjerne) + Copilot Studio (UI) gir best dekning.\n\n## Anbefaling\n\nBruk Azure AI Foundry for AI-tjenester (OCR, klassifisering, forklaring). Hold M365 E5 på saksbehandler-arbeidsstasjoner for audit-logging og compliance-pakke. Vurder Copilot Studio i fase 2 for saksbehandler-co-pilot.\n"
         },
         "migrate": {
           "input": {},
-          "raw_markdown": "# Migrasjonsplan — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nFra: On-prem OCR + manuell klassifisering\nTil: Azure AI Foundry + saksbehandler-co-pilot\n\n## Faser\n\n### Fase 1 — Foundry-fundament (uker 1-6)\n\nVarighet: 6 uker\nStatus: done\n\nMilepæler:\n- Hub + projects opprettet i West Europe\n- Network isolation: Private Endpoints + Vnet integration\n- Identity: Entra ID-integrasjon med PIM\n- Logging: OpenTelemetry → Sentinel pipeline\n\nSuksesskriterier:\n- Pilot OCR-modell deployert med <100ms latency P95\n- Audit-logg fanger 100% av inferences\n- Sikkerhetsarkitekt godkjenner foundation-design\n\n### Fase 2 — Modell-trening og baseline (uker 7-14)\n\nVarighet: 8 uker\nStatus: done\n\nMilepæler:\n- Treningsdata kuratert (200k norske objekt-ID, stratifisert)\n- Custom modell trent på Azure ML\n- Baseline-nøyaktighet etablert (mål: ≥96% F1)\n- Bias-evaluering på utenlandske registre fullført\n\nSuksesskriterier:\n- F1 ≥ 96% overall, ≥ 92% per objekter-segment\n- Drift-deteksjon kalibrert med terskel\n- ROS-revisjon godkjent\n\n### Fase 3 — saksbehandler-co-pilot (uker 15-22)\n\nVarighet: 8 uker\nStatus: active\n\nMilepæler:\n- Forklaringsmodell (GPT-4 Turbo) integrert via Foundry\n- saksbehandler-UI bygget (Copilot Studio + Power Platform)\n- Workflow: AI flagger → saksbehandler reviewer → klar for sanksjon\n- Brukertest med 12 saksbehandler fra ulike regioner\n\nSuksesskriterier:\n- Saksbehandlingstid -40% vs baseline\n- saksbehandler-tillit >7/10 i post-pilot survey\n- Ingen kritiske UX-feil\n\n### Fase 4 — Compliance og produksjonssetting (uker 23-28)\n\nVarighet: 6 uker\nStatus: planned\n\nMilepæler:\n- FRIA gjennomført og godkjent\n- Conformity assessment ferdigstilt per Annex VI\n- DPIA oppdatert med nye operasjonelle data\n- Produksjonssetting til 3 piloter (Oslo, Bergen, Trondheim)\n\nSuksesskriterier:\n- Personvernombud signerer DPIA\n- Ingen open critical-funn fra arkitekturgjennomgang\n- Stabil 99.9% uptime i 30 dager pilot\n\n## Risiko\n\n| Risiko | Sannsynlighet | Konsekvens | Tiltak |\n|--------|---------------|------------|--------|\n| Custom modell underyter mot 96% mål | medium | high | Backup-strategi: bruk Azure AI Vision OCR som fallback |\n| saksbehandler-motstand mot AI | medium | medium | Tidlig involvering; transparent forklaring; opt-out på enkelt-saker |\n| FRIA blokkerer fase 4 | low | high | Pre-FRIA-kjøring i fase 2 for tidlig varsling |\n| Cost-overrun ved skalering | medium | medium | Reserved capacity-binding etter fase 3 |\n\n## Total varighet\n\n28 uker (~7 måneder). Avhengighet: Foundry-fundament må være ferdig før modell-trening starter.\n"
+          "raw_markdown": "# Migrasjonsplan — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nFra: On-prem OCR + manuell klassifisering\nTil: Azure AI Foundry + saksbehandler-co-pilot\n\n## Faser\n\n### Fase 1 — Foundry-fundament (uker 1-6)\n\nVarighet: 6 uker\nStatus: done\n\nMilepæler:\n- Hub + projects opprettet i West Europe\n- Network isolation: Private Endpoints + Vnet integration\n- Identity: Entra ID-integrasjon med PIM\n- Logging: OpenTelemetry → Sentinel pipeline\n\nSuksesskriterier:\n- Pilot OCR-modell deployert med <100ms latency P95\n- Audit-logg fanger 100% av inferences\n- Sikkerhetsarkitekt godkjenner foundation-design\n\n### Fase 2 — Modell-trening og baseline (uker 7-14)\n\nVarighet: 8 uker\nStatus: done\n\nMilepæler:\n- Treningsdata kuratert (200k anonymiserte vedlegg, stratifisert på dokumenttype og språk)\n- Custom modell trent på Azure ML\n- Baseline-nøyaktighet etablert (mål: ≥96% F1)\n- Bias-evaluering på henvendelser og vedlegg på andre språk fullført\n\nSuksesskriterier:\n- F1 ≥ 96% overall, ≥ 92% per dokumenttype\n- Drift-deteksjon kalibrert med terskel\n- ROS-revisjon godkjent\n\n### Fase 3 — saksbehandler-co-pilot (uker 15-22)\n\nVarighet: 8 uker\nStatus: active\n\nMilepæler:\n- Forklaringsmodell (GPT-4 Turbo) integrert via Foundry\n- saksbehandler-UI bygget (Copilot Studio + Power Platform)\n- Workflow: AI flagger → saksbehandler reviewer → klar for vedtak\n- Brukertest med 12 saksbehandlere fra ulike tjenesteområder\n\nSuksesskriterier:\n- Saksbehandlingstid -40% vs baseline\n- saksbehandler-tillit >7/10 i post-pilot survey\n- Ingen kritiske UX-feil\n\n### Fase 4 — Compliance og produksjonssetting (uker 23-28)\n\nVarighet: 6 uker\nStatus: planned\n\nMilepæler:\n- FRIA gjennomført og godkjent\n- Conformity assessment ferdigstilt per Annex VI\n- DPIA oppdatert med nye operasjonelle data\n- Produksjonssetting i 3 pilotbydeler\n\nSuksesskriterier:\n- Personvernombud signerer DPIA\n- Ingen open critical-funn fra arkitekturgjennomgang\n- Stabil 99.9% uptime i 30 dager pilot\n\n## Risiko\n\n| Risiko | Sannsynlighet | Konsekvens | Tiltak |\n|--------|---------------|------------|--------|\n| Custom modell underyter mot 96% mål | medium | high | Backup-strategi: bruk Azure AI Vision OCR som fallback |\n| saksbehandler-motstand mot AI | medium | medium | Tidlig involvering; transparent forklaring; opt-out på enkelt-saker |\n| FRIA blokkerer fase 4 | low | high | Pre-FRIA-kjøring i fase 2 for tidlig varsling |\n| Cost-overrun ved skalering | medium | medium | Reserved capacity-binding etter fase 3 |\n\n## Total varighet\n\n28 uker (~7 måneder). Avhengighet: Foundry-fundament må være ferdig før modell-trening starter.\n"
         },
         "adr": {
           "input": {},
@@ -300,15 +300,15 @@
         },
         "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-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"
+          "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 i 3 bydeler Q4 2026\n- Full utrulling Q2 2027\n\n## Restrisiko\n\nEtter foreslåtte tiltak: medium. Hovedeksponering: bias mot henvendelser på andre språk enn norsk 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": {},
-          "raw_markdown": "# POC-plan — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nPOC-mål: Validere at Azure AI Foundry kan dekke OCR + forklaring + audit innen tids- og kostbudsjett\n\n## Faser\n\n### Fase 1 — Foundation (uker 1-2)\n\nVarighet: 2 uker\nStatus: done\n\nMilepæler:\n- Foundry hub + project i West Europe\n- Identity og networking konfigurert\n- Sample-data uploadet (10k anonymiserte objekt-ID)\n\nSuksesskriterier:\n- Inferens-endpoint nåbart fra dev-Vnet via Private Endpoint\n- Audit-logg fanger første test-inferens\n- Cost-monitor viser daglig forbruk i Azure portal\n\n### Fase 2 — OCR-modell (uker 3-5)\n\nVarighet: 3 uker\nStatus: active\n\nMilepæler:\n- Pre-trent Azure AI Vision OCR pilotert\n- Custom fine-tune på 10k objekt-ID\n- Sammenligning av accuracy/latency mellom de to\n\nSuksesskriterier:\n- F1 ≥ 92% på pilot-sett (lavere mål enn produksjon, akseptabelt for POC)\n- Latency P95 < 200ms\n- Inference-cost ≤ NOK 0.04 per kall\n\n### Fase 3 — Forklarings-loop (uker 6-7)\n\nVarighet: 2 uker\nStatus: planned\n\nMilepæler:\n- GPT-4 Turbo via Foundry integrert\n- Prompt-template for forklaring av flagged sak\n- saksbehandler-mock UI (en enkel webside) prøvd ut med 3 brukere\n\nSuksesskriterier:\n- Forklaring referer til konfidens og kontekst korrekt i 95% av tilfellene\n- saksbehandler-feedback kvalitativt positiv (\"forståelig, men trenger justering\")\n- Prompt-tokens under 250 i snitt per sak\n\n### Fase 4 — Compliance-pre-check (uke 8)\n\nVarighet: 1 uke\nStatus: planned\n\nMilepæler:\n- Audit-logg mot EU AI Act Art. 12-krav\n- Customer-managed keys verifisert\n- Pre-DPIA-sjekk gjort med Datatilsynet\n\nSuksesskriterier:\n- Audit-logg dekker 100% av inferences med tidsstempel + bruker\n- Personvernombud signer pre-DPIA-utkast\n- Ingen åpenbare GDPR-blokkere\n\n## Risiko\n\n| Risiko | Sannsynlighet | Konsekvens | Tiltak |\n|--------|---------------|------------|--------|\n| Custom OCR-modell underyter pre-trent | medium | medium | Aksepter pre-trent for POC; planlegg custom for full prod |\n| Foundry-quota i West Europe utilstrekkelig | low | medium | Reserver kapasitet før POC starter |\n| saksbehandler-recruitment forsinker fase 3 | medium | low | Bruk interne ressurser i AI-teamet som mock |\n| Audit-logg-format ikke kompatibelt med Sentinel | low | medium | Test integrasjon i fase 1 |\n\n## POC-Verdict: BETINGET\n\nPilot-fase 1 fullført med F1=0.94 og inference-cost 0.038 NOK/kall (under budsjett). Fase 2 pågår — sammenligning av custom fine-tune mot pre-trent OCR i progress. Forklarings-loop og compliance-pre-check planlagt for siste halvdel.\n\n## Total varighet\n\n8 uker. Beslutningskriterium for full prosjektgodkjenning: alle 4 fasers suksesskriterier møtt.\n"
+          "raw_markdown": "# POC-plan — Acme Kunde-chatbot\n\nSystem: Acme Kunde-chatbot (Acme Kommune)\nPOC-mål: Validere at Azure AI Foundry kan dekke OCR + forklaring + audit innen tids- og kostbudsjett\n\n## Faser\n\n### Fase 1 — Foundation (uker 1-2)\n\nVarighet: 2 uker\nStatus: done\n\nMilepæler:\n- Foundry hub + project i West Europe\n- Identity og networking konfigurert\n- Sample-data uploadet (10k anonymiserte vedlegg)\n\nSuksesskriterier:\n- Inferens-endpoint nåbart fra dev-Vnet via Private Endpoint\n- Audit-logg fanger første test-inferens\n- Cost-monitor viser daglig forbruk i Azure portal\n\n### Fase 2 — OCR-modell (uker 3-5)\n\nVarighet: 3 uker\nStatus: active\n\nMilepæler:\n- Pre-trent Azure AI Vision OCR pilotert\n- Custom fine-tune på 10k vedlegg\n- Sammenligning av accuracy/latency mellom de to\n\nSuksesskriterier:\n- F1 ≥ 92% på pilot-sett (lavere mål enn produksjon, akseptabelt for POC)\n- Latency P95 < 200ms\n- Inference-cost ≤ NOK 0.04 per kall\n\n### Fase 3 — Forklarings-loop (uker 6-7)\n\nVarighet: 2 uker\nStatus: planned\n\nMilepæler:\n- GPT-4 Turbo via Foundry integrert\n- Prompt-template for forklaring av flagged sak\n- saksbehandler-mock UI (en enkel webside) prøvd ut med 3 brukere\n\nSuksesskriterier:\n- Forklaring referer til konfidens og kontekst korrekt i 95% av tilfellene\n- saksbehandler-feedback kvalitativt positiv (\"forståelig, men trenger justering\")\n- Prompt-tokens under 250 i snitt per sak\n\n### Fase 4 — Compliance-pre-check (uke 8)\n\nVarighet: 1 uke\nStatus: planned\n\nMilepæler:\n- Audit-logg mot EU AI Act Art. 12-krav\n- Customer-managed keys verifisert\n- Pre-DPIA-sjekk gjort med Datatilsynet\n\nSuksesskriterier:\n- Audit-logg dekker 100% av inferences med tidsstempel + bruker\n- Personvernombud signer pre-DPIA-utkast\n- Ingen åpenbare GDPR-blokkere\n\n## Risiko\n\n| Risiko | Sannsynlighet | Konsekvens | Tiltak |\n|--------|---------------|------------|--------|\n| Custom OCR-modell underyter pre-trent | medium | medium | Aksepter pre-trent for POC; planlegg custom for full prod |\n| Foundry-quota i West Europe utilstrekkelig | low | medium | Reserver kapasitet før POC starter |\n| saksbehandler-recruitment forsinker fase 3 | medium | low | Bruk interne ressurser i AI-teamet som mock |\n| Audit-logg-format ikke kompatibelt med Sentinel | low | medium | Test integrasjon i fase 1 |\n\n## POC-Verdict: BETINGET\n\nPilot-fase 1 fullført med F1=0.94 og inference-cost 0.038 NOK/kall (under budsjett). Fase 2 pågår — sammenligning av custom fine-tune mot pre-trent OCR i progress. Forklarings-loop og compliance-pre-check planlagt for siste halvdel.\n\n## Total varighet\n\n8 uker. Beslutningskriterium for full prosjektgodkjenning: alle 4 fasers suksesskriterier møtt.\n"
         },
         "utredning": {
           "input": {},
-          "raw_markdown": "# AI-arkitekturutredning — Acme Kunde-chatbot for Acme Kommune\n\n## 1. Bakgrunn og formål\n\nAcme Kommune har siden 2018 driftet en on-prem Acme Kunde-chatbot-løsning for operasjonell analyse på tvers av leverandørens tjenesteportefølje. Løsningen er basert på et OCR-bibliotek fra 2017 og leveres som et lukket system uten mulighet for retrening eller forbedring av modell. Saksbehandlingen er manuell og tar i snitt 14 minutter per sak. Et internt AI-team utreder modernisering til en skybasert AI-plattform som støtter custom modell-trening, audit-logging på inferens-nivå, og saksbehandler-co-pilot.\n\n## 2. Mandat\n\nUtredningen skal:\n- Anbefale teknologivalg blant Azure AI Foundry, Azure ML+AKS, AWS SageMaker og on-prem GPU-cluster\n- Vurdere compliance-status mot EU AI Act, GDPR, sikkerhetsloven og arkivloven\n- Estimere TCO over 3 år\n- Identifisere risiko og foreslå mitigerende tiltak\n- Definere KPI-er for produksjonssetting\n\n## 3. Metode\n\nUtredningen kombinerer:\n- Kvalitativ analyse av compliance-krav per relevante lover og forskrifter\n- Kvantitativ TCO-analyse basert på 12 millioner Acme Kunde-chatbot-deteksjoner/mnd\n- Risikoanalyse per NS 5814 og DPIA per Datatilsynets veileder\n- Markedsundersøkelse av tilgjengelige plattformer fra Azure, AWS og GCP\n\n## 4. Funn\n\n### 4.1 Compliance\n\nEU AI Act klassifiserer systemet som høyrisiko (Annex III, punkt 6 — rettshåndhevelse). Acme Kommune er Provider og Deployer, hvilket trigger alle krav i Art. 9-15 + Art. 27 (FRIA) + Art. 49 (registrering).\n\n### 4.2 Teknologivalg\n\nAzure AI Foundry er anbefalt primær plattform fordi:\n- Full compliance-pakke for leverandøren\n- Customer-managed keys og Customer Lockbox tilgjengelig\n- Custom modell-trening via integrert Azure ML\n- Norsk dataresidens (West Europe + EU Data Boundary)\n\n### 4.3 TCO\n\n3-års TCO estimert til NOK 6.7M (P50). Hovedkostnad: Azure AI Services (38%) + Azure OpenAI (16%).\n\n### 4.4 Risiko\n\nHovedrisiko: bias mot utenlandske objekt-ID, modell-drift over tid, og manglende ABAC-implementering på saksbehandler-tilgang. Alle har konkrete tiltak.\n\n## 5. Konklusjon\n\nAnbefalt: gjennomfør 8-ukers POC før formell prosjektoppstart. Ved vellykket POC, full implementering over 28 uker mot produksjonssetting Q2 2027.\n\n## 6. Anbefaling\n\nGodkjenn POC-budsjett på NOK 1.2M og forenkle prosjekt-mandat for fase 1-4 ved positiv POC-evaluering.\n\n## 7. Referanser\n\n- EU AI Act 2024/1689\n- GDPR 2016/679\n- Sikkerhetsloven (LOV-2018-06-01-24)\n- Arkivloven (LOV-1992-12-04-126)\n- NS 5814:2008 — Krav til risikovurderinger\n- Datatilsynets veileder for AI og personvern (2024)\n"
+          "raw_markdown": "# AI-arkitekturutredning — Acme Kunde-chatbot for Acme Kommune\n\n## 1. Bakgrunn og formål\n\nAcme Kommune har siden 2018 driftet en on-prem Acme Kunde-chatbot-løsning for forhåndsvurdering av søknader på tvers av kommunens tjenesteportefølje. Løsningen er basert på et OCR-bibliotek fra 2017 og leveres som et lukket system uten mulighet for retrening eller forbedring av modell. Saksbehandlingen er manuell og tar i snitt 14 minutter per sak. Et internt AI-team utreder modernisering til en skybasert AI-plattform som støtter custom modell-trening, audit-logging på inferens-nivå, og saksbehandler-co-pilot.\n\n## 2. Mandat\n\nUtredningen skal:\n- Anbefale teknologivalg blant Azure AI Foundry, Azure ML+AKS, AWS SageMaker og on-prem GPU-cluster\n- Vurdere compliance-status mot EU AI Act, GDPR, sikkerhetsloven og arkivloven\n- Estimere TCO over 3 år\n- Identifisere risiko og foreslå mitigerende tiltak\n- Definere KPI-er for produksjonssetting\n\n## 3. Metode\n\nUtredningen kombinerer:\n- Kvalitativ analyse av compliance-krav per relevante lover og forskrifter\n- Kvantitativ TCO-analyse basert på 1,2 millioner chatbot-meldinger og vedlegg/mnd\n- Risikoanalyse per NS 5814 og DPIA per Datatilsynets veileder\n- Markedsundersøkelse av tilgjengelige plattformer fra Azure, AWS og GCP\n\n## 4. Funn\n\n### 4.1 Compliance\n\nEU AI Act klassifiserer systemet som høyrisiko (Annex III, punkt 5(a) — tilgang til offentlige ytelser). Acme Kommune er Provider og Deployer, hvilket trigger alle krav i Art. 9-15 + Art. 27 (FRIA) + Art. 49 (registrering).\n\n### 4.2 Teknologivalg\n\nAzure AI Foundry er anbefalt primær plattform fordi:\n- Full compliance-pakke for leverandøren\n- Customer-managed keys og Customer Lockbox tilgjengelig\n- Custom modell-trening via integrert Azure ML\n- Norsk dataresidens (West Europe + EU Data Boundary)\n\n### 4.3 TCO\n\n3-års TCO estimert til NOK 6.7M (P50). Hovedkostnad: Azure AI Services (38%) + Azure OpenAI (16%).\n\n### 4.4 Risiko\n\nHovedrisiko: bias mot henvendelser på andre språk enn norsk, modell-drift over tid, og manglende ABAC-implementering på saksbehandler-tilgang. Alle har konkrete tiltak.\n\n## 5. Konklusjon\n\nAnbefalt: gjennomfør 8-ukers POC før formell prosjektoppstart. Ved vellykket POC, full implementering over 28 uker mot produksjonssetting Q2 2027.\n\n## 6. Anbefaling\n\nGodkjenn POC-budsjett på NOK 1.2M og forenkle prosjekt-mandat for fase 1-4 ved positiv POC-evaluering.\n\n## 7. Referanser\n\n- EU AI Act 2024/1689\n- GDPR 2016/679\n- Sikkerhetsloven (LOV-2018-06-01-24)\n- Arkivloven (LOV-1992-12-04-126)\n- NS 5814:2008 — Krav til risikovurderinger\n- Datatilsynets veileder for AI og personvern (2024)\n"
         },
         "compare": {
           "input": {},
@@ -5617,7 +5617,7 @@
         sub: 'Hvem er dere?',
         fields: [
           { id: 'name', label: 'Virksomhetsnavn', type: 'text', required: true,
-            placeholder: 'f.eks. Bærum kommune, Statens vegvesen, Helse Sør-Øst RHF' },
+            placeholder: 'f.eks. Bærum kommune, Eksempeldirektoratet, Helse Sør-Øst RHF' },
           { id: 'description', label: 'Kort beskrivelse', type: 'textarea',
             placeholder: 'Hva gjør virksomheten? F.eks. "Kommune med 8 000 ansatte, ansvar for skole, helse og byggesak."' },
           { id: 'sector', label: 'Sektor', type: 'select', required: true,

playground/screenshots/MANIFEST.json

@@ -0,0 +1,31 @@
+{
+  "generator": "tests/screenshot/run.mjs",
+  "dir": "playground/screenshots/v1.15.0",
+  "demoStateSha256": "f952333f8cc8471c1bf0bfa0e4aff638bdb81b5c1351e4e0b1ca0fea7f24969f",
+  "files": {
+    "01-onboarding-empty-dark.png": "258c8e1d71ee0ef91ca9b0521939bc7b8ed340f1d2a8b477760463d21314da95",
+    "01-onboarding-empty-light.png": "bc0ddc7c386f3eb5d7d9a25f225563d10d917ac263c6df9571a0a8f558b4ebb7",
+    "02-project-overview-dark.png": "dbd45d1b49d33d7483f0bf6e22419e5e6621aec2b7802e6d6880ecc4498a855a",
+    "02-project-overview-light.png": "c98f83ce1f01d7367e10bbc30a97152c27777af55f4df2c62819d808b1f1d001",
+    "03-project-artifact-classify-dark.png": "ab8255ca57624ee81e3790561403934dbd516463c8d3fb2a36aa8d7640492a95",
+    "03-project-artifact-classify-light.png": "268386ca08b5ec5f9a7bb83dab928b4d2f9268781f99e29e0020243fd3926bd0",
+    "04-project-artifact-security-dark.png": "1b3cbc8ddbf0fba6af5de559fdf8208eb4ffe909fe2775d60e52443f53cf3b57",
+    "04-project-artifact-security-light.png": "ed95d278bcf41ebf9377f7a7641b022a14550694feb08a3e03195a347634dd28",
+    "05-project-artifact-ros-dark.png": "7f2bde4833fa35d30b79bc57c847c172d2383cdcfe85bd061860b7b7020602f8",
+    "05-project-artifact-ros-light.png": "02721873b69e2a8fd6636b0b3229035fc89e4af6d04f087228c2e214355f8991",
+    "06-project-artifact-cost-dark.png": "c2516e500aa6eb6b81ec6c770d8a771de653d78ff533b77f0f2c9e6b8f48c2bc",
+    "06-project-artifact-cost-light.png": "54a5d7994f8b660819d6b1302a8cef5605bea505bc729076621975de5f26ae24",
+    "07-project-artifact-summary-dark.png": "513cc3e39e8ee5a9dfa8201d881799e7b5023f1eb6afb96a40be13d9833ab093",
+    "07-project-artifact-summary-light.png": "7ddea4ad5aed3b273323312fe68e767e160adedae937cda9030153ef6107d04d",
+    "08-project-import-modal-dark.png": "72dcf6748bbb5b8227fa2e105e420d04f53270c6a812746ccd33c946807c980e",
+    "08-project-import-modal-light.png": "6fb21d479c6d6e8da4c29e748e2d9611c266fc2577f01bf23248f795dcec5b39",
+    "09-project-search-dark.png": "76ad042f2fb1bd8f6c23d4c7088bcbd8f2cbeb116c31143823c7d1f243502ffa",
+    "09-project-search-light.png": "6ca20d2830775837858c242070836f45a17b2e58067daa82569d9985383a511d",
+    "10-home-dark.png": "c4180d9ef9c379e90759b4ec2f07e43f453e69aff1ef44ad696162f3455dafbd",
+    "10-home-light.png": "60c8907dfbfc3ac69797524bbe2fca2928379d15def16540436fe23b055fc117",
+    "11-catalog-dark.png": "7e211e14fbd6f1fcfe5eb895065675ccfe9d86f69f110d0c812123665bb2c891",
+    "11-catalog-light.png": "47439db2e9b941d9a9d6ade2244d63143c48abaeb619c779d1310dac597a6337",
+    "12-onboarding-prefilled-dark.png": "c443ae30e9f63d29f6153293b388bd6e6d9256ee414ddc3ab1f712a8af8a5c11",
+    "12-onboarding-prefilled-light.png": "bc0ddc7c386f3eb5d7d9a25f225563d10d917ac263c6df9571a0a8f558b4ebb7"
+  }
+}