Metode og forskningsspørsmål
Hva prosjektet undersøker
Diggs undersøker hvordan digital avhengighet kan måles og reduseres på infrastrukturnivå: hvor data ligger, hvem som kan stenge en tjeneste, hva det koster å flytte, og hvilken lov som gjelder.
Kunstig intelligens gjør spørsmålet mer påtrengende, men endrer det ikke. Språkmodellene kjører på den samme infrastrukturen, under den samme jurisdiksjonen, og legger et nytt lag av avhengighet oppå. Prosjektet retter seg derfor mot laget under.
Jeg har ikke en ferdig arkitektur å vise frem, og siden lover ikke en. Det jeg har, er en doktrine med fire tester, en prototype som er satt på pause, og en liste over hva som var galt med den.
Forskningsspørsmål
Om avhengigheten
- Kan de fire testene i doktrinen (kill switch, exit, transparens og adopsjon) formuleres så presist at to uavhengige vurderinger av samme system gir samme svar?
- Hvor dypt må man kartlegge før en vurdering er gyldig? Et system består av underleverandører, API-er, drift, navnetjenester og identitetsløsninger som sjelden står i produktarket. Kan de kartlegges fra offentlig dokumentasjon?
- Hva koster en exit i praksis, målt i timer, penger og tapt funksjon? Og hvor mye av kostnaden kan forutses før man begynner?
- Hvilke egenskaper avgjør om et system kan forlates? Min vurdering er at europeisk eierskap og åpen kildekode verken er nødvendig eller tilstrekkelig, og at formater, protokoller og jurisdiksjon betyr mer. Det er ikke undersøkt systematisk.
- Hva skal til for at uavhengige alternativer blir tatt i bruk? Min hypotese, som bygger på egen erfaring, er at de oftere taper på distribusjon og adopsjon enn på teknologi. Jeg har ikke systematisk belegg for den ennå.
Om instrumentet
- Kan en slik vurdering automatiseres uten at den slutter å være etterprøvbar? Prototypen brukte en språkmodell, og det reiste egne spørsmål: hvor skjønnet ligger, om samme spørsmål gir samme svar to ganger, om modellen kan vurdere sin egen leverandør, og om man kan vise at kriteriene faktisk nådde modellen.
Spørsmålene er utkast. De skal formuleres sammen med et fagmiljø før de brukes i en søknad.
Hva jeg har funnet så langt
Funnene gjelder instrumentet, ikke infrastrukturen. Scorecard er en prototype som vurderer programvare og tjenester mot doktrinen. I september 2026 gikk jeg gjennom koden og fant dette:
Dokumentert i koden
- Poengsummen regnes ut av kode, men alle verdiene som går inn i regnestykket, er modellens skjønn.
- En regel ba modellen vurdere om leverandøren hadde designet innlåsingen med hensikt. Doktrinen spør bare om det finnes en realistisk vei ut. Rettet i koden, men ikke prøvd, fordi verktøyet er på pause. Standarden modellen leser, nevner fortsatt hensikt til versjon 1.1 tas i bruk.
- Én regel ga Hetzner, som diggs.no selv kjører på, et forhåndsbestemt resultat. Rettet i koden, men ikke prøvd.
- Modellen som vurderer, er Gemini. Den vurderer også Googles egne produkter. Ikke løst.
- Den norske rapporten er en maskinoversettelse av den engelske.
- Vurderingene lagres uten versjon av kriteriene og uten modellnavn, og en ny kjøring overskriver den gamle.
- På grunn av en kodefeil fikk modellen ikke doktrinen den skulle vurdere etter. Feilen ble innført 29. april 2026 og rettet 27. september 2026. Systemet hadde ingen kontroll som kunne varslet om det.
Slutning
- Tre produkter av samme type fikk nesten like begrunnelser, men ett fikk en annen konklusjon enn de to andre. Jeg vet ikke om det skyldes modellen, kodefeilen eller endringer mellom kjøringene, fordi kjøringene ikke kan spores.
Min vurdering
- Feilene sier mest om spørsmål 1 og 6. Testene var ikke presise nok til at vurderingen kunne etterprøves, og verktøyet kunne ikke vise hva det hadde vurdert etter.
Funnene er beskrevet i Stemmen i min egen kode og Fire modeller, én redaktør. Verktøyet er satt på pause.
Planlagte undersøkelser
- diggs.no mot egen doktrine. Jeg planlegger å bygge om nettstedet etter doktrinen. Hva som skal erstatte hva, er ikke kartlagt ennå. Avhengighetene slik de er i dag, står nederst på siden. Når ombyggingen starter, logges arbeidet fortløpende: hva som ble byttet, hvor lang tid det tok, og hva som ikke lot seg flytte. Resultatet publiseres uansett utfall. Det gir et første tall til spørsmål 3.
- Pålitelighet. Når Scorecardet åpnes igjen, skal samme produkt, samme kriterier og samme modell gi samme resultat i minst 9 av 10 kjøringer. Holder ikke det, er verktøyet ikke et måleinstrument.
- Manuell mot automatisk vurdering. Jeg vurderer diggs.no for hånd mot de fire testene og sammenligner med det verktøyet kommer frem til. Avvikene publiseres.
- Hetzner på nytt, uten særregelen.
Status og begrensninger
- Ingen teknisk arkitektur. Løsningen er ikke ferdig tenkt. Prosjektet starter med målingen, fordi det er der jeg har noe å vise.
- Ingen formelle partnere. Samtaler med fagpersoner er innledet, og ingenting er formalisert. Neste steg er å avklare grunnlaget for en søknad om forprosjektmidler.
- Ingen ekstern finansiering. Jeg betaler drift og tjenester selv og bruker egen tid.
- Ingen uavhengig vurdering av metoden. Alt på denne siden er min egen gjennomgang av mitt eget arbeid. Det er hovedgrunnen til at jeg søker et fagmiljø.
Egne avhengigheter
diggs.no er selv avhengig av tjenester utenfor europeisk jurisdiksjon. Tabellen viser alle tjenestene nettstedet bruker per 5. oktober 2026, også de europeiske.
| Funksjon | Tjeneste | Jurisdiksjon |
|---|---|---|
| Server og database | Hetzner | Tyskland, datasenter i Finland |
| Domene og DNS | Domeneshop | Norge |
| Utrulling | Laravel Forge | USA |
| Kodelager | GitHub | USA |
| Sertifikat | Let's Encrypt | USA |
| E-post fra skjemaene | Mailgun | USA (eid av svenske Sinch) |
| Innboks | Google Workspace | USA |
| Besøksstatistikk | Google Analytics | USA |
| Samtykkebanner | CookieYes | Storbritannia (ikke kontrollert) |
| Språkmodell i Scorecardet | Gemini | USA (ikke i bruk mens verktøyet er på pause) |
| Pakker og skrifter ved bygging | npm, Google Fonts | USA |
| Språkmodeller i arbeidet med kode og tekst | Claude, Gemini og flere | USA og Frankrike |
Programvaren nettstedet kjører på (blant annet Next.js, Node.js, nginx og MySQL), er åpen kildekode som jeg drifter selv. Den kan ikke stenges utenfra og står derfor ikke i tabellen.
Målt mot pragmatisk patriotisme er dette ikke godt nok. Avhengighetene er dokumentert, som er det første av fem vilkår. Kritikalitet, exit-plan, tidsramme og ansvar mangler. Etter doktrinens egen ordlyd er det utsettelse, ikke pragmatisme. Det er grunnen til at nettstedet skal bygges om.
Sist oppdatert: 5. oktober 2026