portfolio-optimiser/shared/examples/tunnel-hauglia/index.md

type	okf_version	title	description	tags	timestamp
index	0.1	Hauglia-tunnelen — trinnstyring av dagsonen og passiv portalskjerming	OKF-bundle for en toløps vegtunnel med to kandidat-tiltak: oppgradering fra 3-trinns til 13-trinns dimming av innkjørings- og overgangssonen, og passiv portalskjerming. Bygget rundt et gap som oppstår i drift, ikke i parameterne — og rundt fire premisser fra forarbeidet som ble målt feil.	energieffektivisering tunnel tunnelbelysning lysstyring M&V IPMVP realiseringsgrad	2026-08-09

Hauglia-tunnelen

En OKF-bundle for belysningen i en norsk vegtunnel: ett anlegg, to kandidat-tiltak. Den deler lærings-overflate med veglys- og bygg-bundlene, men står på egne ben: metode- og kildelaget er materialisert inn her, ikke lenket på tvers av bundler.

Framework-nøytral artefakt (null kode-avhengighet). Deles uendret mellom implementasjonene. Se shared/README.md.

Prosjektlaget er fiktivt, litteraturlaget er ekte. Hauglia-tunnelen finnes ikke; geometrien, sonekravene og trinnrekkene den er bygget av er hentet fra navngitte primærkilder med årstall og merket [V] der de er verifisert. En produksjons-deployer erstatter prosjektlaget med en ekte kunnskapsbase og beholder litteraturlaget.

Hvorfor tunnel

Domenet ble valgt fordi gapet mellom modellert og realisert besparelse her har en annen årsak enn i de to andre bundlene — og en lærings-sløyfe som bare har sett én årsak, har ikke lært noe generelt.

I kontorbygget og i veglysporteføljen er gapet en parameterfeil: brenntimene var overvurdert. Anlegget gjorde det det skulle; tallet vi matet inn var galt.

Her er parameterne kjent og modellen aritmetisk lukket. Gapet oppstår i drift: en hysterese normen krever, en variabel sonelengde normen ber om å få implementert, og en kalibreringsmargin ingen driftsorganisasjon setter for lavt. Utstyret kan levere; anlegget gjør det ikke. Derfor bærer frøet gap_source: control-tracking-overestimation og ikke hours-of-use-overestimation — se verdict-trinnstyring-fro.md.

⛔ Fire premisser fra forarbeidet som ble målt feil

Bundelen ble bestilt på antakelsen om at tunnelen hadde et ekte norsk ex-post-par og dermed ikke trengte å låne sin realiseringsgrad slik veglys-bundelen måtte. Den antakelsen holdt ikke. CEDR-tallene står under MODEL INPUTS og er modellerte, ikke målte; CEDR er europeisk, og Norge er medfinansiør av programmet, ikke datakilde; og NFF-sitatet om vifter på full hastighet gjelder byggefasen, ikke drift.

Hauglia låner altså også sin rate. Fullstendig oppgjør i kilder-tunnelbelysning-realisering.md.

Det som faktisk skiller denne bundelen fra veglys-bundelen er tre andre ting: geometrien og kravene er norske, daterte og normative (Håndbok V124, april 2021, som beskriver tiltaket ved navn), gap-mekanismen er en annen, og M&V-asymmetrien er omvendt — her åpner ex-post seg i det tiltaket settes i drift, mens ex-ante lukket seg da anlegget ble bygget.

Innhold (progressiv disclosure)

• hauglia-tunnelen.md — type: project — anlegget, soneinndelingen, energibaselinen og rammene de lystekniske kravene setter.
• tiltak-trinnstyring-innkjoringssone.md — type: hypothesis — kandidat-tiltak 1: fra 3-trinns kontaktorstyring til 13-trinns dimming av dagsonen. Det er dette tiltaket som er projisert inn i validatoren.
• tiltak-portalskjerming.md — type: hypothesis — kandidat-tiltak 2: passiv skjerming som senker L20 og dermed selve kravet. Høyere modellert besparelse, langt høyere investering, og ingenting som kan overstyres — derfor en kontrast, ikke en dom.
• metode-ipmvp-a.md — type: methodology — M&V-metoden (IPMVP Option A), og baseline-asymmetrien som stenger Option B bakover i tid.
• kilder-tunnelbelysning-realisering.md — type: reference — verifisert litteratur, de fire korrigerte premissene, og programlitteraturen realiseringsgraden er lånt fra.
• verdict-trinnstyring-fro.md — type: verdict — frøsatt ekspert-dom. ExpeL-frøet loopens steg 1 henter fra.

Hvordan den kjøres i dag

validator-input.json er IR-projeksjonen den eksisterende deterministiske validatoren konsumerer uendret; cost-baseline.json bærer det samme tallgrunnlaget som prosjektets kostdata. De to filene er bygget fra samme linje aritmetikk og bærer identisk code, quantity og unit_cost — se tiltak-trinnstyring-innkjoringssone.md, §«Mapping til validatoren».

Bundelen ships uten golden.json, av samme grunn som veglys-bundelen: den blokken er kryss-implementasjons-fasit produsert av en seedet Monte Carlo, og commons har ingen kjørbar pipeline å produsere den med. En fasit ingen gate leser er verre enn ingen fasit. Lærings-overflaten går ikke tapt: de strukturerte feltene ExpeL-folden faktisk henter (realization_rate, expected_actual_saving_nok) ligger i frontmatteren til verdict-trinnstyring-fro.md, som er der loopen leser dem.