AI System Reliability Summary Prompt Template

This prompt is designed for AI program managers and engineering leads who must prepare board-level reliability reports from production trace data. The core job-to-be-done is transforming aggregated observability metrics—such as availability percentages, error budget consumption rates, incident frequencies, and SLO adherence—into a structured executive summary suitable for governance review. The ideal user has access to pre-aggregated trace data from platforms like Datadog, Grafana, or an internal trace warehouse, and needs to communicate system health without overwhelming non-technical stakeholders with raw diagnostic detail.

Use this prompt when you have already run aggregate queries over your production traces and need to synthesize the results into a decision-ready brief. The required inputs include [AVAILABILITY_METRICS], [ERROR_BUDGET_DATA], [INCIDENT_TIMELINE], and [SLO_COMPLIANCE_REPORT]. The output is a structured narrative with a clear executive summary, trend analysis, and risk assessment. This prompt is not suitable for real-time incident response, raw trace debugging, or engineering-level root-cause analysis. Those workflows require different prompts with finer diagnostic granularity, such as the Incident Root-Cause Summary Prompt Template or the Tool-Call Failure Summary Prompt Template.

Before using this prompt, ensure your input data has been validated for metric accuracy and completeness. The prompt includes a validation step that cross-checks reported availability against error budget consumption to catch inconsistencies before the summary reaches a board deck. If your trace data contains unresolved anomalies or you lack confidence in the aggregation, run a diagnostic prompt from the Trace Review and Diagnosis Prompts group first. Do not use this prompt to invent metrics or smooth over data gaps; the governance audience requires an honest representation of system health, including uncertainty and known blind spots.

This prompt template is designed to synthesize pre-computed reliability metrics into an executive summary suitable for governance audiences. It expects structured input data—not raw trace logs—and applies strict abstraction rules to ensure the output is decision-ready without burying stakeholders in operational detail. The template enforces a clear separation between factual metric reporting and interpretive commentary, and it includes explicit uncertainty language for any metric that falls outside defined confidence thresholds.

textCopy
You are an AI program manager preparing a board-level reliability summary. Your audience is a governance committee that needs to understand system health, risk exposure, and trend direction without operational detail.

## INPUT DATA
[METRICS_JSON]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "executive_summary": "string (3-5 sentence narrative of overall health)",
  "availability": {
    "current_slo": "string (e.g., 99.95%)",
    "target_slo": "string",
    "trend": "improving | stable | degrading",
    "breach_risk": "none | watch | imminent"
  },
  "error_budget": {
    "consumed_pct": "number",
    "remaining_pct": "number",
    "exhaustion_estimate": "string (date or 'N/A')",
    "largest_consumer": "string (category name)"
  },
  "incident_summary": {
    "total_incidents_period": "number",
    "severity_breakdown": {
      "critical": "number",
      "major": "number",
      "minor": "number"
    },
    "top_failure_mode": "string",
    "mean_time_to_resolve_minutes": "number"
  },
  "top_risks": [
    {
      "risk": "string",
      "severity": "high | medium | low",
      "trend": "increasing | stable | decreasing",
      "mitigation_status": "string"
    }
  ],
  "recommendations": ["string (actionable, prioritized)"],
  "data_confidence": "high | medium | low",
  "confidence_notes": "string (explain any gaps or estimation methods)"
}

## CONSTRAINTS
1. Do not invent metrics. If a value is missing from [METRICS_JSON], omit that field rather than estimating.
2. Use plain language. Replace technical terms like 'hallucination rate' with 'factual accuracy issues'.
3. For any trend claim, cite the comparison period from the input data.
4. If error budget consumption exceeds 80%, set breach_risk to 'imminent' and flag in executive_summary.
5. Limit recommendations to a maximum of 5 items, ordered by impact.
6. If data_confidence is 'low', the executive_summary must begin with a caveat about data quality.
7. Round all percentages to two decimal places.
8. Do not speculate about root causes unless explicitly provided in [METRICS_JSON].

## RISK_LEVEL
[HIGH] — This output may inform board-level decisions about resource allocation, SLA commitments, and regulatory reporting. Human review is required before distribution.

To adapt this template, replace [METRICS_JSON] with a structured object containing your pre-aggregated trace metrics. The input should include availability percentages, error budget consumption, incident counts by severity, failure mode frequencies, and any known risks with mitigation status. If your observability pipeline does not produce all these fields, the prompt will safely omit missing sections rather than fabricate data. Before sending this output to stakeholders, validate the JSON structure against the schema, confirm that trend directions match the underlying numbers, and have a human reviewer check that the executive summary accurately reflects the data without overstating confidence.

This prompt is designed to run as a single-turn generation call, not a multi-step agent workflow. Wire it into your reporting pipeline as a scheduled job or on-demand trigger that feeds structured trace data into the model and routes the output to a review queue. The primary integration points are: a data aggregation layer that queries your observability platform for the required metrics, a prompt assembly step that injects the aggregated data into the [TRACE_METRICS] placeholder, and a post-generation validation layer that checks the output before it reaches stakeholders.

Before calling the model, validate that the input data is complete. The prompt requires availability percentages, error budget consumption, incident counts, and trend signals. If any required field is null or outside expected ranges, abort the generation and log a data-quality error rather than producing a misleading summary. After generation, run a structured output validator to confirm the response contains the required sections (Executive Summary, Availability & SLOs, Error Budget, Incident Trends, Recommendations) and that any claimed metrics match the input data within a 1% tolerance. For board-level reports, always route the generated summary to a human reviewer. Implement a retry strategy with a maximum of two attempts: if the first output fails validation, append the validation errors to the retry prompt as [CONSTRAINTS] and request a corrected version. If the second attempt also fails, escalate to a human operator with the raw trace data and both failed generations attached.

Choose a model with strong instruction-following and structured output capabilities, such as GPT-4o or Claude 3.5 Sonnet. Set temperature to 0.2 or lower to maximize consistency across report generations. Log every generation attempt, including the input metrics, the raw model response, validation results, and the final reviewer decision. This audit trail is essential for governance reviews and for debugging when a stakeholder questions a metric. Avoid using this prompt for real-time operational alerts; it is designed for periodic summary reports, not incident response. For latency-sensitive use cases, pair it with a lighter-weight prompt that triggers pager notifications.