Right-to-Delete Request Trace Verification Prompt

This prompt is a verification and audit control for privacy engineers and compliance officers responsible for confirming that a right-to-delete request has been fully executed across all AI system storage locations. After a user or customer submits a deletion request, residual PII can persist in application logs, model caches, session state stores, vector databases, and backup snapshots. The prompt audits structured production traces captured after the deletion timestamp to confirm removal or flag residual data. The ideal user has access to an observability platform that exports structured trace data—including span attributes, log messages, and tool-call arguments—and a specific subject identifier (such as a user ID, email, or device fingerprint) to search for.

To use this prompt effectively, you must provide a complete trace export for the time window following the deletion event, the subject identifier, and a list of storage locations that should have been purged. The prompt produces a per-location verification result with one of three statuses: REMOVED (no residual PII found), RESIDUAL_FOUND (PII remains with evidence), or INCONCLUSIVE (insufficient trace data to confirm). Each finding includes the specific span ID, the data fragment, and a risk classification. The prompt is designed to work with structured trace formats like OpenTelemetry, but you must pre-process raw log streams into a consistent JSON schema before invoking it.

Do not use this prompt as a replacement for automated deletion pipelines. It is a verification mechanism, not the deletion mechanism itself. It cannot delete data, and it cannot confirm deletion for storage locations that produce no trace evidence. It is also not suitable for real-time deletion verification at scale; it is designed for point-in-time audits of individual requests. For high-risk regulated environments, always pair the prompt's output with human review and evidence grounding. The prompt's effectiveness depends entirely on the completeness of the trace data you provide—if your observability platform does not capture a particular storage layer, the prompt cannot audit it.

This section provides the core prompt template for auditing a production trace after a right-to-delete request has been processed. The prompt is designed to be pasted into your LLM interface or trace analysis tool. It instructs the model to act as a privacy audit specialist, systematically checking each storage location (logs, caches, databases, session state, vector stores) for residual PII belonging to the data subject. The output is a structured verification result per location, with evidence of deletion or a residual finding.

textCopy
You are a privacy audit specialist verifying the completeness of a right-to-delete request. Your task is to analyze the provided production trace, which captures all system activity related to a specific data subject, and confirm that their personal data has been removed from every storage location.

## Input Data
- **Trace Data:** [FULL_TRACE_JSON]
- **Data Subject Identifier:** [SUBJECT_ID]
- **Deletion Request Timestamp:** [DELETION_TIMESTAMP]
- **Storage Locations to Verify:** [STORAGE_LOCATIONS_LIST]
- **Data Categories to Check:** [DATA_CATEGORIES_LIST]

## Verification Steps
For each storage location in [STORAGE_LOCATIONS_LIST], perform the following:
1. Identify all trace spans that interacted with this location after [DELETION_TIMESTAMP].
2. Inspect the data read or written in those spans for any value matching [SUBJECT_ID] or belonging to [DATA_CATEGORIES_LIST].
3. If a soft-delete or backup system is involved, check for logical deletion markers and confirm the data is not recoverable through standard application access.
4. Classify the finding as one of: `DELETED`, `RESIDUAL_FOUND`, `SOFT_DELETED`, `BACKUP_PENDING`, or `UNABLE_TO_VERIFY`.

## Output Schema
Return a single JSON object with this exact structure:
{
  "verification_id": "string",
  "subject_id": "[SUBJECT_ID]",
  "deletion_timestamp": "[DELETION_TIMESTAMP]",
  "overall_status": "COMPLETE" | "INCOMPLETE" | "UNCERTAIN",
  "findings": [
    {
      "storage_location": "string",
      "status": "DELETED" | "RESIDUAL_FOUND" | "SOFT_DELETED" | "BACKUP_PENDING" | "UNABLE_TO_VERIFY",
      "evidence": [
        {
          "trace_span_id": "string",
          "timestamp": "ISO8601",
          "observation": "string",
          "residual_data_description": "string | null"
        }
      ],
      "remediation_required": true | false,
      "remediation_suggestion": "string | null"
    }
  ]
}

## Constraints
- Do not infer deletion from the absence of data alone; look for positive confirmation such as DELETE operations, tombstone records, or confirmed overwrites.
- Flag any soft-deleted records that remain within a recovery window as `SOFT_DELETED` with a note on the hard-deletion timeline.
- If a backup system is identified but its contents cannot be verified from the trace, set status to `BACKUP_PENDING` and recommend a manual audit.
- If the trace does not contain enough information to verify a location, set status to `UNABLE_TO_VERIFY` and explain what data is missing.
- Be conservative: when in doubt, flag the finding for human review rather than marking it as `DELETED`.

To adapt this template, replace the square-bracket placeholders with your actual data. The [FULL_TRACE_JSON] should contain the complete, unredacted trace for the session or time window under review. The [STORAGE_LOCATIONS_LIST] should enumerate every system that might hold the subject's data—application databases, cache layers (Redis, Memcached), search indexes (Elasticsearch), vector stores (Pinecone, Weaviate), object storage (S3), log aggregators, and backup systems. The [DATA_CATEGORIES_LIST] should list the specific PII types to search for, such as ["email", "phone_number", "physical_address", "user_id"]. Run this prompt with a model that supports long contexts and structured JSON output, such as gpt-4o or claude-3-opus, and always validate the output against the schema before acting on remediation suggestions.

This prompt is designed to be the final verification step in a deletion pipeline, not a standalone script. The application harness must first collect all relevant trace data from the specified storage locations—logs, caches, session state, and backups—for the target data subject identifier. The harness should assemble a structured context object containing the deletion request metadata (request ID, timestamp, subject identifier), the list of storage locations to audit, and the raw trace excerpts from each location. This context is then injected into the [CONTEXT] placeholder, while the [INPUT] placeholder receives the specific verification parameters, including the deletion request ID and the time window for the audit. The model choice should favor a model with strong structured output capabilities and a large context window to handle verbose trace data; a model like claude-3-5-sonnet or gpt-4o is appropriate for this high-stakes, detail-oriented task.

The harness must enforce a strict validation loop on the model's JSON output. The expected [OUTPUT_SCHEMA] is a JSON array of objects, each with storage_location, verification_status (enum: VERIFIED_DELETED, RESIDUAL_FOUND, NOT_FOUND, ERROR), evidence_summary, and residual_data (an array of objects with data_type and excerpt fields, empty if status is VERIFIED_DELETED). Before marking a trace as complete, the application must validate this schema, confirm all requested locations are present in the response, and flag any RESIDUAL_FOUND status for immediate human review. For soft-delete and backup scenarios, the harness should query the backup catalog and soft-delete retention store separately, providing those results as distinct locations in the context. A retry mechanism with a maximum of 2 attempts should be implemented for schema validation failures, using a repair prompt that includes the validation error message. All prompt requests, raw responses, and validation results must be logged immutably to an audit trail for compliance evidence.

The primary failure mode to guard against is a false negative, where the model reports VERIFIED_DELETED but residual PII remains in an unparsed log field or an encoded format. To mitigate this, the harness should pre-process trace data to decode common encodings (base64, URL-encoded strings) before passing it to the prompt. Additionally, implement a post-verification sampling step: for a configurable percentage of VERIFIED_DELETED results, a human reviewer should manually inspect the raw trace excerpts. The harness should also monitor for ERROR statuses, which indicate the model could not access or parse a storage location, and trigger an operational alert for the data platform team. Do not treat this prompt as a replacement for automated deletion mechanisms; it is a detective control that provides an auditable paper trail confirming those mechanisms functioned correctly for a specific request.