Override Decision Root Cause Analysis Prompt

This prompt is designed for reliability engineers and AI operations teams who need to investigate a single, specific human override event. Its job is to produce a structured root cause hypothesis that traces the override back to an upstream failure in the AI system. The analysis separates evidence-backed findings from speculation, creating a durable record suitable for incident reviews, model improvement backlogs, and governance reports. Use this prompt when an override has already occurred and you need to understand why the system's autonomous decision was insufficient, not when you are deciding whether to override in real-time.

The ideal user has access to the complete context of the override event: the original AI recommendation, the human's justification, the model's confidence scores, the tool outputs or retrieved data available at the time, and the relevant policy documents. The prompt requires these inputs to ground its analysis in evidence. It is not designed to operate on sparse metadata alone. If you only have a log line indicating an override occurred, you must first assemble the diagnostic context before using this prompt. The output is a structured hypothesis, not a final verdict; it flags speculative leaps explicitly and is intended to be reviewed and challenged by a human engineer.

Do not use this prompt for real-time decision-making during an active override workflow. It is a post-hoc analysis tool, not an approval gate. It is also unsuitable for batch pattern analysis across hundreds of overrides; it is built for deep-dive investigation of a single event. For pattern detection across multiple events, use the Override Pattern Detection Prompt. For verifying that a specific override justification complies with policy, use the Override Decision Policy Compliance Check Prompt. The root cause analysis prompt is a scalpel, not a scanner.

This prompt template is designed to be pasted directly into your investigation workflow. It instructs the model to act as a reliability engineer analyzing a specific override event. The goal is to produce a structured root cause hypothesis that links the human override to upstream failures in the AI system, data gaps, or policy ambiguity. Replace every [PLACEHOLDER] in square brackets with data from your actual override event before execution. The prompt enforces evidence grounding and explicitly requires the model to flag any speculation.

textCopy
You are a senior reliability engineer investigating a human override of an automated AI decision. Your task is to perform a root cause analysis and produce a structured hypothesis.

## Override Event Data
- **Original AI Decision:** [ORIGINAL_AI_DECISION]
- **Human Override Action:** [HUMAN_OVERRIDE_ACTION]
- **Override Justification Provided:** [OVERRIDE_JUSTIFICATION]
- **System Logs (excerpts):** [SYSTEM_LOGS]
- **Relevant Policy Documents:** [POLICY_DOCUMENTS]
- **Model Input Context:** [MODEL_INPUT_CONTEXT]

## Analysis Constraints
1.  **Ground in Evidence:** Every causal link in your hypothesis must be supported by a direct quote or reference from the provided data.
2.  **Flag Speculation:** If you must make an inference, explicitly label it as `[SPECULATIVE]` and state what missing evidence would confirm or refute it.
3.  **Categorize Root Cause:** Classify the primary root cause into one of the following categories: `DATA_GAP`, `MODEL_FAILURE`, `POLICY_AMBIGUITY`, `PROMPT_WEAKNESS`, or `HUMAN_ERROR`.
4.  **Do Not Blame:** Focus on systemic causes, not individual human error, unless the evidence explicitly points to a procedural violation.

## Output Schema
Produce a JSON object with the following structure:
{
  "override_event_id": "[OVERRIDE_EVENT_ID]",
  "root_cause_category": "[CATEGORY]",
  "executive_summary": "A 2-3 sentence summary of the root cause hypothesis.",
  "causal_chain": [
    {
      "step": 1,
      "description": "The initial state or trigger.",
      "evidence": "[QUOTE_OR_REFERENCE]",
      "confidence": "high"
    }
  ],
  "speculative_links": [
    {
      "description": "A potential link that could not be fully verified.",
      "missing_evidence": "What data would be needed to confirm this."
    }
  ],
  "recommended_remediation": "A concrete, actionable step to prevent this class of override in the future."
}

To adapt this template, start by populating the [ORIGINAL_AI_DECISION] and [HUMAN_OVERRIDE_ACTION] fields with the core facts. The quality of the analysis depends heavily on the richness of the [SYSTEM_LOGS] and [MODEL_INPUT_CONTEXT] you provide; include raw excerpts rather than summaries. If no relevant policy documents exist, replace [POLICY_DOCUMENTS] with 'No specific policy document provided.' The output schema is strict JSON to enable programmatic ingestion into an incident tracking system. After receiving the output, you should validate the JSON structure and verify that each step in the causal_chain array contains a non-empty evidence field before accepting the analysis.

This prompt is designed to operate as a diagnostic step inside a larger override review pipeline, not as a standalone chat interaction. The harness should invoke the prompt after a human override event has been logged and the associated AI decision, override justification, and relevant context are available. The model's job is to produce a structured root cause hypothesis, not to execute any action or make a policy decision. The harness must enforce this boundary by treating the model output as an analysis artifact that requires human review before it becomes part of any official incident record or governance report.

Wire the prompt into an investigation workflow by first assembling the required inputs: the original AI decision payload, the human override justification record, the applicable policy or rule set that governed the AI's behavior, and any relevant telemetry such as model confidence scores, retrieval sources, or tool-call logs. Pass these into the prompt's [AI_DECISION], [OVERRIDE_JUSTIFICATION], [GOVERNING_POLICY], and [TELEMETRY_CONTEXT] placeholders. After the model returns a response, validate the output structure against the expected [OUTPUT_SCHEMA] — at minimum, check that the root_cause_hypothesis field is populated, that evidence_links reference specific input data rather than hallucinated sources, and that speculation_flags are present when the model indicates uncertainty. Reject and retry outputs that fail schema validation, contain ungrounded claims, or omit required fields. Log every invocation, including the full prompt, model response, validation result, and reviewer decision, to maintain an audit trail for the override investigation itself.

For high-severity overrides — such as those involving financial transactions, safety decisions, or regulatory compliance — route the validated root cause hypothesis to a human reliability engineer or governance reviewer through a review queue. The harness should present the hypothesis alongside the original evidence so the reviewer can confirm, reject, or amend the analysis. Do not automatically close an override incident based solely on the model's output. The prompt's confidence field and speculation_flags should inform review prioritization: hypotheses marked low confidence or containing speculation should surface higher in the review queue. Avoid wiring this prompt directly into automated remediation or policy-update workflows; its output is investigative support, not an executable decision.