Deletion must reach diagnostic copies too

Inventory by content, not by system name

List where the application stores original files, extracted passages, embeddings, generated answers and source excerpts. Then inspect diagnostic paths: failed-job payloads, dead-letter queues, traces, exported evaluation cases and support attachments.

The important question is what each location contains. A log holding only a source identifier creates a different exposure from a log holding the full prompt. Calling both "telemetry" hides that distinction and makes retention rules difficult to apply.

Keep the inventory close to the implementation. New debugging features and connector retries can introduce copies long after the original design review. A field-level review of representative records is more reliable than relying on architecture diagrams alone.

Separate removal from proof of removal

A deletion event should identify the source and the affected derived records. The system may need a minimal record that removal occurred, but that record should not retain the content it was meant to remove.

For example, a deletion receipt can contain the source key, event time, systems processed and verification outcome. Whether identifiers themselves require restricted handling depends on the data model. Avoid assuming that metadata is automatically harmless.

Some stores remove data asynchronously or preserve backups according to a separate lifecycle. Document those behaviours and the access restrictions around them. Do not promise immediate physical erasure merely because the application no longer returns the document.

Review exceptions explicitly

An organisation may need to retain selected records for an approved purpose. Treat that as a separate authorised retention path with a defined audience and expiry, not as an accidental copy in an unrestricted debug store.

Make operational tooling respect the same distinction. A support engineer investigating a stale-answer incident should not receive broad access to historical source text simply because it is convenient. Often the source revision and processing status provide enough information to locate the failure.

Where a removal requirement is legal or contractual, obtain the applicable interpretation from the responsible adviser and implement that requirement precisely. This article describes the engineering inventory and verification work, not a universal retention period.

Verify with a traceable fixture

Ingest a synthetic marker document and deliberately send it through successful processing, a failed job and an evaluation export. Request removal through the supported workflow, then inspect each known location.

Record which copies disappeared, which became inaccessible and which remain under a documented retention rule. These are different outcomes and should not be collapsed into one success flag. The exercise should also reveal stores that cannot locate records by source identity. Fixing that traceability gap is often the first practical step toward dependable deletion.