The Residue Ledger: Verifiable Withdrawal

The residue problem

Modern systems make collection easy to locate and withdrawal hard to specify. A record is copied, cached, transformed, aggregated, exported to vendors, converted into features, used in training, incorporated into model parameters, reproduced in human work products, and eventually detached from the moment in which the original information entered the system.

This changes the object of governance. “Delete my data” cannot honestly be treated as one operation on one row. The governed object is residue: any artifact that persists after a withdrawal request and can continue to represent, expose, or operationalize the subject’s information or its derivatives.

The source identifies recurring residue classes including direct copies, cached copies, transformed copies, aggregated statistics, learned representations, human-memory artifacts, and vendor shadow stores. These classes matter because each supports different claims about what removal can mean and how it can be proved.

The four-part claim

A system can claim verifiable withdrawal only if it can do four things under constraint.

• Trace propagation. Determine where the datum or decision basis flowed across datasets, logs, caches, feature stores, processors, analytic systems, and training corpora.
• Quantify residue. Identify what remains, including transforms, aggregates, learned representations, inferred profiles, and other downstream artifacts, and characterize the risk those remnants still carry.
• Execute meaningful withdrawal. Apply a semantics appropriate to the residue class and threat model: hard deletion, tombstoning, cryptographic erasure, access isolation, recomputation, retraining, bounded unlearning, or another explicitly named control.
• Produce adversarial evidence. Bind the completion claim to artifacts a reviewer can validate instead of asking the reviewer to trust institutional narrative.

The specification refuses purity claims. Some residues cannot or should not be erased because accountability, legal retention, safety, or the rights of other people require a record. The obligation is therefore not universal deletion. It is truthful discrimination between what was removed, what was isolated, what remains, why it remains, how it is constrained, and what evidence supports each statement.

Provenance is accountability geometry

Withdrawal is impossible to verify if provenance is treated as a source label added after the fact. The specification treats provenance and lineage as a computable dependency structure: entities, activities, versions, transformations, agents, trust boundaries, and temporal relations sufficient to answer where something came from, what depended on it, and what changed after the withdrawal event.

The graph should be minimal rather than maximal. A withdrawal-ready lineage system is not entitled to collect everything that can be observed. Every captured relation should answer a withdrawal or accountability question. This is the specification’s anti-surveillance constraint: make the system more legible to oversight without making the person more legible to optional institutional curiosity.

Removal is a controlled vocabulary

The phrase “we deleted it” is too coarse to carry an audit claim. The source distinguishes several removal semantics because each makes a different promise.

Hard deletion is a scoped storage claim. Tombstoning is a distributed promise about future visibility and convergence. Cryptographic erasure depends on key scope, key lifecycle, and the absence of uncontrolled plaintext residue. Isolation removes an artifact from authorized use without claiming that it ceased to exist. Re-encryption is containment and migration rather than erasure. Model-level actions add further distinctions: retraining or certified/approximate unlearning address influence; model editing changes associations; redaction controls emission; policy-constrained generation changes behavior. None of these should inherit the label of another simply because all can reduce harm.

For every withdrawal action, the system records which semantics was performed, its scope, the threat model it is intended to satisfy, the remaining limitations, and the evidence artifacts generated.

Evidence, not dashboards

A dashboard is useful for operations but can only summarize what its underlying evidence permits. The Residue Ledger therefore distinguishes levels of assurance: unsupported assertion, governed logging, controlled attestation, cryptographically bound integrity, reproducible reconstruction, differential testing, and independent verification.

The ladder is not a maturity score. Different claims require different proof. Its discipline is linguistic: an organization must stop describing a low-evidence claim as though it had achieved a stronger one.

The ledger itself

The Residue Ledger is an append-only evidence plane that records withdrawal requests, scope determinations, plans, propagation events, execution actions, verification results, vendor evidence, and justified-remainder records. It is designed to preserve ordering and content under reporting, resist unauthorized alteration or deletion, and support verification across organizational trust boundaries.

The evidence plane is separated from the content plane because evidence about withdrawal is itself residue. Logs and telemetry can become new surveillance stores if accountability is allowed to justify unlimited capture. The source therefore specifies minimized audit architecture: collect only what is necessary to validate declared claims, govern its retention, restrict observability, and prevent audit evidence from flowing back into training or optional analytics.

Reference control plane

The source architecture resolves into a control plane with a Withdrawal Intake Gateway, identity resolution, scope and policy determination, lineage collection, a withdrawal plan, an orchestrator that executes class-appropriate actions, verification tests, and an evidence store. Trust boundaries are explicit because a withdrawal request becomes weakest precisely where an action turns into a message sent to another organization.

At vendor boundaries, the specification replaces deletion promises with evidence interfaces: current propagation maps, stable withdrawal-semantics statements, lineage exports, machine-verifiable receipts, subprocessor flow-down, audit rights, and bounded service levels. Delegation does not dissolve the originating institution’s responsibility for knowing what it can prove.

Twelve control objectives

The underlying source develops twelve testable control objectives: withdrawal-intake integrity; defensible identity resolution; a declared provenance-completeness threshold; scope and purpose binding; deletion-semantics correctness; propagation freeze; model-influence management; separation of memorization prevention from withdrawal claims; evidence-plane isolation; vendor withdrawal enforcement; transparency-log integrity; and a complete human- and auditor-readable withdrawal statement.

Several are designed to fail closed. If lineage completeness falls below the declared threshold, the system should not convert uncertainty into a false completion claim. If a model action suppresses output without establishing reduced influence, the ledger records output control rather than unlearning. If a residue must remain, the system emits a retention-justification record instead of silently treating retention as default entitlement.

Withdrawal as a cost curve

Withdrawal is also an architectural cost property. Propagation and entanglement tend to make reversal more expensive over time. Lineage, versioning, purpose binding, deletion hooks, controlled feature reuse, training bills of materials, and evidence interfaces do not make withdrawal free; they reduce search cost and make the liability curve visible before the system is too entangled to change cheaply.

The governance implication is upstream: withdrawal readiness belongs in design review, procurement, vendor selection, and system economics rather than arriving later as a privacy ticket that operators are asked to solve against an architecture designed only for propagation.

The justified remainder

The framework’s deepest boundary is the justified remainder. Some information must persist to protect safety, preserve an appeal record, comply with legal duties, or prevent an institution from erasing evidence of its own conduct. But retention is not allowed to become a background entitlement. The remainder requires a structured justification: legal or operational basis, minimal scope, time horizon, access boundary, permitted purposes, and a review condition.

This turns the final question from “did everything disappear?” into a harder one: which residues still have legitimate jurisdiction, under what constraints, and who can challenge that claim?

Public object. This control-plane specification is extracted from the larger working manuscript The Residue Ledger: Verifiable Withdrawal for Data, Models, and Institutions. The private source retains its full technical mechanisms, economics, sector cases, procurement clauses, review-board design, evaluation suite, and scholarly apparatus; this public object isolates the reference architecture and claim discipline that independently belong in Research.