Debugging
AuraScore 79/100

Core Settlement Engine Post-Mortem Dispatch

Draft an executive post-mortem email detailing root-cause debugging and containment for a critical transaction settlement failure.

Use this template when an asynchronous settlement engine or order matching system encounters high-severity transactional failures in a production banking environment. It guides engineering leaders in communicating technical root cause, state reconstruction, and regulatory safeguards directly to executive stakeholders.

Template

Role: Principal Infrastructure Reliability Engineer specializing in ultra-low latency settlement architectures.

Context

  • Target System: {{trading_system_name}}
  • Incident Window: {{incident_timestamp}}
  • Observed Telemetry & Symptoms: {{observed_failure_symptom}}
  • Root Cause Discovery: {{root_cause_technical_details}}
  • Regulatory Compliance Scope: {{regulatory_reporting_scope}}
  • Mitigation & Rollback Status: {{immediate_mitigation_applied}}

Task

Draft an authoritative technical post-mortem email for senior leadership and compliance officers, detailing the exact debugging sequence, underlying failure mechanism, system restoration verification, and long-term architectural remediations.

Method

  1. Translate {{observed_failure_symptom}} into an executive-level summary of operational and capital impact.
  2. Detail the systematic debugging path taken across distributed logs, thread dumps, and memory profiling that uncovered {{root_cause_technical_details}}.
  3. Deconstruct the underlying state corruption or lock contention failure within {{trading_system_name}}.
  4. Explain how {{immediate_mitigation_applied}} restored deterministic state and verified idempotency across pending transaction queues.
  5. Detail the audit ledger reconciliation status according to the constraints in {{regulatory_reporting_scope}}.
  6. Outline a prioritized three-tier engineering roadmap to eliminate this defect class.
  7. Provide an open technical Q&A schedule and contact matrix for impacted desk heads.

Constraints

  • MUST express all timestamps in UTC and currency values in standardized ISO formats.
  • MUST NOT expose sensitive customer personally identifiable information or raw cryptographic secrets.
  • MUST differentiate explicitly between transient network anomalies and deterministic logic bugs.
  • Keep the overall email body under 650 words while preserving technical rigor.

Output format

Send-ready executive email composed of:

  1. Subject Line: High-severity incident identifier, system name, and status tag.
  2. Executive Summary (max 100 words).
  3. Technical Diagnostic Timeline (bulleted chronology of discovery and isolation).
  4. Root Cause Anatomy (in-depth explanation of bug mechanics).
  5. Remediation & Verification State (bulleted actions completed).
  6. Regulatory & Audit Footprint.
  7. Next Steps & Incident Review Schedule.

Self-review

  1. Are all references to {{trading_system_name}} and {{regulatory_reporting_scope}} technically precise?
  2. Does the debugging narrative clearly distinguish between symptom and root cause?
  3. Is the tone sufficiently objective, accountable, and transparent for compliance oversight?
AuraScore breakdown
79/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 engineering10/12 · Adequate

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.

developers
developers-debugging
financial-services
debugging
post-mortem
fintech