Post-Action Infrastructure Verification Prompt Template

This prompt is designed for SRE and platform engineering teams who need to close the loop on an infrastructure change by programmatically verifying that the observed state matches the intended outcome. It is the final gate in an autonomous pipeline, a scheduled post-sync job, or a structured checkpoint before resolving an incident. The ideal user is an engineer embedding this prompt into a CI/CD system, a GitOps operator, or a runbook automation that must produce a machine-readable pass/fail report with evidence rather than a conversational summary.

To use this prompt effectively, you must provide three concrete inputs: a description of the intended change, a structured specification of the expected post-action state, and the actual observed state collected from monitoring, logs, or API queries. The prompt compares these inputs and outputs a deterministic verdict. It is not a replacement for real-time alerting or anomaly detection systems; it is a point-in-time verification tool. Do not use this prompt when the expected state is undefined, when the observed state is stale or incomplete, or when the action is still in-flight and side effects have not settled.

Before wiring this into a production pipeline, define the minimum required evidence for a passing verdict and the tolerance for acceptable drift. For high-risk actions such as database migrations, IAM policy changes, or security group modifications, always route the output through a human approval step before considering the verification closed. The prompt's value comes from its structured output contract, which allows downstream systems to act on the result without manual interpretation.

This prompt template is designed to be pasted directly into your AI system after replacing the square-bracket placeholders with data from your infrastructure tooling. It instructs the model to act as an SRE verification engine, comparing a declared expected state against observed actual state collected from logs, metrics, APIs, or configuration scans. The output is a structured report suitable for automated gating in a CI/CD pipeline or for human review in an incident or change management workflow.

textCopy
You are an infrastructure verification engine. Your task is to compare the expected state of a system after a change against the observed actual state and produce a structured pass/fail report.

## INPUTS

### CHANGE CONTEXT
[CHANGE_DESCRIPTION]

### EXPECTED STATE
[EXPECTED_STATE]

### OBSERVED STATE
[OBSERVED_STATE]

### VERIFICATION CRITERIA
[VERIFICATION_CRITERIA]

### CONSTRAINTS
[CONSTRAINTS]

## OUTPUT SCHEMA
Return a single JSON object with this exact structure:
{
  "verification_id": "string",
  "overall_status": "pass" | "fail" | "inconclusive",
  "criteria_results": [
    {
      "criterion": "string (the specific check performed)",
      "status": "pass" | "fail" | "inconclusive",
      "expected": "string (what was expected)",
      "actual": "string (what was observed)",
      "evidence": "string (specific data, metric name, log line, or API response field)",
      "severity": "critical" | "warning" | "info"
    }
  ],
  "drift_detected": true | false,
  "drift_details": "string (summary of any unexpected differences, or null if none)",
  "recommendation": "proceed" | "rollback" | "investigate" | "escalate",
  "recommendation_reasoning": "string (concise explanation for the recommendation)",
  "human_review_required": true | false,
  "human_review_reason": "string (why human review is needed, or null if not required)"
}

## INSTRUCTIONS
1. Compare each item in VERIFICATION CRITERIA against the EXPECTED STATE and OBSERVED STATE.
2. For every criterion, cite specific evidence from the OBSERVED STATE. Do not infer state without evidence.
3. If the OBSERVED STATE is incomplete or missing data needed to verify a criterion, mark that criterion as "inconclusive" and explain what data is missing.
4. If any criterion marked "critical" fails, overall_status must be "fail" and recommendation must be "rollback" or "escalate".
5. If drift is detected that was not part of the expected change, set drift_detected to true and describe the drift in drift_details.
6. If overall_status is "fail" or "inconclusive", set human_review_required to true.
7. Do not fabricate evidence. If you cannot verify something, say so.
8. Follow the CONSTRAINTS when evaluating severity and recommendations.

To adapt this template, replace each placeholder with data from your infrastructure tooling. [CHANGE_DESCRIPTION] should contain the change request, PR, or incident ticket context. [EXPECTED_STATE] should describe what the system should look like after the change—use structured data from Terraform plans, deployment manifests, or configuration management tools. [OBSERVED_STATE] should contain the actual state pulled from monitoring systems, kubectl output, cloud provider APIs, or database queries. [VERIFICATION_CRITERIA] should list specific, testable conditions such as 'pod count equals 3 in namespace production' or 'p95 latency below 200ms for service checkout'. [CONSTRAINTS] should encode organizational policies like 'any security group change requires human review' or 'latency regression over 10% is critical'. After pasting the filled template, validate the JSON output against the schema before using the result to gate a pipeline stage or open an incident.

This prompt is designed to be the final gate in an automated infrastructure pipeline, not a standalone chat query. It should be invoked programmatically after a change has been executed—such as a deployment, a configuration push, or a database migration—and the system has had enough time to stabilize. The harness must supply the [EXPECTED_STATE] from the source of truth (e.g., an IaC plan output, a deployment manifest, or a change ticket) and the [OBSERVED_STATE] from live telemetry, API queries, or log aggregation. The model's job is to act as a structured comparator, not to perform the observation itself; the application layer is responsible for gathering the raw evidence.

To integrate this into a CI/CD or runbook automation platform, wrap the prompt in a function that accepts two required string inputs: expected_state and observed_state. The function should construct the prompt, call a capable model (GPT-4o, Claude 3.5 Sonnet, or similar), and parse the JSON output. Implement a retry loop with a maximum of 2 attempts that catches JSON parsing errors and re-prompts with the malformed output and a strict repair instruction. If the model returns a `

verdict": "FAIL"or a"verdict": "INDETERMINATE

the harness must block pipeline progression and route the full verification report to a human review queue. For `

verdict": "PASS

log the report as an audit artifact and allow the pipeline to continue.

Validation is critical because a false PASS can allow a broken change to propagate. After parsing the model's JSON, apply a programmatic check: if the verdict is PASS but the evidence array contains any item with a status of `

MISMATCH"or"UNKNOWN

override the verdict to INDETERMINATE and escalate. This acts as a safety net against hallucinated summaries. Additionally

implement a time-boxed staleness check: if the observed_state was collected more than 5 minutes before the prompt call

prepend a warning to the `[OBSERVED_STATE