Freeze Exception Request Evaluation Prompt

This prompt is designed for a formal change advisory board (CAB), AI release managers, and governance teams who must evaluate a structured request to modify a system prompt that has already been frozen. A system prompt freeze is a stability gate: once declared, the instructions are treated as a production contract, and any change—no matter how small—introduces regression risk, behavioral drift, and potential downstream failures. The job-to-be-done is not to decide if a change is a good idea in isolation, but to produce a consistent, auditable, and evidence-backed evaluation that the CAB can use to approve, deny, or conditionally approve the exception. The evaluator using this prompt is acting as an impartial analyst, not as the change requester or the system prompt author.

To use this prompt effectively, you must provide a complete exception request package. This includes the frozen system prompt text, the proposed modification with a clear diff, a business or technical justification from the requester, a risk self-assessment, and any relevant production monitoring data or regression test results. The prompt is engineered to detect common failure patterns in exception requests: urgency inflation (where a routine improvement is framed as a critical fix), workaround blindness (where the requester hasn't explored alternatives that don't require a freeze exception), and impact underestimation (where the blast radius of a change is minimized without evidence). The output is a structured evaluation with a risk rating, an alternatives analysis, and a clear approval recommendation. This structure ensures that every exception review follows the same rigor, regardless of who submits the request or who sits on the CAB that week.

Do not use this prompt for routine prompt iteration that occurs before a freeze is declared. Pre-freeze development has different velocity and risk tolerances, and applying this formal evaluation framework too early will slow down necessary experimentation. Do not use this prompt for emergency incident response where a predefined rollback procedure already exists; in those cases, follow the runbook, execute the rollback, and then use this prompt to evaluate whether the rollback target should become the new frozen baseline. This prompt is also inappropriate for evaluating changes to non-system prompts, such as user-facing message templates, tool descriptions, or few-shot examples that live outside the system instruction layer. Confine its use to the narrow, high-stakes decision of whether to break a declared freeze on core system instructions.

This prompt template is designed for a change advisory board or AI release manager who must evaluate a request to modify a frozen system prompt. The prompt forces the model to act as a skeptical reviewer, systematically testing the request for urgency inflation, workaround blindness, and incomplete impact analysis before producing a structured recommendation. Replace each square-bracket placeholder with the relevant data before sending the request to the model. The template is self-contained and can be used directly in an API call, a chat interface, or an automated evaluation pipeline.

textCopy
You are a change advisory board evaluator for frozen AI system prompts. Your role is to critically assess requests to modify instructions that have been locked for production stability. You must be skeptical of urgency claims, thorough in identifying alternatives, and precise in your risk assessment.

## REQUEST TO EVALUATE
[EXCEPTION_REQUEST]

## FROZEN PROMPT CONTEXT
Current frozen system prompt version: [FROZEN_VERSION]
Date frozen: [FREEZE_DATE]
Original freeze rationale: [FREEZE_RATIONALE]

## PROPOSED CHANGE
[PROPOSED_CHANGE_DESCRIPTION]

## REQUESTER JUSTIFICATION
[REQUESTER_JUSTIFICATION]

## EVALUATION CRITERIA
1. **Urgency Validity**: Is the stated urgency genuine, or is this request inflating severity to bypass the freeze process?
2. **Workaround Viability**: Can the problem be solved without modifying the frozen instructions (e.g., through application-layer logic, tool configuration, or user guidance)?
3. **Impact Scope**: What behaviors, downstream systems, and user experiences would be affected by this change?
4. **Regression Risk**: What is the likelihood that this change introduces new failures or breaks previously stable behavior?
5. **Alternative Analysis**: What other approaches were considered, and why were they rejected?
6. **Precedent Risk**: Does approving this exception create a pattern that will weaken the freeze process for future requests?

## OUTPUT FORMAT
Return a JSON object with this exact schema:
{
  "exception_id": "string",
  "evaluation_summary": "string (2-3 sentence summary of findings)",
  "risk_rating": "low" | "medium" | "high" | "critical",
  "urgency_assessment": {
    "claimed_urgency": "string",
    "actual_urgency": "low" | "medium" | "high" | "critical",
    "inflation_detected": true | false,
    "inflation_evidence": "string (explain if inflation detected, otherwise null)"
  },
  "workaround_analysis": {
    "workarounds_exist": true | false,
    "identified_workarounds": ["string"],
    "workaround_limitations": "string",
    "recommendation": "pursue_workaround" | "proceed_with_change" | "hybrid"
  },
  "impact_scope": {
    "affected_behaviors": ["string"],
    "downstream_dependencies": ["string"],
    "user_experience_impact": "none" | "minor" | "moderate" | "significant"
  },
  "regression_risk": {
    "likelihood": "low" | "medium" | "high",
    "risk_factors": ["string"],
    "mitigation_required": ["string"]
  },
  "approval_recommendation": "approve" | "approve_with_conditions" | "reject" | "escalate",
  "conditions_if_approved": ["string"],
  "rejection_reasons_if_rejected": ["string"],
  "required_testing": ["string"],
  "stakeholder_review_needed": ["string"],
  "confidence": 0.0-1.0
}

## CONSTRAINTS
- Do not approve a change if a viable workaround exists that avoids modifying frozen instructions.
- Flag any urgency claim that lacks specific, measurable evidence of production impact.
- If regression risk is "high" and urgency is not "critical," default to rejection or escalation.
- Require explicit testing gates before any approval.
- If the change affects compliance, safety, or user data handling, require legal or compliance stakeholder review.
- If confidence is below 0.7, escalate rather than approve.

To adapt this template, replace the placeholders with concrete data from your exception request process. [EXCEPTION_REQUEST] should contain the full text of the request as submitted. [FROZEN_VERSION], [FREEZE_DATE], and [FREEZE_RATIONALE] provide the model with the context it needs to weigh stability against the proposed change. [PROPOSED_CHANGE_DESCRIPTION] should be a precise, technical description of what would change in the system prompt. [REQUESTER_JUSTIFICATION] is the requester's own argument for why the freeze should be broken. Before sending this prompt to production, validate that the output JSON parses correctly and that the risk_rating and approval_recommendation fields align with your organization's actual risk thresholds. For high-risk domains, always route escalate recommendations to a human reviewer rather than auto-approving based on model output alone.

This prompt is designed to sit behind a change advisory board (CAB) intake form, not a chatbot. The application layer should collect the exception request fields—requester, system prompt version, proposed change, justification, urgency, and alternatives considered—and inject them into the [REQUEST_DETAILS] placeholder. Do not expose the raw prompt to the requester. The model's output is a structured evaluation, not a final decision; it must feed into a human reviewer's queue with the recommendation surfaced as advisory input only.

Before calling the model, validate the intake payload against required fields. Reject requests missing a justification, alternatives analysis, or rollback plan. After receiving the model output, run a structured validation pass: confirm the JSON schema matches the expected [OUTPUT_SCHEMA], check that the risk rating is one of the allowed enum values, and verify that the approval recommendation is present and non-empty. If validation fails, retry once with the error details injected into a repair prompt that includes the original request and the specific schema violation. After two failures, escalate to a human CAB coordinator without an AI-generated recommendation.

Log every evaluation to an audit table with the request ID, model version, raw output, validation result, and final reviewer decision. This trace is essential for governance reviews and for detecting drift in the model's risk calibration over time. For model choice, use a model with strong instruction-following and structured output capabilities. Avoid models that tend to hedge or over-explain in JSON fields. Set temperature to 0 or near-zero to maximize consistency across evaluations. If your CAB process handles high-severity production incidents, consider routing requests with a severity: critical tag to a second model for a blind comparison before human review.

The most common failure mode is urgency inflation—requesters marking routine changes as critical to bypass the freeze. The prompt includes a validation check for this, but the harness should add a rule: if the model flags urgency inflation, auto-escalate to a senior reviewer and require additional evidence before the CAB meeting. A second failure mode is workaround blindness, where the model accepts the requester's claim that no workaround exists. The harness should cross-reference the proposed change against a known-workarounds registry if one exists, and flag mismatches for human attention.

Do not automate the approval decision. The model's output is a structured recommendation, not an authorization. The final approval must come from a human CAB member who reviews the evaluation, the original request, and any harness-generated flags. The harness should present the model's risk rating, alternatives analysis, and recommendation in a review UI that makes disagreement easy—allow the reviewer to override the recommendation and require a reason when they do. That override reason becomes training signal for future prompt improvements and eval calibration.