refactor(examples): replace sector-specific example material with generic, fictitious examples

The context sets, the packaged knowledge bases and the example bundles are
replaced by one fictitious example set about IT operations in an invented
organisation: three context sets (serverrom-2027, driftsavtale-2027 and the
two-base drift-og-avtale-2027), two synthetic knowledge bases under
src/portfolio_optimiser/data/kunnskapsbaser and two example bundles under
src/portfolio_optimiser/data/bundles. Numbers, codes and structural values in
tests and fixtures are kept; names, ids and wording change. Dated measurement
documents that only recorded runs on the replaced material are deleted.

Gate figures measured on the new set are not comparable with earlier ones.
The exclusion gate from the previous commit is green: 0 tracked files hit
outside the shared/ subtree.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

src/portfolio_optimiser/data/bundles/driftssenter-kjoling/tiltak-trinnstyring-kjoling.md

@@ -0,0 +1,167 @@
+---
+type: hypothesis
+title: "Trinnstyring av hovedkjølingen: fra 3 trinn til 13"
+description: "Erstatte kontaktorstyrt 3-trinns regulering av hovedkjølingen med 13-trinns styring slik Driftsstandard DS-09 anbefaler. Modellert besparelse utledet av kvantiseringsoverskuddet i de to trinnrekkene, med et åpent kostnadsgulv."
+resource: DRIFTSSENTER-KJOLING
+measure_id: KJOLING-01
+tags: [kjoling, kjolestyring, frekvensstyring, ECM, DS-09]
+timestamp: 2026-08-09
+---
+
+# Tiltak: 13-trinns styring av hovedkjølingen
+
+Oppgradering av styringen i **høylast- og overgangssonen** fra dagens
+**3-trinns kontaktorstyring** til **13-trinns styring**, slik Driftsstandard DS-09 (2021)
+§ 9.6.1 anbefaler. Aggregatene byttes ikke — det er reguleringen som byttes.
+
+Dette er tiltaket som er **projisert inn i validatoren**.
+
+## Tiltaket er beskrevet av standarden selv
+
+DS-09 § 9.6.1 beskriver både utgangspunktet og målet, ordrett:
+
+> «Høylastsonens nedtrapping er gitt av kjølekurven i figur 9.2. I utførelse har dette
+> vært begrenset til 3 trinn arrangert med oppdeling i kurser styrt via kontaktorer.
+> Frekvensstyrte vifter og kompressorer åpner for en bedre tilpasning til kurven ved hjelp av
+> styring i flere trinn som vil redusere energiforbruket vesentlig.»
+>
+> «Det anbefales å definere høylast-/overgangssonen i 13 trinn henholdsvis
+> 0-5-10-15-20-25-30-40-50-60-70-80-90-100 % alternativt dynamisk (…). Det bør som minimum
+> legges til en hysteresetid på 60 sekunder for endringer i nivåene.»
+
+**Det er uvanlig komfortabelt utgangspunkt for en hypotese:** standarden navngir dagens praksis,
+navngir tiltaket, og lister trinnene. Vi trenger ikke finne på noen av delene.
+
+## Parametere
+
+| Parameter | Verdi | Status | Kilde/forankring |
+|---|---|---|---|
+| Installert effekt, hovedkjøling | 60 kW | [I] | se [driftssenter-kjoling.md](driftssenter-kjoling.md) |
+| Timer høylasttrinn aktivt | 4 500 t/år | [I-avledet] | ≈ 4 380 t over frikjølingsgrensen + sikkerhetsmargin |
+| Trinnrekke FØR | 3 trinn: 33,3 / 66,7 / 100 % | [V-forankret] | DS-09 § 9.6.1, «oppdeling i kurser styrt via kontaktorer» |
+| Trinnrekke ETTER | 14 nivåer: 0-5-10-15-20-25-30-40-50-60-70-80-90-100 % | [V] | DS-09 § 9.6.1, ordrett |
+| Variabel energipris | 1,00 NOK/kWh | [V-forankret] | se [driftssenter-kjoling.md](driftssenter-kjoling.md) |
+
+## Modellert besparelse (ex-ante)
+
+Mekanismen er **kvantiseringsoverskudd**. En trinnstyrt regulator må aldri legge seg *under*
+det kjølekurven krever — gulvet er et driftssikkerhetskrav, ikke en preferanse. Den må derfor
+velge **det laveste tilgjengelige trinnet som er ≥ kravet**. Energitapet er den midlere
+overskytingen, og den krymper når trinnene blir finere.
+
+Med kravet modellert som **jevnt fordelt over trinnrekkens spenn** blir midlere servert nivå:
+
+> 3 trinn `{33,3 %, 66,7 %, 100 %}` → midlere servert nivå **66,67 %**
+> 13 trinn `{0 … 100 %}` → midlere servert nivå **54,25 %**
+> Reduksjon: **12,42 prosentpoeng av installert effekt = 18,625 % av hovedkjølingens energi**
+
+Regnestykket, med den ene antakelsen synlig:
+
+> Hovedkjøling i dag: 60 kW × 0,6667 × 4 500 t = **180 000 kWh/år**
+> Hovedkjøling etter: 60 kW × 0,5425 × 4 500 t = **146 475 kWh/år**
+> Besparelse: 180 000 − 146 475 = **33 525 kWh/år** = **33 525 NOK/år**
+
+Det er **18,6 %** av hovedkjølingens forbruk og **10,00 %** av driftssenterets totale elforbruk.
+
+**Antakelsen som bærer tallet, og som ikke er verifisert:** at kravnivået er jevnt fordelt.
+Det er det nesten sikkert ikke — T20 ved luftinntaket er skjevfordelt mot lave verdier
+store deler av året, og i den skjevheten hjelper de fine trinnene *mer* enn jevnfordelingen
+tilsier, ikke mindre. **Ingen kilde i materialet gir en målt T20-fordeling for driftssenteret.**
+Vi lar antakelsen stå eksplisitt i stedet for å skjule den i et rundt tall.
+
+## Kryss-sjekk mot konsernprosjektet ENTR (og hvorfor tallene ikke er like)
+
+ENTR D2.1 modellerer et beslektet tiltak — *«frekvensstyrt kjøling med lukket
+tilbakekobling»* — på et referanseanlegg med samme geometriklasse som driftssenteret:
+
+| | ENTR D2.1 | Driftssenteret (vårt) |
+|---|---|---|
+| Hovedkjøling før | 158 059 kWh/år | 180 000 kWh/år |
+| Hovedkjøling etter | 136 893 kWh/år | 146 475 kWh/år |
+| **Besparelse** | **21 166 kWh/år (13,4 %)** | **33 525 kWh/år (18,6 %)** |
+
+Størrelsesordenen stemmer — og det er hele poenget med en kryss-sjekk. Men **vår andel er
+5,2 prosentpoeng høyere, og det skal forklares, ikke bortforklares:**
+
+- ENTR-tiltaket beholder **konvensjonelle termostater** og forbedrer selve
+  tilbakekoblingssløyfa. Vårt tiltak endrer **trinnoppløsningen** fra 3 til 13. Det er to
+  ulike inngrep i samme kjede, og de har ingen grunn til å gi samme tall.
+- ENTRs tall er **modellert av prosjektet**, ikke målt. Det er et anslag på linje med vårt,
+  ikke en fasit vårt anslag skal kalibreres mot.
+- Vår jevnfordelings-antakelse trekker i retning av **for lavt** anslag, ikke for høyt (se over).
+
+**⚠️ Og en felle i selve kilden:** D2.1 oppgir **ulik** baseline før tiltak for nominelt
+samme referanseanlegg — **158 059** kWh/år for dette tiltaket, men **150 059** kWh/år for
+innkapslings-tiltaket ([tiltak-kaldgangsinnkapsling.md](tiltak-kaldgangsinnkapsling.md)).
+Baselinen er altså ikke felles på tvers av tiltakene i D2.1. De to kan ikke settes i samme
+regnestykke, og vi gjør det ikke.
+
+## Kostnadssiden — et anker med feil årstall
+
+Eiendomsavdelingens prisbok (publikasjon 4) gir en **intern** enhetspris for kjøleanlegg:
+
+> «For serverhaller større enn ca. 300 m² kan gjennomsnittsprisen per m² variere mellom
+> NOK 1000 og NOK 3000. (Prisen inkluderer aggregater, kabelbroer, installasjon av trafo og
+> nettilknytning)»
+
+For hovedkjølingens 600 m² gir det 0,6–1,8 mill. NOK. **Men tallet er ubrukelig som det står, av
+to grunner:**
+
+1. **Publikasjonen er udatert i vårt uttrekk.** Et beløp uten årstall kan ikke prisjusteres.
+   Prisboken omtaler «mer enn 700 tekniske rom i virksomheten» — virksomheten passerte det for
+   mange år siden, så tallet er gammelt, men *hvor* gammelt vet vi ikke.
+2. **Prisen gjelder feil ting.** Den dekker **hele kjøleanlegget** per m² — aggregater,
+   kabelbroer, trafo, nettilknytning. Vårt tiltak bytter **bare styringen**. En
+   styringsoppgradering er en brøkdel av et komplett anlegg, og ingen kilde i materialet gir
+   den brøken.
+
+**Konsekvensen er at `cost-baseline.json` ikke får noen investeringsrad.** Det er samme valg
+som klientpark-bundelen tok, men av en annen grunn: der fantes det ingen kilde, her finnes det en
+kilde som ikke bærer. Å prisjustere et udatert beløp til et tiltak det ikke gjelder, ville
+vært å produsere et tall og kalle det et anker.
+
+ENTRs `≈ €35 000 per kjølekrets` for det beslektede styringstiltaket er den nærmeste
+størrelsesordenen vi har, og den er fra et annet anlegg og udatert. Den står i
+[kilder-kjoling-realisering.md](kilder-kjoling-realisering.md) som
+orientering, **ikke** som kostbase.
+
+## Usikkerhet (for Monte Carlo P10/P50/P90)
+
+Den dominerende usikkerheten er **ikke** energiprisen — den er **hvor godt styringen faktisk
+følger kurven i drift**. Den usikkerheten er systematisk, ikke tilfeldig, og den peker én vei.
+Derfor håndteres den i verdict-laget
+([verdict-trinnstyring-fro.md](verdict-trinnstyring-fro.md)), ikke her.
+
+Den eksisterende validatorens Monte Carlo varierer **enhetspris**. I denne mappingen brukes
+derfor prisbandet **0,70–1,40 NOK/kWh** som usikkerhetsakse, identisk med klientpark-mappingen.
+
+## Mapping til validatoren (hvorfor `validator-input.json` ser ut som den gjør)
+
+Den eksisterende deterministiske validatoren er en *feasibility-gate*
+(`claimed ≤ 30 % av affected total`, Monte Carlo over enhetspris) bygd for kostnadskutt.
+Tiltaket mappes inn **uendret**:
+
+- `affected_items = [{code: "ENERGI-DRIFTSSENTER-EL", quantity: 335250 kWh/år, unit_cost: 1.00 NOK/kWh}]`
+  → **hele driftssenterets** årlige energikostnad (335 250 NOK).
+- `claimed_saving_nok = 33525` → den modellerte besparelsen.
+- `assumptions = {"ENERGI-DRIFTSSENTER-EL": [0.70, 1.40]}` → prisbandet for Monte Carlo.
+
+**Hvorfor hele driftssenteret og ikke bare hovedkjølingen:** hadde `affected_items` vært
+hovedkjølingens eget forbruk (180 000 kWh), ville besparelsen vært **18,6 %** av den — under
+cap-en, men med langt mindre margin, og konvolutten ville vært feil størrelse i prinsippet:
+tiltaket virker på driftssenterets energikostnad, og det er den linjen anleggseieren betaler.
+Klientpark-bundelen tok samme beslutning med porteføljen som konvolutt. **For ett enkelt anlegg
+er anleggets totale elforbruk den riktige analogien til en portefølje** — ikke den sonen
+tiltaket tilfeldigvis sitter i.
+
+Forholdet blir da `claimed / nominal_feasible = 33 525 / 100 575 = **1/3 eksakt**`, mot
+reservens 0,3333 og klientpark-bundelens 0,3386.
+
+**`cost-baseline.json` bærer nøyaktig samme rad.** `code`, `quantity` og `unit_cost` er
+identiske i de to filene — ikke «innenfor toleranse», men identiske, fordi begge er skrevet
+fra summen `180 000 + 139 230 + 16 020`. Hver `code` i `affected_items` finnes som nøkkel i
+`items`.
+
+**Ærlig begrensning:** validatorens P10/P50/P90 betyr her «øvre feasible grense» (30 % av
+samplet energikostnad), *ikke* «styringsbesparelsens fysiske band». Det er bevisst — den
+domenetro modelleringen og realiseringsgapet hører hjemme i verdict-laget.