Manual Change vs IaC Reconciliation Prompt

This prompt is designed for the specific moment after an incident is resolved but before the next deployment cycle begins. The primary job-to-be-done is to close the gap between what an on-call engineer did under duress to restore service and what the canonical Infrastructure-as-Code (IaC) repository declares as the desired state. The ideal user is a platform engineer or SRE who has access to three critical artifacts: a manual change log (even if it's a rough timeline from a chat channel), the current IaC source files (Terraform, CloudFormation, Pulumi, etc.), and a snapshot of the live infrastructure state. The prompt's value lies in transforming a messy, high-pressure human process into a structured, auditable reconciliation report that can be reviewed, actioned, and archived for compliance.

You should not use this prompt during an active incident. It is a post-mortem analysis tool, not a real-time response aid. It is also inappropriate when the manual change log is entirely absent; the prompt requires at least a partial list of actions to begin reconciliation. If you only have a live state and IaC source without any record of what was changed manually, use a standard drift detection prompt instead. This prompt is specifically for classifying and dispositioning known manual interventions. Furthermore, do not use it for routine, planned changes that were simply executed out-of-band; it is tuned for emergency changes made under duress, where documentation may be incomplete, inconsistent, or captured in unstructured communication logs. The prompt's instructions to handle 'incomplete documentation' and 'changes made under duress' are key differentiators from a standard configuration audit.

Before invoking this prompt, assemble the three inputs into a clear, text-based format. The manual change log can be a raw copy-paste from Slack, PagerDuty notes, or a ticket. The IaC source should be the relevant file contents, not just file paths. The live state should be a structured export from your cloud provider or infrastructure tool. The prompt's output is a structured report classifying each manual change as codify, revert, or exception. Your next step is to feed this report into a remediation planning workflow, such as a set of Jira tickets for codify items and a rollback runbook for revert items. Always require a human to approve the final classification before any automated remediation is triggered, as the model may misinterpret the intent behind a manual change made during a high-stress event.

This template is designed to be copied directly into your AI harness, prompt library, or orchestration layer. It accepts structured inputs describing the incident context, the IaC source of truth, and the manual changes made under duress. The model is instructed to produce a reconciliation report that classifies each manual change as needing codification, reversion, or acceptance as a permanent exception. All placeholders use square-bracket notation and must be replaced with real data before execution.

codeCopy
You are an infrastructure reconciliation analyst. Your task is to compare a set of manual emergency changes against the current Infrastructure-as-Code (IaC) definitions and produce a structured reconciliation report.

## INPUTS

### IaC Source of Truth
[IAC_DEFINITIONS]

### Manual Changes Log
[MANUAL_CHANGES]

### Incident Context
[INCIDENT_CONTEXT]

### Constraints
[CONSTRAINTS]

## OUTPUT SCHEMA

Return a JSON object with the following structure:

{
  "reconciliation_id": "string",
  "generated_at": "ISO8601 timestamp",
  "summary": {
    "total_manual_changes": "integer",
    "changes_to_codify": "integer",
    "changes_to_revert": "integer",
    "permanent_exceptions": "integer",
    "unresolved": "integer"
  },
  "findings": [
    {
      "finding_id": "string",
      "manual_change_description": "string",
      "related_iac_resource": "string or null",
      "classification": "codify | revert | permanent_exception | unresolved",
      "rationale": "string explaining the classification with reference to incident context and constraints",
      "remediation_steps": ["string"],
      "risk_if_not_remediated": "low | medium | high | critical",
      "evidence_sources": ["string references to specific lines or resources in IAC_DEFINITIONS or MANUAL_CHANGES"]
    }
  ],
  "unresolved_items": [
    {
      "finding_id": "string",
      "reason": "string explaining why classification is blocked",
      "information_needed": "string describing what additional data would resolve this"
    }
  ]
}

## CLASSIFICATION RULES

- **codify**: The manual change addresses a legitimate gap in the IaC definitions and should be added to the source of truth. The change is safe, intentional, and aligns with infrastructure patterns.
- **revert**: The manual change was a temporary fix that should be rolled back once the IaC is updated or the incident is resolved. The change introduces drift, security risk, or inconsistency.
- **permanent_exception**: The manual change cannot be codified due to technical limitations, organizational policy, or resource constraints, but it is intentional and must be documented as an accepted exception with a review cadence.
- **unresolved**: Insufficient information exists to classify the change. Specify what additional data is needed.

## RULES

- Ground every classification in specific evidence from [IAC_DEFINITIONS] and [MANUAL_CHANGES].
- If a manual change was made under duress with incomplete documentation, flag it as unresolved rather than guessing.
- For changes classified as permanent_exception, include a recommended review date no more than 90 days out.
- If [CONSTRAINTS] specifies compliance frameworks, check each finding against those requirements.
- Do not invent changes, resources, or incident details not present in the inputs.
- If the manual changes log contains contradictory or ambiguous entries, note the ambiguity in the rationale.

Adaptation guidance: Replace [IAC_DEFINITIONS] with the full text of your Terraform, CloudFormation, Pulumi, or other IaC files. Replace [MANUAL_CHANGES] with a structured log of changes made during the incident—ideally sourced from audit trails, runbooks, or chat transcripts. Replace [INCIDENT_CONTEXT] with a brief description of the incident, its severity, and any time pressure that affected decision-making. Replace [CONSTRAINTS] with organizational policies, compliance frameworks, or architectural rules that must be respected. For high-risk production environments, always route the output through a human review step before any remediation action is taken.

This prompt is designed to sit inside a post-incident reconciliation workflow, not as a real-time response tool. The ideal harness runs after an incident has been declared resolved and the immediate pressure is off. The workflow should gather three inputs before invoking the prompt: the IaC source of truth (e.g., Terraform state, CloudFormation template, or Pulumi stack export), a structured log of manual changes made during the incident (extracted from runbooks, chat transcripts, or audit logs), and the incident timeline with severity classification. The prompt expects these as [IAC_DEFINITION], [MANUAL_CHANGE_LOG], and [INCIDENT_CONTEXT] respectively. Do not feed raw, unprocessed chat logs directly into the prompt—pre-process them into a structured change log with timestamps, actor, resource ID, action taken, and justification if available.

The implementation should include a pre-processing step that normalizes manual change records into a consistent schema before prompt assembly. Each manual change record should contain: resource_id, change_type (create, modify, delete, restart, scale), property_path, old_value, new_value, timestamp, actor, and justification. This normalization prevents the model from misinterpreting free-form incident notes. After the prompt returns its reconciliation report, a post-processing validator should check that every resource referenced in the report exists in the IaC definition and that no IaC resources were silently omitted. The validator should also flag any reconciliation recommendation that suggests destructive actions (e.g., terraform destroy on a production database) for mandatory human review before execution.

Model choice matters here. Use a model with strong structured reasoning capabilities and a large context window—GPT-4o or Claude 3.5 Sonnet are appropriate starting points. Set temperature=0 to maximize deterministic output for the reconciliation classification. The prompt should be wrapped in a retry loop with a maximum of two retries if the output fails schema validation. Log every invocation with the incident ID, prompt version, model used, and a hash of the input change log for auditability. The reconciliation report should be stored alongside the incident record, not as the sole source of truth. Always require a human platform engineer to review and approve the report before any remediation actions are taken. The highest-risk failure mode is the model recommending reversion of a manual change that was actually a necessary security hardening step applied under duress—human review is the only reliable guard against this.

For teams running in regulated environments, add an evidence-grounding step before prompt invocation. Each manual change record should be linked to a source artifact: an audit log entry, a chat message permalink, or a runbook execution timestamp. The prompt's [INCIDENT_CONTEXT] should include a severity classification and any compliance framework tags (SOC 2, HIPAA, PCI) that constrain remediation options. After the reconciliation report is generated, run a compliance-aware post-check that flags any recommendation which would violate a regulatory control—for example, reverting an encryption enablement change or removing an access restriction. These flagged items should be escalated to a compliance reviewer in addition to the platform engineer. Do not use this prompt for real-time drift detection during an active incident; it is a post-incident analysis tool and will produce unreliable results under time pressure with incomplete information.