{
  "schema": "org-writing@v1",
  "slug": "delete-is-not-revoke",
  "kg": {
    "id": "org:writing:delete-is-not-revoke",
    "type": "brick",
    "graph": "/kg.json"
  },
  "title": "Delete is not revoke",
  "subtitle": "Erasing a record ends one row while withdrawing consent has to reach every copy made under it",
  "abstract": "Why consent has four layers a system must not collapse, and what a company is actually promising when it says your data has been deleted. The canonical treatment of the difference between delete and revoke.",
  "kind": "brick",
  "topics": [
    "Endings"
  ],
  "courseMemberships": [
    {
      "course": "org:courses:endings",
      "topic": "Endings",
      "wall": "org:walls:ethics",
      "position": 2,
      "total": 4
    }
  ],
  "publishedAt": "2026-08-03T00:00:00.000Z",
  "version": 1,
  "guidelinesVersion": 15,
  "brief": {
    "problem": {
      "text": "By the time a person asks for their data back, its value has usually moved into derivatives, which is why regulators now order the destruction of models trained on improperly collected material rather than only the material itself.",
      "claims": [
        "required the destruction of the face-recognition models and algorithms developed from them"
      ]
    },
    "mechanism": {
      "text": "Consent separates into a display-binding proof, a durable receipt, a standing permission, and a short-lived runtime lease, each answering a different question, so a system that collapses them reads evidence that someone saw a screen as authority over everything downstream of it.",
      "claims": [
        "Consent separates into four layers"
      ]
    },
    "move": {
      "text": "Stop asking whether a product has a delete button and start asking it to name its derivatives, because a revocation is only as real as the provenance that can find every copy.",
      "claims": []
    }
  },
  "sources": [
    {
      "repo": "mnstry-monorepo",
      "path": "docs/10-platform/40-architecture/core/root-retained-artifact-consent-authority.md"
    }
  ],
  "canonicalPath": "/writing/delete-is-not-revoke/",
  "body": "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.\n\nThat 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.\n\nUnderneath 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.\n\nThe 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.\n\nSo 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.",
  "apparatus": {
    "note": "The human-facing essay is deliberately practical; this apparatus carries the full references, evidence-graded claims, article-local concepts, and research context behind it. Canonical concept definitions come from the concept registry.",
    "references": [
      {
        "id": "org:references:delete-is-not-revoke:r01",
        "author": "US Federal Trade Commission",
        "work": "In the Matter of Everalbum, Inc. (decision and order)",
        "year": 2021,
        "relevance": "The named case for algorithmic disgorgement: deletion of the photos was not the remedy on its own; the models and algorithms trained on them had to go too."
      },
      {
        "id": "org:references:delete-is-not-revoke:r02",
        "author": "US Federal Trade Commission",
        "work": "United States v. Kurbo, Inc. and WW International, Inc. (stipulated order)",
        "year": 2022,
        "relevance": "The second application of the same remedy, on children's data collected in violation of COPPA, which establishes it as a pattern rather than a one-off."
      },
      {
        "id": "org:references:delete-is-not-revoke:r03",
        "author": "European Union",
        "work": "General Data Protection Regulation, Articles 17 and 19",
        "year": 2018,
        "relevance": "The pairing the brick rests on: a right to erasure alongside a duty to communicate that erasure to each recipient, which is the legal form of the argument that erasure at the source is only the start."
      }
    ],
    "claims": [
      {
        "id": "org:claims:delete-is-not-revoke:c01",
        "claim": "The FTC's 2021 Everalbum order reached the images and the models both. It required the destruction of the face-recognition models and algorithms developed from them, not only deletion of the photographs collected without adequate consent.",
        "basis": "The published decision and order, and the Commission's own account of it.",
        "confidence": "verified",
        "sources": []
      },
      {
        "id": "org:claims:delete-is-not-revoke:c02",
        "claim": "The FTC applied the same algorithmic-disgorgement remedy in its 2022 action against Kurbo and WW International, requiring destruction of algorithms derived from improperly collected children's data.",
        "basis": "The stipulated order in the case.",
        "confidence": "verified",
        "sources": []
      },
      {
        "id": "org:claims:delete-is-not-revoke:c03",
        "claim": "GDPR Article 17 pairs the right to erasure with an Article 19 duty to communicate erasure to each recipient of the data.",
        "basis": "The regulation's own text.",
        "confidence": "verified",
        "sources": []
      },
      {
        "id": "org:claims:delete-is-not-revoke:c04",
        "claim": "A delete implemented as a soft tombstone on a source row leaves search vectors, client caches, derived projections, embeddings, analytics, exported bundles already delivered, and external recipients untouched.",
        "basis": "Our own root retained-artifact architecture review, which states the limitation of the implemented delete path directly; the same list is standard in data-rights engineering.",
        "confidence": "verified",
        "sources": []
      },
      {
        "id": "org:claims:delete-is-not-revoke:c05",
        "claim": "Consent separates into four layers that authorize different things: a display-binding proof, a durable receipt, a standing permission, and a short-lived runtime capability lease.",
        "basis": "Our own root consent-authority model. A design distinction we hold and build to, not a measured finding or an industry standard.",
        "confidence": "directional",
        "sources": []
      },
      {
        "id": "org:claims:delete-is-not-revoke:c06",
        "claim": "A revocation cannot be proven without provenance on every derivative linking it back to the consent that authorized it.",
        "basis": "Our own architecture's stated non-negotiable; follows from the definition of revoke rather than from measurement.",
        "confidence": "directional",
        "sources": []
      }
    ],
    "concepts": [
      {
        "id": "org:concepts:consent-layer-collapse",
        "name": "Consent layer collapse",
        "definition": "Treating the four layers of consent as one undifferentiated thing. The layers are a display-binding proof (exactly what the person was shown when they agreed), a durable receipt (a queryable record that they permitted one specific use), a standing permission (an authority with scope, grantee, expiry, and a way to be withdrawn), and a short-lived runtime lease (one action, one destination, one time window, compiled from the rest). Collapsed, a system reads evidence that someone saw a screen as authority over everything made downstream of it, which is how software comes to claim permission nobody granted.",
        "provenance": "canonical"
      },
      {
        "id": "org:concepts:delete-versus-revoke",
        "name": "Delete versus revoke",
        "definition": "Delete acts on a record: it tombstones a row and removes it from the paths that return it. Revoke acts on a relationship: it withdraws the authority under which everything downstream of that row was produced, and must cascade to indexes, caches, embeddings, summaries, analytics, exports already delivered, and external recipients. The test a product can be put to is to name its derivatives, since a revocation is only as real as the provenance that can find every copy.",
        "provenance": "canonical"
      }
    ],
    "researchContext": "Harvested from the root retained-artifact consent-authority architecture\nreview, which is an internal engineering document and is used here only for\nits distinctions, never for its implementation status: no service names,\nmigration names, table names, or gap-matrix contents ship. The four-layer\nmodel and the derivative list are ours and are graded directional or\nverified accordingly, with the FTC orders and the GDPR articles added at\nauthoring time so the argument stands on public record rather than on our\nown architecture. Both FTC matters are cited for the remedy they imposed,\nnot for the underlying conduct. The psychological half of deletion belongs\nto the ceremonial-deletion brick, which depends on this one being true and\ndoes not re-argue it."
  },
  "contract": "https://mnstry.org/contracts/org/org-writing.v1.schema.json",
  "releaseHash": "573f9425b41977ba8fa75e1690bd5d548eb07d806a82fb95c8b763e8171700ee",
  "versions": [
    {
      "version": 1,
      "cutAt": "2026-08-03",
      "note": "Initial publication, endings wave",
      "visibility": "published",
      "path": "/writing/delete-is-not-revoke/",
      "contentHash": "sha256:0091a65a399bbe53",
      "releaseHash": "573f9425b41977ba8fa75e1690bd5d548eb07d806a82fb95c8b763e8171700ee"
    }
  ]
}