Kjell Tore Guttormsen
3a73eeafdc
Ordre 20260912T193441Z-7358817909. Steg 1 var ikke transformen, men å rette
roadmapens R13-gate og få den ratifisert. Gaten `grep -rl "Cosmo"
skills/*/references -> 0` var usann på to uavhengige måter:
1. Ordren fanget den første: 451 av forekomstene er Azure Cosmos DB, ekte
produktinnhold. Diskriminatoren er ikke bokstaven «s» — `Cosmos <norsk
substantiv>` er genitiv av personaen (`### Cosmos tonalitet`), mens
`Cosmos DB`/`CosmosClient`/`cosmos_ru` er produkt.
2. Denne økten fant den andre: 132 persona-forekomster ligger i prosa,
tabeller, dialog-replikker og proveniens-linjer. Heading-nøytralisering
kan ikke nå dem, så «0 persona» er uoppnåelig også under den ratifiserte
formen. Operatøren ratifiserte alternativ A: gaten speiler formen, og de
132 bokføres til R13b/R14.
Tre korreksjoner av premisser som sto i ordren og STATE:
«ca 320 produkt» -> 451 (case-sensitivt nett manglet 327 lowercase
TOC-ankre + 99 identifikatorer; sann nevner 1 638)
«169 headinger» -> 401. 169 var `^## For Cosmo`-prefikset (168) og var
internt inkonsistent med sin egen topp-variant (204)
«417 matcher ingen
populasjon» -> 417 er cosmo-headinger utenfor kodefences; briefens
nevner var reell hele tiden
Fence-bevissthet er målt skadelig, ikke nødvendig: begge toggle-regler er
gale på dette korpuset (naiv toggle skjuler en ekte heading i
chain-of-thought-prompting.md, CommonMark-regelen ubalanserer
service-level-documentation-dr.md). Fence-agnostisk deteksjon finner 401
heading-linjer i nøyaktig de samme 40 variantene som fence-bevisst finner
400 i — ingen kodeblokk-linje er byte-identisk til en persona-heading. Derfor
nøkles transformen på 40 enumererte heading-tekster og ignorerer fences. En
ukjent variant kaster; en slug-kollisjon kaster. Ingenting auto-fikses.
TOC-en regenereres ikke, den rettes kirurgisk: alle 327 persona-lenker hadde
lenketekst lik én av de 40 heading-tekstene og anker lik slugify av den
(327/327, 0 avvik), så heading og TOC-entry skrives i samme operasjon og
ingen mellomtilstand etterlater en død lenke.
Ratifisert målform: `For Cosmo`, `For Cosmo Skyberg` og `For arkitekten
(Cosmo)` konvergerer på `For arkitekten`. To filer kolliderte og er adjudisert
ved å lese dem, ikke ved regel.
Verifisering (alle 7 kriterier fra ordren):
G1 persona på heading-linjer 401 -> 0
G2 døde fragmentlenker 1 -> 1 (pre-eksisterende, unntatt)
G3 produkt-forekomster 451 -> 451; `Cosmos DB|Azure Cosmos` 308 = 308
de 3 kun-produkt-filene byte-identiske
nettet validert begge veier injisert persona feller G1; genitiv feller G1;
produkt-heading og de 3 filene passerer
hele diffen 802 heading-linjer + 654 TOC-linjer, ANNET = 0
linjeantall 728 lagt til = 728 slettet
suite 1120/1120 (1097 + 23 nye)
validate-plugin 250 PASS / 0 FAIL
stikkprøve 10 filer, alle 5 skills, inkl. de 3 mest
produkt-tunge (26/20/19) — kun heading+TOC
Utenfor scope, urørt: de 4 SKILL.md, de 23 commands, CLAUDE.md, README.md,
NOTICE.md, docs/ (alt R14).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
256 lines
12 KiB
Markdown
256 lines
12 KiB
Markdown
# Kildesporing og antakelsesregister
|
||
|
||
**Last updated:** 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 arkitekten
|
||
|
||
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
|