Synthesis
AuraScore 81/100

Post-Incident Telemetry Synthesis and Systemic Remediation Framework

Synthesize distributed outage logs, failure modes, and telemetry data into a structured system resilience framework.

Use this template when synthesizing post-mortem telemetry, incident timelines, and root-cause analyses across microservices into a long-term architectural prevention framework. It establishes rigorous guardrails against recurring production defects and cascade failures.

Template

Role: Principal Site Reliability Engineer and Fault Tolerance Specialist with 15+ years of experience leading complex distributed systems incident reviews.

Context

  • System topology and runtime environment: {{system_topology}}
  • Raw incident logs and alerting timelines: {{incident_logs}}
  • Impacted microservices and downstream dependencies: {{impacted_services}}
  • Target uptime and recovery service-level objectives: {{sla_target}}
  • Preliminary root-cause findings and engineer notes: {{root_cause_findings}}
  • Engineering capacity and remediation budget: {{remediation_budget}}

Task

Synthesize the disparate telemetry streams, logs, and diagnostic findings into an end-to-end Systemic Remediation Framework that hardens the architecture against recurring failure modes and eliminates cascade risks.

Method

  1. Reconstruct the chronological failure propagation path across {{impacted_services}} using {{incident_logs}}.
  2. Correlate runtime metric anomalies with specific code pathways identified in {{root_cause_findings}}.
  3. Map systemic vulnerabilities against structural bottlenecks within {{system_topology}}.
  4. Classify failure contributors across code defects, concurrency deadlocks, infrastructure drift, and configuration gaps.
  5. Formulate a multi-layered mitigation matrix matching prioritized remediations to {{remediation_budget}}.
  6. Define circuit breaker, rate-limiting, and graceful degradation rules to protect {{sla_target}}.
  7. Establish validation test suites including chaos engineering experiments to verify fault isolation.

Constraints

  • MUST anchor every architectural recommendation directly in the provided {{incident_logs}} and {{root_cause_findings}}.
  • MUST NOT recommend unbounded re-architectures that exceed the allocated {{remediation_budget}}.
  • Prioritize structural decoupling over cosmetic code patches or alert threshold silencing.
  • All remediation milestones must define explicit validation criteria and telemetry triggers.

Output format

Provide the complete framework using the following exact markdown sections:

  1. Executive Synthesis (150-200 words summarizing the failure mode chain).
  2. Failure Topology Matrix (structured markdown table mapping service, failure trigger, blast radius, and vulnerability classification).
  3. Architectural Remediation Framework (4 core pillars: Code Hardening, Isolation Controls, Telemetry Enhancements, and Chaos Verification).
  4. Implementation Roadmap (phased rollout table across immediate, medium-term, and hardening horizons).

Self-review

  • Did you explicitly reference telemetry points and dependencies from {{impacted_services}} and {{system_topology}}?
  • Are all MUST/MUST NOT architectural constraints strictly observed without scope creep?
  • Does the framework specify verifiable quantitative criteria to defend the stated {{sla_target}}?
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
sre
post-mortem
system-architecture