# Revisjonspakke — D-F–D-I: intensjonsanalyse → planverk-oppgradering (2026-07-14)

> **Status:** BESLUTTET i operatør-samtale 2026-07-14. Denne pakka er fasit-protokollen +
> innplasserings-planen. **Ingenting frosset er endret ennå** — amendments skjer bevisst via
> commons (PULL-ONLY) og egne økter, med denne pakka som kilde. Operatøren har gitt
> klarsignal for HELE oppgraderingen («du får lov til å gjøre alt som trengs»); utførelsen
> er parkert på Fable-kvote (92 % brukt før torsdag) — gjenopptas 2026-07-16+.
> **Provenance:** anbefalinger = AI (Fable 5, intensjonsanalyse-økt #8 2026-07-14);
> beslutninger = operatør, protokollert punktvis under. Grunnlag: dokumentanalyse (målbilde,
> method-spec, ingest-målbilde, research §15, review 2026-07, sesjonsplan) + to
> Opus-kartlegginger (kode/bundle-innhold; kryssrepo-OKF-inventar — fanget i §0.2, finnes
> ellers kun i samtalen).

---

## 0. Funnene som utløste pakka (intensjonsnivå — ikke implementasjon; F1–F14 er dekket)

1. **F-INT-1 Kunnskapsinnholdet er underspesifisert → kaldstart-problem.** Method-spec §2
   lister kontekst-lagets innhold generisk; intet krav om historisk fagkunnskap om
   sparemåter per dimensjon. Substrat i dag: ÉN mikro-bundle (`bygg-energi-mikro`), de 4
   porteføljeprosjektene er ikke bundles; `Dimension` konstrueres kun i tester (ingen
   katalog/loader). Delt kryssprosjekt-fagkunnskap har ingen arkitekturplass (kontekst-laget
   er strengt per-prosjekt). Kobler til F5/S3.2 (multi-kandidat).
2. **F-INT-2 OKF-duplikasjon + spec-avvik.** 6 kodelokasjoner håndruller formatet (§0.2);
   method-spec avviser OKF-spec-ens anbefalte `/`-lenkeform (review F4/U-1, ligger i D-A).
3. **F-INT-3 Brukervennlighet mangler «ferdig»-definisjon.** Research B9
   (onboarding-intervju) falt ut av målbildet; `main()` driver ikke Fase-1-featurene (P6);
   README-ens eneste inngang er simuleringen.
4. **F-INT-4 «Betydelig verdi» er ikke operasjonalisert.** Ingen suksesskriterier for
   verdibevis; syntetisk domene (D4) kan ikke bevise besparelser; pilot (M3) = 1×1.
5. **F-INT-5 Kjøringskost er en CFO-beslutning.** Reell skala = 50k–1M+ NOK per
   signering → kostnadsestimat/simulering FØR kjøring er en produktegenskap, ikke nice-to-have.

### 0.2 Kryssrepo-OKF-inventar (Opus-kartlegging 2026-07-14, komprimert)

| # | Lokasjon | Språk/størrelse | Delmengde |
|---|---|---|---|
| A1 | `portfolio-optimiser/src/portfolio_optimiser/okf.py` | Py, 202 l | les + skriv + validér |
| A2 | `portfolio-optimiser-claude/src/portfolio_optimiser_claude/okf.py` | Py, 134 l | **kun les** (mangler skrive-halvdelen/Steg 8-primitiver) |
| B1 | `ktg-plugin-marketplace/okr/` (lib+scripts `.mjs`) | JS | index-generering + validering |
| B2 | `ktg-plugin-marketplace/linkedin-studio/scripts/brain/` | TS | emit + conformance-test |
| C1 | `claude-code-llm-wiki/tools/wiki_ingest/bundle.py` | Py, 436 l | OKF-produsent (ingest→bundle) |
| C2 | `llm-ingestion-pipeline-security/src/llm_ingestion_guard/okf.py` | Py, 579 l | defensiv validator, **reject-by-default** |

≥4 uavhengige Python-`parse_frontmatter` + 2 i JS. Ingen kopier: A-paret og B-paret er
bevisste spec-ikke-kode-søsken; C1/C2 uavhengige med annet formål. C2 konsolideres IKKE
(motsatt sikkerhetsfilosofi by design). To eksisterende konvergens-beslutninger («del spec,
ikke kode»: marketplace-brief 2026-06-26 + D7) **reverseres bevisst av D-G for den tolerante
kjernen** — operatør-godkjent 2026-07-14. Gjenbruksmal: `llm-ingestion-guard` (pip-pakke,
stdlib-only kjerne, valgfrie adaptere). Terminologi: **Google Open Knowledge Format v0.1**.

---

## 1. D-F — Kunnskapsinnholdsmodell (BESLUTTET)

**Operatør-fasit:**
1. Ny innholdsmodell i delt spec (commons): kunnskapstyper for **tiltaksmønstre,
   erfaringsnotater, faglige råd** — alt med påkrevd kildebelegg. Målet: alt fageksperter
   har av eksplisitt kunnskap + mest mulig taus kunnskap, erfaringer, råd — «så mye kontekst
   som mulig som KAN være relevant», systematisert så det forblir håndterlig.
2. **Kun lesestoff** for AI-forslagsstilleren. Kalkulatorens (validatorens) regler røres
   ikke — evt. bibliotek→validator-kobling er en egen framtidig beslutning.
3. **Streng separasjon fra dommene** (ufravikelig): bibliotek flyter via `bundle_context`;
   organisasjonens korreksjoner KUN via den gatede ExpeL-folden. Blandes aldri.
4. Delt **dimensjonsbibliotek materialiseres inn** i hver prosjekt-bundle via ingest-mønsteret
   (`generated: true`, manifest-ref, re-materialisering eier egne filer) — IKKE
   kryssbundle-lenker (navigasjonen forblir flat/same-dir), IKKE manuell duplisering.
5. **Dimensjonskatalog som konfig** (skjema-validert fail-fast: id, label,
   allowed_measure_types, allowed_code_prefixes). Rammeverket shipper eksempel-katalog;
   deployer eier sin. Biblioteksfiler tagges med eksisterende `dimension:`-frontmatter.
6. **Trinnvis lesing (nytt krav):** sammendrag-først (én linje per kunnskapsfil),
   fulltekst hentes ved behov — så basen kan bli stor uten prompt-drukning. Dagens
   «render alt navigert» skalerer ikke til ambisjonen.
7. **Shipped eksempel: energi-dimensjonen i tilnærmet realistisk skala** — flere
   bygg/prosjekter, 15–30 tiltak i biblioteket, **med rådataene** (målinger,
   kostnadslinjer, notater som filer/DB-fixtures) så HELE kjeden testes/demonstreres:
   rådata → ingest → base → forslag → validering → dom → læring. AI forfatter innholdet
   med kildeverifisering (søk-først + provenance; operatør er ikke domeneekspert).
8. Taus kunnskap: biblioteket tar det nedskrivbare; genuint taus kunnskap fanges via
   dommene (rationale-prosaen) — det er læringssløyfas eksisterende kanal.

**Innplassering:** beslutning nå; bygging i Fase 3-bolken (etter S2.0/S2.1/S2.5),
koordinert med S3.2 (multi-kandidat, F5). Spec-amendment i commons FØRST (D7-speiling
flagges). Amendment-utkastet skrives i utrullings-økta (§5).

## 2. D-G — OKF: felles modul, fabrikk, evaluator (BESLUTTET)

**Operatør-fasit:**
1. **Standard-kompatibel** («vi må være kompatibel med standarden») — F4/`/`-lenkeformen
   må rettes (forsterker D-A pkt. 3). **Egne utvidelser oppå** (innboks-konseptet,
   ingest-sikkerhet, evaluator-felt) dokumenteres eksplisitt SOM utvidelser — pensjoneres
   hvis standarden senere løser dem.
2. **Felles OKF-kode: JA.** Begge søsknene deler én modul (endrer D7s «from spec
   alone»-avgrensning bevisst — formatlaget ligger under det som sammenlignes). Claude-repoet
   skal være **minst like godt** som MAF-repoet (operatørens favoritt); delt modul gir det
   skrive-halvdelen det mangler i dag (A2).
3. **Eget nytt repo** (tredje signatur-repo, arbeidstittel `okf-toolkit` — operatør
   navngir): delt modul (tolerant les/naviger/skriv-kjerne) + **formatprøve**
   (conformance-testsett alle konsumenter kjører) + **bundle-evaluatoren** +
   **bundle-fabrikken**. Guard-malen: installerbar pakke, avhengighetsfri kjerne,
   Forgejo. Potensielt nyttig for alle som tar i bruk Google OKF. Guard forblir eget repo
   (sikkerhetskomponent, brukes som avhengighet).
4. **Bundle-fabrikken (viktigst nå, operatør):** bruker slipper filer/mapper i en
   **bundle-innboks** → prosessen gjør ALT (strukturerer, oppsummerer, lenker, stempler,
   sikkerhetsvasker — standarden + våre utvidelser) → ferdig base som evaluatoren scorer
   høyt på alle dimensjoner. **Ærlighets-grense:** fabrikken bruker AI og lever UTENFOR
   optimalisererens deterministiske kjøresti; alt merkes maskingenerert; evaluator +
   ekspert er kontrollen.
5. **Evaluatoren har to jobber:** (a) teknisk korrekthet (deterministisk: konformitet,
   navigerbarhet, lenke-integritet, kildedekning, ferskhet, sikkerhet, sammendragsdisiplin);
   (b) **tilstrekkelighet** («omfattende nok til å være nyttig? hva mangler?») —
   AI-vurdert med åpne kriterier. (b) er fagekspertens arbeidsliste under oppbygging.
6. **Rekkefølge:** modul + formatprøve først (liten jobb, fjerner 6-steders-duplikasjonen),
   fabrikk + evaluator deretter — bygget mot energi-caset (D-F pkt. 7) som første kunde.

## 3. D-H — Oppsett og brukervennlighet (BESLUTTET)

**Operatør-fasit:**
1. **Oppsett gjøres ALLTID av et lite team** av tekniske eksperter + fageksperter sammen
   (spesielt MAF-siden er komplisert). Leveransen er en **oppskrift** (dokumentert
   team-prosess), IKKE en veiviser. Ærlig forventning i README: en god kunnskapsbase tar
   **1–2 uker dedikert arbeid** — kvaliteten på investeringen avgjør resultatet.
   (Onboarding-intervju/B9 og guidet dom-kommando: FORKASTET.)
2. **Fagpersonens grensesnitt er kun:** hva de skal bidra med faglig, hvordan og hvor.
   De leverer **filer i egne formater** — aldri skjema/JSON. Evaluatorens
   tilstrekkelighets-feedback styrer bidragene.
3. **Dommer:** eksperten leverer fri-format-fil → **fabrikken** AI-oversetter til det
   strenge domsformatet (store volum gjør manuell oversettelse urealistisk). Godkjenning i
   praksis = **stikkprøver** i generert bundle. Vaktpost: den strukturerte dommen peker
   ALLTID på ekspertens originalfil (provenance), så stikkprøven kan sammenligne «hva
   eksperten skrev» mot «hva systemet forsto». Dommen er menneskets; AI er oversetter.
4. **Demo-stien:** fersk klon → unzip energi-eksemplet i bundle-innboksen → fabrikken
   bygger → hele sløyfa kjører. Demoen er ærlig fordi den viser den reelle prosessen med
   ferdig innhold.
5. **Lese-løsning:** Obsidian/VS Code holder først (bundles er ren markdown). Dedikert
   lese-visning = senere byggekloss i toolkit-repoet.

## 4. D-I — Verdibevis + kostnadsstyring (BESLUTTET)

**Operatør-fasit:**
1. **Nivå 2 som publiserings-påstand:** «på et realistisk case finner og kvalitetssikrer
   systemet reelle besparelses-kandidater» (modellerte tall, ærlig formulert — aldri
   salgsspråk over beleggsnivået). **Nivå 3** (ekte referanse/pilot) er uttalt håp —
   målgruppen er LinkedIn-nettverket som skal VILLE teste det (generelt problem, åpen
   invitasjon). Pilot står åpen; alt bygges klart for den som kommer først (operatør kan
   ikke starte internt; krever CFO-signert budsjett).
2. **Verdirapport per kjøring = kjerne** (løftet fra review-forslag 1): hovedbok-basert —
   modellert → ekspert-korrigert → realisert per prosjekt/dimensjon, målprogresjon,
   **læringseffekt tallfestet** (godkjenningsandel per kjøring; krymper
   modellert-vs-forventet-gapet?), og **kost-mot-verdi** («kjøringen kostet X,
   identifiserte kvalitetssikret modellert besparelse Y»).
3. **Kostnadssimulering FØR kjøring (MÅ-krav, operatør):** what-if over modell-mappet —
   estimert kost for en gitt portefølje-kjøring under ulike **modeller og effortnivåer**,
   med dokumenterte kvalitets-avveininger per modellvalg. Ærlighetsregler: prisdata som
   konfig (aldri hardkodet; verifiseres mot leverandørpriser med kilde+dato);
   kvalitetsutsagn merkes som veiledning med kilde, aldri som målt fakta uten belegg.
   Adopsjonssti dokumenteres: start liten (én dimensjon, ett prosjekt, lavt tak) → eskaler
   med tilliten. Kobler til S3.4/S3.5 (kost på tvers) og M1/M2.

## 5. Innplassering i planverket (apply-liste — status 2026-07-15: pkt. 1, 2, 4 UTFØRT; pkt. 3 = utkast skrevet, venter operatør-godkjenning; pkt. 5–6 uendret)

1. **Sesjonsplanen** (`2026-07-10-sesjonsplan-fase2-6.md`): nye §2-oppføringer D-F–D-I med
   status BESLUTTET (fasit her); nye sesjoner skisseres: S3.5+ *bibliotek/innholdsmodell*
   (etter commons-amendment; koordinert S3.2), S3.x *kostnadssimulering* (S3.4-familien),
   S5.x *verdirapport* (etter S2.1-outbox + ledger), S5.3 utvides med oppskrift-dok;
   avhengighetsgraf + sekvens oppdateres. **S2.0/S2.1/S2.5 forblir uendret byggbare.**
2. **Roadmapen** (`2026-07-06-reell-kjoring-analyse-plan.md`): revisjonsblokk 2026-07-14
   (D-F–D-I + F-INT-funnene).
3. **Commons** (egen økt, PULL-ONLY): amendment-utkast for innholdsmodellen (D-F pkt. 1–6)
   + utvidelses-policy (D-G pkt. 1) — operatør godkjenner utkastet FØR commons-commit;
   D7-søsken-speiling flagges.
4. **Toolkit-repo:** egen brief + repo-init (utenfor dette repoets sesjonskø; blokkerer
   fabrikk-avhengige deler av D-F/D-H).
5. **README:** oppdateres først når nivå-2-beviset finnes (D-I pkt. 1 — ingen påstander før
   belegg).
6. Frosne dokumenter røres KUN via pkt. 3-regimet. D-A/D-B-køen står uendret (D-A pkt. 3
   får forsterket begrunnelse fra D-G).

## 6. Verifisering (pakkas egne kriterier)

- Hver D-beslutning over har: operatør-fasit + belegg/kobling til eksisterende funn-ID-er. ✅
- Utrullings-økta er ferdig når: sesjonsplanen viser D-F–D-I + nye sesjoner med
  TDD/detach-punkt per husregel; roadmapen har revisjonsblokk; commons-amendment-utkast
  foreligger til operatør-godkjenning; toolkit-brief foreligger. Testbart: `grep -n "D-F"
  docs/plan/2026-07-10-sesjonsplan-fase2-6.md` treffer; full suite fortsatt grønn (ingen
  kodeendring i denne pakka).
- Nøkkelantakelse å teste i utrullings-økta: trinnvis-lesing-kravet (D-F pkt. 6) kan
  spesifiseres uten å bryte method-spec §3 Steg 1s render-kontrakt — hvis ikke, er det
  del av commons-amendmenten (flagges eksplisitt).