---
type: index
okf_version: 0.1
title: "Hauglia-tunnelen — trinnstyring av dagsonen og passiv portalskjerming"
description: "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."
tags: [energieffektivisering, tunnel, tunnelbelysning, lysstyring, M&V, IPMVP, realiseringsgrad]
timestamp: 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](../../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](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](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](hauglia-tunnelen.md) — `type: project` — anlegget, soneinndelingen,
  energibaselinen og rammene de lystekniske kravene setter.
- [tiltak-trinnstyring-innkjoringssone.md](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](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](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](kilder-tunnelbelysning-realisering.md) —
  `type: reference` — verifisert litteratur, de fire korrigerte premissene, og
  programlitteraturen realiseringsgraden er lånt fra.
- [verdict-trinnstyring-fro.md](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](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](verdict-trinnstyring-fro.md), som er der loopen leser dem.