ADR Risk Assessment Prompt

This prompt is for architects and engineering leads who need to surface and document the risks associated with a specific architecture decision before it is finalized. The job-to-be-done is disciplined risk surfacing, not general brainstorming. You should have a draft decision, a set of options, or a proposed architecture change already on the table. The prompt expects you to provide the decision context, the chosen or proposed option, and any constraints you are operating under. It then produces a structured risk register with likelihood, impact, mitigation options, and an explicit acceptance rationale that can be reviewed, challenged, and archived alongside the ADR.

Use this prompt when the decision is concrete enough to analyze but not yet immutable. Ideal inputs include a draft ADR, a design document, or a technical proposal with a clear option selected. The prompt works best when you supply specific architectural details—such as the components involved, data flow, and operational boundaries—rather than abstract project goals. Do not use this prompt for organizational risks, personnel risks, or roadmap-level business risks that fall outside the scope of a single architecture decision. It is also not a substitute for a security threat model or a formal failure modes and effects analysis (FMEA), though its output can feed into those processes.

Before running this prompt, gather the decision context, the proposed approach, any rejected alternatives, and known constraints such as latency budgets, compliance requirements, or team capabilities. The prompt will ask you to review the generated risk register for omissions and overconfidence in mitigation claims. After receiving the output, you should validate it against your own engineering judgment, add any missing risks, and ensure the acceptance rationale is honest about residual risk. The final risk register should be appended to the ADR as a living section that is revisited if the decision's context changes.

This prompt template is designed to receive a draft or finalized Architecture Decision Record (ADR) and produce a structured risk assessment. It forces the model to identify risks across multiple categories, estimate likelihood and impact, propose concrete mitigations, and state an explicit acceptance rationale. The output is a machine-readable risk register that can be validated, stored alongside the ADR, and reviewed by a human before the decision is finalized.

textCopy
You are a senior systems architect and risk analyst. Your task is to perform a structured risk assessment on the provided Architecture Decision Record (ADR).

## INPUT
[ADR_DOCUMENT]

## CONSTRAINTS
- Identify risks across these categories: Technical, Operational, Security, Cost, Schedule, Team/Organizational, and Compliance.
- For each risk, provide a likelihood rating (Low, Medium, High) and an impact rating (Low, Medium, High).
- For each risk rated Medium or higher in either dimension, propose at least one concrete mitigation.
- State an explicit acceptance rationale for each risk that will not be fully mitigated.
- Do not invent risks not supported by the ADR text. If a category has no identifiable risks, state "No risks identified in this category."
- Do not claim certainty where evidence is missing. Use language like "based on the ADR," "appears to," or "may."

## OUTPUT_SCHEMA
Return a single JSON object with the following structure:
{
  "decision_title": "string",
  "risk_assessment_date": "string (ISO 8601)",
  "overall_risk_posture": "Low Risk | Medium Risk | High Risk | Critical Risk",
  "risks": [
    {
      "risk_id": "string (e.g., RISK-001)",
      "category": "Technical | Operational | Security | Cost | Schedule | Team/Organizational | Compliance",
      "description": "string",
      "likelihood": "Low | Medium | High",
      "impact": "Low | Medium | High",
      "mitigations": ["string"],
      "acceptance_rationale": "string or null if fully mitigated"
    }
  ],
  "omission_notes": ["string (risks that might exist but are not documented in the ADR)"]
}

## EXAMPLES
[OPTIONAL_FEW_SHOT_EXAMPLES]

## RISK_LEVEL
[HIGH_RISK_THRESHOLD_DEFINITION]

Adaptation guidance: Replace [ADR_DOCUMENT] with the full text of the ADR under review. The [OPTIONAL_FEW_SHOT_EXAMPLES] placeholder can be populated with one or two example risk assessments from your organization's past ADRs to calibrate the model's severity judgment. The [HIGH_RISK_THRESHOLD_DEFINITION] placeholder should contain your team's definition of what constitutes a High or Critical risk posture—for example, "Any risk with High likelihood and High impact, or any unmitigated security risk." After running this prompt, validate the output JSON against the schema before storing it. For regulated environments, always route the output to a human reviewer before the ADR is accepted.

The ADR Risk Assessment prompt is designed to be called programmatically as part of an architecture review pipeline, not as a one-off chat interaction. The harness should treat this prompt as a structured risk extraction step that runs after an ADR draft exists but before final approval. The prompt expects a complete ADR document as [ADR_DOCUMENT] and an optional [SYSTEM_CONTEXT] describing the broader architecture, team constraints, or regulatory environment. The output is a JSON risk register with likelihood, impact, mitigation options, and acceptance rationale for each identified risk. The harness must validate this output before it reaches a reviewer or is stored in the ADR repository.

Validation and Schema Enforcement: The harness must validate the model's JSON output against a strict schema before accepting it. Required fields per risk entry include risk_id, description, category (from a controlled enum: security, reliability, performance, cost, operability, compliance, dependency, team_capability), likelihood (enum: low, medium, high, critical), impact (same enum), mitigation_options (array of strings, minimum one entry), and acceptance_rationale (string explaining why the residual risk is acceptable or must be escalated). If the model omits required fields, returns invalid enum values, or produces an empty risk register when the ADR describes a consequential decision, the harness should retry with a more explicit instruction appended to the prompt. After two failed retries, escalate to a human reviewer with the raw output and validation errors logged. Retry Logic: On validation failure, append a structured error message to the prompt context: The previous output failed validation. Missing fields: [list]. Invalid enum values: [list]. Please regenerate the complete risk register with all required fields. This error-feedback loop significantly improves recovery rates for schema violations.

Model Choice and Temperature: Use a model with strong structured output capabilities and low temperature (0.0–0.2) to minimize variance in risk identification. The risk assessment task benefits from deterministic behavior because reviewers need consistent outputs across multiple ADRs for comparability. If your platform supports structured output modes (e.g., function calling with a JSON schema parameter, or constrained decoding), prefer that over parsing free-text JSON from a chat completion. Human Review Gate: This prompt addresses high-stakes architectural decisions where missed risks can cause production incidents, data loss, or compliance failures. The harness must route every output through a human review step before the risk register is attached to the ADR. The review interface should display each risk with its mitigation options and allow the reviewer to accept, reject, reclassify, or add risks the model missed. Log all reviewer actions for auditability. Integration Points: Store validated risk registers alongside their source ADRs in your documentation repository with a traceable link. If your team uses an ADR management tool or static site generator, the harness should write the risk register as a supplementary file (e.g., adr-0042-risks.json) and update the ADR's status metadata to indicate risk assessment is complete. For CI/CD integration, treat a missing or empty risk register on a high-severity ADR as a pipeline warning, not a hard block, to avoid slowing urgent decisions while still flagging the gap.

What to avoid: Do not run this prompt on ADRs that document trivial or reversible decisions where the cost of risk assessment exceeds the cost of being wrong. Do not treat the model's likelihood and impact ratings as objective ground truth—they are starting points for human judgment. Do not skip the human review gate for decisions affecting security, data integrity, compliance, or system availability. The harness should classify ADRs by decision criticality (using metadata like impact_scope or regulatory_relevance) and only bypass human review for low-criticality decisions where the risk register is advisory. Finally, log every prompt invocation with the ADR version, model response, validation result, retry count, and reviewer actions. This trace data is essential for improving the prompt over time and for audit evidence when a risk that was assessed later materializes.