Release Blocker Severity Classification Prompt

This prompt is designed for release managers and SRE teams who need to triage a batch of pre-release findings before a go/no-go decision. Each finding might be a bug, a failing test, a performance regression, a security advisory, or a configuration drift alert. The prompt classifies each finding as P0-blocking, P1-conditional, or P2-waivable based on blast radius, user impact, and fix complexity. It produces a structured triage output with justification and a recommended action, giving you a consistent, evidence-backed severity assessment that can be reviewed by a human before the final call.

To use this prompt effectively, you must provide a list of findings with sufficient context for each: a description of the issue, the affected component or service, any known user-facing impact, and an estimate of fix complexity if available. The prompt works best when findings are already collected from multiple sources—CI failures, security scans, performance benchmarks, manual QA—and need a single, calibrated severity lens applied. You should also supply a [RISK_LEVEL] parameter that reflects your organization's release risk tolerance (e.g., 'conservative' for regulated environments, 'standard' for typical SaaS releases) so the classification thresholds adjust accordingly.

Do not use this prompt for real-time incident triage during an active outage. It is designed for pre-release assessment, not for live incident command where time pressure, incomplete data, and escalating blast radius require a different decision framework. Do not use it as a replacement for human judgment on P0 decisions—the output should always be reviewed by a release authority before blocking a release. Do not use it when findings lack sufficient context; garbage descriptions produce garbage classifications. Finally, do not use it for post-release bug triage, where the decision space shifts from 'should this block the release?' to 'how quickly must we fix this in production?'—that requires a separate triage prompt with different severity criteria and SLA considerations.

This template provides the core classification logic for triaging release findings. It is designed to be pasted directly into your AI system, with square-bracket placeholders replaced by real data at runtime. The prompt enforces a strict severity taxonomy—P0 (blocking), P1 (conditional), and P2 (waivable)—based on blast radius, user impact, and fix complexity. It also requires calibration against historical blocker decisions to reduce inconsistency across releases.

textCopy
You are a release triage classifier. Your job is to assign a blocker severity to each finding in [FINDINGS_LIST] and produce a structured triage output.

## Classification Rules

### P0 – Blocking
Assign P0 when ALL of the following are true:
- Blast radius affects > [BLAST_RADIUS_THRESHOLD]% of users or a critical revenue path.
- User impact includes data loss, security breach, hard crash, or inability to complete a core workflow.
- No viable workaround exists that can be deployed within [WORKAROUND_WINDOW_HOURS] hours.
- Fix complexity is irrelevant; P0 is about impact, not effort.

### P1 – Conditional
Assign P1 when ANY of the following are true:
- Blast radius affects [P1_BLAST_MIN]%–[BLAST_RADIUS_THRESHOLD]% of users.
- User impact is significant degradation (e.g., slow performance, missing non-critical feature) but core workflows remain functional.
- A viable workaround exists but requires manual intervention or customer communication.
- Fix complexity is high, and the risk of introducing a worse regression is non-trivial.

### P2 – Waivable
Assign P2 when ALL of the following are true:
- Blast radius affects < [P1_BLAST_MIN]% of users or is limited to an internal tool.
- User impact is cosmetic, informational, or affects a non-GA feature behind a disabled flag.
- A documented workaround exists or the issue self-resolves (e.g., cache expiry).
- Fix can be safely deferred to the next release without SLA violation.

## Calibration
Before finalizing each classification, compare the finding against [HISTORICAL_BLOCKER_EXAMPLES]. If a similar finding was classified differently in the past, explain the discrepancy and justify the current decision.

## Output Schema
Return a JSON object with the following structure:
{
  "findings": [
    {
      "finding_id": "string",
      "severity": "P0 | P1 | P2",
      "justification": {
        "blast_radius_assessment": "string",
        "user_impact_assessment": "string",
        "workaround_availability": "string",
        "fix_complexity_note": "string"
      },
      "recommended_action": "BLOCK_RELEASE | CONDITIONAL_APPROVAL | WAIVE_AND_TRACK",
      "calibration_note": "string or null",
      "confidence": "HIGH | MEDIUM | LOW"
    }
  ],
  "summary": {
    "total_findings": number,
    "p0_count": number,
    "p1_count": number,
    "p2_count": number,
    "overall_recommendation": "BLOCK | CONDITIONAL | PROCEED"
  }
}

## Constraints
- Do not reclassify a finding without explicit evidence from the finding description.
- If blast radius or user impact data is missing, set confidence to LOW and recommend human review.
- Never downgrade a security vulnerability below P1 without a security team override.
- For any P0 classification, include a direct link to the evidence in the justification.

To adapt this template, replace the square-bracket placeholders with your release context. [FINDINGS_LIST] should contain the structured or semi-structured findings from your test runs, static analysis, manual QA, or incident reports. [BLAST_RADIUS_THRESHOLD] and [P1_BLAST_MIN] should reflect your service's user base and risk tolerance—for a consumer app with 10M users, 1% might be blocking; for an internal tool, 20% might be acceptable. [HISTORICAL_BLOCKER_EXAMPLES] should include 5–10 real past decisions with their final severity and rationale. This calibration section is the single most important factor for consistency across releases. Before deploying this prompt to production, run it against a golden set of 20–30 previously classified findings and measure exact-match accuracy on severity labels. If accuracy drops below 90%, review whether your thresholds are too ambiguous or your historical examples are contradictory.

This prompt is designed to sit inside a release gating pipeline, not as a standalone chat interaction. The typical integration point is a CI/CD release stage or a release manager's triage dashboard. When a release candidate is assembled, all open findings—from static analysis, test failures, security scans, dependency advisories, and manual QA—are collected into a structured payload and passed to the prompt. The model classifies each finding as P0-blocking, P1-conditional, or P2-waivable, producing a structured triage output that downstream automation or human reviewers can act on. The prompt expects findings with fields like finding_id, source, description, affected_component, detected_at, and any available evidence or reproduction_steps. If your finding source doesn't provide these fields, add a normalization layer before the prompt call—don't expect the model to invent missing context reliably.

Validation and output enforcement are critical because the classification output drives release gates. After the model responds, validate the JSON structure against a strict schema: every finding must have a severity field constrained to P0-blocking, P1-conditional, or P2-waivable, a non-empty justification, and a recommended_action. If validation fails, retry once with the validation error injected into the prompt context. If the second attempt fails, escalate the finding to a human triage queue rather than silently defaulting to a lower severity. For high-risk domains—safety-critical systems, financial transaction paths, healthcare data pipelines—require human approval on all P0-blocking classifications before the release gate is enforced. Log every classification decision with the model version, prompt version, input finding hash, and output classification for auditability.

Calibration against historical decisions is the most important ongoing maintenance task. Maintain a golden dataset of 50–100 findings that were manually triaged by experienced release managers, covering edge cases like false-positive security scanner results, known flaky tests, and intentional breaking changes with migration paths. Run this dataset through the prompt weekly or on every prompt change, and track precision and recall per severity class. P0 recall is the metric that matters most: a missed blocker is far more expensive than an over-classified P2. If P0 recall drops below 0.95, freeze the prompt in production and investigate. Model choice matters here—use a model with strong reasoning capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent) rather than a smaller classifier model, because severity decisions require weighing blast radius, user impact, and fix complexity together. For cost-sensitive pipelines, consider routing P2-obvious findings to a cheaper model and reserving the full prompt for ambiguous or high-risk findings.

Tool integration can strengthen the classification by providing the model with runtime context it can't infer from the finding description alone. If your infrastructure supports it, give the model access to a get_service_dependencies tool that returns the dependency graph for an affected component, a get_recent_incidents tool that returns incidents linked to the same component in the last 30 days, and a get_test_coverage tool that returns coverage percentages for modified paths. The prompt template includes a [TOOLS] placeholder for tool definitions. When tools are available, instruct the model to call them before finalizing P0 vs P1 decisions where blast radius is unclear. If tools aren't available, the prompt should still produce useful output, but flag findings where tool access would have increased confidence. Never let the model hallucinate tool results—validate that every tool-cited fact in the justification appears in the actual tool response.

Retry and fallback logic should be explicit in your harness. If the model returns a malformed response, retry with the original prompt plus the validation error and a stronger format instruction. If the model refuses to classify (rare but possible with safety-tuned models on findings that mention vulnerabilities), log the refusal and escalate to human review immediately—do not retry with softened language that might suppress a legitimate safety concern. If the model exceeds a latency threshold (suggest 10 seconds for a batch of findings), fall back to a simpler classification heuristic based on keyword matching and source severity, and flag the release for manual review. The prompt is a decision-support tool, not an autonomous gate—the release manager always retains override authority, and the harness should make overrides easy to record with a reason.