Backup Integrity Verification Prompt After Action

This prompt is designed for operations engineers and SRE teams who need a structured, evidence-based verification report immediately after a scheduled or ad-hoc backup operation completes. The primary job-to-be-done is closing a change window with confidence: you must confirm that the backup is not just marked 'successful' by a tool, but is actually complete, recoverable, and compliant with retention policies before you declare the maintenance over. The ideal user is an engineer who has access to backup tool logs, storage metadata, and policy definitions, and who is authorized to make a go/no-go decision on the change window.

The prompt requires three concrete inputs to function correctly: a dump of the backup job log or summary, the expected asset inventory (what should have been captured), and the relevant retention policy snippet. It is most valuable after high-risk operations such as database migrations, schema changes, infrastructure-as-code updates, or storage reconfiguration—situations where a silent backup failure could mean data loss with no recovery path. Use it when the cost of an unverified backup is high and when a human must explicitly sign off on the verification before the team moves on.

Do not use this prompt for real-time streaming backup validation, for continuous data protection (CDP) systems where the concept of a discrete 'job' doesn't apply, or as a replacement for automated restore testing. It is a post-hoc verification report generator, not a live monitor. If your backup system already performs automated restore tests and checksum validation, this prompt adds value by synthesizing those signals into a human-readable pass/fail verdict with an explicit escalation recommendation. Avoid using it when the backup job log is incomplete or when the expected asset inventory is unknown—the prompt will correctly flag missing context as an evidence gap rather than fabricating a verdict.

This prompt template is the core engine for a post-action backup verification workflow. It is designed to be pasted directly into your AI harness, where you replace the square-bracket placeholders with live data from your backup system, job scheduler, and storage backend. The prompt instructs the model to act as a reliability auditor, cross-referencing the intended backup scope against the actual results to produce a structured, evidence-backed report. The primary goal is to surface silent failures—such as missed volumes, zero-byte artifacts, or retention policy violations—that automated scripts often miss.

textCopy
You are a senior reliability engineer auditing a backup operation.
Your task is to generate a structured Backup Integrity Verification Report.

## INPUT DATA
- Backup Job ID: [BACKUP_JOB_ID]
- Intended Scope (targets): [INTENDED_SCOPE]
- Execution Timestamp: [EXECUTION_TIMESTAMP]
- Actual Results Log: [ACTUAL_RESULTS_LOG]
- Storage Destination: [STORAGE_DESTINATION]
- Retention Policy: [RETENTION_POLICY]
- Expected Checksums (optional): [EXPECTED_CHECKSUMS]

## OUTPUT SCHEMA
You must output a single JSON object conforming to this structure:
{
  "report_id": "string",
  "verdict": "PASS|FAIL|WARN",
  "completeness_check": {
    "expected_targets": ["string"],
    "verified_targets": ["string"],
    "missing_targets": ["string"],
    "unexpected_targets": ["string"]
  },
  "recoverability_assessment": {
    "checksum_match": "boolean|null",
    "size_anomaly_detected": "boolean",
    "restore_test_recommended": "boolean",
    "notes": "string"
  },
  "retention_compliance": {
    "policy": "string",
    "violations": ["string"],
    "status": "COMPLIANT|NON_COMPLIANT"
  },
  "anomalies": [
    {
      "severity": "CRITICAL|WARNING|INFO",
      "description": "string",
      "evidence": "string"
    }
  ],
  "human_review_required": "boolean",
  "summary": "string"
}

## CONSTRAINTS
- If any target in [INTENDED_SCOPE] is missing from [ACTUAL_RESULTS_LOG], the verdict must be FAIL.
- If a size anomaly is detected (e.g., a backup is >90% smaller than a typical snapshot), flag it as a WARNING at minimum.
- If [RETENTION_POLICY] is violated, set retention_compliance.status to NON_COMPLIANT and escalate the verdict to FAIL.
- Set human_review_required to true if the verdict is FAIL or WARN.
- Base all findings strictly on the provided [ACTUAL_RESULTS_LOG] and [EXPECTED_CHECKSUMS]. Do not invent data.

To adapt this template for your environment, replace the placeholders with data from your specific toolchain. For example, [INTENDED_SCOPE] might be populated by querying your infrastructure-as-code repository for volume IDs, while [ACTUAL_RESULTS_LOG] could be the stdout from a velero or pg_dump command. The [EXPECTED_CHECKSUMS] field is optional but critical for high-integrity workflows; if your backup tool doesn't generate them, a pre-verification step should compute and inject them. Before deploying this prompt, run it against a known set of passing and failing scenarios to ensure the JSON output is reliably parseable by your downstream notification or ticketing system. A common failure mode is an incomplete [ACTUAL_RESULTS_LOG] that causes the model to hallucinate a passing verdict; always validate that the input log contains a record for every item in the intended scope before invoking the model.

The Backup Integrity Verification Prompt is designed to run as a post-action verification gate in an automated operations pipeline. After a backup job completes—whether triggered by a deployment, a configuration change, or a scheduled run—the pipeline should call this prompt with the backup job's metadata, logs, and any available integrity check outputs. The model's structured verification report then becomes the decision point: pass the gate and close the change ticket, or fail the gate and trigger a rollback or manual investigation. This is not a prompt for interactive chat; it is a machine-to-machine verification step that must produce a parseable, trustworthy output every time.

To wire this into an application, wrap the prompt in a verification service with the following contract. Inputs: [BACKUP_JOB_ID], [BACKUP_TYPE] (full, incremental, snapshot), [SOURCE_SYSTEM], [TARGET_LOCATION], [EXPECTED_SIZE_BYTES], [RETENTION_POLICY], [JOB_LOG_SUMMARY], and [INTEGRITY_CHECK_OUTPUT] (e.g., checksum results, file counts, restore test logs). Output: a JSON object with fields verification_status (enum: PASS, FAIL, INCONCLUSIVE), checks (array of check objects with name, status, evidence, recommendation), overall_confidence (0.0–1.0), and human_review_required (boolean). The service must validate this schema strictly. If parsing fails, retry the prompt once with the same inputs and a stronger format constraint appended. If the second attempt also fails to parse, log the raw output and escalate to a human with an INCONCLUSIVE status.

Model choice and tool use matter here. Use a model with strong JSON mode or structured output support (e.g., GPT-4o with response_format, Claude 3.5 Sonnet with tool use). Do not rely on a model that frequently drifts from schema under pressure. The prompt should be called with temperature=0 to maximize determinism. If your backup system emits structured integrity data (checksums, file manifests), pass that as [INTEGRITY_CHECK_OUTPUT] rather than asking the model to imagine checks. The model's job is to reason over the evidence, compare it against expectations, and flag anomalies—not to hallucinate verification steps. For high-compliance environments, add a tool that queries the backup system's API directly for the latest job status, so the model can ground its report in live data rather than only the provided log summary.

Retry and escalation logic must be explicit. If verification_status is FAIL, the pipeline should block the next stage (e.g., deployment promotion, change closure) and route the report to the on-call channel with a link to the backup job. If human_review_required is true—even on a PASS—the report should still go to a human queue because the model detected an anomaly it cannot confidently resolve. Common triggers for this flag include: checksum mismatches on non-critical files, retention policy violations that are within a grace period, or backup sizes that deviate from expected by more than a configurable threshold (e.g., 20%). The verification service should log every report, the model version used, the prompt template version, and the final gate decision for auditability.

Testing this harness requires a suite of known backup scenarios. Create golden test cases: a clean full backup with matching checksums (expect PASS), an incremental backup with a missing parent snapshot (expect FAIL with a specific recommendation), a backup that completed but skipped three files due to permission errors (expect INCONCLUSIVE with human_review_required: true), and a backup log that is truncated or malformed (expect INCONCLUSIVE with a request for manual log review). Run these through the harness before any production change to the prompt or model. Monitor the overall_confidence distribution in production; a sudden drop below 0.7 on previously stable backup types is an early signal of model drift or a change in backup job output format. Finally, never let a parse failure or a timeout silently pass the gate—default to INCONCLUSIVE and escalate.