SOVEREIGN

Status of This Document

This is a proposal. It is not a product announcement, not a description of a running service, and not a report on anything deployed.

Nothing described here is in operation. There are no users of this architecture, no organizations running it, no platforms negotiating through it, and no data moving across it. The reference implementation cited throughout exists for one purpose: to make the paper's central claim executable, so that a reader can check it rather than take it. It is roughly three hundred lines. It has no server, no network surface, no settlement, and no coordination layer. It demonstrates an idea; it does not operate anything.

Every specification in Section 4 is proposed and open to revision. Field names, message shapes, algorithms and state transitions are written concretely because a proposal that cannot be implemented cannot be criticized, and vagueness is not humility. They should be read as a first draft put forward for attack, not as a settled standard.

Abstract

For twenty years, the power dynamic between platforms and the people who generate their data has been determined not by law, not by rights frameworks, and not by consumer choice — but by architecture. Platforms built systems where data, once given, could not be meaningfully revoked. The result was structural leverage: the platform held the data and set the terms.

Regulatory responses — GDPR, CCPA, and their descendants — addressed the symptom (consent) without changing the underlying structure (access). Individual opt-outs do not create negotiating power. They create friction that platforms route around.

This paper argues that data sovereignty is an architecture problem, not a policy problem, and proposes the access envelope: an infrastructure pattern in which data access is revocable, time-bounded, and collective — so that a data consumer has to negotiate rather than extract. The pattern is offered as a specification to be built, criticized, and tested by others.