Synthesis
AuraScore 81/100

Distributed Outage Telemetry Synthesis and Resilience Roadmap

Synthesize multi-service incident telemetry and root-cause data into an actionable engineering resilience and hardening plan.

Use this template when recovering from complex distributed system failures or multi-service outages. It consolidates disparate telemetry, post-mortems, and team constraints into a phased reliability remediation roadmap.

Template

Role: Staff Site Reliability Engineer with twelve years of experience in distributed tracing, incident command, and fault-tolerant cloud architecture.

Context

  • Observability and log excerpts: {{incident_telemetry_logs}}
  • Impacted microservices ecosystem: {{affected_services}}
  • Discovered failure modes and triage notes: {{root_cause_findings}}
  • Target Service Level Objectives: {{target_slo_metrics}}
  • Engineering team availability: {{engineering_squad_capacity}}
  • Production risk boundaries: {{risk_tolerance_threshold}}

Task

Synthesize the disparate post-incident telemetry and triage findings into an exhaustive, phased Reliability Remediation Plan that eliminates systemic single points of failure without exceeding operational constraints.

Method

  1. Cross-reference {{incident_telemetry_logs}} against {{affected_services}} to establish the exact cascade sequence and latency blast radius.
  2. Categorize all items in {{root_cause_findings}} into architectural, configurational, environmental, or human-process defects.
  3. Evaluate the gap between the degradation profile and required {{target_slo_metrics}}.
  4. Prioritize engineering interventions based on recurrence likelihood and impact severity within the limits of {{risk_tolerance_threshold}}.
  5. Map technical mitigations (circuit breakers, dead-letter queues, backoff strategies, isolation bulkheads) to each identified failure node.
  6. Group remediation tasks into three distinct horizons: immediate stabilization, structural refactoring, and automated observability hardening.
  7. Calibrate task allocations against {{engineering_squad_capacity}} to ensure sprint feasibility.
  8. Formulate definitive rollback and verification triggers for every proposed deployment phase.

Constraints

  • MUST prioritize preventative structural changes over superficial alerting tweaks.
  • MUST NOT recommend greenfield rewrites where tactical patterns (such as rate limiters or caching tiers) achieve {{target_slo_metrics}}.
  • Every proposed task must cite specific evidence from {{incident_telemetry_logs}} or {{root_cause_findings}}.
  • Deliverable must remain purely technical and actionable for senior engineering teams.

Output format

Present the final deliverable as a structured remediation plan containing:

  1. Executive Incident Synthesis (200-250 words summarizing the cascading failure).
  2. Critical Root-Cause Breakdown Table (Columns: Subsystem, Failure Mechanism, Impact Score, Recommended Fix).
  3. Phased Implementation Roadmap (Divided into Immediate [Sprint 1-2], Medium-term [Sprint 3-6], and Long-term Architecture).
  4. Verification & Chaos Testing Plan (Bullet-pointed validation scenarios per phase).

Self-review

  • Confirm that every service mentioned in {{affected_services}} has an explicit mitigation.
  • Verify all recommendations fit within {{engineering_squad_capacity}}.
  • Ensure no ambiguous actions like "improve logging" appear without precise metric targets.
AuraScore breakdown
81/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering12/12 · Strong

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

research-analysis
research-synthesis
software-engineering-debugging
site-reliability
post-mortem
distributed-systems