Post-Freeze Change Request Triage Prompt

This prompt is designed for AI operations and release management teams who are responsible for maintaining the stability of a frozen system prompt. The primary job-to-be-done is to transform an unstructured, often overwhelming queue of incoming change requests into a structured, prioritized, and auditable triage report. After a system prompt freeze, every modification request—whether a critical bug fix, a policy update, or a minor wording tweak—carries the risk of behavioral regression and requires careful evaluation. This prompt acts as a consistent first-pass filter, classifying each request by severity, estimating its operational impact, detecting duplicates, and recommending a routing path. The ideal user is a release manager or a member of a change advisory board who needs a standardized artifact to accelerate human decision-making, not to replace it.

Use this prompt when the volume of post-freeze change requests exceeds your team's capacity for immediate manual evaluation, and you need a defensible, repeatable process to separate critical exceptions from deferrable improvements. It is particularly valuable in high-stakes environments where the system prompt governs a production AI product, and an unvetted change could silently degrade user experience or violate a safety policy. The prompt requires a well-formed input: a list of change requests, each with a description, requester, and any claimed urgency. The output is a triage queue that ranks requests by a calculated priority score, flags potential duplicates, and suggests whether an item should be escalated for immediate review, batched for a maintenance window, or deferred. This structure ensures that every request is seen and categorized before any frozen instruction is touched.

It is equally important to understand when not to use this prompt. This is a classification and prioritization tool, not a decision engine. It must never be used to auto-approve or auto-reject a change to a frozen system prompt. The output is a recommendation for a human change advisory board or release manager, who must apply final judgment, consider broader context the model may lack, and own the decision. Do not use this prompt for real-time, automated rollback decisions or for triaging changes to non-frozen, actively iterated prompts. Furthermore, this prompt is not a substitute for a full impact analysis or a regression test suite; it is a triage step that precedes those deeper investigations. The next step after generating this report is always a structured human review, where the board can challenge severity classifications, merge related requests, and authorize the next stage of evaluation for the highest-priority items.

This prompt template is designed to be the operational core of your change request triage workflow. It accepts a batch of incoming change requests against a frozen system prompt and produces a structured, prioritized queue. The template uses square-bracket placeholders that you must replace with your specific operational data before sending it to the model. Do not treat this as a static prompt; the [FROZEN_PROMPT_SNAPSHOT], [CHANGE_REQUESTS], and [EXCEPTION_POLICY] placeholders are dynamic inputs that should be populated from your version control system, ticketing platform, and governance runbooks respectively.

textCopy
You are a Post-Freeze Change Request Triage Agent. Your job is to analyze incoming requests to modify a frozen system prompt, classify their severity, estimate their impact, and produce a prioritized triage queue with clear routing recommendations.

## FROZEN SYSTEM PROMPT (CURRENT BASELINE)
[FROZEN_PROMPT_SNAPSHOT]

## EXCEPTION HANDLING POLICY
[EXCEPTION_POLICY]

## INCOMING CHANGE REQUESTS
[CHANGE_REQUESTS]

## TRIAGE RULES
1. Classify each request into one of these severity levels:
   - **CRITICAL**: Production outage, safety violation, or regulatory non-compliance. Requires immediate exception.
   - **HIGH**: Significant behavioral regression or policy breach affecting multiple users. Requires exception within 24 hours.
   - **MEDIUM**: Edge-case failure or minor behavioral drift. Can wait for next maintenance window.
   - **LOW**: Cosmetic, stylistic, or non-urgent improvement. Defer to next planned iteration.
   - **INVALID**: Duplicate, already addressed, or outside the scope of the frozen prompt.

2. For each request, estimate:
   - **Impact blast radius**: Number of users, workflows, or downstream systems affected.
   - **Rollback risk**: Likelihood that applying this change introduces new regressions.
   - **Workaround availability**: Whether a temporary operational workaround exists.

3. Detect duplicates by comparing request descriptions, affected prompt sections, and proposed changes. Flag duplicates with a reference to the original request ID.

4. Route each request to one of:
   - **IMMEDIATE_ACTION**: For CRITICAL severity. Escalate to on-call and change advisory board.
   - **EXCEPTION_REVIEW**: For HIGH severity. Queue for next exception review meeting.
   - **BACKLOG**: For MEDIUM severity. Assign to prompt engineering backlog.
   - **DEFER**: For LOW severity. Note for next planned unfreeze cycle.
   - **CLOSE**: For INVALID or duplicate requests. Provide closure reason.

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "triage_queue": [
    {
      "request_id": "string",
      "severity": "CRITICAL | HIGH | MEDIUM | LOW | INVALID",
      "summary": "One-sentence description of the requested change",
      "impact_blast_radius": "string",
      "rollback_risk": "LOW | MEDIUM | HIGH",
      "workaround_available": true,
      "workaround_description": "string or null",
      "duplicate_of": "string or null",
      "routing": "IMMEDIATE_ACTION | EXCEPTION_REVIEW | BACKLOG | DEFER | CLOSE",
      "routing_rationale": "string",
      "affected_prompt_sections": ["string"]
    }
  ],
  "summary_stats": {
    "total_requests": 0,
    "critical_count": 0,
    "high_count": 0,
    "medium_count": 0,
    "low_count": 0,
    "invalid_count": 0,
    "duplicate_count": 0
  },
  "escalation_required": true,
  "escalation_details": "string or null"
}

## CONSTRAINTS
- Do not invent change requests. Only triage what is provided in [CHANGE_REQUESTS].
- If a request is ambiguous, classify it as MEDIUM and flag it for human clarification.
- Never recommend bypassing the exception policy for LOW or MEDIUM severity requests.
- If [EXCEPTION_POLICY] specifies approval chains, reflect those in routing recommendations.
- For CRITICAL requests, include a recommended rollback plan if the change fails.

To adapt this template, start by wiring [FROZEN_PROMPT_SNAPSHOT] to your prompt version control system so it always reflects the current frozen baseline. The [EXCEPTION_POLICY] placeholder should pull from your governance runbook, not be hardcoded. For [CHANGE_REQUESTS], structure each request as a JSON array with id, description, proposed_change, and requester fields before injecting them into the prompt. If your triage volume exceeds a few dozen requests per batch, split them into multiple model calls to avoid context window limitations and degraded classification accuracy on later items.

Before deploying this prompt into production, validate its output against a golden dataset of pre-classified change requests. Pay particular attention to duplicate detection accuracy and severity inflation—two failure modes that degrade trust in automated triage. Always require human review for CRITICAL and HIGH severity classifications before any change is applied to a frozen prompt. The model's routing recommendation is advisory, not executable.

This prompt is designed to sit behind a change request intake form or an internal ticketing system. The typical integration path is a lightweight API endpoint that receives a structured change request payload, injects it into the prompt template alongside the frozen system prompt baseline and any recent triage history, and returns a classified, prioritized triage record. Because the output drives operational decisions about whether to convene a change advisory board or trigger an emergency rollback, the harness must enforce output schema validation before the triage result enters any downstream queue.

Wire the prompt into an application by first assembling the required inputs: the frozen system prompt text, the change request details (requester, description, affected sections, business justification), and a deduplication context containing recently triaged requests. Pass these into the prompt using the [FROZEN_PROMPT], [CHANGE_REQUEST], and [TRIAGE_HISTORY] placeholders. On the output side, enforce a strict JSON schema that includes severity (one of CRITICAL, HIGH, MEDIUM, LOW), impact_estimate (affected behaviors, user-facing surfaces, downstream dependencies), routing (target team or approval body), duplicate_of (nullable reference to a prior request ID), and urgency_justification (evidence for the severity classification). Use a validator that rejects malformed JSON, missing required fields, or severity classifications that lack supporting evidence in the justification field. For high-risk deployments, add a human review step before routing: if severity is CRITICAL or HIGH, queue the triage record for manual approval rather than auto-routing.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities. Set temperature to 0 or near-zero to maximize classification consistency across repeated runs. Implement retry logic with exponential backoff for schema validation failures, but cap retries at three attempts before escalating to a human operator with the raw model output and validation errors attached. Log every triage result—including the prompt version, model identifier, input hash, output payload, validation status, and reviewer decision—to create an audit trail that supports post-incident review and freeze exception governance. Avoid wiring this prompt directly into an automated approval path without human-in-the-loop gates for high-severity classifications; the cost of an incorrectly downgraded change request is a production behavior regression that violates the freeze contract.