“Data sovereignty” is the most laundered phrase in technology right now.
Three different things wear the label. Two are residency theater. One is the real thing.
Last week I was at the 4th Solid Symposium in London. All three definitions appeared in the same room, by name, sometimes in the same sentence. So let me draw the lines.
§ 1 The word has been overloaded.
The cloud-infrastructure crowd uses “sovereignty” to mean residency: your data sits in a server rack inside your jurisdiction. Frankfurt for the Germans, Sydney for the Australians, Riyadh for the Saudis. The vendor still holds the keys, the application still mediates every read, and the protocol still says they may inspect what they host. Geographic placement is a regulatory hedge, which is useful, but it is not sovereignty.
The local-first AI crowd uses “sovereignty” to mean runtime locality: the agent runs on your hardware, your conversations live on your disk, your model weights are yours. This is closer, but it answers a narrower question, which I will treat in the next section.
The Solid community uses “sovereignty” to mean protocol control: the patient owns the Pod, applications come to the data rather than the other way around, and every access leaves an audit log on the patient’s record. This is the only one of the three that holds up under scrutiny, because it does not depend on a vendor’s good faith or a runtime’s network discipline.
§ 2 OpenClaw: runtime sovereignty, not data sovereignty.
OpenClaw is the open-source local-first AI agent platform that has been compounding attention through the back half of 2025 and into 2026. Its public position on sovereignty is unambiguous: all data, conversations, and memories sit on the user’s own computer, and the architecture is open-source so users can audit and modify it freely. That is a real thing, and it is the right answer to a real question.
It is also incomplete. Independent technical reviews of OpenClaw deployments published in late 2025 and early 2026 noted a gap between the marketing message and the operational reality. The local execution path is genuine, but the surrounding fabric leaks: ClawHub for skill distribution, the hosted account surface for analytics, default telemetry, and the bot adapters into chat surfaces such as Telegram, Discord, and Slack. None of those vectors are inherent to the protocol; all of them are configurable. None of them are the user’s by default.
The deeper issue, which I do not see discussed enough, is structural. OpenClaw answers the runtime question. It does not define how a third party reads your data with your permission, on terms you can revoke, with an audit trail. It does not give you a portable, structured record that survives the agent and the operating system it runs on. Local-first compute over locally-stored unstructured text is a defensible position, and it is what OpenClaw delivers; it is not the same thing as a sovereign record.
§ 3 Solid: protocol-level data sovereignty.
Solid was conceived by Tim Berners-Lee at MIT and is now under the organizational stewardship of the Open Data Institute. Its mechanics are deliberately small: WebID for identity, the Pod for storage, ACL for access, and a vocabulary of W3C standards underneath. The patient’s data lives in a Pod that the patient controls. Applications authenticate with WebID, request scope, and read only what the patient has authorized.
The crucial property is that the Pod is host-agnostic. It can sit on a vendor’s infrastructure, on a hospital’s, on a municipal server, or on a Raspberry Pi in a closet. The protocol does not care, and the protocol is what enforces the access boundary. This is the difference that residency advocates miss: a sovereign record does not require sovereign hosting, because the protocol is doing the work that the hosting was supposed to do.
Solid is also explicit about what it is not. It is not a decentralized peer-to-peer system. It is not a blockchain. It is not zero-knowledge. It is a user-centric protocol layered on the existing web, which is exactly the move that makes adoption tractable.
§ 4 What I showed at the Symposium.
EverBetter was a sponsor of the symposium’s healthcare session, “Practical uses of Solid for medical and health data,” alongside Inrupt, the Open Data Institute, and Muze. I was also on the program for the Community Demo Day with a ten-minute talk on EverBetter and our live deployment at Paath, a functional medicine clinic group operating direct-to-consumer through paath.us with a LabCorp partnership. The demo path is short and it demonstrates the protocol claim end-to-end. A patient installs the Paath’s version of the EverBetter Me app from the App Store. Auth0 issues an org-bound identity. A WebID is minted, and a Solid Pod is provisioned for that patient. Lab results from LabCorp are transformed from HL7 into FHIR-RDF and written into the patient’s Pod. Clinical agents running on Google ADK 2.0 read the Pod through MCP, with per-element consent enforced at runtime, and every access leaves an audit log on the patient’s record.
The point of the demo was not the agent stack, although our team did spend a year arriving at it. The point was that the patient’s record outlives the agent, the application, the clinic, and us. If Paath wound down tomorrow, the patient would still own a structured, portable, FHIR-RDF copy of their longitudinal biology, addressable by WebID, queryable by SPARQL, governed by an ACL the patient controls. That is the property residency cannot give you and runtime locality does not address.
§ 5 The honest version: they compose.
None of this is an argument against OpenClaw, and OpenClaw is not an argument against Solid. They answer different questions, and the most honest reading of both is that they compose. A local-first agent is the right runtime; a Pod-resident record is the right substrate. An OpenClaw skill that authenticates with WebID and reads a Solid Pod under per-element consent is a coherent product. I am not aware of one in the wild today; I am asserting the architecture, not the implementation.
Without Solid, OpenClaw is local compute over hosted or unstructured data, which is sovereignty by location. Without OpenClaw or its kin, Solid is a protocol with a thin runtime story for the agent era. The integration is the work that has not yet been done, and it is the work I think the next year of the Solid community will be measured on.
§ 6 The next chapter.
The Symposium’s tagline this year is “The Next Chapter for Data on the Web.” I read that as a refusal: a refusal of the residency framing, a refusal of the runtime-only framing, and a refusal of the proposition that sovereignty is something a vendor can give you. The next chapter is the patient’s record, in the patient’s Pod, accessible to the agents and clinicians the patient delegates, on terms the patient sets, audited.
That is what we demoed. That is what Solid was designed for. That is the only one of the three definitions that means what the word says.
Buzz O’Neil is CTO of EverBetter. He spoke on the EverBetter and Paath deployment at the 4th Solid Symposium, London, 30 April to 1 May 2026.