Policy Update Failure Mode Analysis Prompt

This prompt is for reliability engineers, AI operations teams, and platform engineers who own production assistant behavior. It forces the model to act as an adversarial analyst conducting a structured pre-mortem on a proposed policy update. The job-to-be-done is not deployment approval—it is failure mode discovery. You bring the proposed system prompt diff, the current production prompt, and your known failure history. The model returns a ranked register of what can break, how each failure will surface in production, what detection mechanisms exist, and what containment strategies are available. This output informs your go/no-go decision but does not make it.

Use this prompt when you are changing behavioral rules, role boundaries, refusal policies, tool-use authorization, instruction priority, or any system-level constraint that affects how the assistant responds to users. It is particularly valuable before policy migrations that touch multiple behaviors simultaneously, before rolling out a new system prompt version to production traffic, and after an incident where you need to verify that a proposed fix does not introduce new failure modes. The prompt works best when you provide concrete before-and-after policy text, known edge cases from production logs, and the specific deployment environment context. Do not use this prompt for trivial wording changes, for prompts that have no production exposure, or as a substitute for actual canary testing and production monitoring.

The output is a structured failure mode register with severity rankings, not a binary safe/unsafe verdict. You should expect the model to identify failures you have not considered, but you should also expect false positives—the model may flag risks that your specific architecture, tooling, or user base makes irrelevant. Always review the output with engineering judgment. Pair this analysis with your existing regression test suite, canary deployment plan, and rollback procedures. If the analysis surfaces high-severity failures without adequate detection mechanisms, pause the deployment until you have instrumented the necessary observability. This prompt reduces the risk of silent policy regressions but does not eliminate the need for staged rollout and production validation.

This prompt template is designed to be pasted directly into your orchestration layer, evaluation harness, or manual review workflow. It forces the model to act as a reliability engineer conducting a failure mode and effects analysis (FMEA) on a proposed policy update. The template uses square-bracket placeholders for all dynamic inputs, ensuring you can parameterize it for any system prompt change in your pipeline. Before using this template, ensure you have a clear diff between the current and proposed system instructions, an understanding of the deployment environment, and a defined risk tolerance for the product surface this policy governs.

textCopy
You are a senior site reliability engineer specializing in AI system behavior. Your task is to conduct a structured pre-mortem failure mode analysis on a proposed system instruction (policy) update.

## INPUTS
[CURRENT_SYSTEM_PROMPT]
[PROPOSED_SYSTEM_PROMPT]
[DEPLOYMENT_CONTEXT]: Description of the product, user base, tool access, and environment.
[RISK_TOLERANCE]: The organization's risk tolerance for this surface (e.g., 'low: safety-critical', 'medium: customer-facing product', 'high: internal tool').
[CONSTRAINTS]: Any specific areas of concern, regulatory requirements, or known brittle behaviors to examine.

## ANALYSIS REQUIREMENTS
For each identified failure mode, provide:
1. **Failure Description**: What specifically breaks and under what conditions.
2. **Trigger Conditions**: The user inputs, tool outputs, or conversation states that activate the failure.
3. **Manifestation**: How the failure appears to users, operators, or downstream systems.
4. **Detection Mechanism**: How this failure would be caught in production (e.g., specific metric, log pattern, user report).
5. **Severity Ranking**: Critical, High, Medium, or Low, justified against the provided risk tolerance.
6. **Containment Strategy**: Immediate action to limit blast radius if detected (e.g., feature flag, rollback, circuit breaker).
7. **Mitigation Priority**: P0 (must fix before deploy), P1 (fix soon after deploy), P2 (accept risk, monitor).

## OUTPUT FORMAT
Return a JSON object with the following structure:
{
  "analysis_metadata": {
    "change_summary": "One-sentence summary of the policy change.",
    "overall_risk_assessment": "Safe to proceed | Proceed with caution | Do not deploy",
    "critical_failure_modes_count": 0,
    "top_mitigation_recommendation": "Primary action before deployment."
  },
  "failure_modes": [
    {
      "id": "FM-001",
      "failure_description": "string",
      "trigger_conditions": "string",
      "manifestation": "string",
      "detection_mechanism": "string",
      "severity": "Critical | High | Medium | Low",
      "severity_justification": "string",
      "containment_strategy": "string",
      "mitigation_priority": "P0 | P1 | P2"
    }
  ]
}

## ANALYSIS INSTRUCTIONS
- Focus on behavioral regressions, safety policy gaps, instruction conflicts, and multi-turn degradation.
- Consider adversarial inputs that exploit ambiguity between the old and new instructions.
- Evaluate tool-use authorization changes if the system prompt governs tool access.
- Flag any removal of refusal conditions or safety boundaries.
- If no critical or high-severity failure modes are found, explicitly state why the change is low-risk.

To adapt this template, replace each square-bracket placeholder with concrete values from your change management pipeline. The [DEPLOYMENT_CONTEXT] should include whether the assistant has tool access, the user population, and the product surface. The [RISK_TOLERANCE] field calibrates the severity rankings—a failure that is 'Medium' for an internal tool may be 'Critical' for a healthcare application. After running the analysis, validate the JSON output against the schema before ingesting it into your release gate. If the overall_risk_assessment returns 'Do not deploy' or any failure mode is ranked Critical with a P0 mitigation, block the release and require human review of the specific failure modes before proceeding.

This prompt is designed to run as a gated pre-mortem step in a policy change management pipeline, not as an ad-hoc chat. The analysis it produces should block or conditionally approve a system prompt rollout. Wire it into your CI/CD or release management system so that every proposed system instruction diff triggers this analysis before it reaches canary or production. The prompt expects a structured diff of the policy change, the current system prompt, and the target deployment environment as inputs. The output is a structured failure mode register that downstream automation and human reviewers can act on.

Integration pattern: When a policy change PR is opened, a pipeline job extracts the diff and current prompt, formats them into the [POLICY_DIFF] and [CURRENT_SYSTEM_PROMPT] placeholders, sets [DEPLOYMENT_CONTEXT] to the target environment (e.g., production-us-east-1, canary-eu), and sends the assembled prompt to a capable reasoning model. Parse the JSON output and validate it against the expected schema: each failure mode must have a severity score, detection mechanism, and containment strategy. If the output fails schema validation, retry once with a repair prompt that includes the validation errors. If it fails again, escalate to a human reliability engineer and block the release.

Human approval gate: Do not auto-approve a policy change based solely on this analysis. Route the parsed failure mode register to a review queue (e.g., a Jira ticket or Slack approval workflow) where an on-call SRE or AI safety engineer must acknowledge each critical or high severity finding before the deployment proceeds. The approval UI should display the failure mode description, severity, and proposed mitigation side by side. Log the full prompt input, raw model output, parsed register, and reviewer decision to an audit trail for post-incident review. Model selection: Use a model with strong reasoning and structured output capabilities (e.g., Claude 3.5 Sonnet, GPT-4o). Avoid smaller or faster models here—this is a safety-critical analysis where thoroughness matters more than latency.

What to avoid: Do not run this prompt on every minor wording change; gate it on diffs that touch behavioral constraints, refusal rules, tool authorization, or instruction priority. Do not treat the model's severity ratings as ground truth—they are advisory inputs to human judgment. Do not skip the schema validation step; malformed JSON in this workflow can silently drop failure modes from the review queue. Finally, ensure the [DEPLOYMENT_CONTEXT] is specific enough that the model can reason about environment-specific risks (e.g., tenant isolation, data residency, model version differences). A vague context like production produces vague analysis.