Method and research questions
What the project investigates
Diggs investigates how digital dependency can be measured and reduced at the infrastructure level: where data is stored, who can shut down a service, what it costs to move, and which law applies.
Artificial intelligence makes the question more pressing, but does not change it. The language models run on the same infrastructure, under the same jurisdiction, and add a new layer of dependency on top. The project is therefore aimed at the layer underneath.
I do not have a finished architecture to show, and this page does not promise one. What I have is a doctrine with four tests, a prototype that is paused, and a list of what was wrong with it.
Research questions
About the dependency
- Can the four tests in the doctrine (kill switch, exit, transparency and adoption) be formulated so precisely that two independent assessments of the same system give the same answer?
- How deep does the mapping have to go before an assessment is valid? A system consists of subcontractors, APIs, operations, name services and identity solutions that are rarely listed on the product sheet. Can they be mapped from public documentation?
- What does an exit cost in practice, measured in hours, money and lost functionality? And how much of the cost can be foreseen before one starts?
- Which properties determine whether a system can be left? My assessment is that European ownership and open source are neither necessary nor sufficient, and that formats, protocols and jurisdiction matter more. This has not been investigated systematically.
- What does it take for independent alternatives to be adopted? My hypothesis, which is based on my own experience, is that they lose on distribution and adoption more often than on technology. I do not yet have systematic evidence for it.
About the instrument
- Can such an assessment be automated without ceasing to be verifiable? The prototype used a language model, and that raised questions of its own: where the judgement lies, whether the same question gives the same answer twice, whether the model can assess its own provider, and whether one can show that the criteria actually reached the model.
The questions are drafts. They are to be formulated together with a research community before they are used in an application.
What I have found so far
The findings concern the instrument, not the infrastructure. The Scorecard is a prototype that assesses software and services against the doctrine. In September 2026 I went through the code and found the following:
Documented in the code
- The score is calculated by code, but every value that goes into the calculation is the model's judgement.
- One rule asked the model to assess whether the provider had designed the lock-in deliberately. The doctrine only asks whether there is a realistic way out. Fixed in the code, but not tested, because the tool is paused. The standard the model reads still mentions intent until version 1.1 is put into use.
- One rule gave Hetzner, which diggs.no itself runs on, a predetermined result. Fixed in the code, but not tested.
- The model that does the assessing is Gemini. It also assesses Google's own products. Not solved.
- The Norwegian report is a machine translation of the English one.
- The assessments are stored without the version of the criteria and without the model name, and a new run overwrites the old one.
- Because of a coding error, the model did not receive the doctrine it was meant to assess against. The error was introduced on 29 April 2026 and fixed on 27 September 2026. The system had no check that could have raised an alert.
Inference
- Three products of the same type were given almost identical reasoning, but one received a different conclusion from the other two. I do not know whether this is due to the model, the coding error or changes between the runs, because the runs cannot be traced.
My assessment
- The errors say most about questions 1 and 6. The tests were not precise enough for the assessment to be verified, and the tool could not show what it had assessed against.
The findings are described in The Voice in My Own Code and Four models, one editor. The tool is paused.
Planned investigations
- diggs.no against its own doctrine. I plan to rebuild the website according to the doctrine. What will replace what has not been mapped yet. The dependencies as they are today are listed at the bottom of the page. When the rebuild starts, the work will be logged continuously: what was replaced, how long it took, and what could not be moved. The result will be published whatever the outcome. It gives a first figure for question 3.
- Reliability. When the Scorecard reopens, the same product, the same criteria and the same model must give the same result in at least 9 out of 10 runs. If that does not hold, the tool is not a measuring instrument.
- Manual versus automatic assessment. I will assess diggs.no by hand against the four tests and compare the result with what the tool arrives at. The discrepancies will be published.
- Hetzner again, without the special rule.
Status and limitations
- No technical architecture. The solution has not been worked out. The project starts with the measurement, because that is where I have something to show.
- No formal partners. Conversations with researchers and practitioners have begun, and nothing has been formalised. The next step is to clarify the basis for an application for pre-project funding.
- No external funding. I pay for hosting and services myself and use my own time.
- No independent assessment of the method. Everything on this page is my own review of my own work. That is the main reason I am looking for a research community.
My own dependencies
diggs.no itself depends on services outside European jurisdiction. The table shows all the services the website uses as of 5 October 2026, including the European ones.
| Function | Service | Jurisdiction |
|---|---|---|
| Server and database | Hetzner | Germany, data centre in Finland |
| Domain and DNS | Domeneshop | Norway |
| Deployment | Laravel Forge | USA |
| Code repository | GitHub | USA |
| Certificate | Let's Encrypt | USA |
| Email from the forms | Mailgun | USA (owned by Sinch, Sweden) |
| Inbox | Google Workspace | USA |
| Visitor statistics | Google Analytics | USA |
| Consent banner | CookieYes | United Kingdom (not verified) |
| Language model in the Scorecard | Gemini | USA (not in use while the tool is paused) |
| Packages and fonts at build time | npm, Google Fonts | USA |
| Language models in the work on code and text | Claude, Gemini and others | USA and France |
The software the website runs on (including Next.js, Node.js, nginx and MySQL) is open source that I operate myself. It cannot be shut down from outside and is therefore not in the table.
Measured against pragmatic patriotism, this is not good enough. The dependencies are documented, which is the first of five conditions. Criticality, exit plan, time frame and responsibility are missing. By the doctrine's own wording, that is postponement, not pragmatism. That is why the website is to be rebuilt.
Last updated: 5 October 2026