{
  "schema": "org-writing@v1",
  "slug": "a-vector-of-your-words",
  "kg": {
    "id": "org:writing:a-vector-of-your-words",
    "type": "brick",
    "graph": "/kg.json"
  },
  "title": "A vector of your words",
  "subtitle": "A derivative of your writing carries every restriction the writing carried, because the derivative can be turned back into the writing",
  "abstract": "Why an embedding is another copy of the text rather than a safe abstraction of it, and the deletion rule that follows from the difference. The canonical treatment of deletion reach.",
  "kind": "brick",
  "topics": [
    "Privacy"
  ],
  "courseMemberships": [
    {
      "course": "org:courses:privacy",
      "topic": "Privacy",
      "wall": "org:walls:engineering",
      "position": 2,
      "total": 6
    }
  ],
  "publishedAt": "2026-08-03T00:00:00.000Z",
  "version": 1,
  "guidelinesVersion": 15,
  "brief": {
    "problem": {
      "text": "Embeddings are handled across the industry as anonymized metadata, a safe numerical shadow of content that can be persisted, synced, and shared under looser rules than the content itself.",
      "claims": [
        "recovered 92 percent of 32-token text inputs exactly"
      ]
    },
    "mechanism": {
      "text": "An embedding preserves enough of its source to be reconstructed rather than destroying it, which makes the vector a second copy of the words instead of an abstraction of them, and a second copy inherits every restriction the first one carried.",
      "claims": [
        "preserves enough of the source to support reconstruction"
      ]
    },
    "move": {
      "text": "Treat a derived vector as the content it came from, and refuse to create any derivative your deletion path cannot reach.",
      "claims": []
    }
  },
  "sources": [
    {
      "repo": "mnstry-monorepo",
      "path": "docs/10-platform/50-database/75-e2ee-readiness/metadata-boundary.md"
    },
    {
      "repo": "mnstry-monorepo",
      "path": "docs/10-platform/50-database/75-e2ee-readiness/embedding-policy.md"
    },
    {
      "repo": "mnstry-monorepo",
      "path": "docs/10-platform/50-database/75-e2ee-readiness/architecture-decisions.md"
    },
    {
      "repo": "mnstry-monorepo",
      "path": "docs/10-platform/70-ai-integration/00-master/PRIVACY_ROADMAP.md"
    }
  ],
  "canonicalPath": "/writing/a-vector-of-your-words/",
  "body": "An embedding is what a model makes when it reads your sentence and hands back a list of numbers. The industry has spent a decade treating that list as a shadow of the text, safe to persist where the text is not, safe to sync where the text is not, safe to hand to a vendor under terms the text would never have passed. In 2023 Morris, Kuleshov, Shmatikov, and Rush published the experiment that ends the assumption. They framed inversion as controlled generation, producing text that lands close to a fixed point in the same latent space, and a method that iteratively corrects its guess and re-embeds it recovered 92 percent of 32-token text inputs exactly. Not the gist of them. The inputs. On a corpus of clinical notes the same method pulled back full names.\n\nThe instinct that mislabeled the vector was an analogy to hashing, and the analogy is wrong at the only place it mattered. A hash destroys its input and keeps a fingerprint, which is why a password hash can sit in a breach dump and still protect something. An embedding preserves enough of the source to support reconstruction, because preserving meaning is the entire job it was trained for, and a representation faithful enough to retrieve a document is faithful enough to rebuild it. So the vector is a second copy of the words rather than an abstraction of them, and a second copy inherits every restriction that attached to the first.\n\nOnce that lands, the rules stop being a matter of policy preference and start falling out of arithmetic. Our own embedding policy names embeddings derived from a person's content as content-bearing derived data and handles them at the sensitivity of their source, which is the only classification the inversion result permits. Hard deletion of a source has to remove the vectors derived from it, or the deletion was a gesture performed on one copy while another sat in an index answering queries. Every persisted vector has to record which model made it, because a vector without model identity cannot be reasoned about, revoked coherently, or reproduced. And the part we find most instructive is the refusal that follows: vectorization of core message and artifact content stays blocked in our platform until the purge behavior is built and tested, rather than shipping the capability first and building the deletion path once someone asks for it.\n\nThat ordering is the whole rule, and it generalizes past embeddings to every derivative a system is tempted to make. Summaries, classifications, extracted entities, behavioral profiles, and fine-tuning corpora are all derivatives whose relationship to a deletion request is exactly as strong as the engineering that connects them back to a source row. If the derivative cannot be deleted, it must not be created, because creating it converts a reversible act into a permanent one on someone else's behalf and without telling them. Most systems have this backwards; they build the derivative because it is cheap and discover the deletion problem when a person exercises a right, at which point the honest answer is that the right cannot be honored and the dishonest answer is much easier to give. The discipline is small and it is available to anyone building today. Before you derive anything from a person's words, write down how it dies, and if you cannot, you have just learned something true about what you were about to build.",
  "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:a-vector-of-your-words:r01",
        "author": "John X. Morris, Volodymyr Kuleshov, Vitaly Shmatikov, Alexander M. Rush",
        "work": "Text Embeddings Reveal (Almost) As Much As Text, EMNLP 2023",
        "year": 2023,
        "relevance": "The measurement the brick rests on. Frames embedding inversion as controlled generation and recovers 92 percent of 32-token inputs exactly through iterative correction and re-embedding, including full names from a clinical-notes corpus. The result is what converts embeddings from metadata into content."
      },
      {
        "id": "org:references:a-vector-of-your-words:r02",
        "author": "MNSTRY platform documentation",
        "work": "Embedding policy, metadata boundary specification, E2EE readiness architecture decisions (ADR-009), and the AI platform privacy roadmap",
        "year": 2026,
        "relevance": "The internal policy lineage. ADR-009 records the reversibility finding as its most important security conclusion; the embedding policy turns it into rules on classification, purge, and model identity; the privacy roadmap cites the 92 percent figure as the reason embeddings were treated as sensitive from the first schema."
      }
    ],
    "claims": [
      {
        "id": "org:claims:a-vector-of-your-words:c01",
        "claim": "Morris, Kuleshov, Shmatikov, and Rush reported at EMNLP 2023 that a method which iteratively corrects and re-embeds its guess recovered 92 percent of 32-token text inputs exactly from their dense embeddings.",
        "basis": "The paper's abstract and results, verified against the published abstract at authoring time.",
        "confidence": "verified",
        "sources": []
      },
      {
        "id": "org:claims:a-vector-of-your-words:c02",
        "claim": "The same work reports a BLEU score of 97.3 and recovers full names from a dataset of clinical notes, and the inverted embedders were GTR-base and OpenAI's text-embedding-ada-002.",
        "basis": "The paper's abstract and reported results.",
        "confidence": "verified",
        "sources": []
      },
      {
        "id": "org:claims:a-vector-of-your-words:c03",
        "claim": "An embedding differs from a cryptographic hash in that it preserves enough of the source to support reconstruction, so it is not a one-way function.",
        "basis": "The inversion result itself, plus the design intent of representation learning, which optimizes for preserving semantic content rather than destroying it.",
        "confidence": "verified",
        "sources": []
      },
      {
        "id": "org:claims:a-vector-of-your-words:c04",
        "claim": "Our embedding policy treats embeddings derived from a person's own content as content-bearing derived data rather than as anonymized metadata.",
        "basis": "The policy's first core rule, which states the classification directly.",
        "confidence": "verified",
        "sources": []
      },
      {
        "id": "org:claims:a-vector-of-your-words:c05",
        "claim": "Our embedding policy requires that hard deletion of a source remove its derived embeddings, and requires every persisted embedding to carry model identity.",
        "basis": "The policy's deletion-and-retention and model-identity sections.",
        "confidence": "verified",
        "sources": []
      },
      {
        "id": "org:claims:a-vector-of-your-words:c06",
        "claim": "Vectorization of core artifact and message content remains blocked in our platform until purge behavior is implemented and tested.",
        "basis": "The policy's stated block, recorded as a shipping constraint rather than an aspiration.",
        "confidence": "verified",
        "sources": []
      },
      {
        "id": "org:claims:a-vector-of-your-words:c07",
        "claim": "Our E2EE readiness decision record names embedding reversibility as its most important security finding and rules that persisting or syncing embeddings of protected content defeats the protection.",
        "basis": "ADR-009 and its anti-pattern table.",
        "confidence": "verified",
        "sources": []
      }
    ],
    "concepts": [
      {
        "id": "org:concepts:deletion-reach",
        "name": "Deletion reach",
        "definition": "The set of derivatives a deletion request can actually reach and destroy. Embeddings, summaries, classifications, extracted entities, behavioral profiles, and training corpora are all derived from a source, and each one is inside the reach only if engineering connects it back to the source row that a person can ask to have erased. A derivative outside the reach converts a reversible act into a permanent one on the subject's behalf and without telling them, which yields the rule the term exists to carry: if the derivative cannot be deleted, it must not be created. The test is applied before the derivative is built, by writing down how it dies, because a system that discovers the question when a person exercises a right has already made the answer no.",
        "provenance": "canonical"
      }
    ],
    "researchContext": "Harvested from four internal documents in the embedding and privacy lineage,\nnone of which is citable, so the load-bearing evidence is the public paper\nand the internal material supplies the policy consequences. The 92 percent\nfigure was verified externally at authoring time against the published\nabstract rather than taken from the internal roadmap's summary of it, since\nthe roadmap cites the number secondhand and a secondhand number is how\nfigures drift.\n\nThe brick deliberately declines to state a mitigation. Noise injection,\ndimensionality reduction, and distance-preserving transforms all appear in\nthe inversion literature as partial defenses with retrieval costs, and none\nof them is settled enough to name in a piece whose argument does not depend\non any of them holding. The argument is a classification argument, and it\nsurvives whatever the mitigation literature concludes.\n\nBoundary with destroy-the-key, kept on purpose: that brick is about erasing\ncontent held under a key. This one is about derivatives that were never\nunder a key at all, where key destruction has nothing to operate on and the\nonly available discipline is refusing to create the derivative."
  },
  "contract": "https://mnstry.org/contracts/org/org-writing.v1.schema.json",
  "releaseHash": "15141330b82ac2cfb2dfa9283672ee662f9e255974693eaf7be19e6fa3349763",
  "versions": [
    {
      "version": 1,
      "cutAt": "2026-08-03",
      "note": "Initial publication, privacy wave",
      "visibility": "published",
      "path": "/writing/a-vector-of-your-words/",
      "contentHash": "sha256:d40246534415abd4",
      "releaseHash": "15141330b82ac2cfb2dfa9283672ee662f9e255974693eaf7be19e6fa3349763"
    }
  ]
}