Erasure and the terms of use
into someone else's personal context — is agreeing to two lines of terms of use, and any
operator who may one day execute an erasure should know exactly what the code does and does
not reach.
stands behind its own terms. What this page documents is the behavior the code enforces
today, so those terms can quote it rather than promise past it.
deployments the organization that hosts Temper owns the workspace the way it owns its mail
or chat tenancy: a "personal" context is personal to the worker inside the organization's
estate, the way a work mailbox is yours as a worker — not your property — and leaving does
not entitle anyone to deletion. Erasure exists for the case where the organization itself
determines erasure is necessary or warranted: a data-protection request it must honor, a
regulator's order. It is destructive and irreversible — content emptied, identity scrubbed —
and it is never self-serve; the door belongs to the organization, not the subject.
The two lines a contributor crosses
a team-owned context other than someone's personal team (line 2) — resources, edges,
properties, uploaded files, data artifacts, schemas — stays when you leave the team, and
stays when an erasure acts on your profile, whoever authored it. You crossed this line the moment you wrote there; deleting the content
afterwards is the team's act, not yours, and your erasure never performs it for you.
person's personal contexts are their own (
@me) contexts and the contexts of their personalteam, the
+personal-<handle> team made for them. When the owner of a personal contextgrants you authorship into it, everything you write there
lives and dies with that context: if that profile is later erased, your content there is
erased with it — text, structured content, and binary files alike. You tied its lifetime
to theirs by writing into their context — being its author does not hold it back, and
nothing uploaded there is held back either. This line is the disclosure: by writing into
someone else's personal context you accept that your files there die with their estate if
it is ever erased, even though the erasure was never about you.
synced content to your laptop, that copy is yours and Temper has no enforcement over it —
the same is true of any export from Google Drive or OneDrive. Collecting a departing
person's local copies is an IT/Security process outside Temper, not a Temper control.
What an erasure wipes — and what it leaves
executed by an instance administrator (system-admin standing) on the organization's
determination. In one server-side transaction it:
@me) contextsand their personal team's contexts — whoever authored or uploaded it. Each
resource there goes through the same act that erases a single resource: its text,
structured content, embeddings, search data, title, origin, properties and history are
emptied or replaced by placeholders, in the projections and in the event ledger, and
it remains only as an empty record marked erased. Every relationship touching it is ended
and its label cleared, including relationships from a team's content into the estate.
Content a guest wrote there under line 2 dies with it, files included; the bytes are
released only when no live record carries the same content hash.
identifiers. Attribution to them anywhere else breaks because their profile stops
resolving to a person (the pseudonym break) — their past contributions to team contexts
are never edited to hide them.
name and address are replaced by placeholders, in the projections and in every earlier event
that recorded them (a rename, a retirement, a restoration). Retirement is what makes line 2
enforceable rather than promised: every share and grant that reached the estate through the
context dies with it — nobody can read into it afterward, guests included. An erased context
is never restored, by anyone: not by a member who administers the personal team, not by an
instance administrator. Writing is deliberately not blocked the same way: a fresh commit into a
retired home mints live, lawful content, and any later erasure of the same estate strikes it
again.
change it makes there is to end a relationship that points into the estate.
inherits it: whoever owns a resource homed in the wiped estate keeps owner standing
over that resource — the same door that lets an owner move work out of a merely-retired
context. What they keep is a husk: the content was emptied before the door could matter,
and what they write there now, nobody else can reach.
What the code enforces, and what it only reports
wipe is computed from where content is homed, so contributions to other teams' contexts are
never in scope and personal-context content never escapes it, regardless of author. What the act
cannot enforce, it names in its record — the erasure's response and the ledger event carry
per-target outcomes, so an operator reads the remainder at the door and the audit trail
keeps it afterward:
whose genesis write the subject emitted — in other teams' or map homes — are named in the record
with their content hashes: attribution for the audit trail, never a deletion claim.
Contributing into a shared space never carried a sole claim on the content; attribution
is what the system provides and what survives. The prose itself stays; only the
attribution breaks (the pseudonym break). The other text the subject wrote there — titles,
property values, relationship labels, citation-audit reasons and the names they gave contexts
outside the estate — is counted in the record,
one count per kind, and never quoted.
one is named in the record with its content hash as held by the team or map that homes
it. The team keeps the bytes; the record is what proves the erasure was not silent about
them.
sweep is computed from where content is homed, not who committed it: a file a guest
uploaded into the subject's context dies with the estate, whoever uploaded it. This is
the accepted cost of line 2, disclosed there rather than adjudicated here — the act
itself neither asks nor compensates; it strikes. The bytes release only when no live
record carries the same content hash, so a guest's bytes die outright only when they
were the last copy. Structured-data artifacts on those resources are emptied with the
resource, whichever principal's kind owns them.
resources, files and contexts were still in the estate after the act committed: ones created
there while the act ran. A non-zero count means the operator runs the act again, which
erases them. When the count cannot be read, the response leaves it out rather than report
zero.
Where the act lives
POST /api/admin/erasure, operator-only: a caller withoutsystem-admin standing is answered as a not-found before anything is looked up, so the answer
discloses nothing about the subject, and the attempt adds nothing to the ledger. A retried
request with the same reference completes as a no-op on an already-erased subject. A
read-only companion,
POST /api/admin/erasure/survey, predicts what the record would be —the act's own computation, its strike verdicts simulating the act's own sequential refcount,
so in the same state it matches what the act then records (a commit or strike after the
survey can still flip the strike-time verdict) — and writes nothing: a caller without
standing gets the same not-found.
Re-committing identical bytes after an erasure is an ordinary write — nothing refuses it,
and nothing treats it as a violation by whoever wrote it.
Further reading
Deleting a blob.
Offboard a Departure.
Modified at 2026-11-15 01:09:09