Gjør all dokumentasjon tilgjengelig i repo og fiks alle lenker

Tidligere refererte repoet til dokumentasjon som lå utenfor (i Salg/_mal/),
og brukte Obsidian-wikilinks [[...]] som ikke er klikkbare i Gitea. Begge
deler gjorde at lenker var døde i Gitea-web.

Endringer:
- Hentet inn arbeidsdokumentene som faktisk brukes under oppdraget:
  _metode/ (00-konvensjoner, 01-startklar-sjekkliste, 02-gjennomforing)
  artefakter/ (risikoregister, integrasjonslandskap, workshop-agenda,
  domenemodell-skjema)
- Konverterte 82 Obsidian-wikilinks til standard markdown-lenker med
  korrekte relative stier — klikkbare både i Gitea og lokalt
- Begrepsord i begrepskatalogen ([[Bedrift]] etc.) ble til ren tekst
  (de var aldri filer)
- Oppdaterte konvensjonsdokumentet til å foreskrive standard markdown,
  ikke wikilinks (med begrunnelse: Gitea rendrer ikke [[...]])
- Oras/Kirken/salgsmateriale er nå tydelig merket som eksterne
  arbeidsområde-referanser (andre kunder / salgsfase), ikke
  dinglende lenker som lot som de var i repoet

Verifisert: 133 ekte interne lenker resolver korrekt. De 4 gjenværende
treffene i validering er kodeeksempler i backticks (viser lenke-syntaks),
ikke faktiske lenker.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

1.oppdrag-og-kontekst/motelogg-og-beslutninger.md

@@ -23,14 +23,14 @@ Master-oversikt over alle møter, beslutninger (DEC), handlinger (ACT) og risiko
 
 ## Handlingsregister
 
-Tverrgående oversikt. Se også [[../7.standardisering-og-handlingsplan/prioriteringsliste]] for prioriterte tiltak.
+Tverrgående oversikt. Se også [prioriteringsliste](../7.standardisering-og-handlingsplan/prioriteringsliste.md) for prioriterte tiltak.
 
 | ID | Handling | Ansvarlig | Frist | Status |
 |---|---|---|---|---|
 
 ## Risikoregister
 
-Se [[../../artefakter/risikoregister]] for fullt register med Impact × Likelihood-score.
+Se [risikoregister](../artefakter/risikoregister.md) for fullt register med Impact × Likelihood-score.
 
 ---
 

1.oppdrag-og-kontekst/oppdragsbeskrivelse.md

@@ -39,7 +39,7 @@ version: 1
 
 ## Leveranser
 
-Se [[mal-og-leveranser]] for detaljert leveranseoversikt.
+Se [mal-og-leveranser](mal-og-leveranser.md) for detaljert leveranseoversikt.
 
 ## Tidsramme
 

1.oppdrag-og-kontekst/rammer-og-avklaringer.md

@@ -31,7 +31,7 @@ version: 1
 
 ## Åpne avklaringspunkter
 
-Se [[../8.kontinuerlig-laering-og-referanser/apne-sporsmal]] for løpende spørsmålsliste.
+Se [apne-sporsmal](../8.kontinuerlig-laering-og-referanser/apne-sporsmal.md) for løpende spørsmålsliste.
 
 ---
 

3.system-og-datalandskap/integrasjoner-og-flyt.md

@@ -11,11 +11,11 @@ version: 1
 
 # Integrasjoner og dataflyt
 
-Hvordan data flyter mellom systemene som er kartlagt i [[hovedsystemer]].
+Hvordan data flyter mellom systemene som er kartlagt i [hovedsystemer](hovedsystemer.md).
 
 ## Integrasjonslandskap
 
-Bruk strukturen fra [[../../artefakter/integrasjonslandskap]]:
+Bruk strukturen fra [integrasjonslandskap](../artefakter/integrasjonslandskap.md):
 
 | System | Retning | Motpart | Mekanisme | Datatyper | Frekvens | Implikasjon |
 |---|---|---|---|---|---|---|

3.system-og-datalandskap/systemkart-as-is.md

@@ -9,7 +9,7 @@ version: 1
 
 # Systemkart (as-is)
 
-Visuell oversikt over dagens systemlandskap. Bygges ut i Fase B basert på [[hovedsystemer]] og [[integrasjoner-og-flyt]].
+Visuell oversikt over dagens systemlandskap. Bygges ut i Fase B basert på [hovedsystemer](hovedsystemer.md) og [integrasjoner-og-flyt](integrasjoner-og-flyt.md).
 
 ## Hovedkart
 
@@ -49,7 +49,7 @@ graph TB
 
 ## Sammenligning med målbilde
 
-Lenke til [[../9.leveranser-og-oppsummeringer/sluttrapport#målarkitektur]] når den er ferdig.
+Lenke til [sluttrapport](../9.leveranser-og-oppsummeringer/sluttrapport.md#målarkitektur) når den er ferdig.
 
 ---
 

4.informasjonsarkitektur/begrepskatalog.md

@@ -17,19 +17,19 @@ Felles begrepsdefinisjoner for Standard Online. Bygges ut løpende gjennom oppdr
 ## Hvordan bruke
 
 - **Definisjon** skal være entydig og gjenkjennelig for forretningen
-- **Domene** kobler begrepet til [[informasjonsdomener]]
+- **Domene** kobler begrepet til [informasjonsdomener](informasjonsdomener.md)
 - **Begrepseier** er den som har semantisk eierskap (definerer hva begrepet betyr)
 - **System-of-Record** er det systemet som er autoritativ kilde for data om dette begrepet
-- **Relaterte begreper** lenkes med [[term]]
+- **Relaterte begreper** lenkes med term
 
 ## Katalog
 
 | Term | Definisjon | Domene | Begrepseier | System-of-Record | Relaterte |
 |---|---|---|---|---|---|
-| Bedrift | En juridisk enhet som vi har et kunde-, leverandør- eller partnerforhold til | Bedrift | | | [[Kontakt]], [[Avtale]] |
+| Bedrift | En juridisk enhet som vi har et kunde-, leverandør- eller partnerforhold til | Bedrift | | | Kontakt, Avtale |
-| Kontakt | Person tilknyttet en bedrift, identifisert med navn og kontaktinformasjon | Person | | | [[Bedrift]], [[Bruker]] |
+| Kontakt | Person tilknyttet en bedrift, identifisert med navn og kontaktinformasjon | Person | | | Bedrift, Bruker |
-| Bruker | Person med autentisert tilgang til en av våre tjenester | Person | | | [[Kontakt]], [[Rolle]] |
+| Bruker | Person med autentisert tilgang til en av våre tjenester | Person | | | Kontakt, Rolle |
-| Ordre | Bestilling av varer eller tjenester med kobling til [[Bedrift]] og [[Bruker]] | Ordre | | | [[Produkt]], [[Faktura]] |
+| Ordre | Bestilling av varer eller tjenester med kobling til Bedrift og Bruker | Ordre | | | Produkt, Faktura |
 
 *Disse er eksempler — bytt ut, slett eller utvid basert på kunden.*
 

4.informasjonsarkitektur/data-governance-prinsipper.md

@@ -42,7 +42,7 @@ Formålet med Data Governance hos Standard Online:
 - Definere hvordan data blir tilgjengelig for konsumenter
 - Etablere og forvalte kodeverk for domenet
 - Godkjenne endringer i datamodellen
-- Sikre at data tilfredsstiller de 8 kriteriene (se [[masterdata-og-eierskap#8-kriterier-for-godt-dataeierskap]])
+- Sikre at data tilfredsstiller de 8 kriteriene (se [masterdata-og-eierskap](masterdata-og-eierskap.md#8-kriterier-for-godt-dataeierskap))
 
 **Eksempler:** Fagavdeling kunde- og bedriftsdata, fagavdeling produktdata.
 

4.informasjonsarkitektur/datakvalitet-og-avvik.md

@@ -43,14 +43,14 @@ Standardvurdering per dimensjon:
 
 ## Avviksliste
 
-Konkrete observerte avvik. Også lenket fra [[../7.standardisering-og-handlingsplan/avviksliste]].
+Konkrete observerte avvik. Også lenket fra [avviksliste](../7.standardisering-og-handlingsplan/avviksliste.md).
 
 | ID | Avvik | Domene | System | Konsekvens | Foreslått tiltak |
 |---|---|---|---|---|---|
 
 ## Anbefalinger
 
-*Prioriterte tiltak for datakvalitet, koblet til [[../7.standardisering-og-handlingsplan/prioriteringsliste]].*
+*Prioriterte tiltak for datakvalitet, koblet til [prioriteringsliste](../7.standardisering-og-handlingsplan/prioriteringsliste.md).*
 
 ---
 

4.informasjonsarkitektur/informasjonsdomener.md

@@ -45,10 +45,10 @@ Hovedinndeling av informasjon hos Standard Online. Hvert domene har en eller fle
 *Hva mangler for at domenet skal være godt forvaltet?*
 
 **Risikoer:**
-*Kobling til [[../../artefakter/risikoregister]].*
+*Kobling til [risikoregister](../artefakter/risikoregister.md).*
 
 **Anbefalte tiltak:**
-*Kobling til [[../7.standardisering-og-handlingsplan/prioriteringsliste]].*
+*Kobling til [prioriteringsliste](../7.standardisering-og-handlingsplan/prioriteringsliste.md).*
 
 ---
 

4.informasjonsarkitektur/masterdata-og-eierskap.md

@@ -64,7 +64,7 @@ Skillet er kritisk — "dataeier" som ett begrep skaper diskusjon. Vi skiller de
 
 ### <Entitet> — eksempel: Bedrift
 
-**Definisjon:** *Hva er en bedrift i denne sammenhengen? Lenke til [[begrepskatalog]].*
+**Definisjon:** *Hva er en bedrift i denne sammenhengen? Lenke til [begrepskatalog](begrepskatalog.md).*
 
 **Master (SoR):**
 - **System:**
@@ -79,9 +79,9 @@ Skillet er kritisk — "dataeier" som ett begrep skaper diskusjon. Vi skiller de
 - **Alternativer i dag:** *Hvilke ulike nøkler brukes i ulike systemer? Konfliktrisiko?*
 
 **Tilstand:**
-- **Kvalitet:** <vurdering — lenke til [[datakvalitet-og-avvik]]>
+- **Kvalitet:** <vurdering — lenke til [datakvalitet-og-avvik](datakvalitet-og-avvik.md)>
 - **Gap:**
-- **Anbefalt tiltak:** *Lenke til [[../7.standardisering-og-handlingsplan/prioriteringsliste]]*
+- **Anbefalt tiltak:** *Lenke til [prioriteringsliste](../7.standardisering-og-handlingsplan/prioriteringsliste.md)*
 
 ---
 

4.informasjonsarkitektur/standardiseringsbehov.md

@@ -31,7 +31,7 @@ Identifiserte behov for felles standarder, kodeverk og strukturer på tvers av s
 
 ## Anbefalinger
 
-Lenke til [[../7.standardisering-og-handlingsplan/prioriteringsliste]] for prioriterte tiltak.
+Lenke til [prioriteringsliste](../7.standardisering-og-handlingsplan/prioriteringsliste.md) for prioriterte tiltak.
 
 ---
 

5.personvern-og-sikkerhet/dataflyt-og-risiko.md

@@ -12,7 +12,7 @@ version: 1
 
 # Dataflyt og personvernrisiko
 
-Personvernperspektiv på dataflyten kartlagt i [[../3.system-og-datalandskap/integrasjoner-og-flyt]].
+Personvernperspektiv på dataflyten kartlagt i [integrasjoner-og-flyt](../3.system-og-datalandskap/integrasjoner-og-flyt.md).
 
 ## Risikomatrise per integrasjon
 

5.personvern-og-sikkerhet/gdpr-oversikt.md

@@ -57,11 +57,11 @@ Skal omfatte alle behandlinger av personopplysninger. Bygges ut i Fase B.
 - **Forklarbarhet:** Kan vi forklare hvordan en AI-beslutning er tatt? (jf. art. 13/14)
 - **Sletting:** Kan persondata slettes fra både operative systemer og trente modeller?
 
-Lenke til [[../6.ai-rammeverk/ai-prinsipper]].
+Lenke til [ai-prinsipper](../6.ai-rammeverk/ai-prinsipper.md).
 
 ## Risikoer
 
-Lenke til [[../../artefakter/risikoregister]] for GDPR-relaterte risikoer.
+Lenke til [risikoregister](../artefakter/risikoregister.md) for GDPR-relaterte risikoer.
 
 ---
 

5.personvern-og-sikkerhet/tiltak-for-innebygd-personvern.md

@@ -62,7 +62,7 @@ Følgende tiltak mangler eller bør prioriteres hos Standard Online:
 
 ## Anbefalinger
 
-*Lenke til [[../7.standardisering-og-handlingsplan/prioriteringsliste]] for prioriterte tiltak.*
+*Lenke til [prioriteringsliste](../7.standardisering-og-handlingsplan/prioriteringsliste.md) for prioriterte tiltak.*
 
 ---
 

6.ai-rammeverk/ai-prinsipper.md

@@ -19,29 +19,29 @@ Operasjonelle prinsipper for AI-agenter hos Standard Online. **Dette er ikke en
 
 ## Grunnpremiss
 
-AI-agenter blir bare så pålitelige som dataene under dem. Kontroll og eierskap til data er fundamentet for å kunne sette agenter i produksjon. AI-fundamentet er bygget på [[../4.informasjonsarkitektur/masterdata-og-eierskap]] og [[../4.informasjonsarkitektur/data-governance-prinsipper]].
+AI-agenter blir bare så pålitelige som dataene under dem. Kontroll og eierskap til data er fundamentet for å kunne sette agenter i produksjon. AI-fundamentet er bygget på [masterdata-og-eierskap](../4.informasjonsarkitektur/masterdata-og-eierskap.md) og [data-governance-prinsipper](../4.informasjonsarkitektur/data-governance-prinsipper.md).
 
 ## Fem prinsipper
 
 ### 1. Identifiserbarhet — hver agent har egen identitet
 
-Ingen AI-agent skal opptre under en generisk eller delt identitet. Hver agent autentiseres og autoriseres som en egen entitet. Se [[identifiserbarhet-og-tilgang]].
+Ingen AI-agent skal opptre under en generisk eller delt identitet. Hver agent autentiseres og autoriseres som en egen entitet. Se [identifiserbarhet-og-tilgang](identifiserbarhet-og-tilgang.md).
 
 ### 2. Minste privilegium — agenter får kun det de trenger
 
-Tilganger gis per agent, per oppgave, og kun til nødvendig data og funksjonalitet. Tilganger gjennomgås periodisk. Se [[identifiserbarhet-og-tilgang]].
+Tilganger gis per agent, per oppgave, og kun til nødvendig data og funksjonalitet. Tilganger gjennomgås periodisk. Se [identifiserbarhet-og-tilgang](identifiserbarhet-og-tilgang.md).
 
 ### 3. Sporbarhet — hver handling logges
 
-Hver handling utført av en agent logges med agent-ID, tidspunkt, input, output og berørt data. Logger er tilgjengelige for dataeier. Se [[logging-og-sporbarhet]].
+Hver handling utført av en agent logges med agent-ID, tidspunkt, input, output og berørt data. Logger er tilgjengelige for dataeier. Se [logging-og-sporbarhet](logging-og-sporbarhet.md).
 
 ### 4. Human-in-the-loop for kritiske beslutninger
 
-Beslutninger kategoriseres i tre nivåer: autonom, varslende, godkjennende. Kategoriseringen reflekterer risiko og reversibilitet. Se [[human-in-the-loop]].
+Beslutninger kategoriseres i tre nivåer: autonom, varslende, godkjennende. Kategoriseringen reflekterer risiko og reversibilitet. Se [human-in-the-loop](human-in-the-loop.md).
 
 ### 5. Datakvalitet som premiss
 
-En agent settes ikke i produksjon mot et domene før domenet har tydelig System-of-Record, definert Dataforvalter og minimum akseptabel datakvalitet. Se [[datakvalitet-som-ai-premiss]].
+En agent settes ikke i produksjon mot et domene før domenet har tydelig System-of-Record, definert Dataforvalter og minimum akseptabel datakvalitet. Se [datakvalitet-som-ai-premiss](datakvalitet-som-ai-premiss.md).
 
 ## Åpne spørsmål for kundedialog
 

6.ai-rammeverk/datakvalitet-som-ai-premiss.md

@@ -28,12 +28,12 @@ Per masterdata-domene må følgende være på plass før AI-agenter slippes inn:
 
 | Krav | Lenke |
 |---|---|
-| SoR tildelt | [[../4.informasjonsarkitektur/masterdata-og-eierskap]] |
+| SoR tildelt | [masterdata-og-eierskap](../4.informasjonsarkitektur/masterdata-og-eierskap.md) |
-| Dataforvalter utnevnt | [[../4.informasjonsarkitektur/masterdata-og-eierskap]] |
+| Dataforvalter utnevnt | [masterdata-og-eierskap](../4.informasjonsarkitektur/masterdata-og-eierskap.md) |
-| Begrepskatalog dekker entitetene | [[../4.informasjonsarkitektur/begrepskatalog]] |
+| Begrepskatalog dekker entitetene | [begrepskatalog](../4.informasjonsarkitektur/begrepskatalog.md) |
-| Datakvalitet kjent (måling utført) | [[../4.informasjonsarkitektur/datakvalitet-og-avvik]] |
+| Datakvalitet kjent (måling utført) | [datakvalitet-og-avvik](../4.informasjonsarkitektur/datakvalitet-og-avvik.md) |
-| Personverntiltak på plass | [[../5.personvern-og-sikkerhet/tiltak-for-innebygd-personvern]] |
+| Personverntiltak på plass | [tiltak-for-innebygd-personvern](../5.personvern-og-sikkerhet/tiltak-for-innebygd-personvern.md) |
-| Tilgangsstyring etablert | [[identifiserbarhet-og-tilgang]] |
+| Tilgangsstyring etablert | [identifiserbarhet-og-tilgang](identifiserbarhet-og-tilgang.md) |
 
 ## Per use case
 

7.standardisering-og-handlingsplan/maleparametere.md

@@ -17,9 +17,9 @@ KPIer for å følge opp handlingsplanen og måle fremgang.
 
 | KPI | Definisjon | Frekvens | Mål |
 |---|---|---|---|
-| Andel masterdata-entiteter med tildelt SoR | % entiteter i [[../4.informasjonsarkitektur/masterdata-og-eierskap]] med master | Kvartalsvis | 100% innen 12 mnd |
+| Andel masterdata-entiteter med tildelt SoR | % entiteter i [masterdata-og-eierskap](../4.informasjonsarkitektur/masterdata-og-eierskap.md) med master | Kvartalsvis | 100% innen 12 mnd |
 | Andel masterdata-entiteter med Dataforvalter | % entiteter med navngitt forvalter | Kvartalsvis | 100% innen 12 mnd |
-| Begrepskatalog-dekning | Antall begreper i [[../4.informasjonsarkitektur/begrepskatalog]] | Månedlig | Vekst |
+| Begrepskatalog-dekning | Antall begreper i [begrepskatalog](../4.informasjonsarkitektur/begrepskatalog.md) | Månedlig | Vekst |
 
 ### Datakvalitet
 

7.standardisering-og-handlingsplan/prioriteringsliste.md

@@ -17,7 +17,7 @@ Konkrete, prioriterte tiltak basert på funn fra kartleggingen. Faseinndelt 0-3
 
 ## Prioriteringskriterier
 
-- **Risiko** — hvor stor er risikoen ved å ikke gjøre dette? (lenke til [[../../artefakter/risikoregister]])
+- **Risiko** — hvor stor er risikoen ved å ikke gjøre dette? (lenke til [risikoregister](../artefakter/risikoregister.md))
 - **Gevinst** — hva oppnår vi?
 - **Avhengighet** — hva må være på plass først?
 - **Innsats** — estimert ressursbehov

7.standardisering-og-handlingsplan/tiltak-per-omrade.md

@@ -11,7 +11,7 @@ version: 1
 
 # Tiltak per område
 
-Samme tiltakssett som [[prioriteringsliste]], men gruppert per fagområde i stedet for tidsfase. Gjør det enklere for ulike eierskap å se hva som angår dem.
+Samme tiltakssett som [prioriteringsliste](prioriteringsliste.md), men gruppert per fagområde i stedet for tidsfase. Gjør det enklere for ulike eierskap å se hva som angår dem.
 
 ## Masterdata og governance
 

9.leveranser-og-oppsummeringer/executive-summary.md

@@ -57,7 +57,7 @@ Kort om hvorfor oppdraget ble gjennomført og hva som var innenfor scope.
 
 ## 4. Risikoer
 
-Toppen av risikoregisteret. Fullt register: [[../../artefakter/risikoregister]].
+Toppen av risikoregisteret. Fullt register: [risikoregister](../artefakter/risikoregister.md).
 
 | # | Risiko | Score | Mitigasjon |
 |---|---|---|---|
@@ -66,7 +66,7 @@ Toppen av risikoregisteret. Fullt register: [[../../artefakter/risikoregister]].
 
 ## 5. Anbefalinger
 
-Hovedanbefalinger, gruppert. Detaljer i [[../7.standardisering-og-handlingsplan/prioriteringsliste]].
+Hovedanbefalinger, gruppert. Detaljer i [prioriteringsliste](../7.standardisering-og-handlingsplan/prioriteringsliste.md).
 
 ### Kortsiktig (0-3 mnd)
 1.

9.leveranser-og-oppsummeringer/leveranseplan.md

@@ -11,7 +11,7 @@ version: 1
 
 # Leveranseplan
 
-Overordnet leveranseplan, koblet til [[../1.oppdrag-og-kontekst/mal-og-leveranser]] og [[../../02-gjennomforing]].
+Overordnet leveranseplan, koblet til [mal-og-leveranser](../1.oppdrag-og-kontekst/mal-og-leveranser.md) og [02-gjennomforing](../_metode/02-gjennomforing.md).
 
 ## Faser og milepæler
 

9.leveranser-og-oppsummeringer/sluttrapport.md

@@ -35,7 +35,7 @@ version: 1
 
 ### 1.2 Mål med oppdraget
 
-*Hva skulle oppdraget oppnå? Lenke til [[../1.oppdrag-og-kontekst/mal-og-leveranser]].*
+*Hva skulle oppdraget oppnå? Lenke til [mal-og-leveranser](../1.oppdrag-og-kontekst/mal-og-leveranser.md).*
 
 ### 1.3 Omfang og avgrensninger
 
@@ -52,7 +52,7 @@ version: 1
 
 ### 1.5 Tilnærming og metode
 
-Oppdraget ble gjennomført med Fortes **Startklar-metodikk** for data readiness (`Salg/Startklar.pdf`), tilpasset Nivå 1 (avgrenset strategisk). Gjennomføringsmodellen følger 4 faser — se [[../../02-gjennomforing]] og [[leveranseplan]].
+Oppdraget ble gjennomført med Fortes **Startklar-metodikk** for data readiness (`Salg/Startklar.pdf`), tilpasset Nivå 1 (avgrenset strategisk). Gjennomføringsmodellen følger 4 faser — se [02-gjennomforing](../_metode/02-gjennomforing.md) og [leveranseplan](leveranseplan.md).
 
 **Gjennomførte aktiviteter:**
 - [x] Kickoff og scope-bekreftelse
@@ -72,7 +72,7 @@ Oppdraget ble gjennomført med Fortes **Startklar-metodikk** for data readiness
 
 ### 2.1 Nåsituasjon
 
-Sammenstilling av [[../3.system-og-datalandskap/hovedsystemer]] og [[../3.system-og-datalandskap/integrasjoner-og-flyt]].
+Sammenstilling av [hovedsystemer](../3.system-og-datalandskap/hovedsystemer.md) og [integrasjoner-og-flyt](../3.system-og-datalandskap/integrasjoner-og-flyt.md).
 
 #### 2.1.1 Systemlandskap
 
@@ -87,11 +87,11 @@ Sammenstilling av [[../3.system-og-datalandskap/hovedsystemer]] og [[../3.system
 
 ### 2.3 Datakvalitet og governance
 
-Sammenstilling av [[../4.informasjonsarkitektur/datakvalitet-og-avvik]] og [[../4.informasjonsarkitektur/masterdata-og-eierskap]].
+Sammenstilling av [datakvalitet-og-avvik](../4.informasjonsarkitektur/datakvalitet-og-avvik.md) og [masterdata-og-eierskap](../4.informasjonsarkitektur/masterdata-og-eierskap.md).
 
 ### 2.4 Personvern og sikkerhet
 
-Sammenstilling av [[../5.personvern-og-sikkerhet/gdpr-oversikt]] og [[../5.personvern-og-sikkerhet/tiltak-for-innebygd-personvern]].
+Sammenstilling av [gdpr-oversikt](../5.personvern-og-sikkerhet/gdpr-oversikt.md) og [tiltak-for-innebygd-personvern](../5.personvern-og-sikkerhet/tiltak-for-innebygd-personvern.md).
 
 ### 2.5 Innsiktsoppsummering
 
@@ -111,26 +111,26 @@ Sammenstilling av [[../5.personvern-og-sikkerhet/gdpr-oversikt]] og [[../5.perso
 
 ### 3.2 Anbefalt målarkitektur
 
-*Skisse, integrasjonsmønster, anbefalte komponenter. Detaljer i [[../3.system-og-datalandskap/systemkart-as-is]] (sammenligning) og dedikerte arkitektur-skisser.*
+*Skisse, integrasjonsmønster, anbefalte komponenter. Detaljer i [systemkart-as-is](../3.system-og-datalandskap/systemkart-as-is.md) (sammenligning) og dedikerte arkitektur-skisser.*
 
 ### 3.3 Masterdata-modell
 
-Sammenstilling av [[../4.informasjonsarkitektur/masterdata-og-eierskap]].
+Sammenstilling av [masterdata-og-eierskap](../4.informasjonsarkitektur/masterdata-og-eierskap.md).
 
 | Entitet | Master (SoR) | Begrepseier | Dataforvalter |
 |---|---|---|---|
 
 ### 3.4 AI-rammeverk
 
-Sammenstilling av [[../6.ai-rammeverk/ai-prinsipper]]. Fem prinsipper: identifiserbarhet, minste privilegium, sporbarhet, HITL, datakvalitet som premiss.
+Sammenstilling av [ai-prinsipper](../6.ai-rammeverk/ai-prinsipper.md). Fem prinsipper: identifiserbarhet, minste privilegium, sporbarhet, HITL, datakvalitet som premiss.
 
 ### 3.5 Governance-modell
 
-Sammenstilling av [[../4.informasjonsarkitektur/data-governance-prinsipper]].
+Sammenstilling av [data-governance-prinsipper](../4.informasjonsarkitektur/data-governance-prinsipper.md).
 
 ### 3.6 Anbefalte tiltak
 
-Sammenstilling av [[../7.standardisering-og-handlingsplan/prioriteringsliste]].
+Sammenstilling av [prioriteringsliste](../7.standardisering-og-handlingsplan/prioriteringsliste.md).
 
 ### 3.7 Kost/nytte-vurdering
 
@@ -139,7 +139,7 @@ Sammenstilling av [[../7.standardisering-og-handlingsplan/prioriteringsliste]].
 
 ### 3.8 Risikovurdering
 
-Lenke til [[../../artefakter/risikoregister]] for fullt register.
+Lenke til [risikoregister](../artefakter/risikoregister.md) for fullt register.
 
 ---
 
@@ -186,7 +186,7 @@ Fase 1: Grunnmur     Fase 2: Konsolidering   Fase 3: AI-aktivering
 
 ### Vedlegg A: Datakilde-inventar
 
-Lenke til [[../3.system-og-datalandskap/hovedsystemer]].
+Lenke til [hovedsystemer](../3.system-og-datalandskap/hovedsystemer.md).
 
 ### Vedlegg B: Intervjuoversikt
 
@@ -195,15 +195,15 @@ Lenke til [[../3.system-og-datalandskap/hovedsystemer]].
 
 ### Vedlegg C: Risikoregister
 
-Lenke til [[../../artefakter/risikoregister]].
+Lenke til [risikoregister](../artefakter/risikoregister.md).
 
 ### Vedlegg D: Integrasjonslandskap
 
-Lenke til [[../../artefakter/integrasjonslandskap]] og [[../3.system-og-datalandskap/integrasjoner-og-flyt]].
+Lenke til [integrasjonslandskap](../artefakter/integrasjonslandskap.md) og [integrasjoner-og-flyt](../3.system-og-datalandskap/integrasjoner-og-flyt.md).
 
 ### Vedlegg E: Begrepskatalog
 
-Lenke til [[../4.informasjonsarkitektur/begrepskatalog]].
+Lenke til [begrepskatalog](../4.informasjonsarkitektur/begrepskatalog.md).
 
 ### Vedlegg F: Ordliste
 

CLAUDE.md

@@ -43,7 +43,7 @@ Ragnhild driver det daglige arbeidet (kartlegging, workshops, dialog med Standar
 | C — Anbefalinger | 3-5 | Masterdata, arkitektur, AI, personvern | Delleveranse 2: Målbilde + masterdata (uke 5) |
 | D — Forankring | 6-7 | Presentasjon, overlevering | Sluttleveranse (uke 6-7) |
 
-Detaljer i `../../Salg/_mal/startklar-malverk/02-gjennomforing.md`.
+Detaljer i [_metode/02-gjennomforing.md](_metode/02-gjennomforing.md).
 
 ## Mappestruktur — 9 nummererte mapper
 
@@ -63,7 +63,7 @@ Komplett innholdsfortegnelse: [_index.md](_index.md).
 
 ## Konvensjoner
 
-Felles konvensjoner følger Forte sitt startklar-malverk: `../../Salg/_mal/startklar-malverk/00-konvensjoner.md`.
+Felles konvensjoner er dokumentert i [_metode/00-konvensjoner.md](_metode/00-konvensjoner.md) (avledet fra Forte sitt kanoniske startklar-malverk).
 
 ### Frontmatter
 
@@ -125,10 +125,12 @@ Når Claude oppdager noe verdt å huske som er prosjekt-spesifikt, skal det lagr
 
 ## Sentrale referansecase (metodikk og maler)
 
-Bygger på to ferske oppdrag:
+Metodikken bygger på to ferske oppdrag. Disse ligger i Forte sitt bredere arbeidsområde — **ikke i dette repoet** (de gjelder andre kunder; Kirken er konfidensielt for en annen kunde). De er nevnt her som bakgrunn for hvor mønstrene kommer fra:
 
-- **Oras Group** (`../../Salg/Oras/`): Data Health Assessment for CRM-anskaffelse. Risikoregister-mønster, Executive Summary-struktur, integrasjonslandskap-tabell.
+- **Oras Group** — Data Health Assessment for CRM-anskaffelse. Risikoregister-mønster, Executive Summary-struktur, integrasjonslandskap-tabell. (Ligger i `Salg/Oras/` i Forte-arbeidsområdet.)
-- **Den norske kirke / Nstat** (`../../../Kirken/`): Informasjonsarkitektur for offentlig organisasjon. 9-mappe-struktur, Begrepseier/Dataforvalter/Master-vokabular, Privacy by Design, 3-nivå governance.
+- **Den norske kirke / Nstat** — Informasjonsarkitektur for offentlig organisasjon. 9-mappe-struktur, Begrepseier/Dataforvalter/Master-vokabular, Privacy by Design, 3-nivå governance. (Eget repo/arbeidsområde.)
+
+Det vi faktisk trenger fra metodikken er hentet inn i dette repoet under [_metode/](_metode/) og [artefakter/](artefakter/).
 
 ## Repository-konvensjoner
 
@@ -140,10 +142,10 @@ Bygger på to ferske oppdrag:
 
 ## Salgsmaterialet — kilden til oppdraget
 
-`../../Salg/Standard/` inneholder:
+Salgsmaterialet ligger i `Salg/Standard/` i Forte-arbeidsområdet (**ikke i dette repoet** — det er salgsfase-materiale, ikke leveranse):
 - Forslaget vi sendte (`Forslag - Masterdata, arkitektur og AI-klargjøring.md`)
 - Kundens oppdragsbeskrivelse (PDF)
 - Pitch-presentasjon (PPTX)
 - CV-er for teamet
 
-Når du trenger å verifisere "hva vi lovet kunden" — slå opp der.
+Når du trenger å verifisere "hva vi lovet kunden" — slå opp der. Det viktigste innholdet er destillert inn i [_memories/project_standard-online-kontekst.md](_memories/project_standard-online-kontekst.md), som ligger i repoet.

README.md

@@ -17,10 +17,13 @@ Arbeidsmappe for Standard Online-oppdraget: kartlegging og anbefalingsarbeid for
 
 ## Struktur
 
-9-mappe-modell fra Startklar-malverket. Se [_index.md](_index.md) for full innholdsfortegnelse, eller [Salg/_mal/startklar-malverk/README.md](../../Salg/_mal/startklar-malverk/README.md) for forklaring av modellen.
+9-mappe-modell fra Startklar-malverket. Se [_index.md](_index.md) for full innholdsfortegnelse. Modellen er forklart i metodikkdokumentene under [_metode/](_metode/) (kopiert inn i repoet, avledet fra Forte sitt kanoniske `startklar-malverk` i `Salg/_mal/`-arbeidsområdet).
 
 ```
 Oppdrag/Standard/
+├── _metode/                       # Konvensjoner, sjekkliste, gjennomføringsmodell
+├── artefakter/                    # Gjenbrukbare maler (risikoregister, integrasjonslandskap, ...)
+├── _memories/                     # Prosjektkunnskap som overlever sesjoner
 ├── 1.oppdrag-og-kontekst/        # Scope, leveranser, interessenter, møtelogg
 ├── 2.organisasjonsforstaelse/     # Roller, beslutningsveier, nøkkelpersoner
 ├── 3.system-og-datalandskap/      # Systemer, integrasjoner, as-is
@@ -48,30 +51,29 @@ Detaljer i `1.oppdrag-og-kontekst/oppdragsbeskrivelse.md` når den fylles ut ved
 
 ## Når oppdraget starter
 
-1. Petter fyller ut `Salg/_mal/startklar-malverk/01-startklar-sjekkliste.md` internt (kopier inn i `1.oppdrag-og-kontekst/` om ønskelig)
+1. Petter fyller ut [_metode/01-startklar-sjekkliste.md](_metode/01-startklar-sjekkliste.md) internt
-2. Oppdater `1.oppdrag-og-kontekst/oppdragsbeskrivelse.md` med faktiske datoer, team, scope
+2. Oppdater [1.oppdrag-og-kontekst/oppdragsbeskrivelse.md](1.oppdrag-og-kontekst/oppdragsbeskrivelse.md) med faktiske datoer, team, scope
-3. Følg fasestrukturen i `Salg/_mal/startklar-malverk/02-gjennomforing.md`
+3. Følg fasestrukturen i [_metode/02-gjennomforing.md](_metode/02-gjennomforing.md)
 
 ## Verktøykasse
 
-Maler og artefakter som ikke kopieres inn lokalt (forblir kanoniske i `Salg/_mal/`):
+Gjenbrukbare maler ligger i [artefakter/](artefakter/) — kopier dem inn i passende undermappe når du tar dem i bruk (typisk inn i den leveransen de hører til):
 
-- [Risikoregister](../../Salg/_mal/startklar-malverk/artefakter/risikoregister.md) — Impact × Likelihood
+- [Risikoregister](artefakter/risikoregister.md) — Impact × Likelihood
-- [Integrasjonslandskap](../../Salg/_mal/startklar-malverk/artefakter/integrasjonslandskap.md)
+- [Integrasjonslandskap](artefakter/integrasjonslandskap.md)
-- [Workshop-agenda](../../Salg/_mal/startklar-malverk/artefakter/workshop-agenda.md)
+- [Workshop-agenda](artefakter/workshop-agenda.md)
-- [Domenemodell-skjema](../../Salg/_mal/startklar-malverk/artefakter/domenemodell-skjema.md)
+- [Domenemodell-skjema](artefakter/domenemodell-skjema.md)
-
-Når du trenger en av disse for Standard, kopier dem inn i passende undermappe (typisk `8.kontinuerlig-laering-og-referanser/` for sjekklister, eller direkte i den leveransen den hører til).
 
 ## Konvensjoner
 
-Følger Forte/Startklar-konvensjonene definert i `Salg/_mal/startklar-malverk/00-konvensjoner.md`:
+Følger Forte/Startklar-konvensjonene definert i [_metode/00-konvensjoner.md](_metode/00-konvensjoner.md):
 
 - Frontmatter med `qa.status`
 - DEC/ACT/RISK-YYYY-XXX-IDer for beslutninger/handlinger/risikoer
 - ANTAKELSE-markering med confidence-nivå
 - ISO-datoformat
 - Norsk Bokmål
+- **Lenker som standard markdown** (`[tekst](sti.md)`), ikke Obsidian-wikilinks — slik at de er klikkbare både i Gitea og lokalt
 
 ---
 

_memories/MEMORY.md

@@ -4,7 +4,7 @@ Prosjektspesifikke memories. Hver linje peker til en memory-fil i denne mappen.
 
 Format: `- [Tittel](fil.md) — én-linjes hook`
 
-Hold listen kort og scannbar. Bruk `[[fil-navn]]`-lenker innen memory-filer for kryssreferanser.
+Hold listen kort og scannbar. Bruk standard markdown-lenker `[tekst](fil-navn.md)` innen memory-filer for kryssreferanser — de er klikkbare både i Gitea og lokalt.
 
 ---
 

_memories/_template-memory.md

@@ -29,7 +29,7 @@ For **reference** memories — strukturér slik:
 
 ## Lenker til relaterte memories
 
-Bruk wikilink-stil: `[[andre-memory-navn]]`. Det er greit å lenke til memories som ikke finnes ennå — markerer at de er verdt å skrive.
+Bruk standard markdown-lenker: `[andre-memory-navn](andre-memory-navn.md)`. Det er greit å lenke til memories som ikke finnes ennå — markerer at de er verdt å skrive. (Vi bruker ikke Obsidian-wikilinks `[[...]]` her, fordi Gitea ikke rendrer dem som klikkbare.)
 
 ## Sjekkliste når du oppretter en ny memory
 

_memories/project_standard-online-kontekst.md

@@ -99,9 +99,11 @@ Konsekvens: Vi skal IKKE replikere Oras' entity-by-entity-dybde. Vi stopper på
 
 ## Salgsmaterialet som etablerer kontekst
 
-- `../../Salg/Standard/Forslag - Masterdata, arkitektur og AI-klargjøring.md` — fullstendig forslag
+Ligger i `Salg/Standard/` i Forte-arbeidsområdet (ikke i dette repoet — salgsfase-materiale):
-- `../../Salg/Standard/Oppdragsbeskrivelse masterdataprosjekt.pdf` — kundens RFP
+
-- `../../Salg/Standard/Standard_Digital2.pptx` — pitch-presentasjonen
+- `Forslag - Masterdata, arkitektur og AI-klargjøring.md` — fullstendig forslag
+- `Oppdragsbeskrivelse masterdataprosjekt.pdf` — kundens RFP
+- `Standard_Digital2.pptx` — pitch-presentasjonen
 
 ## Sjekkpunkter ved oppstart
 

_metode/00-konvensjoner.md

@@ -0,0 +1,124 @@
+---
+title: "Konvensjoner — Startklar-malverk"
+date: "2026-05-21"
+tags: ["konvensjoner", "frontmatter", "metode"]
+version: 1
+---
+
+# Konvensjoner
+
+Felles konvensjoner for alle dokumenter i et oppdrag som bruker dette malverket. Arvet og generalisert fra Den norske kirke-oppdraget.
+
+## Frontmatter
+
+Alle leveranse- og analysedokumenter skal ha YAML-frontmatter:
+
+```yaml
+---
+title: "Dokumenttittel — Kundenavn"
+date: "YYYY-MM-DD"
+source: "Kilder dokumentet bygger på (komma-separert)"
+tags: ["tag1", "tag2"]
+refs:
+  - "relativ/sti/til/relatert-dokument.md"
+qa:
+  status: "draft | final-candidate | needs-fix"
+  reviewed_on: "YYYY-MM-DD"
+  reviewer: "Navn eller rolle"
+version: 1
+---
+```
+
+**Status-verdier:**
+- `draft` — under arbeid
+- `final-candidate` — klar for sluttgjennomgang
+- `needs-fix` — funn å adressere
+
+For mindre interne arbeidsdokumenter (intervjunotater, hypoteseskisser) kan frontmatter forenkles til kun `title`, `date`, `tags`.
+
+## ID-system
+
+Strukturerte ekstrakter får IDer slik at de kan refereres på tvers av dokumenter:
+
+| Prefiks | Type | Eksempel |
+|---|---|---|
+| `DEC-YYYY-XXX` | Beslutning | DEC-2026-005 |
+| `ACT-YYYY-XXX` | Handling | ACT-2026-012 |
+| `RISK-YYYY-XXX` | Risiko | RISK-2026-003 |
+
+**Format:** ID + tittel, deretter strukturerte felter:
+
+```markdown
+### DEC-2026-005 — Bedrift som master-entitet ligger i Business Central
+
+**Dato:** 2026-06-03
+**Kilde:** Kickoff med Standard Online + Standard Digital
+**Status:** Bekreftet
+**Konsekvens:** SuperOffice og nopCommerce konsumerer; ingen skriving direkte i CRM/nettbutikk.
+```
+
+ID-numre allokeres fortløpende per type per år. Sjekk eksisterende dokumenter for siste brukte nummer før nytt ID utstedes.
+
+## Citation-format
+
+Når du refererer til kildemateriale:
+
+| Kildetype | Format | Eksempel |
+|---|---|---|
+| Markdown | `sti/til/fil.md#L12-L34` | `3.system-og-datalandskap/hovedsystemer.md#L42-L58` |
+| DOCX | `docx:avsnitt-N-M` eller `docx:side-N` | `oppdragsbeskrivelse.docx:avsnitt-3-5` |
+| PDF | `pdf:side-N` | `Startklar.pdf:side-1` |
+| Ekstern URL | Full URL i lenke | `[Tittel](https://...)` |
+| Møte | Dato + tema | `Møte 2026-06-03: Kickoff` |
+
+Lenker til andre dokumenter i samme oppdrag bruker **standard markdown med relativ sti**: `[masterdata-og-eierskap](../4.informasjonsarkitektur/masterdata-og-eierskap.md)`. Vi bruker IKKE Obsidian-wikilinks `[[...]]` — de er klikkbare i Obsidian lokalt, men Gitea rendrer dem ikke som lenker. Standard markdown fungerer i begge. Relative stier fungerer både i Gitea-web og lokalt så lenge målet ligger inne i repoet.
+
+## ANTAKELSE-markering
+
+Når du formulerer noe basert på begrenset informasjon, marker det eksplisitt:
+
+```
+ANTAKELSE: Bedriftsdata i SuperOffice er kanonisk for kundetjenesten, men ikke for fakturering. conf: moderat
+```
+
+Confidence-nivåer:
+- **lav** — gjetning basert på kontekst, må verifiseres
+- **moderat** — basert på indirekte informasjon, sannsynlig korrekt
+- **høy** — basert på direkte kilde, men ikke formelt bekreftet
+
+Bekreftede fakta trenger ingen markering.
+
+## Datoformat
+
+ISO 8601 alltid: `YYYY-MM-DD` (f.eks. `2026-05-21`). Aldri `21.05.2026` eller `21/5-26`.
+
+## Språk
+
+Norsk Bokmål er standard. Engelsk for kundefasade ved internasjonale kunder (avklares i `01-startklar-sjekkliste.md`).
+
+## Versjonering
+
+`version: N` i frontmatter inkrementeres ved hver meningsfull endring etter første ferdigstilling. Mindre rettinger trenger ikke version-bump. Bruk `endringslogg`-seksjon nederst i dokumenter som endrer seg ofte:
+
+```markdown
+## Endringslogg
+
+| Versjon | Dato | Endring | Forfatter |
+|---|---|---|---|
+| 1 | 2026-06-03 | Første utkast | Ragnhild |
+| 2 | 2026-06-10 | Lagt til SuperOffice-avhengighet | Ragnhild |
+```
+
+## Klassifisering
+
+Alle leveranser klassifiseres nederst:
+
+- **Åpen** — kan deles eksternt
+- **Begrenset** — kun for kunden og Forte-teamet (default)
+- **Konfidensiell** — kun for navngitte personer
+
+## Filnavn
+
+- Bruk bindestrek, ikke understrek: `masterdata-og-eierskap.md`, ikke `masterdata_og_eierskap.md`
+- Æ/Ø/Å erstattes med ae/oe/aa i filnavn for kompatibilitet: `kontinuerlig-laering`, ikke `kontinuerlig-læring`
+- Datert prefix kun når relevant: `2026-06-03-kickoff.md` for møtenotater

_metode/01-startklar-sjekkliste.md

@@ -0,0 +1,141 @@
+---
+title: "Startklar-sjekkliste — pre-flight"
+date: "YYYY-MM-DD"
+tags: ["startklar", "sjekkliste", "pre-flight"]
+qa:
+  status: "draft"
+version: 1
+---
+
+# Startklar — sjekkliste
+
+> *Du tar ikke av før laget vet hvor det skal.*
+
+Pre-flight før kundedialog og oppstart. Fyll ut **internt** før kickoff. Resultat: felles mandat, tydelige prioriteringer, kundedialog på riktig grunnlag.
+
+Strukturen følger Startklar "keep it simple"-versjonen (8 punkter). For Nivå 2/3-oppdrag, se utvidet sjekkliste i `Salg/Startklar.pdf`.
+
+---
+
+## 01 · Retning — Hvor skal vi?
+
+**Spørsmål:**
+- Hva er strategisk plattform/ambisjon dette oppdraget tjener?
+- Hva er ønsket tilstand 1-2 år etter oppdragets slutt?
+- Hvilket konkret verdibidrag skal oppdraget gi?
+
+**Svar:**
+
+---
+
+## 02 · Hensikt — Hvorfor skal vi dit?
+
+**Spørsmål:**
+- Hva er hovedproblemet vi løser? (én setning)
+- For hvem løser vi det?
+- Hva skjer hvis vi *ikke* gjør dette?
+
+**Svar:**
+
+---
+
+## 03 · Team — Hvem er med?
+
+**Spørsmål:**
+- Hvem fra Forte? (rolle + allokering)
+- Hvem fra kunden? (rolle + tilgjengelighet)
+- Hvem fra tredjepart (utviklingspartner, leverandør)? (rolle + samspillsform)
+
+**Svar:**
+
+| Person | Organisasjon | Rolle | Allokering | Kontakt |
+|---|---|---|---|---|
+
+---
+
+## 04 · Eierskap — Hvem eier beslutningene?
+
+**Spørsmål:**
+- Hvem er primært beslutningspunkt hos kunden?
+- Hvem signerer av på scope og leveranser?
+- Hvem er stedfortreder ved fravær?
+- Hvor i organisasjonen er mandatet forankret? (avdeling, ledergruppe, styre)
+
+**Svar:**
+
+---
+
+## 05 · Scope — Hva er innenfor, og hva er ikke?
+
+**Spørsmål:**
+- Hvilke systemer/domener er innenfor scope?
+- Hvilke er eksplisitt **utenfor**?
+- Hva er dybden? (oversikt, fagvurdering, dyp teknisk analyse)
+- Implementering inkludert eller ikke?
+
+**Innenfor scope:**
+-
+
+**Utenfor scope:**
+-
+
+---
+
+## 06 · Innsikt — Hva vet vi om problemet?
+
+**Spørsmål:**
+- Hvilken eksisterende dokumentasjon finnes? (arkitekturskisser, dataflytdiagrammer, tidligere utredninger)
+- Hvilke tidligere oppdrag eller pågående initiativer er relevante?
+- Hva er kunnskapshullene? Hvem må vi snakke med for å lukke dem?
+
+**Tilgjengelig underlag:**
+-
+
+**Kunnskapshull / hovedspørsmål:**
+-
+
+---
+
+## 07 · Risiko — Hvilke avhengigheter må håndteres?
+
+**Spørsmål:**
+- Hvilke andre prosjekter er kritiske avhengigheter? (ERP-skifte, CRM-migrasjon, etc.)
+- Hvilke harde tidsfrister finnes? (lisens, regulatorisk, kontraktuelt)
+- Hvilke organisatoriske risikoer? (kapasitet, beslutningshastighet, motstand)
+
+**Avhengigheter:**
+-
+
+**Risikoer (kort liste):**
+-
+
+---
+
+## 08 · Teknologi — Hvilke kapabiliteter trengs?
+
+**Spørsmål:**
+- Hva er kundens teknologisk landskap i hovedtrekk?
+- Hvilke kapabiliteter trenger vi (datamodellering, integrasjonsanalyse, AI-rammeverk, GDPR)?
+- Hvilke verktøy bruker vi? (Neo4j for relasjoner, Mermaid for diagrammer, etc.)
+- Hvilke tilganger trenger vi
+
+**Svar:**
+
+---
+
+## Resultat — felles mandat
+
+Etter utfylling:
+
+- [ ] **Felles mandat** internt i Forte-teamet
+- [ ] **Tydelige prioriteringer** for første ukene
+- [ ] **Kundedialog på riktig grunnlag** — vi vet hva vi skal spørre om og hva vi allerede vet
+
+**Sign-off:**
+
+| Navn | Rolle | Dato |
+|---|---|---|
+
+---
+
+*Klassifisering: Begrenset — internt Forte-dokument*

_metode/02-gjennomforing.md

@@ -0,0 +1,140 @@
+---
+title: "Gjennomføring — 4-fase-modell"
+date: "2026-05-21"
+tags: ["gjennomføring", "metode", "faseplan"]
+version: 1
+---
+
+# Gjennomføring — 4 faser
+
+Standard gjennomføringsmodell for Nivå 1-oppdrag (6-12 uker). Følger Standards forslag (slide 11) og Fortes Startklar-metodikk.
+
+## Oversikt
+
+| Fase | Varighet | Hovedaktivitet | Delleveranse |
+|---|---|---|---|
+| **A — Oppstart og avgrensning** | Uke 1 | Kickoff, scope, datakilde-inventar | Bekreftet scope og plan |
+| **B — Kartlegging og analyse** | Uke 2-3 | Intervjuer, workshops, datakvalitet | **Delleveranse 1**: Nåsituasjon + risiko (uke 3) |
+| **C — Anbefalinger og målbilde** | Uke 3-5 | Masterdata-modell, arkitektur, AI, personvern | **Delleveranse 2**: Målbilde + masterdata (uke 5) |
+| **D — Forankring og overlevering** | Uke 6-7 | Presentasjon, forankring, overlevering | **Sluttleveranse**: Handlingsplan + governance |
+
+## Fase A — Oppstart og avgrensning (uke 1)
+
+**Mål:** Bekrefte felles forståelse av scope, mandat og arbeidsform. Etablere grunnlag for kartlegging.
+
+**Aktiviteter:**
+- Kickoff med kunden (60-90 min) — felles gjennomgang av scope, leveranser, tidslinje
+- Avklare beslutningspunkter og styringspunkter
+- Få tilgang til eksisterende underlag (arkitekturskisser, dataflytdiagrammer, tidligere utredninger)
+- Datakilde-inventar (første utkast) — hvilke systemer, dataflyt, integrasjoner
+- Sett opp møtekadens, kommunikasjonsstruktur, mappe-tilgang
+- Identifiser de 8-12 personene som skal intervjues i Fase B
+
+**Leveranser fra Fase A:**
+- `1.oppdrag-og-kontekst/oppdragsbeskrivelse.md` — bekreftet versjon
+- `1.oppdrag-og-kontekst/mal-og-leveranser.md` — operasjonalisert
+- `1.oppdrag-og-kontekst/interessenter-og-kontaktinfo.md`
+- `1.oppdrag-og-kontekst/rammer-og-avklaringer.md`
+- `3.system-og-datalandskap/hovedsystemer.md` — første utkast
+- Intervjuplan for Fase B
+
+**Styringspunkt:** Avstemming med beslutningskontakt på slutten av uke 1 — bekreft scope og plan før Fase B starter.
+
+## Fase B — Kartlegging og analyse (uke 2-3)
+
+**Mål:** Bygge en faktabasert forståelse av nåsituasjon, datakvalitet, integrasjoner og risiko.
+
+**Aktiviteter:**
+- **8-12 intervjuer** (1-2 timers økter) med:
+  - Forretningseiere per domene
+  - IT-ansvarlige per system
+  - Potensielle dataeiere
+  - Sluttbrukere (utvalg)
+- **Workshops:**
+  - Dataflyt-workshop (visualiser hvordan data oppstår, dupliseres, konsumeres)
+  - Datakvalitet-workshop (per system: hva fungerer, hva er problematisk)
+- Bygg `3.system-og-datalandskap/*` ferdig
+- Start `4.informasjonsarkitektur/begrepskatalog.md` (løpende gjennom hele oppdraget)
+- Bruk `artefakter/integrasjonslandskap.md` til å strukturere integrasjonsfunn
+- Fyll inn `artefakter/risikoregister.md` med funn etter hvert som de identifiseres
+
+**Leveranser fra Fase B:**
+- `3.system-og-datalandskap/integrasjoner-og-flyt.md`
+- `3.system-og-datalandskap/systemkart-as-is.md`
+- `3.system-og-datalandskap/teknologier-og-leverandorer.md`
+- `8.kontinuerlig-laering-og-referanser/funn-og-hypoteser.md`
+- `artefakter/risikoregister.md`
+
+**Delleveranse 1 (uke 3):** Nåsituasjon + risikobilde — sammenstilling av mappe 3 + risikoregister + funn. Presenteres i styringsmøte med beslutningskontakt.
+
+## Fase C — Anbefalinger og målbilde (uke 3-5)
+
+**Mål:** Bygge masterdata-modell, målarkitektur, AI-rammeverk, personvern-vurdering og handlingsplan basert på funnene fra Fase B.
+
+**Aktiviteter:**
+- **Masterdata-modellering:**
+  - Identifiser kjernedomener (typisk 4-6 for Nivå 1)
+  - For hver entitet: bestem System-of-Record, Begrepseier, Dataforvalter
+  - Bygg `4.informasjonsarkitektur/masterdata-og-eierskap.md` + `informasjonsdomener.md`
+- **Målarkitektur:**
+  - Skisser to-be-arkitektur basert på funn
+  - Identifiser anbefalte komponenter (MDM, integrasjonsplattform, datakatalog)
+  - Vurder hub-and-spoke der det gir mening
+- **AI-rammeverk:**
+  - Operasjonelle prinsipper, ikke arkitektur-spec
+  - Fyll ut `6.ai-rammeverk/*`
+- **Personvern:**
+  - Privacy by Design-tiltak per domene (`5.personvern-og-sikkerhet/*`)
+  - Identifiser mangler og foreslå tiltak
+- **Workshops for validering:**
+  - Masterdata-workshop med potensielle dataeiere
+  - Målarkitektur-workshop med IT-eierskap
+- Skriv `4.informasjonsarkitektur/data-governance-prinsipper.md`
+
+**Delleveranse 2 (uke 5):** Målbilde + masterdata-modell + AI-rammeverk + GDPR-vurdering. Sammenstilling av mappe 4, 5, 6 + arkitekturskisser. Presenteres i workshop med beslutningskontakt og dataeiere.
+
+## Fase D — Forankring og overlevering (uke 6-7)
+
+**Mål:** Forankre anbefalingene, levere handlingsplan og governance-modell, klargjøre for neste fase.
+
+**Aktiviteter:**
+- Bygg `7.standardisering-og-handlingsplan/*` — prioritert handlingsplan basert på Fase B-C
+- Sammenstill `9.leveranser-og-oppsummeringer/executive-summary.md`
+- Bygg `9.leveranser-og-oppsummeringer/sluttrapport.md`
+- **Presentasjon for beslutningskontakt og hennes/hans linje** (90 min)
+- Bredere intern forankring hos kunden (workshop eller leder-runde)
+- Overlevering av alle leveranser (Nextcloud / SharePoint / kundens valgte plattform)
+- Anbefalinger for videre fase (skissér mulig implementeringsfase som egen leveranse)
+
+**Sluttleveranse (uke 6-7):** Komplett leveransesett, inkludert Executive Summary (standalone for ledelse) og Sluttrapport (5-delt).
+
+## Møtekadens
+
+| Møte | Frekvens | Deltakere | Varighet |
+|---|---|---|---|
+| Standup Forte-team | Daglig | Forte-team internt | 15 min |
+| Statusmøte med beslutningskontakt | Ukentlig | + 1 fra kunden | 30 min |
+| Workshop / intervju | Per behov | Forte + relevant rolle | 60-120 min |
+| Styringspunkt | Fase-overgang | Forte + beslutningskontakt | 60 min |
+
+## Forutsetninger (jf. Standard slide 16)
+
+- Beslutningskontakt eller utpekt stedfortreder tilgjengelig for rask respons
+- 8-12 nøkkelpersoner tilgjengelige for 1-2 timers intervju i Fase B
+- Dedikert kontakt hos kundens utviklingspartner (om aktuelt)
+- Eksisterende underlag (arkitekturskisser, dataflyt) tilgjengelig fra Fase A
+- Potensielle dataeiere deltar i workshops og validering
+
+## Avgrensninger
+
+- Dette er kartlegging og anbefaling — implementering er **ikke** inkludert
+- Endelige beslutninger om systemvalg og arkitektur ligger hos kunden
+- Detaljert teknisk implementeringsdesign er utenfor scope
+- Eventuell implementeringsfase prises som egen leveranse
+
+## Metodisk fundament
+
+- **Startklar** — Fortes egen metodikk for data readiness (`Salg/Startklar.pdf`)
+- **Personvern by design** — GDPR som premiss, ikke etterarbeid
+- **Hub-and-spoke der det gir mening** — fra DNK-erfaring, ikke et obligatorisk valg
+- **Funn først, anbefaling etterpå** — ingen tiltak uten dokumentert grunnlag

artefakter/domenemodell-skjema.md

@@ -0,0 +1,91 @@
+---
+title: "Domenemodell-skjema — mal"
+date: "YYYY-MM-DD"
+tags: ["domenemodell", "skjema", "masterdata", "artefakt"]
+qa:
+  status: "draft"
+version: 1
+---
+
+# Domenemodell-skjema
+
+Strukturert mal for å dokumentere en domenemodell — én fil per domene. Brukes som vedlegg til [informasjonsdomener](../4.informasjonsarkitektur/informasjonsdomener.md).
+
+## Header
+
+**Domene:**
+**Versjon:**
+**Eier (Domain Data Owner):**
+**Sist oppdatert:**
+
+## Entiteter
+
+| Entitet | Beskrivelse | Master (SoR) | Konsumenter | Begrepseier | Dataforvalter | Sensitivitet |
+|---|---|---|---|---|---|---|
+
+## ER-diagram
+
+```mermaid
+erDiagram
+  BEDRIFT ||--o{ KONTAKT : "har"
+  KONTAKT ||--o{ ORDRE : "lagt-inn"
+  BEDRIFT {
+    string OrgNr PK
+    string Navn
+    string Adresse
+  }
+  KONTAKT {
+    string KontaktId PK
+    string OrgNr FK
+    string Navn
+    string Epost
+  }
+```
+
+## Per entitet
+
+### <Entitetnavn>
+
+**Definisjon:** *Lenke til [begrepskatalog](../4.informasjonsarkitektur/begrepskatalog.md).*
+
+**Primær identifikator:**
+
+**Attributter (kritiske):**
+
+| Attributt | Type | Obligatorisk | Begrepseier | Master | Validerings-regler |
+|---|---|---|---|---|---|
+
+**Relasjoner:**
+
+| Relasjon | Til entitet | Kardinalitet | Beskrivelse |
+|---|---|---|---|
+
+**Livssyklus:**
+
+*Opprettelse → endring → arkivering/sletting. Hvem gjør hva?*
+
+**Tilgangskrav:**
+
+*Hvem skal kunne lese / skrive / slette?*
+
+**Personverntiltak:**
+
+*Lenke til [sensitive-dataomrader](../5.personvern-og-sikkerhet/sensitive-dataomrader.md).*
+
+---
+
+*Repeter for hver entitet i domenet.*
+
+## Avhengigheter til andre domener
+
+| Domene | Type avhengighet | Konsekvens hvis brutt |
+|---|---|---|
+
+## Endringslogg
+
+| Versjon | Dato | Endring | Forfatter |
+|---|---|---|---|
+
+---
+
+*Klassifisering: Begrenset*

artefakter/integrasjonslandskap.md

@@ -0,0 +1,66 @@
+---
+title: "Integrasjonslandskap — <KUNDE>"
+date: "YYYY-MM-DD"
+tags: ["integrasjon", "landskap", "artefakt"]
+qa:
+  status: "draft"
+version: 1
+---
+
+# Integrasjonslandskap
+
+Strukturert oversikt over alle integrasjoner. Mønster fra Oras Group sin Data Health Assessment (seksjon 6).
+
+## Per system / integrasjon
+
+| System | Retning | Kilde / motpart | Mekanisme | Datatyper | Frekvens | Personopplysninger? | Migrasjons-/endringsimplikasjon |
+|---|---|---|---|---|---|---|---|
+
+**Retning:**
+- **Inbound** — kommer inn til system
+- **Outbound** — går ut fra system
+- **Bidirectional** — toveis
+
+**Mekanisme:**
+- REST API
+- GraphQL
+- SOAP
+- Event/message bus
+- Filoverføring (SFTP/batch)
+- Database-til-database
+- Manuell (Excel-eksport, etc.)
+- ETL/ELT-jobb
+
+**Frekvens:** Real-time / Hver time / Daglig / Ukentlig / Månedlig / Ad hoc
+
+## Kritisk-vurdering
+
+For hver integrasjon, vurder:
+
+| Spørsmål | Hvis ja: konsekvens |
+|---|---|
+| Brytes ved skifte av motpart? | Må redesignes |
+| Inneholder personopplysninger? | GDPR-vurdering kreves |
+| Cross-border? | DPA/SCC kreves |
+| Real-time vs. batch? | Påvirker arkitekturvalg |
+| Blokkerende ved feil? | Resiliens-tiltak nødvendig |
+
+## Endringer som påvirker landskapet
+
+*Pågående initiativer hos kunden som vil endre integrasjonsbildet. Lenke til [pagaende-initiativer](../3.system-og-datalandskap/pagaende-initiativer.md).*
+
+## Punkt-til-punkt vs. hub-and-spoke
+
+Antall integrasjoner i dag: **N**
+
+Vurdering: Er antallet håndterbart, eller bør vi vurdere å konsolidere via integrasjonsplattform (hub-and-spoke)?
+
+**Vurderingskriterier:**
+- Antall punkt-til-punkt-integrasjoner (>15-20 begynner å bli vanskelig)
+- Vedlikeholdskostnad
+- Nye systemer som skal kobles på
+- Behov for sentral logging og styring
+
+---
+
+*Klassifisering: Begrenset*

artefakter/risikoregister.md

@@ -0,0 +1,70 @@
+---
+title: "Risikoregister — <KUNDE>"
+date: "YYYY-MM-DD"
+tags: ["risiko", "register", "artefakt"]
+qa:
+  status: "draft"
+version: 1
+---
+
+# Risikoregister
+
+Sentralt register over alle identifiserte risikoer. Mønster fra Oras Group sin Data Health Assessment.
+
+## Scoring
+
+**Score = Impact × Likelihood**
+
+| Impact | Beskrivelse |
+|---|---|
+| 5 | Kritisk — kan stoppe oppdraget eller forårsake store konsekvenser |
+| 4 | Alvorlig — betydelig negativ påvirkning |
+| 3 | Moderat — håndterbart, men krever oppmerksomhet |
+| 2 | Lav — mindre påvirkning |
+| 1 | Minimal |
+
+| Likelihood | Beskrivelse |
+|---|---|
+| 5 | Sikker — vil inntreffe |
+| 4 | Svært sannsynlig |
+| 3 | Sannsynlig |
+| 2 | Mulig |
+| 1 | Usannsynlig |
+
+**Risikonivå:**
+- **20-25** — KRITISK (rød)
+- **12-19** — HØY (oransje)
+- **6-11** — MIDDELS (gul)
+- **1-5** — LAV (grønn)
+
+## Aktivt register
+
+| # | Risiko | Impact | Likelihood | Score | Kategori | Kilde | Mitigasjon | Eier | Status |
+|---|---|---|---|---|---|---|---|---|---|
+| R1 | | | | | | | | | |
+
+*Kategori: Teknisk / Organisatorisk / Personvern / Tidsplan / Avhengighet / Kommersielt*
+*Status: Åpen / Mitigert / Akseptert / Lukket*
+
+## Lukkede risikoer (arkiv)
+
+| # | Risiko | Lukket dato | Begrunnelse |
+|---|---|---|---|
+
+## Risikomatrise (visualisering)
+
+```
+Likelihood
+   5 │            │            │   R3 (20) │   R1 (25) │
+   4 │            │            │            │   R2 (16) │
+   3 │            │            │            │            │
+   2 │            │            │            │            │
+   1 │            │            │            │            │
+     └────────────┴────────────┴────────────┴────────────┘
+        1            2            3            4            5
+                          Impact
+```
+
+---
+
+*Klassifisering: Begrenset*

artefakter/workshop-agenda.md

@@ -0,0 +1,65 @@
+---
+title: "Workshop-agenda — mal"
+date: "YYYY-MM-DD"
+tags: ["workshop", "agenda", "mal"]
+qa:
+  status: "draft"
+version: 1
+---
+
+# Workshop-agenda
+
+Generell mal — tilpasses per workshop. Bruk gjerne sammen med rollebaserte intervjuguider i [intervjuguider](../8.kontinuerlig-laering-og-referanser/intervjuguider.md).
+
+## Header
+
+**Dato:** YYYY-MM-DD
+**Tid:** HH:MM – HH:MM
+**Sted / kanal:**
+**Workshop-tema:**
+**Forberedelseunderlag:**
+
+## Deltakere
+
+| Navn | Rolle | Bekreftet |
+|---|---|---|
+
+## Mål
+
+*Hva skal vi oppnå?*
+
+1.
+2.
+3.
+
+## Agenda
+
+| Tid | Aktivitet | Eier | Format |
+|---|---|---|---|
+| 00:00 | Velkommen og innledning | | Plenum |
+| 00:10 | Felles utgangspunkt — sammendrag og rammer | | Plenum |
+| 00:20 | Tema 1 — kartlegging | | Diskusjon / gruppe |
+| 01:00 | Pause | | |
+| 01:10 | Tema 2 — prioritering | | Workshop-øvelse |
+| 01:50 | Oppsummering og neste skritt | | Plenum |
+
+## Forberedelse
+
+**Fra Forte:**
+- Forhåndsdelte underlag
+- Whiteboard / Miro
+- Notater fra forrige workshop
+
+**Fra deltakere:**
+- Eventuelle dokumenter til gjennomgang
+- Konkret eksempler å bringe inn
+
+## Etterarbeid
+
+- [ ] Sende referat senest 48 timer etter workshop
+- [ ] Logge beslutninger/handlinger/risikoer i [motelogg-og-beslutninger](../1.oppdrag-og-kontekst/motelogg-og-beslutninger.md)
+- [ ] Oppdatere relevante leveransedokumenter
+
+---
+
+*Klassifisering: Begrenset*