Delete is not revoke

In 2021 the Federal Trade Commission settled with Everalbum, a photo-storage company that had used its customers’ images to train face recognition without telling them. The order did not stop at deleting the photos. It required the company to destroy the models and algorithms developed from them. The following year the same remedy reached Kurbo, the weight-management service WW ran for children, whose algorithms derived from improperly collected data had to be destroyed as well. The remedy has a name now, algorithmic disgorgement, and it exists because deleting the source data had stopped meaning very much. By the time anyone asked, the value had already moved downstream.

That gap is not a legal curiosity. It is what happens when a system treats two different words as though they were one. Delete acts on a record. Revoke acts on a relationship. A delete tombstones a row and takes it out of the paths that return it to you, which is a real thing to do and a small one. A revoke withdraws the authority under which everything downstream of that row was ever produced, and it has to reach the search index, the caches, the embeddings, the summaries, the analytics extract, the export bundle already sitting in someone’s downloads folder, and the third party who received a copy last spring.

Underneath the two verbs sit four layers of consent, and they are just as easy to collapse. A display-binding proof records exactly what a person was shown at the moment they agreed, hash and all. A receipt is a durable, queryable record that they permitted one specific use. A permission is a standing authority carrying a scope, a grantee, an expiry, and a way to be withdrawn. A lease is a short-lived runtime authorization compiled from all of the above for one action, one destination, one time window. The mechanism is that each layer answers a different question, so a system that collapses them ends up reading a proof that someone saw a screen as a permission to do whatever that screen implied, and reading a permission as a standing right over every derivative made under it, which is how software comes to claim authority nobody ever granted.

The law worked this out before most architectures did. The GDPR pairs its right to erasure in Article 17 with a duty in Article 19 to communicate that erasure to every recipient the data reached, because the drafters understood that erasure at the source is where the work starts. Meeting that duty is an engineering property rather than a policy one, and it has a hard precondition: you cannot revoke what you cannot find. Every derivative has to carry provenance back to the consent that authorized it, or a revocation is a promise made in good faith with no mechanism behind it, which is the most expensive kind to break.

So the question worth putting to a product is not whether it has a delete button, since nearly everything does. Ask what becomes of the copies, and ask to be shown. A company that can name every derivative has built a system capable of letting go, and the capacity to let go is precisely what makes a system safe to hand something to in the first place.