portfolio-optimiser/docs/plan/2026-07-14-revisjonspakke-DF-DI.md

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