Production Trace to Decision-Ready Brief Prompt Template

This prompt is designed for engineering leads and AI program managers who have already completed a technical review of production traces and need to translate those findings into a structured decision document for stakeholders who do not read raw logs. The job-to-be-done is communication, not diagnosis. The ideal input is a set of analyzed findings—such as identified failure modes, tool-call anomalies, latency spikes, or grounding gaps—that have already been extracted and interpreted from trace data. The prompt transforms this technical analysis into a brief that includes a clear problem statement, an evidence summary, evaluated options, and an actionable recommendation, formatted for leadership, product, or cross-functional review.

Use this prompt when the diagnostic work is complete and the audience needs a concise, decision-ready narrative. For example, after an incident responder has correlated multiple traces to isolate a root cause, this prompt can produce the executive summary for the postmortem. After a platform engineer has audited tool-call failures, this prompt can generate the stakeholder-facing report on tool reliability. Do not use this prompt for the initial trace diagnosis itself—it assumes the input is analyzed findings, not raw log data, JSON trace dumps, or uninterpreted metrics. If you need to perform the diagnosis first, use a trace review and diagnosis prompt from the same pillar before handing findings to this template.

The prompt is also inappropriate when the audience requires full forensic detail, such as a security incident report for a red team or a granular latency breakdown for infrastructure engineers. In those cases, use a more specialized trace summarization prompt that preserves lower-level signal. Before running this prompt, confirm that you have: a defined audience, a clear decision the audience needs to make, and analyzed findings that can be mapped to evidence, options, and a recommendation. If any of those are missing, the output will be vague or untethered from production reality.

This prompt template is designed to be the core engine of your trace-to-brief pipeline. It takes a pre-processed analysis of a production trace—including identified anomalies, tool-call failures, or performance regressions—and formats it into a concise document for non-engineering stakeholders. The primary job is to preserve diagnostic truth while translating technical signals into business impact, options, and a clear recommendation. Use this when you have already completed a technical diagnosis and need to communicate findings to a product manager, an executive, or a governance committee. Do not use this prompt for live incident response where second-by-second updates are needed; it is for structured, post-analysis communication.

codeCopy
You are an AI engineering lead translating a technical production trace analysis into a decision-ready brief for a non-technical stakeholder. Your goal is to compress complexity without hiding uncertainty or trade-offs.

## INPUT
[TRACE_ANALYSIS]

## STAKEHOLDER CONTEXT
- Audience: [AUDIENCE_ROLE, e.g., VP of Product, CTO, Compliance Officer]
- Decision they need to make: [DECISION_CONTEXT, e.g., approve a rollback, investigate a cost spike, review a safety incident]
- Time sensitivity: [URGENCY_LEVEL, e.g., High/Medium/Low]

## OUTPUT FORMAT
Generate a structured brief with the following sections. Use clear, jargon-free language.

### 1. Executive Summary
- **Incident/Event:** A one-sentence description of what happened.
- **Business Impact:** A one-sentence summary of the effect on users, revenue, or risk posture.
- **Recommendation:** A single, clear recommended action.

### 2. Problem Statement
- Explain the core issue in plain terms.
- Describe the symptoms observed in production (e.g., increased latency, incorrect outputs, tool failures).
- State the affected scope (e.g., % of users, specific feature, time window).

### 3. Evidence Summary
- Present the top 3-5 key findings from the trace analysis that support the problem statement.
- For each finding, explicitly link it to the conclusion it supports.
- Quantify the evidence where possible (e.g., "error rate spiked from 0.1% to 5.2%").

### 4. Options Analysis
- Provide 2-3 distinct options for addressing the issue.
- For each option, state the expected outcome, level of effort, and risks.
- Clearly separate short-term mitigation from long-term fixes.

### 5. Recommendation and Next Steps
- Reiterate your primary recommendation with a clear rationale.
- List the immediate next steps with owners and timelines if known.
- Define what success looks like after the action is taken.

## CONSTRAINTS
- Do not use technical jargon without a brief, plain-language explanation.
- If the evidence is inconclusive, state that uncertainty directly. Do not overstate confidence.
- If the issue involves a safety, compliance, or PII risk, you MUST include a "Risk and Compliance Note" subsection in the Evidence Summary.
- Keep the entire brief concise; it must be skimmable in under two minutes.

To adapt this template, replace the [TRACE_ANALYSIS] placeholder with the output of your diagnostic prompt or a structured summary of your trace review. The [AUDIENCE_ROLE], [DECISION_CONTEXT], and [URGENCY_LEVEL] variables should be set programmatically based on the alert or report that triggered the briefing workflow. Before putting this into production, run a set of evals that check for logical coherence: every claim in the Evidence Summary must be traceable back to a signal in the input analysis, and the final recommendation must logically follow from the options presented. A common failure mode is the model inventing a plausible-sounding but unsupported root cause; mitigate this by pairing this prompt with a strict evaluation step that verifies evidence-to-conclusion traceability before the brief is sent.

This prompt is designed to be the final transformation step in a trace analysis pipeline, not a standalone chat interaction. The typical harness ingests raw trace data from an observability store, runs diagnostic prompts to extract findings, then feeds those structured findings into this prompt to produce the stakeholder brief. The harness should enforce a strict contract: the prompt receives a [TRACE_FINDINGS] object with pre-validated fields (problem statement, evidence list, affected metrics, timeline), and it must return a JSON object matching the [OUTPUT_SCHEMA] with sections for executive summary, evidence summary, options, and recommendations. Do not pass raw, unprocessed trace logs directly into this prompt—the model will hallucinate structure and miss critical signals.

Wire the prompt into an application function that accepts a validated findings object and returns a parsed brief. Implement a retry loop with a maximum of three attempts: if the output fails JSON schema validation, feed the validation error back into the [CONSTRAINTS] field and retry. Log every invocation with a correlation ID, the input findings hash, the model version, the output brief, and the validation result. For high-stakes briefs (incident postmortems, board reports, SLA breach summaries), route the output to a human review queue before distribution. Use a model with strong instruction-following and structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent). Set temperature=0.2 to balance coherence with consistency. If the prompt is part of a scheduled report generator, cache the findings-to-brief mapping keyed on findings hash to avoid redundant generation when trace data hasn't changed.

Before deploying, build a small eval harness that tests the prompt against five golden examples: a normal trace with clear findings, a trace with ambiguous root cause, a trace with multiple competing hypotheses, a trace with no significant anomalies, and a trace with missing evidence. For each, validate that the output brief correctly preserves the evidence-to-conclusion chain, does not invent facts not present in the findings input, and maintains the appropriate level of abstraction for the stated audience. If the prompt is used in a regulated domain, ensure the human review step is mandatory and auditable. Avoid wiring this prompt into a fully automated distribution pipeline without a review gate—stakeholder briefs carry organizational weight, and an incorrect recommendation can trigger costly decisions.