# Kildesporing og antakelsesregister

**Sist oppdatert:** 2026-02 (v1.0)
**Målgruppe:** Arkitekter som utarbeider AI-arkitekturvurderinger og utredninger
**Formål:** Sikre sporbarhet, transparens og etterprøvbarhet i arkitekturvurderinger
**Category:** Solution Architecture & Advisory
**Status:** Reference

---

## Om dette dokumentet

Enhver arkitekturvurdering bygger på en blanding av verifiserte fakta, kunnskapsbase-informasjon, eksperterfaring og antakelser. Denne referansefilen gir rammeverk for å klassifisere, dokumentere og validere kildene — slik at beslutningstakere vet hva de kan stole på og hva som må verifiseres.

---

## 1. Kildeklassifisering

### 1.1 Klassifiseringsnivåer

| Klasse | Betegnelse | Tillitsnivå | Definisjon | Eksempler | Holdbarhet |
|--------|-----------|-------------|------------|-----------|------------|
| **V** | **Verifisert** | Høyest | Bekreftet via MCP-verktøy (microsoft-learn, tavily) eller offisiell dokumentasjon i nåværende sesjon | MCP-søk i microsoft-learn som bekrefter GA-status for Azure OpenAI i Norway East; prisdata fra azure.microsoft.com/pricing | 1-6 måneder (avhenger av tjenestens modenhet) |
| **KB** | **Kunnskapsbase** | Høy | Fra plugin-kunnskapsbasen (references/). Kvalitetssikret ved opprettelse, men kan være foreldet. | Informasjon fra `platforms/copilot-studio.md`, `cost-models.md`, `security.md` | Sjekk "Sist oppdatert"-dato. Stale etter 6+ måneder. |
| **E** | **Ekspert** | Middels | Basert på arkitektens erfaring og fagkunnskap. Ikke verifisert mot offisiell kilde i denne sesjonen. | Arkitektens vurdering av integrasjonskompleksitet; erfaringsbaserte tidsestimater; beste-praksis-anbefalinger | Varierer. Mest robust for etablerte mønstre, minst for nye tjenester. |
| **A** | **Antakelse** | Lavest | Uverifisert antakelse. Kan være rimelig, men er ikke bekreftet. Må valideres. | "Vi antar at virksomheten har M365 E5-lisenser"; "Vi antar at Azure AI Search støtter semantic ranker i Norway East" | Må valideres før den brukes i beslutning. |

### 1.2 Visuelle markører

For bruk i utredningsdokumenter:

```markdown
Denne tjenesten er tilgjengelig i Norway East [V: microsoft-learn MCP, 2026-02-13]
Copilot Studio støtter custom topics med GPT-4o [KB: platforms/copilot-studio.md, 2026-01]
Integrasjonen med fagsystemet tar typisk 4-6 uker [E: erfaringsbasert]
Virksomheten har tilgjengelig Azure-abonnement [A: ikke verifisert — må avklares]
```

### 1.3 Regler for kildeklassifisering

1. **Alltid bruk høyest tilgjengelig klasse.** Hvis du kan verifisere via MCP, gjør det — ikke nøy deg med KB.
2. **Nedgrader ved usikkerhet.** Hvis KB-informasjon er eldre enn 6 måneder, vurder å verifisere via MCP eller nedgrader til E.
3. **Vær ærlig om antakelser.** Det er bedre å merke noe som A enn å presentere det som V.
4. **Verifiser kritiske antakelser.** Antakelser som påvirker anbefalingen må valideres — enten i sesjonen eller som oppfølgingspunkt.

---

## 2. Antakelsesregister — mal

### 2.1 Registertabell

```markdown
### Antakelsesregister

**Prosjekt:** [Prosjektnavn]
**Sist oppdatert:** YYYY-MM-DD

| ID | Antakelse | Kilde | Klasse | Konsekvens hvis feil | Sannsynlighet for feil | Valideringsplan | Status | Validert dato |
|----|-----------|-------|--------|---------------------|----------------------|-----------------|--------|---------------|
| A01 | Virksomheten har M365 E5-lisenser | Oppdragsbeskrivelse | A | Copilot-løsningen krever E5, uten den trengs separat lisensanskaffelse (+3 mnd, +X NOK) | Lav | Bekreft med IT-avdeling | ⬜ Åpen | — |
| A02 | Azure OpenAI GPT-4o er GA i Norway East | KB: platforms/azure-ai-foundry.md | KB | Må bruke Sweden Central → dataresidenskonsekvens, mulig DPIA-påvirkning | Lav | Verifiser via MCP: microsoft-learn | ✅ Validert | 2026-02-13 |
| A03 | SharePoint-innhold er strukturert og klassifisert | Ikke verifisert | A | RAG-kvalitet blir lav → POC-tid øker med 4-6 uker for datakuratering | Middels | Be om tilgang til SharePoint, gjennomfør stikkprøve | ⬜ Åpen | — |
| A04 | Integrasjon med fagsystem [X] er mulig via REST API | Muntlig fra prosjektleder | E | Uten API kreves custom connector-utvikling (+8 uker, +Y NOK) | Middels | Be om API-dokumentasjon, gjennomfør teknisk spike | ⬜ Åpen | — |
| A05 | AI Act risikoklasse er "begrenset" (ikke "høy") | Arkitektens vurdering | E | Høyrisikoklassifisering utløser conformity assessment (+3-6 mnd, +Z NOK) | Lav-Middels | Gjennomgå med juridisk rådgiver | 🔄 Under arbeid | — |
```

### 2.2 Status-verdier

| Status | Betydning | Neste steg |
|--------|-----------|------------|
| ⬜ **Åpen** | Ikke påbegynt validering | Prioriter basert på konsekvens |
| 🔄 **Under arbeid** | Validering pågår | Vent på resultat |
| ✅ **Validert** | Bekreftet korrekt | Oppgrader kildeklasse (A→V eller A→E) |
| ❌ **Avkreftet** | Antakelsen var feil | Revurder arkitekturbeslutning |
| ⏳ **Utløpt** | Valideringen er foreldet | Re-valider |

---

## 3. Konsekvensanalyse per antakelse

### 3.1 Konsekvens-kategorier

Når du dokumenterer "Konsekvens hvis feil" i antakelsesregisteret, bruk disse kategoriene:

| Kategori | Beskrivelse | Eksempel |
|----------|-------------|---------|
| **Tidskonsekvens** | Forsinkelse i prosjektplan | "+4 uker for å anskaffe manglende lisenser" |
| **Kostnadskonsekvens** | Uforutsett kostnad | "+200 000 NOK for alternativ komponent" |
| **Arkitekturkonsekvens** | Endring i valgt løsning | "Må bytte fra Norway East til Sweden Central → DPIA-oppdatering" |
| **Regulatorisk konsekvens** | Compliance-implikasjon | "Høyrisiko iht. AI Act → conformity assessment nødvendig" |
| **Organisatorisk konsekvens** | Krav til organisasjonen | "Trenger ekstern data engineer → anskaffelsesprosess" |
| **Prosjektkonsekvens** | Påvirkning på prosjektet som helhet | "Prosjektet bør stoppes/omfangsreduseres" |

### 3.2 Konsekvensmatrise

Prioriter validering basert på konsekvens × sannsynlighet:

| Prioritet | Når | Handling |
|-----------|-----|---------|
| **P1 — Kritisk** | Høy konsekvens + middels/høy sannsynlighet | Valider **før** beslutning. Blokkerer anbefaling. |
| **P2 — Viktig** | Middels konsekvens + middels sannsynlighet, ELLER høy konsekvens + lav sannsynlighet | Valider i **POC-fase**. Dokumenter som risiko. |
| **P3 — Ønskelig** | Lav konsekvens ELLER lav sannsynlighet | Valider **underveis**. Dokumenter, men blokker ikke. |

---

## 4. Valideringsarbeidsflyt

### 4.1 Valideringsprosess

```
1. Identifiser antakelse under utredningsarbeid
   ↓
2. Registrer i antakelsesregisteret med kildeklasse og konsekvens
   ↓
3. Vurder prioritet (P1/P2/P3)
   ↓
4. For P1: Forsøk å validere umiddelbart
   │
   ├─ MCP-verifiserbar? → Bruk microsoft-learn, tavily, eller azure-mcp
   ├─ Krever tilgang/info fra virksomhet? → Dokumenter som oppfølgingspunkt
   └─ Krever ekstern ekspertise? → Registrer som avhengighet
   ↓
5. Oppdater status og kildeklasse
   ↓
6. Hvis avkreftet: Revurder berørte beslutninger
```

### 4.2 MCP-verifiseringsprotokoll

For antakelser som kan verifiseres med MCP-verktøy i sesjonen:

| Verktøytype | MCP-verktøy | Egnet for |
|-------------|-------------|-----------|
| **Microsoft-dokumentasjon** | `microsoft_docs_search`, `microsoft_docs_fetch` | GA-status, regional tilgjengelighet, prismodeller, konfigurasjon |
| **Kodeeksempler** | `microsoft_code_sample_search` | API-tilgjengelighet, SDK-støtte |
| **Generelt web** | `tavily_search`, `tavily_extract` | Nyheter, annonserte endringer, community-erfaringer |
| **Azure-infrastruktur** | `azure-mcp-server` (hvis tilgjengelig) | Faktisk konfigurasjon, RBAC, ressursstatus |

### 4.3 Valideringsmal per antakelse

```markdown
### Validering av A01: [Antakelse]

**Antakelse:** [Beskrivelse]
**Kilde:** [Original kilde]
**Prioritet:** P1/P2/P3

**Valideringsmetode:** [MCP/Dokumentgjennomgang/Intervju/Teknisk spike]

**Valideringsresultat:**
- [ ] Bekreftet korrekt → Oppgrader til klasse [V/KB/E]
- [ ] Delvis korrekt → Oppdater antakelse: [ny formulering]
- [ ] Avkreftet → Konsekvens: [beskrivelse], Tiltak: [handling]

**Ny kildeklasse:** [V/KB/E]
**Validert av:** [Navn/rolle]
**Dato:** YYYY-MM-DD
**Notater:** [Evt. tilleggsinfo]
```

---

## 5. Integrasjon med utredningsdokumentet

### 5.1 Kildesporing i tekst

I utredningsdokumentet, bruk inline-kildemarkører:

```markdown
Azure OpenAI tilbyr GPT-4o i Norway East [V: MCP microsoft-learn 2026-02-13].
Copilot Studio kan integreres med Azure AI Search for RAG [KB: platforms/copilot-studio.md].
Vi estimerer at integrasjon med fagsystemet tar 4-6 uker [E: erfaringsbasert].
Vi antar at virksomheten har tilstrekkelig Azure-budsjett [A01: Må valideres med IT-avdeling].
```

### 5.2 Antakelsessammendrag i utredningen

Inkluder dette i utredningens sammendrag (S1):

```markdown
### Antakelser og konfidens

| Antall | Kategori | Konsekvens |
|--------|----------|------------|
| [X] | Verifisert (V) | Høy tillit — dokumentert i sesjonen |
| [X] | Kunnskapsbase (KB) | Høy tillit — sjekk "sist oppdatert" |
| [X] | Ekspert (E) | Middels tillit — basert på erfaring |
| [X] | Antakelse (A) | Lav tillit — må valideres |

**P1-antakelser (kritiske, blokkerende):**
- A01: [Beskrivelse] — Valideringsplan: [Plan]
- A05: [Beskrivelse] — Valideringsplan: [Plan]

**Overordnet konfidensgrad:** 🟢 Høy / 🟡 Medium / 🔴 Lav
```

### 5.3 Antakelsesregister som vedlegg

Fullt antakelsesregister (seksjon 2.1) bør inkluderes som vedlegg i utredningsdokumentet, referert fra S10 (Vedlegg).

---

## 6. Livssyklus for antakelser

### 6.1 Antakelsens livssyklus

```
Identifisert (A) → Prioritert (P1/P2/P3) → Validering pågår (🔄) → Validert (✅) / Avkreftet (❌)
                                                                       ↓ (med tid)
                                                                   Utløpt (⏳) → Re-validering
```

### 6.2 Re-valideringsregler

| Kildeklasse | Re-valider etter | Trigger |
|-------------|-----------------|---------|
| V (Verifisert) | 3-6 måneder | Ny major release, prisendring, regional utvidelse |
| KB (Kunnskapsbase) | 6 måneder | KB-staleness-sjekk (`scripts/kb-staleness-check.sh`) |
| E (Ekspert) | Ved ny informasjon | Ny erfaring, tilbakemelding fra prosjekt |
| A (Antakelse) | Umiddelbart — bør valideres snarest | Alltid |

---

## For Cosmo Skyberg

Denne referansefilen er ditt verktøy for å sikre transparens og etterprøvbarhet i arkitekturvurderinger. Slik bruker du den:

### Under arkitekturvurderinger:

1. **Klassifiser alltid kilder** med [V], [KB], [E], eller [A] inline i teksten. Dette tar sekunder og gir enorm verdi for beslutningstaker.
2. **Opprett antakelsesregister** for hvert prosjekt. Start med de mest kritiske antakelsene.
3. **Verifiser P1-antakelser i sesjonen** ved hjelp av MCP-verktøy (microsoft-learn, tavily).
4. **Presenter konfidensoversikt** i sammendragseksjonen.

### Når du bruker MCP-verktøy for verifisering:

- **microsoft_docs_search** → Oppgrader til klasse V med dato og søkeord
- **tavily_search** → Oppgrader til klasse V, men noter at web-kilder er mindre stabile enn offisiell docs
- **Kunnskapsbasen** → Bruk klasse KB, men sjekk "Sist oppdatert"-dato i filen

### Vanlige antakelser å registrere:

1. Lisenssituasjon (M365 E3/E5, Copilot Studio, Azure-abonnement)
2. Regional tilgjengelighet (Norway East vs. Sweden Central)
3. Datakvalitet og tilgjengelighet (SharePoint, fagsystemer)
4. Kompetansenivå i organisasjonen
5. Budsjettramme og tidsfrist
6. Regulatorisk klassifisering (AI Act risikoklasse)
7. Integrasjonsmuligheter (API-er i fagsystemer)

### Integrasjon med andre referansefiler:

- **Alternativanalyse** (`alternativanalyse-methodology.md`): Score-begrunnelser bør ha kildeklassifisering
- **Regional tilgjengelighet** (`regional-availability-verification.md`): Verifiseringslogg er kildeklasse V
- **Gjennomførbarhet** (`capacity-feasibility-benchmarks.md`): Tidsestimater er typisk klasse E eller A
- **Utredningsmal** (`ai-utredning-template.md`): Antakelsesregister er vedlegg i utredningen