Event Replay and Recovery Plan Prompt

This prompt is for platform engineers and SREs who need to design or review a recovery plan for replaying events from a log, queue, or stream. The job-to-be-done is producing a structured analysis of replay safety, ordering guarantees, consumer impact, and side-effect risk before an incident forces an unplanned replay. Use this prompt when you are introducing a replay capability to an existing event-driven system, auditing a replay plan after a dead-letter queue (DLQ) overflow, or preparing a runbook for disaster recovery scenarios. The ideal user has access to event schema definitions, consumer group topologies, idempotency key strategies, and retention window configurations.

Do not use this prompt for real-time incident response where seconds matter—this is a design-time review, not a live triage tool. It is also inappropriate for systems where events are purely ephemeral with no retention log, or where replay is handled entirely by an external managed service with no consumer-side coordination required. The prompt assumes you have already decided that replay is architecturally possible; it does not evaluate whether your system should be event-sourced in the first place. If you lack concrete details about consumer idempotency behavior or retention policies, the output will be speculative and should be flagged for human review before any operational use.

Before running this prompt, gather your event envelope schema, consumer group inventory, current retention window settings, and any existing runbook documentation. The prompt will produce a plan that identifies gaps in idempotency coverage, replay ordering risks, and side-effect duplication scenarios. After receiving the output, validate any critical claims about data loss or corruption risk against your actual infrastructure configuration. For high-risk systems where replay errors could cause financial or compliance impact, require a second human reviewer to sign off on the plan before it enters a runbook.

The following prompt template is designed to be copied directly into your AI harness. It instructs the model to act as a platform architecture reviewer, analyzing your event replay and recovery plan against a comprehensive set of criteria. The template uses square-bracket placeholders for all system-specific inputs, ensuring you can adapt it without altering the core evaluation logic. Before using it, gather the required context: your system's architecture diagram or description, the current replay procedure, and any known constraints like retention windows or consumer SLAs.

codeCopy
You are a senior platform engineer specializing in event-driven architectures. Your task is to conduct a rigorous review of an event replay and recovery plan for the system described below. Your analysis must be structured, actionable, and identify failure modes that could lead to data loss, inconsistency, or extended downtime.

## System Context
[SYSTEM_ARCHITECTURE_DESCRIPTION]

## Current Replay and Recovery Plan
[REPLAY_PROCEDURE_DOCUMENTATION]

## Review Constraints
- Retention Window: [RETENTION_PERIOD_IN_DAYS]
- Consumer SLAs: [CONSUMER_SLA_DESCRIPTION]
- Idempotency Strategy: [IDEMPOTENCY_IMPLEMENTATION_DETAILS]
- Risk Level: [RISK_LEVEL]

## Required Output
Produce a structured review in the following JSON format:
{
  "executive_summary": "A concise summary of the plan's overall readiness and the top 3 risks.",
  "replay_ordering_assessment": {
    "strategy": "Description of the ordering strategy (e.g., by timestamp, by offset).",
    "risks": ["List of risks, such as out-of-order processing causing invalid state."],
    "recommendation": "A specific recommendation to mitigate ordering risks."
  },
  "idempotency_review": {
    "coverage": "Assessment of whether all consumers are idempotent for the duration of the replay window.",
    "gaps": ["List of specific consumers or operations that are not idempotent."],
    "recommendation": "A strategy to handle non-idempotent consumers during replay (e.g., side-effect journaling, dry-run mode)."
  },
  "consumer_impact_analysis": {
    "affected_consumers": ["List of all consumer groups impacted by a replay."],
    "stale_data_risk": "Analysis of the risk that consumers will act on stale data during the replay.",
    "throttling_strategy": "Recommendation for throttling the replay to avoid overwhelming consumers."
  },
  "side_effect_duplication_check": {
    "high_risk_operations": ["List of operations with external side effects (e.g., sending emails, charging credit cards)."],
    "mitigation": "For each high-risk operation, propose a specific mitigation, such as a replay-safe wrapper or manual approval gate."
  },
  "failure_mode_analysis": [
    {
      "failure_scenario": "A specific failure scenario (e.g., broker failure mid-replay).",
      "impact": "The blast radius of the failure.",
      "recovery_procedure": "Step-by-step instructions to recover from this failure."
    }
  ],
  "overall_recommendation": "APPROVED | NEEDS REVISION | REJECTED with a clear justification."
}

## Evaluation Criteria
- **Completeness:** The plan must cover all critical failure scenarios.
- **Safety:** The plan must prevent data corruption and unintended side effects.
- **Operability:** The plan must be executable by an on-call engineer under stress.

To adapt this template, replace each square-bracket placeholder with your system's specifics. For [SYSTEM_ARCHITECTURE_DESCRIPTION], provide a high-level overview of your event broker, producers, and consumers. For [REPLAY_PROCEDURE_DOCUMENTATION], paste your existing runbook. If a placeholder like [IDEMPOTENCY_IMPLEMENTATION_DETAILS] is unknown, state 'Unknown' to force the model to flag it as a critical gap. The [RISK_LEVEL] field should be set to HIGH, MEDIUM, or LOW to calibrate the review's intensity. The output schema is a strict JSON contract, making it suitable for direct parsing in an automated CI/CD pipeline or an operational dashboard. After receiving the output, always validate the JSON structure before acting on its recommendations.

This prompt is designed to be integrated into a pre-replay review gate, not a fully autonomous recovery system. Before an operator or an automated pipeline initiates a replay of events from a dead letter queue, archive, or primary log, this prompt should be invoked with the replay plan details. The output serves as a structured risk assessment that a human on-call engineer or a release manager must acknowledge before execution. The harness should therefore treat the model's output as a decision-support artifact, not as an execution command.

To wire this into an application, build a lightweight review service that accepts a replay plan object containing fields like source_topic, target_consumer_group, start_timestamp, end_timestamp, estimated_event_count, replay_reason, and idempotency_strategy. The service should populate the prompt's [REPLAY_PLAN_DETAILS] placeholder with a structured JSON or YAML representation of this object. After receiving the model's response, the harness must parse the output against a strict schema that includes a risk_level enum (LOW, MEDIUM, HIGH, CRITICAL), a list of failure_modes with severity ratings, and a boolean requires_manual_approval field. If the model's output fails schema validation, retry once with a repair prompt that includes the validation error. If it fails again, escalate to a human operator and log the failure for prompt debugging.

For high-risk domains such as financial transaction replays or healthcare event recovery, the harness must enforce a hard human-in-the-loop step. Even if the model returns requires_manual_approval: false, the system should require an explicit approval action from an authorized operator when the risk_level is HIGH or CRITICAL. Log the full prompt, the model's response, the validator result, and the human approval decision to an audit trail. This prompt is best used with a model that supports structured output or function calling, such as GPT-4o or Claude 3.5 Sonnet, to guarantee schema compliance. Do not use this prompt with a base model that lacks instruction-following or JSON mode, as the failure mode analysis requires precise, structured reasoning that weaker models will hallucinate or omit.