Multi-Region Consistency Verification Prompt

This prompt is for infrastructure and reliability engineers who need to verify that data, configuration, or application state is consistent across multiple regions after a replication change, deployment, or failover event. The job-to-be-done is a post-action verification step: you have already collected state snapshots from two or more regions and now need a structured, diffable report to declare the system consistent before resuming normal operations. The ideal user is an SRE, platform engineer, or DBA who understands the replication topology and can gather raw state data but wants the model to perform the analytical comparison, flagging replication lag, data conflicts, and missing records.

Use this prompt only when you have complete, pre-collected state snapshots from each target region. The prompt assumes the raw data is already gathered and formatted for comparison; it does not connect to live systems, run queries, or perform real-time monitoring. It is a verification gate, not a monitoring tool. This workflow is appropriate for scheduled consistency checks after a maintenance window, a failover test, or a replication topology change. Do not use this prompt for continuous real-time drift detection, as it lacks the timing precision and stateful connection required for operational monitoring. For real-time checks, integrate a dedicated observability pipeline and use this prompt only for point-in-time human-reviewed verification.

Before executing this prompt, ensure you have defined your consistency tolerances. The prompt's value depends on clear constraints: acceptable replication lag windows, conflict resolution rules, and a definition of what constitutes a 'missing' versus 'delayed' record. Without these, the model will apply generic heuristics that may not match your system's operational reality. After receiving the output, a human must review any flagged discrepancies before taking corrective action. This prompt is a decision-support tool, not an autonomous remediator. The next step is to wire the output into your incident review or change approval process, not directly into an automated rollback pipeline.

This prompt template is designed to be copied directly into your AI harness. It expects structured input describing the expected state, observed state across multiple regions, and your specific consistency requirements. Replace every [PLACEHOLDER] with data from your infrastructure tooling—such as Terraform state outputs, AWS Config rules, or custom observability queries—before sending it to the model. The prompt is engineered to produce a structured comparison report, not a conversational summary, so it can be parsed by downstream automation.

codeCopy
You are an infrastructure verification agent. Your task is to compare the expected state of a multi-region deployment against the observed state in each region and produce a structured consistency report.

## INPUT

### EXPECTED STATE
[EXPECTED_STATE]

### OBSERVED STATE PER REGION
[OBSERVED_STATE_PER_REGION]

### CONSISTENCY REQUIREMENTS
[CONSISTENCY_REQUIREMENTS]

### REPLICATION TOPOLOGY
[REPLICATION_TOPOLOGY]

### EVENTUAL CONSISTENCY WINDOW
[EVENTUAL_CONSISTENCY_WINDOW]

## OUTPUT SCHEMA

Return a JSON object with the following structure:
{
  "report_id": "string",
  "generated_at": "ISO8601 timestamp",
  "overall_status": "consistent | inconsistent | partially_consistent",
  "regions": [
    {
      "region_id": "string",
      "status": "consistent | lagging | divergent | unreachable",
      "drifted_resources": [
        {
          "resource_id": "string",
          "expected_value": "string",
          "observed_value": "string",
          "drift_type": "missing | extra | value_mismatch | stale",
          "severity": "critical | warning | informational"
        }
      ],
      "lag_seconds": "number | null",
      "last_sync_timestamp": "ISO8601 timestamp | null"
    }
  ],
  "conflicts": [
    {
      "resource_id": "string",
      "conflict_type": "write_conflict | split_brain | ordering_violation",
      "regions_involved": ["string"],
      "description": "string",
      "recommended_resolution": "string"
    }
  ],
  "remediation_summary": "string",
  "requires_human_review": "boolean"
}

## CONSTRAINTS
- Compare every resource in EXPECTED_STATE against every region in OBSERVED_STATE_PER_REGION.
- If a resource is missing from a region and the last sync timestamp is older than the EVENTUAL_CONSISTENCY_WINDOW, classify it as `stale`, not `missing`.
- Flag any region where two or more regions show divergent values for the same resource as a `split_brain` conflict.
- If any region is unreachable, set its status to `unreachable` and exclude it from conflict detection.
- Set `requires_human_review` to `true` if any conflict has severity `critical` or if `overall_status` is `inconsistent`.
- Do not invent resource IDs or values. Only reference data present in the input.

## EXAMPLES

### Example 1: Consistent State
Input:
EXPECTED_STATE: { "resources": { "vpc-abc": { "cidr": "10.0.0.0/16" } } }
OBSERVED_STATE_PER_REGION: { "us-east-1": { "vpc-abc": { "cidr": "10.0.0.0/16" } }, "eu-west-1": { "vpc-abc": { "cidr": "10.0.0.0/16" } } }
CONSISTENCY_REQUIREMENTS: "exact_match"
REPLICATION_TOPOLOGY: "active-active"
EVENTUAL_CONSISTENCY_WINDOW: "30s"

Output:
{
  "overall_status": "consistent",
  "regions": [
    { "region_id": "us-east-1", "status": "consistent", "drifted_resources": [], "lag_seconds": 0 },
    { "region_id": "eu-west-1", "status": "consistent", "drifted_resources": [], "lag_seconds": 0 }
  ],
  "conflicts": [],
  "requires_human_review": false
}

### Example 2: Lag Within Window
Input:
EXPECTED_STATE: { "resources": { "sg-xyz": { "rules": ["allow-443"] } } }
OBSERVED_STATE_PER_REGION: { "us-east-1": { "sg-xyz": { "rules": ["allow-443"] } }, "ap-southeast-1": { "sg-xyz": { "rules": ["allow-80"] } } }
CONSISTENCY_REQUIREMENTS: "exact_match"
REPLICATION_TOPOLOGY: "active-passive"
EVENTUAL_CONSISTENCY_WINDOW: "300s"
LAST_SYNC_AP_SOUTHEAST_1: "2025-01-01T00:04:00Z"
CURRENT_TIME: "2025-01-01T00:05:00Z"

Output:
{
  "overall_status": "partially_consistent",
  "regions": [
    { "region_id": "us-east-1", "status": "consistent", "drifted_resources": [] },
    { "region_id": "ap-southeast-1", "status": "lagging", "drifted_resources": [{ "resource_id": "sg-xyz", "drift_type": "stale", "severity": "warning" }], "lag_seconds": 60 }
  ],
  "conflicts": [],
  "requires_human_review": false
}

## INSTRUCTIONS
Analyze the input and return only the JSON object conforming to OUTPUT_SCHEMA. Do not include explanatory text outside the JSON.

To adapt this template, replace each placeholder with data from your infrastructure stack. [EXPECTED_STATE] should contain your Infrastructure-as-Code definition or desired configuration in a structured format (JSON works best). [OBSERVED_STATE_PER_REGION] should be populated by querying each region's control plane or state store immediately before invoking the prompt. [CONSISTENCY_REQUIREMENTS] can be a string like "exact_match" or a more detailed policy object. [REPLICATION_TOPOLOGY] should describe your architecture (e.g., "active-active", "active-passive", "multi-leader"). [EVENTUAL_CONSISTENCY_WINDOW] is the maximum acceptable replication lag in seconds. The examples demonstrate how the model should handle lag within the window versus true divergence. Wire the output JSON into a post-processing step that triggers alerts or opens a ticket if requires_human_review is true.

Before deploying, validate that your input data is complete and that the model's output conforms to the schema. A common failure mode is the model hallucinating resource IDs when the observed state is empty; the constraint to only reference input data mitigates this. For high-risk environments, always route outputs with requires_human_review: true to a human operator and log the full prompt and response for audit. Do not use this prompt for real-time transaction consistency (e.g., database row-level checks); it is designed for infrastructure configuration state, not application data integrity.

This prompt is designed to be called by an automation system—such as a post-replication hook, a scheduled consistency job, or an incident response runbook—not by a human typing into a chat window. The harness must supply structured, machine-readable inputs for each region's state snapshot and enforce a strict output schema so that downstream systems can parse the comparison report without manual interpretation. The primary integration points are a data collection layer that gathers region state (e.g., row counts, checksums, last-write timestamps, replication lag metrics) and a decision layer that acts on the verification result.

Input assembly: Before calling the model, collect the following for each region: a region identifier, a timestamped snapshot of key metrics (record counts, checksums, lag in seconds), and any known replication topology context (e.g., primary-region, async-replication). Format these as a JSON object matching the [REGION_STATE] placeholder. Include a [CONSISTENCY_WINDOW_SECONDS] parameter that defines the acceptable eventual-consistency threshold. The [OUTPUT_SCHEMA] placeholder should contain a strict JSON schema requiring: a per-region comparison matrix, a conflict_detected boolean, a lag_violations array of regions exceeding the window, and a recommended_action enum of proceed, hold, or escalate. Validation layer: After the model responds, validate the output against this schema. If parsing fails, retry once with the validation error injected into the [CONSTRAINTS] field. If the second attempt also fails, log the raw output and escalate to a human with a review_queue ticket containing the input snapshots and both failed responses.

Model choice and tool use: This task requires strong structured-output adherence and low hallucination on numeric comparisons. Use a model that supports strict JSON mode or function calling with a defined tool schema matching your output contract. Do not rely on free-text generation. If your infrastructure supports it, provide a calculator tool for checksum and lag comparisons rather than asking the model to perform arithmetic. Retry and escalation logic: If the model returns conflict_detected: true or recommended_action: escalate, the harness should automatically create a human-review ticket with the full comparison report, raw region snapshots, and a pre-populated severity field. Do not allow the automation to proceed past a conflict flag without human acknowledgment. Logging and audit: Log every invocation with the input snapshots, model response, validation result, and escalation decision. This audit trail is critical for post-incident review and for tuning the consistency window threshold over time.

What to avoid: Do not use this prompt for real-time transactional consistency checks where milliseconds matter—this is for near-real-time or periodic verification of eventually consistent systems. Do not skip the output schema validation step; a malformed JSON response that passes a visual check can still break downstream automation. Finally, do not treat the model's recommended_action as an executable command. The harness should treat it as a recommendation that requires a deterministic rule evaluation (e.g., if conflict_detected is true, always escalate regardless of the recommendation string).