docs(review): kryssmodell-review 2026-07 (14 funn, 11 detach-bevis) + revidert roadmap + sesjonsplan Fase 2-6

docs/plan/2026-07-06-reell-kjoring-analyse-plan.md

@@ -0,0 +1,151 @@
+# Analyse & plan — første reelle virksomhetskjøring
+
+> **Status:** UNDER UTFØRELSE — revidert 2026-07-10. **Fase 1 (klynge A) EKSEKVERT**
+> (`a44256a`→`847ed90`, 10/10 steg, 279/4 grønn). Kryssmodell-review 2026-07-09
+> ([funn](../review-2026-07.md)) injiserte endringer i Fase 2–6; den detaljerte, gjeldende
+> per-sesjons-planen er [sesjonsplanen 2026-07-10](2026-07-10-sesjonsplan-fase2-6.md)
+> (S2.0–S5.3 + beslutnings-kø D-A–D-E + operatør-milepæler M1–M3). Denne fila forblir
+> task-definisjonen/gap-analysen; sesjonsplanen er utførelses-nivået.
+>
+> **Kilde:** operatør-scenario 2026-07-06 + [gap-analyse](#) forankret i målbilde §2–§4,
+> ingest-målbilde §11/§12, research §15. Ingen modell-kostnad påløpt.
+
+## 1. Scenariet (operatørens ord, presisert)
+
+Et team i en virksomhet starter en seriøs kjøring over en portefølje av flere uavhengige
+prosjekter. Hvert prosjekt skal kostnadsreduseres innenfor **flere dimensjoner** (anta ~10 per
+prosjekt), og det kjøres typisk **én dimensjon per prosjekt per kjøring**. Inn i systemet legges
+i tillegg **all relevant kontekst**:
+
+- faglig kunnskap + faglige vurderingsmetoder,
+- tidligere vurderinger (både **godkjente og forkastede**),
+- hvor mye som er **spart så langt**,
+- **målsetning** per prosjekt og totalt for porteføljen,
+- + øvrig relevant kontekst.
+
+Data er en blanding av **eksterne og interne** kilder, lagt inn enten **manuelt** eller **hentet**
+fra databaser, rapporter, **MCP-servere** og annet.
+
+## 2. Hva som gjenbrukes (bygget + load-bearing-testet)
+
+Ikke bygg på nytt. Dette står og er dekket av detach-bevisende tester:
+8-stegs-loopen (kontekst→hypotese→debatt→validér→forbedre→foreslå→feedback→promotér), den
+**blokkerende deterministiske validatoren** (solver + Monte Carlo), budsjett-/stopp-tak,
+provenance-stempling, ingest-kjernen (CSV + SQL på begge stacker; HTTP MAF-demo), gated
+wiki-promotering (fail-closed), async verdict-inbox, ExpeL-folden, og den delte framework-nøytrale
+kjernen (`shared/` = OKF + golden-suite + ekspert-persona-skill).
+
+## 3. Gap-analyse: scenario → dagens tilstand → gap
+
+Fem gap-klynger. Kostnad er konsentrert i C og D.
+
+### A. Domenemodellering (offline, gratis, load-bearing-testbar)
+- **Dimensjon som begrep.** I dag: kandidat-tiltak per prosjekt. Trengs: «dimensjon» som
+  førsteklasses scoping av hypoteserommet (hvilken kostnadsakse en kjøring adresserer) + IR/config
+  for det + orkestrering av N prosjekter × 10 dimensjoner (hvilken dimensjon når, dedup på tvers).
+- **Mål + besparelses-hovedbok.** I dag: ingen. Trengs: persistent, provenance-stemplet hovedbok
+  over *realiserte* besparelser per prosjekt + portefølje, mål-tilstand per prosjekt + totalt, og
+  «stopp når mål nådd»-logikk (distinkt fra token-budsjett-taket).
+- **Faglige vurderingsmetoder.** I dag: deterministisk validator + persona. Trengs: encoding av
+  domenets faktiske metoder — dels som kunnskap i OKF-bundelen, dels evt. som validator-regler.
+
+### B. Datainntak for virkeligheten
+- **MCP wiret i kjørestien.** I dag: extension-point-demo (`build_mcp_server`), ikke wiret.
+  Trengs: MCP som en ekte ingest-kilde (bygg extension-punktet du eksplisitt vil bruke).
+- **Dokument/rapport-connector.** I dag: ingen (kun CSV/SQL/HTTP). Trengs: PDF/DOCX/rapport →
+  OKF-bundle med provenance.
+- **Live-kilde-herding.** I dag: alt mot committede fixtures / lokal mock — ingen bundle er
+  materialisert fra en ekte kilde, noensinne. Trengs: credentials-håndtering, feilhåndtering,
+  live-provenance, inkrementell re-ingest.
+
+### C. Skala + henting (kostnad begynner her)
+- **Semantisk henting.** I dag: feature-key-match. Ved «all faglig kunnskap + alle tidligere
+  dommer» blir dette utilstrekkelig — embeddings/vektor-henting (B2/R4/U10) blir load-bearing.
+- **Concurrency + kostnadsstyring.** I dag: sekvensiell `run_portfolio` + per-kjøring token-tak.
+  N×10 kjøringer krever concurrent fan-out (U1, bevisst kuttet) + kostnadsstyring på tvers av mange
+  kjøringer.
+
+### D. Kjøretid mot ekte modell (kostnad + tenant)
+- **Azure/Foundry-profil eksersert.** I dag: kun lokal/offline; azure-blokk i `model_map.json` er
+  placeholders. Trengs: ekte deployments i virksomhetens tenant.
+- **Live-modell-kjøring.** I dag: alt ende-til-ende er skriptet offline-sim (bevis for plumbing,
+  ikke for at en levende LLM produserer forslaget/dommen). Trengs: første genuine kjøring, validert
+  i liten skala før full portefølje.
+
+### E. HITL-operasjoner i skala
+- **Verdict-ruting + -sporing.** I dag: én mappe-inbox. Ved mange kandidater trengs ruting til rett
+  fagekspert, sporing av utestående dommer, oversikt for teamet.
+- **Varsling.** I dag: `notify=`-stub. Trengs: ekte leveranse (e-post/Teams/webhook — B11).
+
+## 4. Åpne designbeslutninger (må avklares i Fase 0, ikke av meg nå)
+
+> **Status 2026-07-10 (post Fase 1 + review):** (1) dimensjonsmodell **AVKLART** av Fase 1
+> (både kontekst-subsett OG kandidat-constraint; dobbelttelling løst av ledgerens dimensjonsfrie
+> sum-nøkkel). (2) hovedbok-sannhet **I HOVEDSAK AVKLART** (typet `SavingsLedger` + fail-closed
+> `realize`-ekspertgate; driftskonvensjon gjenstår). (3) mål-semantikk **DELVIS** (absolutt +
+> prosent + hard/soft bygget; prosent-BASELINE uavklart → beslutning **D-E**). (4) første
+> live-kilde **ÅPEN** → **D-B** (NB: krever samtidig bevisst amendment av frossen
+> ingest-målbilde §8/§11 — review P1). (5) vektor-store **ÅPEN** → **D-C** (research-grunnlag
+> klart: numpy brute-force > sqlite-vec; LanceDB utelukket på Intel-Mac). (6) stack-paritet
+> **ÅPEN** → **D-E**. D-referanser: [sesjonsplanen §2](2026-07-10-sesjonsplan-fase2-6.md).
+
+1. **Dimensjon-modell:** er en dimensjon en delmengde av bundle-konteksten, en constraint på
+   kandidat-typer, eller begge? Hvordan unngås dobbelttelling av besparelser på tvers av dimensjoner?
+2. **Besparelses-hovedbok:** hvor bor sannheten om «realisert» besparelse — en ny RAW-fil-lag à la
+   verdicts, eller en egen typet store? Hvem stempler «realisert» (ekspert-gate, som promotering)?
+3. **Mål-semantikk:** absolutt beløp, prosent, eller per-dimensjon-vekting? Stopp-adferd ved nådd mål.
+4. **Første live-kilde:** hvilken (DB / rapport / MCP) er tryggest å herde først?
+5. **Vektor-store-valg:** hvilken embeddings-backend passer begge stacker + kostnadsdisiplinen?
+6. **Rettferdig stack-paritet:** kjører den ekte kjøringen på MAF, Claude-SDK, eller begge for
+   sammenligning? (påvirker hvor Azure/Foundry vs. Claude-API-kostnaden lander)
+
+## 5. Faset plan (roadmap)
+
+Hver fase er uavhengig verifiserbar; kostnad konsentreres i Fase 4+. Utføres via Voyage-pipeline
+(`/trekbrief → /trekresearch → /trekplan → /trekexecute → /trekreview`) per fase — én fase per
+større arbeidsbolk, aldri one-shot.
+
+> **Revisjon 2026-07-10 (etter kryssmodell-review):** Fase 1 EKSEKVERT (`847ed90`). Fase 2–6 er
+> detaljert og REVIDERT i [sesjonsplanen](2026-07-10-sesjonsplan-fase2-6.md) — viktigste
+> endringer: «MCP wiret i kjørestien» presisert til **MCP-ingest-konnektor** (method-spec §3
+> forbyr query-time retrieval); live-kilde-herding **gated på bevisst ingest-målbilde-amendment**
+> (D-B — konflikt med frossen §8/§11, review P1); concurrent fan-out krever beslutning **D-D**
+> først (determinisme-modell, review F6); nye funn-injiserte sesjoner **S2.0**
+> (portefølje-læringssløyfe, F1), **S2.1** (outbox/output-laget, P4), **S2.5** (inbox-herding,
+> F7/F11), **S2.7** (validator-stramming, F2), **S4.0** (kostbaseline-forankring, F3); Fase 4/6
+> splittet i offline-sesjoner (S4.0–S4.2) + operatør-milepæler **M1–M3**.
+
+- **Fase 0 — Dyp planlegging + research.** Voyage trekbrief/trekplan per etterfølgende fase; ekstern
+  research på vektor-stores, MCP-connector-mønstre, Foundry-deployment. Avklar §4-beslutningene.
+  *Output:* per-fase-briefer. *Kostnad:* ingen (planlegging).
+- **Fase 1 — Domenemodellering (klynge A).** Dimensjon-begrep, mål + besparelses-hovedbok,
+  vurderingsmetode-encoding. Offline, fixtures, load-bearing. *Kostnad:* ingen.
+- **Fase 2 — Datainntak for virkeligheten (klynge B).** MCP-wiring, dokument-connector,
+  live-kilde-herding (mot én kontrollert kilde). *Kostnad:* minimal.
+- **Fase 3 — Skala + henting (klynge C).** Embeddings/semantisk henting, concurrent fan-out,
+  kostnadsstyring på tvers av kjøringer. *Kostnad:* lav (embeddings).
+- **Fase 4 — Kjøretid mot ekte modell (klynge D).** Eksersér Azure/Foundry-profil i tenant; første
+  live-modell-kjøring i liten skala. *Kostnad:* reell API — hardt tak, minimal verifisering.
+- **Fase 5 — HITL-operasjoner i skala (klynge E).** Verdict-ruting/-sporing + varsling (B11).
+- **Fase 6 — Pilot.** Én ekte kjøring: **én dimensjon, ett prosjekt**, live kilde + live modell +
+  ekte ekspert. Verifiser hele sløyfa mot virkeligheten FØR skalering til full N×10-portefølje.
+- **Deretter:** skaler til full portefølje.
+
+## 6. Verifisering (suksesskriterier, testbare)
+
+- **Fase 1:** en dimensjon-scopet kjøring produserer kun kandidater innen dimensjonen (test);
+  hovedboken akkumulerer realisert besparelse med provenance og respekterer et mål-stopp (test).
+- **Fase 2:** en bundle materialiseres fra en live kilde via MCP + via dokument-connector, med
+  korrekt provenance (golden mot kontrollert kilde).
+- **Fase 3:** semantisk henting returnerer relevant tidligere dom over en syntetisk stor base;
+  concurrent portefølje-kjøring gir identisk resultat som sekvensiell (determinisme bevart).
+- **Fase 4:** én dokumentert live-modell-kjøring innen token-tak; Azure/Foundry-profil grønn.
+- **Fase 6:** pilot-kjøringen lukker sløyfa (forslag → validér → ekspert-dom → promotering →
+  neste kjørings kontekst bærer dommen) mot ekte modell + ekte kilde.
+
+## 7. Grenser (uendret, gjelder også her)
+
+Rent teknisk rammeverk (deployer eier DPIA/ROS/formål). 90%-prinsipp: bygg generisk kjerne +
+extension points, ikke de siste 10 %. Deterministisk validator forblir obligatorisk + blokkerende.
+Kostnadsdisiplin: offline/lokal primært; ekte modell kun målrettet minimal verifisering, harde tak.
+`shared/` forblir framework-nøytralt; commons PULL-ONLY.