Evidence-Based Go/No-Go Memo Prompt

This prompt is designed for QA managers, release coordinators, and engineering leads who must produce a formal, auditable go/no-go recommendation memo for a software release. The primary job-to-be-done is synthesizing multiple structured quality signals—test results, open defect lists, coverage reports, performance metrics, and operational readiness indicators—into a single, defensible document where every conclusion is explicitly linked to supplied evidence. Use this prompt when the decision must survive post-release review, an audit, or an incident postmortem, and when stakeholders outside the immediate engineering team (such as compliance officers or VP-level decision-makers) need to trace the rationale back to specific data points.

The prompt assumes you have structured, machine-readable quality signals ready to feed in as variables. Required inputs include a test execution summary with pass/fail counts, a list of open defects with severity and affected components, a coverage gap analysis, and any relevant operational signals such as SLO compliance or incident history. The prompt is not designed to interpret raw logs, unstructured chat threads, or sparse dashboards. If your input data is too thin to support evidence-backed claims—for example, you have only a gut feeling and a few Slack messages—this prompt will either produce weak, caveat-heavy output or fabricate connections to satisfy its instructions. In those cases, use a lighter-weight triage prompt or invest in gathering structured signals first.

Do not use this prompt for informal team communication, real-time dashboard commentary, or as a substitute for a live release war room discussion. It is a document-generation tool, not a conversational advisor. The output is a formal memo meant to be read, signed off on, and archived. After generating the memo, you should validate that every recommendation is traceable to a specific piece of input evidence, check for hallucinated defect IDs or metrics, and route the memo through a human approval workflow before it becomes the official release decision record. If your release process requires a weighted scorecard or a conditional go framework instead of a narrative memo, use the sibling prompts designed for those specific output structures.

The prompt below is designed to produce a defensible, auditable release decision memo. It forces the model to link every recommendation to specific evidence, flag dissenting signals, and state confidence levels explicitly. Before using it, gather your release data: test results, open defect lists, coverage reports, performance test summaries, security scan findings, and any incident history relevant to the release window. The prompt works best when you provide concrete data rather than summaries of summaries.

textCopy
You are a QA release auditor producing an evidence-based go/no-go memo for a software release. Your memo must be traceable, defensible, and suitable for post-release review. Every recommendation must cite specific evidence. Do not invent data.

## INPUT DATA
[RELEASE_CONTEXT]
[TEST_RESULTS_SUMMARY]
[OPEN_DEFECTS_LIST]
[COVERAGE_REPORT]
[PERFORMANCE_TEST_RESULTS]
[SECURITY_SCAN_FINDINGS]
[INCIDENT_HISTORY]
[ADDITIONAL_RISK_SIGNALS]

## OUTPUT SCHEMA
Produce a JSON object with this exact structure:
{
  "memo_metadata": {
    "release_id": "string",
    "assessment_date": "YYYY-MM-DD",
    "assessor_role": "QA Release Auditor",
    "confidence_level": "high|medium|low"
  },
  "recommendation": {
    "decision": "GO|NO-GO|CONDITIONAL-GO",
    "rationale_summary": "One-paragraph summary of the primary reasoning"
  },
  "evidence_assessment": [
    {
      "signal_type": "test_results|defects|coverage|performance|security|incidents|other",
      "finding": "Specific finding from the data",
      "source_reference": "Where in the input data this finding comes from",
      "supports": "GO|NO-GO|NEUTRAL",
      "confidence": "high|medium|low",
      "caveats": "Any limitations or uncertainty about this evidence"
    }
  ],
  "dissenting_signals": [
    {
      "signal": "Evidence that contradicts the primary recommendation",
      "source_reference": "Where this dissenting signal originates",
      "why_overruled": "Explanation of why this signal did not change the overall decision"
    }
  ],
  "residual_risk_summary": {
    "top_risks": ["Risk 1", "Risk 2"],
    "unresolved_items": ["Item that remains open or uncertain"],
    "mitigation_in_place": ["Mitigation already deployed or planned"],
    "acceptance_rationale": "Why the residual risk is acceptable if recommending GO"
  },
  "conditions": [
    {
      "condition": "Specific condition that must be met",
      "verification_method": "How to verify the condition is satisfied",
      "deadline": "When this must be verified",
      "if_unmet": "What happens if the condition is not met"
    }
  ],
  "assumptions": ["Assumption 1 made during assessment", "Assumption 2"]
}

## CONSTRAINTS
- Every evidence_assessment entry must include a source_reference pointing to specific input data.
- If the input data is insufficient to assess a signal_type, state that explicitly with confidence "low" and explain what data is missing.
- Dissenting_signals must not be empty. If no dissenting signals exist, explain why the evidence is unanimously aligned.
- For CONDITIONAL-GO decisions, conditions array must be non-empty with concrete, verifiable conditions.
- Do not recommend GO if any open defect has severity "critical" and no documented mitigation.
- State all assumptions explicitly. If you must assume something not in the input data, flag it.

## RISK LEVEL
[RISK_LEVEL]

Adaptation guidance: Replace each square-bracket placeholder with your actual release data. The [RELEASE_CONTEXT] should include the release name, version, scope, and any business constraints (e.g., regulatory deadlines). For [RISK_LEVEL], set it to high, medium, or low based on the blast radius of this release—this adjusts how conservative the model's recommendation threshold should be. If you lack data for a section (e.g., no security scan was run), leave the placeholder empty or state "Not available" rather than removing the section, so the model can flag the gap explicitly. The output is structured JSON suitable for ingestion into a release management dashboard or audit trail system. Before trusting the output, validate that every source_reference actually exists in your input data and that no findings were hallucinated.

This prompt is not a casual chatbot interaction. It is a decision-support tool that feeds a downstream release governance process. The implementation harness must treat the prompt output as a structured artifact that passes through validation, enrichment, and human approval before it influences a release decision. The goal is to produce an auditable memo where every recommendation is traceable to specific evidence, and where the system refuses to fabricate confidence when inputs are missing or contradictory.

Wire the prompt into a release pipeline that assembles the required inputs programmatically. The [TEST_RESULTS_SUMMARY], [OPEN_DEFECT_LIST], [COVERAGE_REPORT], [INCIDENT_HISTORY], and [DEPENDENCY_STATUS] placeholders should be populated from test management systems, defect trackers, coverage tools, incident databases, and dependency manifests—not from free-text user recall. Before calling the model, run a pre-validation step that checks for missing or stale inputs. If any required evidence source is absent, do not call the prompt; instead, surface a blocking input gap to the release coordinator. After the model returns the memo, run a structured output validator that confirms the JSON schema, checks that every recommendation has at least one linked evidence reference, and flags any confidence level above 'Medium' that lacks supporting quantitative data. If validation fails, retry once with a repair prompt that includes the specific validation errors. If the retry also fails, escalate to a human reviewer with the partial output and error details attached.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities, such as Claude 3.5 Sonnet or GPT-4o, with a low temperature setting (0.1–0.2) to reduce variance in the decision language. Enable structured output mode if the model supports it, providing the exact memo schema as a JSON Schema constraint rather than relying solely on the prompt's [OUTPUT_SCHEMA] description. Log every prompt invocation, the assembled inputs, the raw model output, validation results, and the final human decision in an immutable audit store. This trace is essential for post-release reviews, especially when a release decision is later questioned. Never allow the prompt output to automatically trigger a deployment gate. The memo must always pass through a human release manager who reviews the evidence alignment, challenges unsupported conclusions, and signs off on the final recommendation. The system should present the memo alongside a diff view showing which inputs were used, which were missing, and where the model's confidence diverges from historical release outcomes.