Instruction Drift Root Cause Triage Prompt

This prompt is for AI operations engineers and SREs who have detected instruction drift in a production agent and need to understand why it happened before applying a correction. The job-to-be-done is root cause classification: taking a session trace where drift was flagged and producing a structured diagnosis that separates context saturation from conflicting user input, tool output contamination, or ambiguous original instructions. Without this triage step, teams risk applying generic re-anchoring prompts that don't address the actual failure mechanism, leading to repeated drift in subsequent sessions.

Use this prompt when you have a confirmed drift event with an available session trace containing the original instruction hierarchy, user messages, tool calls, tool outputs, and model responses. The prompt expects a complete trace excerpt spanning at least the turns where drift was detected plus sufficient prior context to establish the baseline. It is not designed for real-time drift detection—that's the job of the Session Instruction Drift Detection Prompt. It is also not a correction prompt; it diagnoses the cause so you can select the right remediation strategy, whether that means rewriting ambiguous system instructions, adding tool output sanitization, or adjusting context window management.

Do not use this prompt when the drift event is unconfirmed, when session traces are incomplete or lack tool output data, or when you need an immediate automated correction rather than a root cause analysis. The output includes remediation recommendations per cause category, but those are guidance for the operator, not executable correction prompts. For high-risk domains where drift could cause compliance violations or safety incidents, always route the triage output to human review before applying any remediation. The classification confidence score in the output schema helps operators decide when to escalate.

This template is designed to be dropped directly into your drift investigation workflow. It expects a session trace and the original instruction hierarchy as input, and it produces a structured root cause classification with evidence citations. The square-bracket placeholders let you swap in your own trace format, instruction layers, and output schema without rewriting the core triage logic.

textCopy
You are an AI operations analyst investigating instruction drift in a production AI system. Your task is to identify the root cause of drift, classify it into a defined category, and provide supporting evidence from the session trace.

## INPUTS

### Original Instruction Hierarchy
[INSTRUCTION_HIERARCHY]

### Session Trace
[SESSION_TRACE]

### Drift Symptom Description
[DRIFT_SYMPTOM]

## OUTPUT SCHEMA

Return a JSON object with the following structure:
{
  "root_cause_classification": "context_saturation | conflicting_user_input | tool_output_contamination | instruction_ambiguity | priority_inversion | multi_agent_handoff_decay | unknown",
  "confidence_score": 0.0-1.0,
  "affected_instruction_layers": ["system", "developer", "user", "tool", "policy"],
  "evidence": [
    {
      "trace_location": "turn number or timestamp",
      "observation": "what happened",
      "expected_behavior": "what should have happened per the instruction hierarchy",
      "deviation_type": "omission | substitution | override | dilution"
    }
  ],
  "contributing_factors": ["list of conditions that enabled the drift"],
  "remediation_recommendation": {
    "immediate_action": "what to do now for this session",
    "preventive_change": "what to change in the prompt, architecture, or tool contracts",
    "monitoring_adjustment": "what drift signal to add to observability"
  },
  "requires_human_review": true/false,
  "human_review_rationale": "explain why if true"
}

## CONSTRAINTS

- Classify into exactly one root cause category. Use "unknown" only if no category fits with confidence above 0.3.
- Every piece of evidence must cite a specific trace location (turn number or timestamp).
- If the trace contains PII or sensitive data, redact it in your evidence citations and note the redaction.
- Do not speculate beyond what the trace and instruction hierarchy support.
- If multiple root causes are present, select the primary one and list others as contributing factors.
- For "tool_output_contamination," identify which tool output overrode which instruction layer.
- For "conflicting_user_input," show where the user message contradicted a higher-priority instruction.
- For "context_saturation," identify the approximate context position where instruction fidelity degraded.
- Remediation recommendations must be actionable and specific to the classified root cause.

## ROOT CAUSE DEFINITIONS

- **context_saturation**: Instruction fidelity degraded because the context window became too full, pushing critical instructions out of the model's effective attention range.
- **conflicting_user_input**: A user message directly or indirectly contradicted a system, developer, or policy instruction, and the model followed the user input instead of the higher-priority layer.
- **tool_output_contamination**: Output from a tool call contained language or instructions that overrode the original instruction hierarchy.
- **instruction_ambiguity**: The original instructions were vague, contradictory, or missing edge-case guidance, making drift inevitable under certain inputs.
- **priority_inversion**: The model applied instruction layers in the wrong order, treating lower-priority instructions as higher-priority.
- **multi_agent_handoff_decay**: Instruction fidelity was lost during context transfer between agents or sub-systems.

## RISK LEVEL
[RISK_LEVEL]

If RISK_LEVEL is "high" or "critical," set requires_human_review to true and include a detailed human_review_rationale.

To adapt this template, replace each bracketed placeholder with your actual data. [INSTRUCTION_HIERARCHY] should contain the full original instruction set with layer labels. [SESSION_TRACE] should include all turns, tool calls, and model outputs in chronological order. [DRIFT_SYMPTOM] is a brief description of what went wrong, provided by the operator or detection system. [RISK_LEVEL] should be set to "low," "medium," "high," or "critical" based on your organization's risk taxonomy. The output schema is designed to be machine-readable for downstream logging and alerting systems, but the evidence array is structured to be human-readable during incident review.

Before deploying this prompt in production, validate it against at least five known drift incidents with confirmed root causes. Compare the prompt's classification against your ground truth labels and tune the root cause definitions if your system has domain-specific drift patterns not covered by the default categories. If your session traces are long, consider truncating to the most relevant turns to stay within context limits while preserving enough evidence for accurate triage.

This prompt is designed as a diagnostic tool, not a real-time guardrail. It should be invoked by an on-call engineer or an automated monitoring system after a drift alert fires from a detection harness (such as the Session Instruction Drift Detection Prompt). The triage prompt expects a structured session trace as input, so the implementation harness must first assemble that trace from production logs, including the original instruction hierarchy, user messages, tool outputs, and model responses across the turns where drift was observed. Without a complete trace, the root cause classification will be unreliable.

Wire the prompt into a diagnostic pipeline that triggers on drift severity thresholds. The pipeline should: (1) fetch the session trace from your observability store (e.g., LangSmith, Braintrust, or a custom trace database); (2) format the trace into the [SESSION_TRACE] placeholder, including turn numbers, speaker roles, and message content; (3) inject the original [INSTRUCTION_HIERARCHY] as a structured JSON object with layer priorities; (4) call the model with a low temperature (0.0–0.2) to maximize classification consistency; and (5) parse the output against the expected schema. Validate that the root_cause_category field matches one of the defined enum values (context_saturation, conflicting_user_input, tool_output_contamination, instruction_ambiguity, or unknown). If the model returns an invalid category or missing evidence, retry once with a stricter constraint prompt before escalating to a human reviewer.

For production integration, log every triage result alongside the drift alert that triggered it. Store the root cause classification, confidence score, evidence excerpts, and remediation recommendation as structured metadata on the incident. This enables trend analysis over time—if context_saturation appears in 80% of drift incidents, the team should prioritize context window management strategies rather than rewriting instructions. Avoid using this prompt as a real-time interceptor on every model call; the token cost and latency are justified only for post-detection diagnosis. The remediation recommendations are advisory and should be reviewed by a human operator before applying corrective prompts, especially in regulated or customer-facing systems where a misapplied correction could introduce new failure modes.