Concurrency Bug Impact Analysis Prompt

This prompt is for engineering managers, SREs, and on-call engineers who need to assess the blast radius of a concurrency bug that has been discovered in a codebase. It is designed to be used after a bug has been identified and its mechanics are understood, but before a fix is deployed. The goal is to produce a structured impact assessment that answers: what is affected, how badly, and who needs to know. Use this prompt when you need a consistent, evidence-backed analysis to inform rollback decisions, customer communication, and remediation prioritization.

The prompt requires a documented bug mechanism as input—you must already know the race condition, deadlock scenario, or unsafe interleaving before invoking this analysis. Provide the affected code paths, concurrency primitive involved, reproduction conditions, and any available production telemetry (error rates, latency spikes, corrupted records). The output is a structured impact report covering affected components, data integrity risks, user-facing symptoms, dependent service blast radius, and estimated customer exposure. This report feeds directly into incident severity classification and stakeholder communication templates.

Do not use this prompt for initial bug detection or root cause analysis; it assumes the bug's mechanism is already documented. It is also not a replacement for runtime debugging tools, thread analyzers, or formal verification. The analysis is only as good as the evidence you provide—if production telemetry is missing or reproduction conditions are uncertain, the prompt will flag those gaps rather than fabricate certainty. For high-severity bugs affecting customer data or financial transactions, always pair the AI-generated impact assessment with human review from a senior engineer familiar with the affected system before communicating externally or making irreversible remediation decisions.

This prompt template is designed to be pasted directly into your AI harness, LLM playground, or automated incident analysis pipeline. It takes a structured description of a concurrency bug—including affected code paths, symptoms, and environment details—and produces a standardized impact assessment. The output is intended for engineering managers, SREs, and product owners who need to understand the severity, scope, and customer exposure of a race condition or deadlock before committing to a fix timeline.

codeCopy
You are a senior SRE conducting a blast-radius analysis of a confirmed concurrency bug. Your task is to produce a structured impact assessment that engineering leadership can use to prioritize remediation.

## Bug Report
[BUG_DESCRIPTION]

## Affected Code Paths
[AFFECTED_CODE_PATHS]

## Observed Symptoms
[OBSERVED_SYMPTOMS]

## Environment Context
- Service/Component: [SERVICE_NAME]
- Deployment Region(s): [REGIONS]
- Traffic Volume: [TRAFFIC_VOLUME]
- Concurrency Model: [CONCURRENCY_MODEL]
- Recent Deployments: [RECENT_DEPLOYMENTS]

## Output Schema
Return a JSON object with the following structure. Do not include any text outside the JSON.
{
  "severity": "CRITICAL|HIGH|MEDIUM|LOW",
  "affected_components": [
    {
      "component": "string",
      "impact_type": "DATA_CORRUPTION|SERVICE_DEGRADATION|INCORRECT_RESULTS|CRASH|RESOURCE_EXHAUSTION",
      "impact_description": "string"
    }
  ],
  "data_integrity_risk": {
    "risk_level": "PERMANENT_CORRUPTION|TRANSIENT_INCONSISTENCY|NO_RISK",
    "affected_data_stores": ["string"],
    "recovery_possible": true,
    "recovery_notes": "string"
  },
  "customer_exposure": {
    "exposure_type": "ALL_USERS|USER_SEGMENT|INTERNAL_ONLY|NONE",
    "estimated_affected_percentage": "number (0-100)",
    "visible_symptoms_to_users": ["string"],
    "data_loss_possible": true
  },
  "dependent_services": [
    {
      "service": "string",
      "failure_mode": "CASCADING_FAILURE|STALE_DATA|TIMEOUT|RETRY_STORM|NONE"
    }
  ],
  "reproducibility": "ALWAYS|INTERMITTENT|RARE|UNKNOWN",
  "exploitability": "EASILY_TRIGGERED|SPECIFIC_CONDITIONS|UNLIKELY",
  "recommended_actions": [
    {
      "action": "string",
      "urgency": "IMMEDIATE|WITHIN_HOURS|NEXT_BUSINESS_DAY|NEXT_SPRINT",
      "type": "ROLLBACK|HOTFIX|CONFIG_CHANGE|TRAFFIC_DRAIN|COMMUNICATION|MONITORING"
    }
  ],
  "confidence": "HIGH|MEDIUM|LOW",
  "unknowns": ["string"]
}

## Constraints
- Base your analysis only on the provided bug report and code paths. Do not invent symptoms or affected services not mentioned.
- If information is insufficient to determine a field, set confidence to LOW and list the missing information in "unknowns".
- For severity, use CRITICAL only if data corruption is permanent and affects all users.
- Distinguish between transient inconsistency (self-healing) and permanent corruption (requires data repair).
- Consider cascading failure modes: retry storms, connection pool exhaustion, and deadlock propagation.

To adapt this template, replace the square-bracket placeholders with data from your incident tracking system, bug report, or on-call handoff notes. The [BUG_DESCRIPTION] should include the exact race condition or deadlock mechanism, not just the symptom. The [AFFECTED_CODE_PATHS] field works best when you paste specific file paths and function names from stack traces or profiling data. For production use, wire this prompt into an incident management bot that auto-populates fields from your monitoring stack and enforces the JSON schema with a post-generation validator. Always require human review for CRITICAL severity assessments before they reach an executive summary.

This prompt is designed to be called programmatically as part of an incident response or bug triage pipeline, not as a one-off chat interaction. The primary integration point is a webhook or API call triggered when a concurrency bug is confirmed in production or flagged during a pre-merge review with high severity. The application layer must assemble the required inputs—bug description, affected code paths, service topology, and recent deployment or traffic data—before invoking the model. Because the output directly informs severity classification, customer communication, and rollback decisions, the harness must enforce strict validation and a human-in-the-loop approval step before any downstream action is taken.

To wire this into an application, construct a request object that maps to the prompt's square-bracket placeholders. The [BUG_DESCRIPTION] should be a structured object containing the symptom, reproduction conditions, and first observed timestamp. [AFFECTED_CODE_PATHS] should be a list of file paths, function signatures, and the concurrency primitives involved, sourced from your code intelligence platform. [SERVICE_DEPENDENCY_MAP] requires a machine-readable graph of upstream and downstream services, ideally pulled from your service catalog or distributed tracing system. [DEPLOYMENT_HISTORY] should include recent commits, feature flags, and config changes within the window of the bug's first appearance. The harness should validate that all required fields are non-empty and that timestamps are within a reasonable range before sending the prompt. If any input is missing, the system should return a clear error to the operator rather than hallucinating an incomplete analysis.

After the model returns its structured impact assessment, the harness must run a validation layer before the output reaches a human reviewer. First, validate the JSON schema against the expected [OUTPUT_SCHEMA]—reject any response missing the affected_components, data_integrity_risk, or customer_exposure_estimate fields. Second, run a grounding check: every claimed affected component must map to an entry in the input [SERVICE_DEPENDENCY_MAP]. If the model cites a service not present in the input, flag it for hallucination and either retry with a stricter constraint or escalate. Third, implement a confidence threshold; if the model's self-reported confidence score falls below a configurable limit (e.g., 0.7), route the analysis for mandatory senior engineer review rather than auto-publishing to the incident channel. Log every input, output, validation result, and reviewer decision for post-incident audit and prompt improvement.

For model choice, prefer a model with strong reasoning capabilities and a large context window, as the combined input of code paths, service maps, and deployment history can exceed 8K tokens. Claude 3.5 Sonnet or GPT-4o are suitable defaults. Set the temperature low (0.1–0.2) to maximize consistency in the structured output. Implement a retry strategy with exponential backoff (1s, 2s, 4s) for up to three attempts on validation failures, but stop retrying if the same hallucinated component appears twice—this indicates a grounding failure that requires prompt or input refinement, not a transient error. Finally, never use the model's output to automatically trigger a rollback or page customers. The harness must always insert a human approval step, presenting the validated impact assessment alongside a clear 'Approve / Reject / Request More Info' action in your incident management tool.