1
The problem is replication, not privacy
The usual framing of personal data is ethical: companies hold information about people without meaningful consent, and that is wrong. It is wrong. It is also, separately and less often argued, a bad architecture, and the architectural case is the one that will actually change behaviour, because it costs the incumbent money.
Consider what the current world literally is. Some large number of independent parties each maintain a private, partial, unsynchronised replica of the same underlying entity: a person. No replica has an authoritative source. None can invalidate another. There is no propagation mechanism, so a correction made at one replica never reaches the others. The person, who is the only party with ground truth, has write access to none of them.
Stated in those terms, any systems engineer recognises the shape immediately. It is an unbounded fan-out cache with no invalidation, no coherence protocol, and no path back to the origin. We would not accept that design for a product catalogue. We accept it for human beings.
| Property | Shadow replicas | Subscribed origin |
|---|---|---|
| Source of truth | None | The person |
| Correction cost | O(replicas), unbounded | O(1), at the origin |
| Staleness | Unbounded, undetectable | Bounded by grant window |
| Revocation | Not possible | Per field, per subscriber |
| Audit | Invisible to the subject | A receipt for every read |
| Breach blast radius | Every replica, forever | Fields granted, until revoked |
2
Why staleness is the commercial argument
The incumbent model does not just leak. It decays, and the decay is invisible to the holder. A retailer with a six-year-old size, an insurer with a former address, a clinic with a superseded medication: each acts on data it believes is current and has no mechanism to learn otherwise. The cost lands as wrong recommendations, failed deliveries, mispriced risk and irritated customers, and it is charged to the holder as an ordinary cost of doing business rather than recognised as a coherence failure.
A subscribed origin inverts the economics. A subscriber pays, in money or discount or service or time returned, for access to a field that is current by construction, because it is read from the origin rather than from a copy taken at an unknown moment. That is a better product for the subscriber, not a concession extracted from them. It is the reason this can be a business rather than a movement.
The sharpest case is the one with the shortest half-life. A person’s location is worth almost nothing as a record and a great deal as a live fact, and its value collapses within hours. No replica architecture can serve it at all: by the time it has been copied, it is wrong. Only a subscription to the origin, granted for a stated purpose and a stated window, can deliver it, and that is precisely the field the incumbent model has been least able to handle honestly.
3
Why this needs the compute to be owned
The inversion has an obvious failure mode: move every shadow replica into one central service, and you have built a more efficient version of the same problem with a single, larger target. If the origin is a company’s server, the person has traded a thousand weak custodians for one strong one and gained nothing they can enforce.
So the origin has to run on hardware the person owns. This is where the argument stops being about policy and starts being about silicon. The practical objection has always been capability: a phone or laptop could not host a model of a person and answer queries against it. Unified memory architectures changed that, and the change is recent enough that most of the industry’s assumptions predate it.
The consequence is a ladder rather than a binary. Routine work runs locally. Occasional heavy work escalates, and every rung change is a consent gate, because a boundary crossing is exactly where a person’s data leaves their control. The transport for those crossings is specified as RFC-003, and it is a specification with no conforming implementation, which the specification says on its own front page.
4
The vocabulary problem, which is the real work
“Subscribe to a person” is easy to say and hard to make safe, because a subscription needs a vocabulary precise enough that a grant means something. “Access my profile” is not a grant; it is a surrender with better manners.
The published registry, at version 0.5.0, carries 252 scopes across seven roots, each with a tier that governs what may ever happen to it, and 8 purposes that let a counterparty ask one legible question instead of naming forty dot-paths. Tier 3 and above cannot be bundled: a named counterparty, a named purpose, one field at a time, or no grant. Those figures are read from the registry itself as this page renders, so they cannot drift from the artefact they describe.
The registry also carries a removal contract, which is the part that makes it a contract at all: a published scope stays servable for at least 365 days after retirement is announced, and its tombstone is permanent. A vocabulary a developer can build against must be a vocabulary that cannot vanish under them.
5
Where this is genuinely novel, and where it is not
Not novel: personal data stores have been proposed for two decades, and consent receipts have a standards history. Verifiable credentials solve adjacent problems well. We are not the first people to notice that the current arrangement is bad, and a note claiming otherwise should not be trusted on anything else it says.
What is different now is a conjunction of three things that did not previously hold together. Consumer hardware can host the origin. Agent protocols give machines a reason to query a person programmatically at volume, which no prior personal-data-store had. MCP, A2A, AP2 and UCP all assume the data is simply available. And live fields have become commercially interesting enough that a subscriber will pay for freshness, which is what turns a rights argument into a market.
Whether that conjunction is a leapfrog or merely a good idea arriving on time is not something we can assert about our own work. It is a claim other people get to evaluate, which is why the specification, the registry and the resolver are all public.
6
What is actually running
The distinction between a design and a deployment is the one this note most wants to keep. So, plainly:
The scope registry. Running. 252 scopes, tiers, purposes, and a 365-day removal contract, served publicly and enforced by tests.
The resolver. Running. A portable model served by spaceID, with the public slice open and trusted or private scopes withheld pending a consented request.
The consent embed. Running. Running on this site, on our own rails, with analytics denied until granted.
Origin on owned hardware. Not built. Specified. The agent runs, the transport does not.
hu_ssh. Not built. RFC-003 exists. No conforming implementation does.
Paid subscription to live fields. Not built. The commercial mechanism in section 2 is an argument, not a running market.
7
Open problems
Four, none solved, all of which would make good work for somebody outside this company.
- 1
Revocation is not retroactive. A field read legitimately yesterday is in the subscriber's hands today. Receipts make misuse detectable, not impossible, and no cryptography changes that.
- 2
Freshness has no honest unit. A subscriber needs to know how current a field is without that metadata itself becoming a tracking signal. We do not have a good answer.
- 3
Aggregation defeats field-level consent. Enough separately reasonable grants reconstruct something nobody agreed to. Tiering slows this; it does not solve it.
- 4
Origin availability. A person's laptop is closed at 3am. A subscription implies uptime the owner never agreed to provide, and delegating that reintroduces the custodian.
8
Read the artefacts
Every claim above that concerns a running component can be checked without asking us.
🤫