Back to insights
5 October 2026 · Analysis
By Kenneth Bæver Bjerke, Diggs.no

One provider, four dependencies

I mapped the dependencies in two of my own systems. In one I found 24 where I would have guessed ten. In the other, one provider turned out to be four dependencies.

The doctrine requires a dependency to be documented before it can be accepted. That is the first of five conditions in pragmatic patriotism. In October 2026 I tried to meet that condition for two systems I have built myself. This text is about what I found, and about what I could not find.

A small website with 24 dependencies

The first system is diggs.no. It is a content website with a contact form and a prototype that is paused. The mapping produced 24 entries:

  • eight that must work for the website to respond: server, web server, database, domain, DNS, certificate, deployment and code repository
  • six third parties used while the website is running, including email, visitor statistics, a consent banner and a language model
  • six that are only needed when the website is built: package registry, fonts, framework and tools
  • four leftovers in the code that were not in use

The services are collected in a table on the method page.

Two of the findings are worth mentioning. Four unused packages had been in the project since it was created. When they were removed, the number of packages the website fetched at build time went from 1240 to 618. One of the four accounted for almost the entire drop. And the service that sends email from the forms is a US company owned by a Swedish one. Which jurisdiction applies cannot then be read from the ownership alone.

One provider, four functions

The second system is a project I am building on the side, which has not been launched. There I had chosen European providers for servers, storage, email and DNS, and I expected one US dependency: GitHub, where the code is hosted.

When I went through the documentation, GitHub turned out to cover four functions:

  1. The code, and the building and deployment of it.
  2. The registry where the finished program packages are stored, and which the servers fetch from.
  3. The secrets the deployment needs. They are never in the code. They are stored encrypted in GitHub's own secrets store, and the deployment fetches them from there.
  4. The alerting. The check that the backup has been taken runs there, and that is where I am notified from if it fails.

I also found a fifth dependency that was not on my list at all: the certificates for HTTPS, which are issued by a US organisation.

The check before publication found two more, both in the layer that is only needed at build time: the registries from which the base images and the program libraries are fetched. Both are American. The mapping of this system has therefore not been done as deeply as for diggs.no.

What could not be seen

I did the mapping of diggs.no with Claude Code, a language model that read the code and looked up what can be seen from outside. Even so, 18 questions remained that could not be answered from there. Among them:

  • how the certificate is renewed
  • where the backups are stored, and with whom
  • whether anything monitors the website, and who raises the alert
  • where the secrets are kept, and who has access

The answers exist only with me, and some of them I had to look up myself.

From outside, one sees even less. The model could establish where the server is located, who issued the certificate, and where the email goes, because that can be read from DNS and from the server's responses. The rest is invisible to anyone who only has public documentation.

Three layers

Documented

The 24 entries, the four functions and the 18 open questions. For each entry it is stated whether it was seen in the code, seen from outside or is an inference.

Inference

Two small systems are thin evidence, and both were built by the same person. I nevertheless infer this: a list of providers underestimates the dependency, because one provider can cover several functions, and because what surrounds the system is not in the code.

Both systems are simple. One is a website with fewer than a hundred pages, the other a project with one developer. Norwegian municipalities and county authorities can each have several hundred digital solutions, according to a report Oslo Economics and Capto produced for KS, the Norwegian Association of Local and Regional Authorities, in February 2026 (Leverandørmarkedet for digitale løsninger til kommunal sektor, in Norwegian). The report's definition of digital solutions includes learning platforms, among other things. The report describes a related pattern on a large scale: dependency on the large international providers also arises indirectly, through solutions from Norwegian providers that build on them, and the municipalities experience a lack of insight into key aspects of the solutions.

For the hospitals I have not found a corresponding figure, and I have not mapped such an organisation myself. I assume that the question of who can shut down what is far harder to answer there than in two systems I have built myself. That is something the project will investigate.

The doctrine's assessment

The kill switch test asks whether an external actor can stop or restrict the system. The answer depends on the function. If I lose access to the code repository, the service keeps running. I just cannot deploy anything new, the servers cannot fetch program packages, and nobody alerts me to a backup that fails. That is four answers to one question.

The certificates show the opposite. The issuer is American, but the protocol is an open standard, and switching to a European issuer is a change in the configuration. There the doctrine is right that open standards make jurisdiction a choice.

What it means for the mapping

I propose three changes to how a dependency is mapped:

  1. Count functions, not providers. One row per thing that stops working.
  2. Map four layers: what must work for the system to respond, what is used while it is running, what is needed to build it, and what surrounds it (secrets, backup, monitoring, certificates, name services).
  3. Distinguish between services and software. A service can be shut down from outside. Open source that I operate myself cannot, even if the company behind it is American.

It is also an answer to one of the research questions in the project: how deep does the mapping have to go before an assessment is valid, and can it be done from public documentation? For these two systems the answer is that the code was not enough, and that public documentation would have given even less. Whether there is a depth that is good enough, I do not know yet.

Disclosures

I am product manager at Akari, which sells Google Workspace. diggs.no runs on Hetzner and uses email via Google Workspace. The code is hosted on GitHub. None of the dependencies on diggs.no currently has an exit plan with a deadline, and the website is to be rebuilt. The other project is my own.

How this text was made

The register for diggs.no was produced by Claude Code, which read the code and looked up DNS, certificate and response headers. The text was written together with Claude. Claude Code has checked the figures about diggs.no against the register and the git history. Claude Code also checked the description of the other system against the code, and the claims about the KS report against the report. The KS report was found by Claude, which has read the summary and the first three chapters. I have not read the whole report.