Instruction Drift Notification for Human Review Prompt

This prompt is designed for AI ops engineers, SREs, and platform teams who operate long-running, production AI agents where instruction hierarchy integrity is critical. Its primary job-to-be-done is to act as the final decision gate after an automated drift detection system has flagged a potential violation. Instead of automatically applying a correction, which could disrupt a healthy session or mask a systemic issue, this prompt generates a structured, human-readable notification. The on-call engineer uses this notification to assess the severity of the drift, understand the session context, and make an informed decision to intervene, suppress the alert, or escalate. The core value is creating a consistent, auditable decision record before any potentially disruptive action is taken on a live agent.

Use this prompt when the cost of a false positive (unnecessary intervention that resets state or confuses a user) or a false negative (missed drift that causes a compliance violation or a bad tool call) is high. It is ideal for regulated environments, customer-facing agents with strict brand guidelines, or complex multi-agent systems where a single erroneous correction can cascade. You must have the following context available to populate the prompt's placeholders: the original instruction hierarchy, a summary of recent agent actions, the specific drift alert details (including severity score and affected layers), and relevant session traces. Do not use this prompt for low-severity, transient anomalies where an automated correction with a verification loop is a faster and safer choice; for those cases, use the Instruction Drift Correction Prompt for Agents instead.

This prompt is not a replacement for your drift detection logic; it is the human interface for that logic. It assumes a drift event has already been identified and scored by a separate system. The output is a notification for a human reviewer, not a new system instruction. Before wiring this into an on-call rotation, ensure your drift detection system has been calibrated to suppress obvious false positives, such as acceptable paraphrasing or a single malformed output in an otherwise healthy session. The next step after reading this section is to review the prompt template and adapt its structured output schema to match your incident management tooling.

This prompt template is designed to be used as the system message for a dedicated classifier/summarizer model call. Its job is to analyze a session trace, compare recent model behavior against the original instruction hierarchy, and produce a structured notification when drift severity warrants human attention. The output is not a correction—it is an escalation artifact that tells an operator what degraded, how severely, and what action to consider next. Use this when your drift detection pipeline has already flagged a session and you need a consistent, machine-readable notification for routing to a review queue, incident channel, or on-call rotation.

textCopy
You are an instruction drift notification generator for production AI systems. Your output will be consumed by operators, SREs, and incident management systems. Do not attempt to correct the drift. Your sole job is to produce a structured, evidence-backed notification that a human reviewer can act on.

## INPUTS
- [SESSION_TRACE]: Full multi-turn conversation trace including system prompt, user messages, assistant responses, tool calls, and tool outputs.
- [INSTRUCTION_HIERARCHY]: The original instruction layers with their priority order, including system instructions, developer directives, user-instruction boundaries, tool-use policies, output contracts, and refusal rules.
- [DRIFT_DETECTION_RESULTS]: Pre-computed drift signals from upstream detection, including affected instruction layers, severity scores, and specific turn indices where violations were observed.
- [SESSION_METADATA]: Session ID, start time, model version, prompt version, user/tenant identifier, and any deployment tags.
- [ESCALATION_RULES]: Thresholds that determine when drift warrants human review, including minimum severity, affected layer count, and user-facing impact criteria.

## OUTPUT SCHEMA
Return a single JSON object with this exact structure:
{
  "notification_id": "string, unique identifier for this notification",
  "session_id": "string, from session metadata",
  "generated_at": "ISO 8601 timestamp",
  "escalation_triggered": true,
  "drift_summary": {
    "severity": "LOW | MEDIUM | HIGH | CRITICAL",
    "affected_layers": ["list of instruction layer names that show degradation"],
    "primary_failure_mode": "PRIORITY_INVERSION | BOUNDARY_EROSION | OUTPUT_CONTRACT_VIOLATION | REFUSAL_WEAKENING | PERSONA_SHIFT | TOOL_POLICY_DRIFT | CONTEXT_CONTAMINATION",
    "brief_description": "One to two sentences describing what degraded and the likely user-facing impact."
  },
  "evidence": [
    {
      "turn_index": 0,
      "instruction_layer": "string, which layer was violated",
      "expected_behavior": "string, what the instruction required",
      "observed_behavior": "string, what the model actually did",
      "violation_type": "string, specific category of deviation"
    }
  ],
  "recommended_action": "HUMAN_REVIEW_REQUIRED | ROLLBACK_PROMPT_VERSION | APPLY_CORRECTION_PROMPT | INCREASE_MONITORING | INVESTIGATE_ROOT_CAUSE",
  "false_positive_risk": "LOW | MEDIUM | HIGH",
  "false_positive_rationale": "Brief explanation of why this might be a false positive, including any ambiguous turns or edge cases.",
  "context_window_position": {
    "drift_first_observed_at_turn": 0,
    "total_turns": 0,
    "approximate_token_position": "EARLY | MID | LATE",
    "positional_decay_suspected": true
  },
  "reviewer_notes": "Any additional context a human reviewer needs to triage this notification effectively."
}

## CONSTRAINTS
- Only trigger escalation when drift severity meets or exceeds the thresholds in [ESCALATION_RULES].
- If no drift warrants human review, set escalation_triggered to false and provide a brief summary explaining why thresholds were not met.
- Cite specific turn indices and instruction layers for every piece of evidence. Do not generalize.
- Flag false-positive risk explicitly. If the drift signal could be explained by ambiguous user input, edge-case tool output, or legitimate context adaptation, note it.
- Do not fabricate evidence. If the session trace does not contain clear violations, do not invent them.
- Keep the notification concise. Operators need to triage quickly.

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

Adapt this template by replacing each square-bracket placeholder with your actual data and configuration. [SESSION_TRACE] should contain the full conversation, not a summary—the model needs raw turns to cite evidence. [INSTRUCTION_HIERARCHY] must include the priority order of your instruction layers, because the model needs to distinguish between a minor tone shift and a critical priority inversion where user input overrides system policy. [ESCALATION_RULES] should encode your team's specific thresholds: for example, escalate on HIGH or CRITICAL severity, or when more than two instruction layers are affected, or when refusal boundaries show any degradation in regulated domains. [EXAMPLES] should include at least two few-shot examples: one where escalation is correctly triggered with clear evidence, and one where drift is detected but correctly suppressed as a false positive. [RISK_LEVEL] should be set to HIGH if this notification feeds into incident management or compliance workflows, because a missed escalation or a false alarm both carry operational cost. After adapting, test this prompt against a golden dataset of session traces with known drift and non-drift cases before deploying to production.

The Instruction Drift Notification prompt is designed to be called by an automated monitoring job, not by an end user. It should be triggered when a drift detection system (such as a session scanner or trace-level adherence scorer) identifies a session that exceeds a configured drift severity threshold. The prompt receives a structured [DRIFT_EVIDENCE] payload containing the original instruction hierarchy, the detected deviations, affected layers, session metadata, and a pre-computed drift score. Its job is to produce a human-readable notification that an on-call engineer or AI ops reviewer can act on without needing to replay the entire session trace.

Wire this prompt into your observability stack as a post-detection enrichment step. When your drift detection harness flags a session, construct the [DRIFT_EVIDENCE] input by combining: (1) the original instruction hierarchy snapshot from the session's start, (2) the detected drift events with turn-level citations, (3) the severity classification and affected instruction layers, and (4) a compressed session context summary covering the last N turns before drift was detected. Pass this payload to the model with a low temperature (0.1–0.2) to ensure consistent notification structure. Validate the output against the expected [OUTPUT_SCHEMA] before routing it to your incident management system. If the model produces a malformed notification, retry once with an explicit format correction instruction; if it fails again, fall back to a templated notification with the raw drift evidence attached.

The notification output must be routed based on the severity field. For critical and high severity drift events, send the notification directly to the on-call channel (PagerDuty, Opsgenie, Slack on-call rotation) with a high-priority flag. For medium severity, route to the AI ops review queue for triage within the next business day. For low severity, log the notification to your drift observability dashboard and include it in the weekly drift health summary. Implement a false-positive suppression mechanism: if a human reviewer marks a notification as a false positive, store the session fingerprint and suppress future notifications for sessions with matching drift patterns unless the severity increases. Log every notification decision—including suppression reasons—for auditability and threshold calibration. Do not allow the model to decide whether to send the notification; the routing logic must be deterministic application code that reads the structured severity field from the validated output.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent). Avoid smaller or older models that may hallucinate severity levels or omit required fields. If you are running this prompt at high volume across many sessions, consider caching the system prompt prefix and batching drift evidence payloads where latency permits. For regulated environments, ensure that the full drift evidence payload and the generated notification are written to an append-only audit log before any human review action is taken. The notification itself should never automatically trigger a correction action—human approval is required for any session modification, especially in production agents handling customer-facing interactions or regulated workflows.