Et tall som endrer seg

Del 4 av 5 i serien om data maskiner kan stole på

← Forrige del: Kildehenvisningen er en påstand

Tidlig i september 2026 fantes Norges klimagassutslipp i to utgaver hos Faktaportalen samtidig.

I datalageret, der en språkmodell skrev oppsummeringer, var tallet fra 2025. På energisidene, som leserne faktisk så, var det fra 2023. SSB hadde publisert både 2024 og 2025 i tabell 13931 [1]. Ingen kjøring hadde feilet, og ingen varsler var røde.

Grunnen var enkel. Datapipelinen ba SSB om en fast liste med årstall. Nye år sto ikke på lista, så de ble aldri hentet. Hver kjøring fikk nøyaktig det den ba om, og meldte at alt var i orden.

Denne delen handler om det som skjer med et tall over tid. For en maskin er det ikke nok å vite hva et tall er og hvor det kom fra. Den må også vite om det fortsatt gjelder, og hvorfor det er annerledes enn sist.

Fem grunner til at et tall endrer seg

Når tallet for et gitt år er annerledes i dag enn i går, kan det ha minst fem ulike forklaringer. De betyr svært forskjellige ting.

Den tredje raden viser hvorfor skillet er viktig. I august 2026 la NAV om tre av pensjonsstatistikkene sine, fra å telle alderspensjonister per 31. desember til å telle dem per 30. juni. Tallene for 2016 til 2024 endret seg. Men NAV hadde ikke revidert noe: tallene var talt på et annet tidspunkt i året enn før. Å merke det som en revisjon ville vært å si at de gamle tallene var feil. Det var de ikke [3].

En maskin som bare ser at tallet er annerledes, kan ikke vite hvilken av de fem det er. Da vet den heller ikke om den skal stole mer på det nye tallet, like mye, eller om de to i det hele tatt kan sammenlignes.

En dato som lyver

Den enkleste formen for sporbarhet er en dato: når ble dette sist oppdatert? Selv den kan være feil.

I mai 2026 oppdaget vi at en av portalens generatorer satte dagens dato som «sist oppdatert» hver gang den kjørte, også når alle tre hentingene fra SSB hadde feilet. Datoen sa i dag. Tallene var gamle. Det er verre enn ingen dato, fordi leseren og maskinen har grunn til å tro på den.

Et beslektet tilfelle er alvorligere. En serie om individuell pensjonssparing ble hentet fra en SSB-tabell som ikke inneholder slike tall. Filteret traff aldri noe, koden falt tilbake på startverdier som var skrevet inn for hånd, og de ble publisert som Finans Norge-tall med dagens dato ved hver kjøring. Ingenting sammenlignet det som ble skrevet, med det som sto i koden fra før.

Og i sommer sto sju datasett frosne bak en grønn datapipeline, det eldste i 99 dager. En henting som feilet, ble en advarsel i en logg ingen leste, og pipelinen beholdt forrige versjon av fila, slik den skulle [5].

Hva Faktaportalen gjør

W3Cs anbefalinger for data på nettet sier at et datasett skal ha en versjonsangivelse og en versjonshistorikk [2]. Portalen har bygget sin variant av begge.

• Datoen flyttes bare når dataene er nye. En generator får bare sette dagens dato når hentingen faktisk ga nye data. Feiler den, beholdes både forrige fil og forrige dato.
• Hver datafil melder sitt eget utfall. Etter hver kjøring melder hver datafil om den ble hentet, var uendret hos kilden, feilet eller er bevisst fryst. En datafil som feiler, får en egen sak i oppgavesporeren. Kjøringen kan fortsatt være grønn, men en frossen datafil forsvinner ikke lenger i en logg [5].
• Maskinen sammenligner hver ny versjon med den forrige. Hver gang pipelinen skriver en datafil, sammenlignes den med forrige versjon, og funnene skrives i en historikk: nye perioder, reviderte perioder, fjernede perioder, omlegginger. Historikken har 1 464 rader, og 490 av dem har oppdaget minst én endring. Funnene er oftest revisjoner (351) og nye perioder (303).
• Kildens endringer og våre holdes fra hverandre. Koden kan ikke selv se forskjellen på at SSB reviderte et tall og at vi byttet ut et anslag som var feil. Derfor står våre egne rettelser i en egen liste med begrunnelse, og det samme gjør kildenes omlegginger. I historikken merkes hver linje enten «fra kilden» eller «av oss», med stiplet og hel strek [3].
• Endringene står ved grafen. Ved siden av kildemerket på grafene står et lite merke som «Revidert» eller «Nytt», med de siste endringene når man klikker. Hele historikken finnes på oppdateringssida [3][4].
• Startverdier som publiseres, oppdages. En test feiler når en publisert serie er helt lik startverdiene i koden. Den fant 33 andre serier med samme mønster, og de er gått gjennom én for én.
• Tekst endres aldri stille. En publisert bloggartikkel eller en manuelt vedlikeholdt datafil som endres, må få en oppføring i en endringslogg, merket som rettelse eller oppdatering. Ellers stopper en sjekk i kodeløypa endringen.

Rettelsen etter at utslippstallene sto fast, fulgte samme mønster. Årsutvalget er nå dynamisk. Datoen flyttes bare når SSB har et nytt år eller har revidert et gammelt. En feilet henting beholder forrige fil i stedet for å skrive inn startverdier. Og et nytt år tas bare med når alle utslippskildene er publisert for det.

Luftfartssida fikk samtidig en rettelse i endringsloggen sin. Den hadde sammenlignet luftfartens utslipp for 2024 med transportsektorens og hele landets tall for 2023. Nå gjelder alle tre 2024, og loggen sier hva som var galt [6].

Hvorfor KI trenger endringshistorikken

En språkmodell som svarer på spørsmål om data, siterer det den får. Den har ingen hukommelse av at tallet var annerledes i forrige uke, og ingen måte å vite at en graf ble tatt ut fordi tallene ikke hadde noen kilde.

Derfor sender portalens grensesnitt for KI-agenter med en versjonsmerking i hvert svar: hvilken versjon av koden og dataene tallene kom fra. En agent som siterer portalen, kan dermed si hvilken versjon den siterte, og et svar kan spores tilbake selv etter at tallene er endret.

Egen vurdering: Den viktigste linja i endringshistorikken er ikke «Revidert», men «av oss». Kilder reviderer, det er normalt. At vi selv har rettet noe, er det leseren trenger å vite for å vurdere oss.

Det portalen fortsatt ikke gjør

• Datalageret har fortsatt en fast årsliste. Hentingen til datasammendraget i datalageret ber fortsatt SSB om en fast liste med årstall for tabell 13931, og den lista slutter i 2025. Når SSB publiserer 2026, vil sammendraget ikke få det med seg. Det er den samme feilen som frøs energisidene, i den andre halvdelen av arkitekturen.
• Noen hentinger er fortsatt ødelagte. Gjennomgangen av serier som var lik startverdiene, fant serier der tallene er riktige, men der hentingen fra to av SSB-tabellene bak dem ikke virker. Rettingen står i en egen sak som ikke er løst.
• Omlegginger må meldes for hånd. Koden kan ikke skille en omlegging fra en revisjon. Merker ingen det, vises NAVs neste omlegging som en revisjon.

I neste del: Når maskinen spør. Hva et grensesnitt for KI-agenter må gjøre, hva en brukertest fant, og hvorfor portalen i dag er mer maskinlesbar enn den er tilgjengelig for maskiner.

Les del 5: Når maskinen spør →

Kilder

1. SSB. Tabell 13931: Klimagasser, etter utslippskilde, energiprodukt og komponent.
2. W3C (2017). Data on the Web Best Practices. Anbefalingene om versjonsangivelse og versjonshistorikk.
3. Faktaportalen. Oppdateringer. Endringshistorikken for alle datafiler, med forklaring av «fra kilden» og «av oss».
4. Faktaportalen. Oppdateringer og utfall per datakilde.
5. Faktaportalen. Faste kjøringer, drift og overvåkning. Om utfall per datafil.
6. Faktaportalen. Luftfart. Endringsloggen for utslippstallene.