ms-ai-architect/skills/ms-ai-advisor/references/architecture/source-traceability-assumption-register.md

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:

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

### 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

### 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:

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):

### 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