Reporting
AuraScore 83/100

Error Budget Burn and Root-Cause Blast Radius Reporting Framework

Establish a post-mortem reporting framework to evaluate error budget exhaustion, blast radius, and system safeguards.

Use this template following a major system outage or continuous error budget burn to produce an architectural incident report that isolates cascading failure modes and validates automated safeguards.

Template

Role: Principal Distributed Systems Architect and Reliability Lead.

Context

  • Target infrastructure cluster: {{architecture_cluster_env}}
  • Quarterly error budget consumption rate: {{error_budget_burn_rate}}
  • Failure domain subsystem: {{root_cause_subsystem}}
  • Cumulative outage duration: {{outage_duration_minutes}}
  • Core ingestion pipeline: {{data_pipeline_id}}
  • Validated remediation commit: {{mitigation_commit_hash}}

Task

Author an error budget burn and root-cause blast radius reporting framework that enables distributed systems teams to analyze catastrophic outages, quantify system availability burn in {{architecture_cluster_env}}, and document structural safeguards.

Method

  1. Calculate systemic availability impact against SLOs based on {{outage_duration_minutes}} of downtime.
  2. Determine the multi-window burn rate accelerating {{error_budget_burn_rate}} across the cluster.
  3. Trace the cascading failure path originating within {{root_cause_subsystem}} through {{data_pipeline_id}}.
  4. Quantify downstream blast radius including dropped messages, dead-letter queue overflow, and state corruption.
  5. Validate that {{mitigation_commit_hash}} resolves underlying deadlock, race condition, or memory leak triggers.
  6. Formulate defensive architectural patterns such as circuit breakers, backpressure valves, and degraded mode fallbacks.
  7. Structure an executive and engineering post-mortem reporting protocol that translates system telemetry into reliability commitments.

Constraints

  • MUST establish a timeline with sub-second granularity for the initial trigger event in {{root_cause_subsystem}}.
  • MUST NOT classify human operator error as a primary root cause; reports must isolate systemic and architectural gaps.
  • All financial or data-loss impact metrics MUST explicitly correlate to {{data_pipeline_id}} throughput.
  • Output MUST contain actionable architectural changes that directly address the mechanism validated in {{mitigation_commit_hash}}.

Output format

  1. Incident Reliability Summary (max 100 words, including total availability loss).
  2. Timeline and Blast Radius Mapping (chronological table: Timestamp, System State, Subsystem Impact, Ingestion Loss).
  3. Architectural Vulnerability Deep-Dive (analysis of failure mechanisms in {{root_cause_subsystem}}).
  4. Reliability Action Plan & Guardrails (prioritized table: Action Item, Engineering Owner, Verification Metric).

Self-review

  • Check that the timeline requirements explicitly forbid operator blame and enforce systemic root cause analysis.
  • Verify that {{architecture_cluster_env}} and {{mitigation_commit_hash}} are embedded in the remediation criteria.
  • Ensure the output strictly follows the four numbered sections without omitting the blast radius mapping table.
AuraScore breakdown
83/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.

Robustness5/5 · Strong

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

data-analytics
data-reporting
software-engineering-debugging
error-budget
post-mortem
incident-reporting