Training Data Deletion Propagation: Tombstones, Watermarks, and Derived Artifact Disposition

After a DELETE is executed against the source table, yesterday's exported Parquet files, deduplicated representative samples, training-node caches, and object-storage snapshots may still contain the same record. A checkpoint that has already been produced certainly cannot be corrected by deleting one row from a file. If only the ingestion point is cleaned up, nightly incremental jobs or disaster-recovery restores may reintroduce the data into the training set.

Agent Memory Erasure Propagation handles forgetting across interaction memory, caches, and tools currently in use. This article addresses offline training data and artifacts such as checkpoints, adapters, and model releases. RAG Authorization Revocation Propagation blocks revoked documents at query time. A training pipeline cannot rely on applying the same filter during every inference request; disposition must be completed at data admission and before artifact publication.

A Tombstone Is a Monotonic Control Fact

Whether deletion is legally or contractually required is determined by the organization's data-governance process. The engineering entry point accepts only approved, precisely scoped commands and resolves them into stable recordId values, subject keys, source grants, or purpose authorizations. It must not fuzzy-search the original text across every log. The control plane appends an immutable tombstone and assigns it a monotonic sequence and policy generation:

{
  "tombstoneId": "ts_01K1...",
  "sequence": 44193,
  "scope": {"sourceGrant": "grant_882", "recordIdsDigest": "sha256:..."},
  "reason": "CONSENT_WITHDRAWN",
  "effectiveAt": "2026-07-19T10:00:00Z",
  "requiredAction": "EXCLUDE_AND_REVIEW_ARTIFACTS",
  "policy": "training-erasure.v3"
}

State advances through REQUESTED -> FENCED -> PROPAGATING -> ARTIFACT_REVIEW -> VERIFIED; any unknown target sends it to BLOCKED. FENCED atomically advances the minimum tombstone watermark for training admission. Any training dataset snapshot created afterward must prove that it has consumed tombstones through at least that watermark and that none of its members match. Older builders, replayed outboxes, and restored environments below the watermark are rejected from publication immediately, rather than relying on tombstone consumption to "eventually catch up."

Every running job is bound to its input watermark. The control plane closes its artifact-publication permit and then decides whether to cancel, drain, or restart it. Even if a worker read the data before the fence, it cannot submit a new checkpoint after the fence. Permit closure and in-flight registration must be completed within a consistency gate. A TTL only reclaims ownership; it does not mean that the old worker has stopped.

Reverse Lineage Determines the Impact Radius

The asset graph records source -> canonical record -> dedup cluster -> snapshot -> shard -> run -> checkpoint/adapter -> model release, with every edge carrying the generating activity, version, and purpose. Deleting a record requires finding not only direct copies, but also whether it became the representative item for a dedup cluster, whether it contributed to synthetic or distilled data, and which models continued training from related checkpoints. Memory Consolidation Lineage focuses on summarized facts and supersede relationships; training lineage must additionally cover model artifacts and publication status.

Structured data, membership lists, and training shards can be regenerated as versions that exclude the target records, after which aliases and read authorizations for the old versions are revoked. Old objects are quarantined or deleted according to the retention policy. Using stable IDs, set digests, and tombstone watermarks, the verifier proves that the new version contains no matches. If individual entries cannot be erased from backups, apply a shorter restricted-retention window and establish a restore gate: replay the complete tombstone journal after restoration before permitting any data build.

Model weights do not support exact per-sample deletion by default. Affected checkpoints are first quarantined from further training, publication, and download paths. An approved policy then selects retraining from a clean snapshot, validated machine unlearning, or documentation after a risk assessment that replacement is unnecessary. Every unlearning procedure must be tied to an algorithm, baseline, membership-inference evaluation, and utility evaluation. A decrease in loss alone does not justify claiming that the sample has been forgotten. Models already distributed externally and impossible to recall must be explicitly listed as a limitation in the completion evidence; the system must not fabricate a claim of "physical deletion across the entire chain."

Evidence Must Not Copy Content Slated for Deletion

Each adapter reports its target version, scan watermark, match count, newly generated digest, disposition status of old objects, and verifier version. Completion evidence stores the scope HMAC, counts, and artifact IDs, but not the original text. NIST SP 800-88 can guide media sanitization and disposition, but object-storage behavior, key destruction, and backup capabilities must still be verified against the actual platform. The applicability of requirements such as GDPR Article 17 should be confirmed by legal professionals.

Fault injection covers races between tombstone and snapshot commits, deletion of a dedup representative, recovery after a builder was offline, continued training from an old checkpoint, disaster recovery that omits the journal, and mismatches between an unlearning report and the model digest. No new artifact whose watermark is below the fence or that still matches a tombstone may be published. A duplicate command returns the same job.

Metrics include tombstone lag, rejected low-watermark builder counts, pending volume by asset type, unknown lineage edges, affected checkpoints, quarantined releases, verification failures, and maximum completion latency. If the SLO expires while unknown targets remain, report BLOCKED; never mark the job complete automatically just to bring a dashboard count to zero. Disaster recovery drills must also assert that the deletion watermark never regresses.

Software can be rolled back; tombstones cannot. Before an older version is deployed, it must prove that it recognizes the current minimum watermark and artifact permit. Otherwise, training and model publication remain disabled. An erroneous deletion request can be corrected only by creating a new authorization fact and future data versions. It cannot undo a historical tombstone or restore the publication eligibility of an old checkpoint. Reliable propagation means that every new read and artifact has crossed the fence, while historical impact and items that cannot be recalled have honest, auditable disposition conclusions.

Further Reading

• Agent Memory Erasure Propagation
• RAG Authorization Revocation Propagation
• Training Dataset Snapshots
• Atomic Training Shard Publication