ADR Summary Prompt for Executives

This prompt is designed for a single, high-stakes translation task: converting a completed, approved Architecture Decision Record (ADR) into a concise executive summary. The primary user is an engineering lead, architect, or technical program manager who must communicate a technical decision upward to a VP, CTO, or board member. The job-to-be-done is not to create a new decision or to re-litigate the technical trade-offs, but to faithfully compress an existing, detailed document into a business-impact narrative. The ideal input is a fully drafted ADR that has already passed technical peer review and contains clear sections for context, options considered, rationale, and consequences.

Use this prompt when the source ADR is stable and the audience needs to understand the business implications, risks, timeline effects, and resource commitments without implementation details. It is appropriate for decisions that affect budget, team structure, product roadmap, or operational risk. The prompt includes explicit controls for tone and abstraction level, instructing the model to avoid technical jargon, implementation specifics, and deep architectural rationale. Instead, it focuses on the decision itself, the problem it solves, the cost and risk trade-offs, and the expected business outcomes. Do not use this prompt to generate an ADR from scratch, to summarize a decision that is still under debate, or to replace the full ADR for an engineering audience that needs the technical details.

Before using this prompt, confirm that the source ADR is complete and approved. If the ADR is missing key sections like 'options considered' or 'consequences,' the summary will be hollow and potentially misleading. The prompt is not a substitute for stakeholder communication; it is a drafting aid that produces a first version for human review and editing. In high-risk or regulated environments, always have a human review the summary for accuracy and tone before distribution. The output should be treated as a communication draft, not a binding record. For the binding record, always link back to the full ADR.

This template is designed to be copied directly into your prompt layer or AI harness. It instructs the model to act as a senior architect communicating upward, compressing a full ADR into a format suitable for CTOs, VPs, and non-technical stakeholders. The prompt enforces a strict output schema, a professional tone, and explicit handling of uncertainty. Before using it, ensure you have the complete ADR text and a clear understanding of your audience's primary concerns (e.g., budget, timeline, risk, strategic alignment).

codeCopy
You are a Staff Software Architect preparing an executive summary for a non-technical leadership team. Your summary must be accurate, concise, and focused on business impact, not implementation details.

**Input ADR:**
[FULL_ADR_TEXT]

**Audience Context:**
[AUDIENCE_CONCERNS]

**Output Schema (JSON):**
{
  "title": "string (a clear, business-oriented title for the decision)",
  "decision_summary": "string (a 2-3 sentence plain-English summary of what was decided and why)",
  "strategic_alignment": "string (1-2 sentences on how this supports a business goal or strategy)",
  "key_impact": {
    "timeline": "string (impact on delivery dates or milestones, use 'None' if no impact)",
    "cost": "string (impact on budget, infrastructure, or licensing, use 'None' if no impact)",
    "teams": "string (teams or roles affected and how, use 'None' if no impact)",
    "risk_posture": "string (how this changes the system's risk profile: increased, decreased, or unchanged, and why)"
  },
  "top_risks": [
    {
      "risk": "string (a specific, material risk introduced or accepted by this decision)",
      "mitigation": "string (the planned mitigation or acceptance rationale)"
    }
  ],
  "rejected_alternatives_summary": "string (a brief summary of the main alternatives considered and why they were rejected, in business terms)",
  "required_actions": ["string (a concrete next step or action item for leadership or teams)"],
  "confidence_level": "string (High/Medium/Low, with a one-sentence justification)"
}

**Constraints:**
- Write for a time-constrained executive audience. Avoid all technical jargon, acronyms, and code references.
- The 'top_risks' array must contain only risks with a material business impact. If there are no material risks, return an empty array.
- If the source ADR does not contain information for a field, use 'Not specified in source ADR' rather than inventing content.
- The tone must be neutral and factual, not promotional or defensive.

To adapt this template, replace the [FULL_ADR_TEXT] placeholder with the complete markdown or plain text of your Architecture Decision Record. The [AUDIENCE_CONCERNS] placeholder should be filled with a brief, bulleted list of what your specific leadership team cares about most—for example, 'Current focus: cloud cost reduction, Q4 delivery deadlines, and SOC 2 audit preparation.' This context dramatically improves the relevance of the summary. For high-stakes decisions, always route the final output for human review before distribution, and consider running an automated evaluation to check that the output JSON strictly conforms to the schema and contains no undefined jargon.

This prompt is designed to be integrated into an architecture review pipeline, not used as a one-off chat interaction. The primary integration point is after an ADR has been drafted and reviewed, when an architect or engineering lead needs to communicate the decision upward. The harness must enforce that the input ADR is complete and approved before the summary is generated, preventing the model from summarizing incomplete or unreviewed decisions that could mislead executives.

Implement a pre-generation validation step that checks the [INPUT] ADR for required sections: context, decision, options considered, trade-offs, and consequences. If any required section is missing or empty, reject the request and return a structured error asking the user to complete the ADR before generating an executive summary. Use a lightweight schema validator in your application layer before the prompt is assembled. For model selection, prefer models with strong instruction-following and tone control (GPT-4o, Claude 3.5 Sonnet) rather than smaller models that may drift into technical detail or fail to maintain executive-appropriate abstraction. Set temperature to 0.2 or lower to reduce stylistic variance across repeated runs on the same ADR.

Post-generation, run two automated evals before the summary reaches a human. First, a tone and abstraction check: verify the output contains no implementation details, code references, or jargon not defined in plain language. Use a secondary LLM call with a rubric that scores the summary on a 1-5 scale for executive readability; reject scores below 4 and trigger a retry with explicit tone feedback appended to the prompt. Second, a factual consistency check: extract every claim from the summary and verify it is grounded in the source ADR. Flag any claim not directly supported by the input for human review. Log every generation attempt, validation result, and retry for auditability. For high-risk decisions (security architecture, data privacy, compliance-affecting changes), enforce a human-in-the-loop approval step before the summary is distributed. The reviewer should confirm both factual accuracy and audience appropriateness before the summary reaches any executive stakeholder.