Did the erased record actually leave the state?
A record has already entered a long-lived system’s consolidated state — an agent’s learned memory, a summarized profile — and must come out: a right-to-erasure demand, a poisoned batch, a data clawback. The owed claim: prove it left the state, not just the row store.
the pain
Deleting the row is easy and beside the point — the value lives in the consolidated state. Removing one record from that is the machine-unlearning problem, and its documented status is stronger than merely “open”: the EDPS states unlearning “alone cannot fully guarantee the right to be forgotten”; certified removal offers only approximate (ε,δ) bounds; and an ICML 2024 result shows the verification is fragile — a dishonest provider can pass every current check while retaining the information. A bound is precisely a place for residual influence to hide.
the process today
You run unlearning, cite the bound, and self-attest. The strongest near-miss — event-sourcing plus re-projection — breaks down where it matters: LLM re-projection is nondeterministic, and numeric re-folds hit the no-universal-tolerance wall, so a third party comparing states is back to negotiating an exploitable ε. Erasure-the-operation is achievable; erasure-the-proof is not — in those architectures.
the cost
A data-protection authority asking “prove the record left the model” — precisely where EDPB Opinion 28/2024 says the obligation can reach model state — gets a probabilistic argument. Poisoned-batch and clawback remediation stays “we think we removed its influence.” And a downstream party inherits the producer’s self-attestation — the exact trust gap the verification-fragility result exposes.
the exhibit — recompute it yourself
corpus: trace-commons/agent-traces (Hugging Face, CC-BY, 2026-06) · 28 donated coding-agent session traces · three states, one substrate: WITH = 11,761 events, the 7,499 declared records mixed in · ERASED = WITH minus the declared set, the erasure performed by the verifier itself · NEVER = the 4,262 eligible events that never held the set · protected geometry: the self-authorship axis. Register: detection — byte-decidable. Erased equals never-enrolled to the byte, and one record left behind is caught. No floor, no null and no ranking is needed to see it.
This register used to read “localized”, and that was an overclaim — ours, corrected here. It asserted that the geometry independently nominates the self-authorship axis. It cannot: n_tool_use carries no variance in the eligible field by construction — a tool_result block cannot contain a tool_use block — so 18 of 21 cells tie at ∞ and any rank among them is decided by sort order, not geometry. It is also a diagonal, a variance term rather than a coupling, so under the convention this site uses for coupling claims it is not in the ranking at all. On the one agent corpus where the boundary is real rather than definitional (Wikipedia), the same test fails at 0.32×. Erasure was always a byte-decidability claim; that claim is untouched and is the stronger one. How this class of correction was caught — the record.
The reference here is a community dataset — trace-commons, best-effort anonymized. Its provenance is checkable at a public source, and it checks out: rebuilt from the raw public Hugging Face session files, the never-enrolled state reproduces byte-for-byte (67a6f95e…) and this receipt's own declared single-residual state — one record left behind — reproduces as 7fbb9ec5…, the kit's own declared value. This page previously said its provenance was “attested by the certificate rather than checkable at a public source”; that was understated and is corrected here.
Full removal, decidable: erased and never-had-it either collide to the byte or they do not — not “close,” not a bound. The erasure is performed by the verifier, on the bytes, not taken on faith.
The record set genuinely conditioned the state — ~9×10⁷× past the declared floor — so the erasure was non-hollow. And it is forge-armed: leaving even one of the 7,499 records behind lands on a different digest (~2×10⁶× past the floor) and is refused.
recompute fingerprint — ERASED and NEVER, the value the kit’s verify step reproduces byte-for-byte on any engine that follows the kit’s published canonicalization · sha256 =
67a6f95ee308a2884f73e071ed72bfb0326ba1b7d6da08a147e6ef10394009aa
kit fingerprint · sha256 =
dac39d3392d88cbaa760cdffb53525a640d8aa73014b8e7a1376afab379e6e80
The verifier recomputes all
three states — WITH, ERASED, NEVER — plus the negative controls (tampered artifact,
one-record-leftover forge), in a clean environment (numpy only).
Why this is decidable at all: the state is an exact, canonical function of its record set, so “erased” and “never had it” either collide exactly or they do not. The decidability is the substrate’s, not a tolerance’s.
the relief
On a substrate where the accumulated state is an exact, canonical function of a provenance-carried record set, erasure becomes recompute-without-the-set and the receipt becomes byte-equality. “We ran unlearning; trust the bound” becomes “recompute it: the state is identical to the one that never held the record.” A data-protection authority gets a checkable answer; a clawback gets a receipt that the state no longer carries it; a downstream party verifies a claimed removal instead of inheriting an attestation.
what this does not prove
The receipt proves a substrate-level take-out: a record that conditioned the accumulated geometry was removed, and the post-erasure geometry is byte-identical to the never-had geometry — decidable, where the field’s best is an (ε,δ) bound. It does not reach other substrates — weights, retrieval indexes, caches, backups. Crucially, it requires the record to live on a recomputable substrate in the first place: you cannot erase-with-proof from someone else’s opaque memory — the buyer adopts the substrate to get the receipt. It is a snapshot (“out of this certified state”), not “never again.” A human reads the receipt; a data-protection authority resolves what it means.
The field’s honest words for this are “cannot fully guarantee” and “only approximate bounds.” This receipt is full removal, recomputed — on your bench, from the artifact alone.
The longer read — the landscape of recomputable data boundaries and both exclusion case overviews — is in the docs.
Recompute it yourself — in your tab
The digit above (67a6f95e…) is the number habitat published for the NEVER state — the records as if the erased ones had never been present. Recompute it here from those vectors — nothing leaves your tab — then try to fool it: reshuffle the records and it holds; change a record and it moves.
what just happened
habitat read the NEVER state once, on our engine, and reduced it to a small set of vectors — the geometry of how its records relate. From those your browser recomputed one number: the covariance, conditioned and inverted (math.fsum → Gauss-Jordan inverse → SHA-256), ~40 lines of public arithmetic, nothing sent. Built from the relationships, not the order — so a reshuffle leaves it identical, a real change moves it. The reading (record → geometry) is the method; it stays on our engine, the recompute is yours.
what this proves — and what it doesn't
Proves: the published number falls out of the NEVER state's own vectors — reproduced byte-for-byte, no server; and it's not a checksum (survives a benign reshuffle, moves on a real change). The full take-out receipt — that erasing the records returns the field to exactly this NEVER state (ERASED == NEVER, byte-for-byte) — is in the downloadable kit.
Doesn't: not tamper-proof, not authenticity. Same number = same relationships, not the same bytes: a uniform shift, or a change finer than the arithmetic's floor, is invisible by design, and a dataset engineered to share those relationships would pass. Self-served (our page, our vectors); the independent version is the kit against a separately-published fingerprint. And it's this published state, not your data — reading your data into geometry runs on our engine, not your tab.
This corpus’s noise floor has its own readout on the site’s second instrument — pre-built for this card, or run on your own data, in your tab: trace your noise →
verify this receipt in your browser
This case's receipt records its verdict and both digests above, and carries its own SHA-256. Recompute it here — WebCrypto, in your tab, nothing sent — and it matches; alter one character of a copy and it fails. It is the smallest version of the whole move: recompute, don't trust. The geometry digest itself you can recompute above, in this tab, or on your bench from the kit.
published fingerprint ·
or download this receipt and check it on your bench:
receipt-takeout-agent-trace.json
— shasum -a 256 prints the same number. Every receipt is on
the ledger.
request the kit
The take-out receipt kit — artifact, manifest, verify.py. A person sends it: the kit and its
verification steps arrive by reply, usually within a business day.
← Receipts · Docs · Ledger