Data Deletion Pre-Action Summary Prompt

This prompt is for compliance and data engineering teams building AI-assisted workflows that handle regulated data. Its job is to generate a structured, human-readable summary of a planned data deletion operation before any destructive action executes. The summary must capture what data will be deleted, the retention policy justification, affected systems, irreversibility warnings, and required stakeholder approvals. Use this prompt when the cost of a wrong deletion is high, when regulatory frameworks like GDPR or HIPAA require documented review, or when deletion requests must be routed through multiple approval layers.

The prompt assumes that the deletion scope, policy references, and system inventory are provided as input variables and that a separate verification step confirms backup integrity before the summary is routed for human sign-off. In a production harness, this means the prompt should never be the sole gate. The application layer must first validate that a recent, successful backup exists for the target data and attach that evidence to the prompt's input context. The generated summary then becomes the payload for a multi-stakeholder approval queue, where designated reviewers confirm the intent, scope, and compliance justification before any DELETE, DROP, or PURGE command is issued.

Do not use this prompt for low-risk, non-regulated data cleanup where a simple confirmation dialog is sufficient. It is over-engineered for clearing a cache, removing a test user, or pruning logs past a standard retention window. Reserve it for irreversible actions on production data subject to legal hold, data subject access requests (DSARs), or retention schedules that require human judgment. If the deletion scope is fully deterministic and pre-approved by policy, replace this summary prompt with an automated, policy-enforced deletion job that logs its actions without blocking on human review.

The following prompt template is designed to be wired directly into an application's approval workflow. It takes a deletion request and its surrounding context and produces a structured summary that a human reviewer can quickly assess. The prompt is engineered to be descriptive and analytical, not executive; it must not execute any deletion, call any tool, or make any irreversible change. Its sole job is to create a clear, auditable checkpoint.

textCopy
You are a compliance-focused pre-action summarizer. Your output is a structured summary for a human approval queue. You do not execute deletions. You do not call tools. You only produce the summary.

Generate a Data Deletion Pre-Action Summary using the following inputs:

[REQUEST_DETAILS]
[REQUESTOR_IDENTITY]
[DATA_CLASSIFICATION]
[REGULATORY_POLICY]
[RETENTION_RULES]
[BACKUP_VERIFICATION_STATUS]
[AFFECTED_SYSTEMS]
[ROLLBACK_PLAN]

# OUTPUT_SCHEMA
Return a single JSON object with the following fields. Do not include any text outside the JSON.
{
  "summary_id": "string, a unique identifier for this summary",
  "status": "string, always set to 'PENDING_APPROVAL'",
  "requestor": {
    "identity": "string, from [REQUESTOR_IDENTITY]",
    "on_behalf_of": "string or null"
  },
  "deletion_target": {
    "data_description": "string, a clear, non-technical description of the data to be deleted",
    "data_classification": "string, from [DATA_CLASSIFICATION]",
    "affected_systems": ["list of strings, from [AFFECTED_SYSTEMS]"],
    "volume_estimate": "string, e.g., '150 records' or '2.3 GB'"
  },
  "policy_justification": {
    "regulatory_basis": "string, from [REGULATORY_POLICY]",
    "retention_rule_applied": "string, from [RETENTION_RULES]",
    "policy_compliant": "boolean, your assessment based on provided rules"
  },
  "risk_assessment": {
    "irreversibility_warning": "string, a clear statement that this action is permanent",
    "backup_verified": "boolean, from [BACKUP_VERIFICATION_STATUS]",
    "rollback_plan_summary": "string, from [ROLLBACK_PLAN]",
    "risk_level": "string, one of: 'LOW', 'MEDIUM', 'HIGH', 'CRITICAL'"
  },
  "required_approvals": [
    {
      "role": "string, e.g., 'Data Owner', 'Compliance Officer'",
      "justification": "string, why this role is required"
    }
  ],
  "generated_at": "string, ISO 8601 timestamp"
}

# CONSTRAINTS
- If [BACKUP_VERIFICATION_STATUS] is false, set risk_level to 'CRITICAL' and add a note in the irreversibility_warning.
- If [DATA_CLASSIFICATION] is 'PII', 'PHI', or 'PCI', always require 'Compliance Officer' and 'Data Protection Officer' in required_approvals.
- Do not hallucinate any details not present in the input variables.
- If any required input is missing or 'UNKNOWN', set the corresponding output field to null and add a flag "input_missing": true to the root object.

To adapt this template, replace the bracketed variables with data from your application's context. The [REQUEST_DETAILS] should be a natural-language description of the deletion request. The other variables are expected to be pre-resolved by your application logic before the prompt is assembled. The output is strict JSON, making it trivial to parse in your approval pipeline. The constraints section encodes critical business logic—such as forcing a 'CRITICAL' risk level when backups aren't verified—directly into the prompt, reducing the chance of a misleading summary reaching a reviewer.

This prompt is the first stage in a multi-step deletion workflow. It should never be the final gate. The harness must treat the model's output as a structured summary for human review, not as an executable command. Wire the prompt into an application layer that receives a deletion request, assembles the required context (data inventory, retention policies, affected systems, backup status), calls the model, validates the output against a strict schema, and then routes the summary to the correct approval queue based on the data classification and risk level detected in the response.

Validation and Schema Enforcement: Before the summary reaches a human, validate the model's JSON output against a defined schema. Required fields include deletion_scope (list of data categories), affected_systems (list of system identifiers), retention_policy_justification (string), irreversibility_warning (string), backup_verification_status (enum: verified | unverified | not_applicable), and risk_level (enum: low | medium | high | critical). If the output fails schema validation, retry the prompt once with the validation error injected into the [CONSTRAINTS] block. If it fails again, escalate to a human operator with the raw output and error details. Do not proceed with an invalid summary. For critical risk deletions, the harness must require multi-stakeholder approval (e.g., Data Protection Officer and Engineering Lead) before any deletion action is queued.

Routing and Audit Trail: Use the risk_level and affected_systems fields from the validated summary to route the approval request. A deletion touching production databases with PII and a critical risk level should follow a different approval path than a deletion of stale logs from a staging environment. The harness must log the full prompt, the validated summary, the reviewer's identity, the approval timestamp, and any override justification into an immutable audit store. This audit trail is the primary evidence for compliance reviews. The deletion action itself should be executed by a separate, permissioned service that verifies the approval record exists before proceeding. The prompt's job is to create clarity and accountability; the harness's job is to enforce the rules that keep the organization safe.