Post-Freeze Exception Handling Policy Prompt

This prompt is for AI release managers and platform engineers who need a structured, auditable process for handling exceptions to a frozen system prompt. The core job-to-be-done is converting an ad-hoc, high-pressure request to modify production instructions into a governed workflow. The ideal user is someone responsible for system stability who must balance the urgency of a fix against the risk of destabilizing a validated, locked-down prompt. Required context includes the original freeze record, the specific behavioral gap or production incident triggering the request, and the stakeholder approval chain. Do not use this prompt for minor wording tweaks that don't change model behavior, for prompts that have never been frozen, or for brainstorming new features—it is a production change control tool, not a design workshop.

The prompt produces an exception classification framework, not a simple yes/no answer. It forces the model to categorize the request by severity (e.g., 'Critical Safety Gap', 'Performance Regression', 'Policy Violation', 'Feature Request'), propose an approval path with named roles, define explicit rollback triggers, and list the minimum documentation required before the change can be merged. A concrete implementation would feed this prompt the original freeze baseline, the proposed diff, and incident evidence. The output should be treated as a draft recommendation that requires human review by the change advisory board. Never auto-apply the model's recommendation without human sign-off, as the model cannot weigh unstated organizational risk tolerances.

Before using this prompt, ensure you have a frozen prompt baseline with a version lock and a behavioral regression test suite. Without these, the exception policy has no anchor and becomes just another change request. After generating the exception framework, validate it against known failure modes: urgency inflation (every request is 'critical'), workaround blindness (a simpler non-prompt fix exists), and approval chain gaps (no one is accountable for the final decision). The next step is to route the structured evaluation to the change advisory board and log the decision for audit. Avoid using this prompt as a substitute for a human-led postmortem; it structures the decision, it does not make it.

This prompt is designed to be the core instruction set for an AI system acting as a change advisory board analyst. Its job is to take a raw exception request against a frozen system prompt and produce a structured, actionable policy framework. The template uses square-bracket placeholders for all dynamic inputs, allowing you to wire it directly into an automated triage pipeline or a human-in-the-loop review tool. The goal is not just to approve or deny, but to define how an exception should be handled, including rollback triggers and required evidence.

codeCopy
You are an AI release policy analyst. Your task is to evaluate a request to modify a frozen system prompt and produce a structured exception handling policy.

## FROZEN SYSTEM PROMPT CONTEXT
[FROZEN_PROMPT_SNIPPET]

## EXCEPTION REQUEST
[EXCEPTION_REQUEST_DETAILS]

## REQUESTER INFORMATION
- Requester Role: [REQUESTER_ROLE]
- Urgency Claim: [URGENCY_CLAIM]
- Proposed Change: [PROPOSED_CHANGE]

## POLICY FRAMEWORK
Analyze the request and generate a strict JSON output conforming to the schema below. Do not include any text outside the JSON object.

### Classification
Classify the exception into one of the following categories:
- `CRITICAL_SAFETY`: A failure that could cause harm, violate policy, or create legal liability.
- `FUNCTIONAL_REGRESSION`: A core product feature is broken or severely degraded.
- `OPERATIONAL_BLOCKER`: A non-functional but critical operational workflow is blocked.
- `PERFORMANCE_DEGRADATION`: Latency, cost, or token efficiency has fallen below acceptable thresholds.
- `COSMETIC_IMPROVEMENT`: A non-critical improvement to tone, formatting, or style.
- `UNWARRANTED`: The request does not demonstrate a valid need to break the freeze.

### Approval Path
Based on the classification, define the required approval path:
- `AUTOMATED`: For COSMETIC_IMPROVEMENT only, with a pre-defined rollback window.
- `PEER_REVIEW`: Requires one senior engineer approval.
- `CAB_REVIEW`: Requires a full Change Advisory Board review.
- `EMERGENCY_CAB`: For CRITICAL_SAFETY, requires immediate CAB convening.
- `REJECTED`: For UNWARRANTED requests.

### Rollback Triggers
Define specific, measurable conditions that will automatically trigger a rollback of this exception. Use the format: `IF [metric] [operator] [threshold] FOR [duration] THEN [action]`.

### Documentation Requirements
List the specific artifacts that must be created before, during, and after the exception is granted.

## OUTPUT SCHEMA
{
  "exception_id": "string",
  "classification": "CRITICAL_SAFETY | FUNCTIONAL_REGRESSION | OPERATIONAL_BLOCKER | PERFORMANCE_DEGRADATION | COSMETIC_IMPROVEMENT | UNWARRANTED",
  "risk_rating": "LOW | MEDIUM | HIGH | CRITICAL",
  "approval_path": "AUTOMATED | PEER_REVIEW | CAB_REVIEW | EMERGENCY_CAB | REJECTED",
  "rollback_triggers": [
    {
      "condition": "string",
      "metric": "string",
      "threshold": "string",
      "action": "string"
    }
  ],
  "documentation_required": ["string"],
  "alternative_analysis": "string (explain why a workaround outside the prompt is not sufficient)",
  "urgency_validation": "string (assess whether the claimed urgency is inflated)"
}

## CONSTRAINTS
- Do not approve an exception if the same outcome can be achieved through application-layer logic, a routing rule, or a lightweight model wrapper.
- If the proposed change introduces a new ambiguity or policy loophole, flag it in the `risk_rating` and require `CAB_REVIEW`.
- For any classification above `COSMETIC_IMPROVEMENT`, a rollback trigger is mandatory.

To adapt this template, replace the placeholders with data from your ticketing system or API. The [FROZEN_PROMPT_SNIPPET] should include the specific instruction block the change targets, not the entire system prompt, to keep context focused. The [EXCEPTION_REQUEST_DETAILS] should be the raw, unedited text from the requester. Before deploying this into an automated pipeline, you must implement a validation layer that checks the JSON output against the schema. A common failure mode is the model inventing a classification that is not in the enum list; your harness should reject the output and retry with a stricter constraint message. For high-risk workflows, always route CRITICAL_SAFETY and EMERGENCY_CAB outputs to a human queue for final confirmation before any change is applied.

This prompt is designed to sit inside a change management or release governance workflow, not as a standalone chatbot. The primary integration point is a structured intake form or API that collects the exception request details—frozen instruction version, proposed change, rationale, urgency, and affected behaviors—and passes them as the [EXCEPTION_REQUEST] input. The model's output should be treated as a structured recommendation, not an automated approval. The JSON output schema defined in the prompt template is the contract between the model and the downstream approval routing system.

Wire the prompt into an application by building a thin service layer that: (1) validates the incoming exception request against required fields before calling the model; (2) injects the current frozen instruction baseline and any recent drift monitoring data into the [FROZEN_BASELINE] and [PRODUCTION_OBSERVATIONS] placeholders; (3) calls the model with a strict JSON mode or structured output constraint matching the [OUTPUT_SCHEMA]; (4) parses and validates the returned JSON against the schema, retrying once on parse failure with a repair prompt that includes the validation error; and (5) routes the validated output to the appropriate approval path based on the exception_classification and risk_rating fields. Low-risk, pre-approved exception types can be auto-applied with logging; medium-risk exceptions route to a change advisory board queue; high-risk or requires_legal_review: true exceptions must block on human sign-off before any system prompt update is deployed.

Logging and audit requirements are critical here. Every invocation should record: the full request payload, the frozen baseline version, the model's raw and parsed output, the validation result, the routing decision, and the final human disposition if applicable. This creates an audit trail that satisfies the documentation requirements the prompt itself enforces. For model choice, prefer a model with strong instruction-following and structured output reliability—GPT-4o or Claude 3.5 Sonnet with JSON mode enabled are appropriate defaults. Avoid using smaller or open-weight models for this workflow unless you have validated their schema adherence and classification consistency against a golden test set of historical exception requests. The primary failure mode in production is not hallucination but misclassification: the model may down-rank a genuinely risky exception or inflate urgency on a routine request. Mitigate this by running periodic evaluations comparing model classifications against human reviewer decisions, and by setting a hard rule that any exception touching safety guardrails, PII handling, or compliance boundaries skips the model's risk rating and forces human review regardless of the output.