The problem · three articles
You cannot run what you do not understand.
Three articles, then the repositories that check them. Each describes a mechanism we meet at our clients, and ends with what the argument does not claim.
Article I
You did not outsource operations. You outsourced understanding.
At three in the morning, the question is not who is on the contract. It is who understands.
A managed service, taken on its own, is a good deal. You stop operating a database to focus on your business, and the invoice reads more clearly than an engineer does. The transaction looks like it is about time. It is about something else: you trade the operational load for knowledge of how the component behaves when it degrades.
As long as nothing breaks, the trade is invisible. It becomes visible on the day of an incident that crosses several components — latency climbing, a failover that does not happen, replication falling behind. Diagnosis then requires knowing what each layer actually does, and nobody knows any more: not the team, which never had to, and not the vendor's support, which only sees its own scope. Everyone looks at their own component and declares it healthy.
Stack twelve of them and you get an architecture nobody can picture in full. That is the situation we most often walk into. The problem is never the component: it is that no one present can say what happens between two components. The capability was not lost through negligence — it was bought from someone else, one contract at a time.
We sell the opposite, and it is the only reason our engineers move into teams rather than deliver a project and leave. A capability that walks out with the contractor was not transferred: it was rented. ▪
Cite this article
A reference line ready to copy. The anchor points at the article.
Nudibranches Technologies, “The problem — Article I. You did not outsource operations. You outsourced understanding”, www.nudibranches.tech/en/the-problem#comprehension, legal references as of August 2026.
Article II
What holds you is not a clause. It is what you no longer know how to do.
Lock-in is not written into the contract. It is built, one reasonable decision at a time.
No contract has a clause headed “lock-in”. It rests on four pieces, and each looks reasonable on its own. First the format: your tables are written in an internal representation only the vendor's engine can read, and the export yields bare CSV or Parquet — bytes without schema evolution, without history, without transactions. Then coupling: the engine only runs on the vendor's storage, so changing engine means moving the data first. The catalogue — the map of tables, permissions and lineage — usually has no published interface. And the dialect: proprietary functions, stored procedures, semi-structured types written in a syntax that exists nowhere else. You do not migrate that SQL. You rewrite it.
The European legislator took on the most visible and least decisive piece, egress fees: the Data Act removes them from 12 January 2027 and mandates open interfaces. § That date is known. The four pieces above are on nobody's calendar — because they are not settled by a text but by an architecture.
And behind those four technical pieces hides a fifth, which migrating does not repair: after three years of consuming a service, nobody on your side knows how to size, operate or debug what it replaced. You can get your data back. You do not get back the capability to run it. That is why reversibility is a question for before signing, in operational form: what remains usable if I leave, with which third-party tool, on which copy, by when, and without the vendor's help. For financial entities this is not good practice but a written obligation. §
The technical counterpart is known and entirely public: an open, versioned table format, object storage reachable through a standard API, a decoupled and replaceable engine, a catalogue whose interface is specified. None of those components belong to us, and that is the only argument worth making: what keeps you with us must be our work, not your inability to leave. ▪
| Item | The question to ask | A usable answer | A warning sign |
|---|---|---|---|
| Table format | In what format are my tables written on disk, and where is its specification? | An open, versioned format, publicly specified, read by at least two independent engines. | “Optimised internal format.” An export exists but loses schema, history and transactions. |
| Storage | Can I read the files with my own credentials, without going through your control plane? | Object storage, standard API, your keys, your access, in your account. | Data access runs exclusively through the vendor's service. |
| Query engine | Can another engine query the same tables, in place? | Yes, demonstrated, with no prior copy or conversion. | “Yes, after an export.” |
| Catalogue and grants | Is the catalogue interface specified, and implemented anywhere other than by you? | Published interface, an existing third-party implementation, exportable grants and lineage. | The catalogue is a service, with no documented interface and no export of grants. |
| Getting the data out | What does it cost to take everything out, and how long does it take? | An amount and a lead time written into the contract, decreasing until 12 January 2027. | A per-unit price list, with no cap and no completion deadline. |
| SQL dialect | What share of my queries would run unchanged on another engine? | A measured share, against your own query corpus, with the exceptions listed. | “Standard SQL compatible”, with no measurement and no corpus. |
| Contractual reversibility | Is the exit strategy an annex to the contract, with a plan and a deadline? | A reversibility annex: scope, format, lead time, and a restitution test run. | A termination clause, and no exit plan. |
Cite this article
A reference line ready to copy. The anchor points at the article.
Nudibranches Technologies, “The problem — Article II. What holds you is not a clause. It is what you no longer know how to do”, www.nudibranches.tech/en/the-problem#verrouillage, legal references as of August 2026.
Article III
Sovereignty is a consequence, not a goal.
Sovereignty is not declared. It is what remains once you understand your stack.
The word has become a sales argument and no longer means anything. It appears on offers where the client holds neither the keys, nor the logs, nor the ability to describe what leaves their network. It then names an intention, sometimes a shareholder's nationality, never a verifiable property.
The law says why the question arises. Since 2018, a company subject to United States law must produce data within its possession, custody or control, regardless of where it is stored: the text does not speak of a place, it describes a chain of control. § European law saw the collision coming and only recognises a foreign order where it rests on an international agreement in force. § A provider caught between the two does not have a compliance problem: it has a conflict of laws. A datacentre in Paris run by the European subsidiary of an American group does not break that chain — the subsidiary receives its keys, its patches and its permissions from a parent company that is within reach of a judge.
But the law stops there. It does not tell you who holds the root of trust of your cluster, which process can open an administrative session without asking you, or what flows cross your perimeter at two on a Tuesday afternoon. Those answers do not come from changing vendor: they come from knowing how the stack is built. It is the same problem as in the two previous articles, under another name.
So we use the word in a narrow, checkable sense. A deployment is sovereign when you can answer three questions without taking our word for it: which entity can be compelled to produce your data and before which judge, who holds the keys, and what crosses your perimeter. The sovereignty brief answers all three, target by target, including where the answer does not suit us. ▪
Cite this article
A reference line ready to copy. The anchor points at the article.
Nudibranches Technologies, “The problem — Article III. Sovereignty is a consequence, not a goal”, www.nudibranches.tech/en/the-problem#souverainete, legal references as of August 2026.
The check
When a component was missing, we wrote it.
The three articles above describe mechanisms; they prove nothing about us. What proves something is below, and opens in another tab.
talos-rust-client
8,316 lines of Rust · published on crates.ioWe operate Talos Linux, an immutable system with no shell: you do not log into it, you talk to it over gRPC. We needed a typed client with mTLS by default. We wrote it from the official proto files and published it under MIT or Apache-2.0.
trino-rust-client
6,374 lines of Rust · 45 filesA fork of prusto taken over in December 2024: Presto support removed, advanced Trino features added, including the spooling protocol — the one that decides how large result sets travel. Going down to that level is not a luxury: it is what lets you answer when a query stops responding.
Hyperfluid
internal cloud · 20 services · one consoleWe were operating the same components at several clients, with the same trade-offs to make again each time. We industrialised them into a cloud that installs inside the client's perimeter. Writing a platform forces you to understand every component all the way down — which is what makes the team able to operate other people's.
Ferris Key
authentication server · Rust · Apache-2.0A community project we contribute to and sponsor. Identity is the component every other one depends on: we would rather it were readable by the people who run it.
Legal references as of August 2026. The legal references on this page are given so they can be checked. They are not legal advice, and the exact scope of your obligations depends on how your entity is classified and on your national law.