Anomaly Investigation Chain-of-Thought Prompt

This prompt is designed for data engineering, SRE, and operations teams who need an AI system to perform systematic, auditable anomaly investigations. The core job-to-be-done is transforming a raw anomaly alert and its surrounding context into a structured report that includes a ranked list of hypotheses, supporting evidence for each, and a clear chain of investigative reasoning. The ideal user is a developer or operator integrating this prompt into a diagnostic workflow where consistency and resistance to confirmation bias are more critical than sub-second latency. Required context includes the anomaly description, a baseline for normal behavior, and recent relevant telemetry or logs.

You should use this approach when you need every investigation to follow the same rigorous structure, making the outputs comparable and reviewable over time. The few-shot demonstration pattern is particularly effective here because it teaches the model how to think about the problem—generating investigation steps, ranking hypotheses by likelihood, and always comparing against a baseline—more reliably than verbose procedural instructions alone. This is a strong fit for offline or asynchronous investigation of batch-detected anomalies, where a 10-30 second response time is acceptable. It is also appropriate when the cost of a missed or misdiagnosed anomaly is high, justifying a thorough, evidence-based report that an on-call engineer can quickly validate.

Do not use this prompt for real-time alerting systems that require sub-second latency, as the chain-of-thought generation adds non-trivial processing time. It is also the wrong tool when the anomaly is already fully understood and only a notification needs to be sent; in that case, a simpler templated message is more efficient. Avoid this pattern if you cannot provide a reliable baseline for comparison, as the prompt's core instruction to 'compare against a baseline' will lead to hallucinated or meaningless baselines. Finally, while this prompt produces a report, it does not execute remediation steps. The next step after generating this report should be a human review or feeding the structured output into a separate automation runbook.

This prompt template uses worked examples to transfer a structured investigation pattern to the model. Instead of describing how to investigate anomalies, the examples demonstrate the full reasoning chain: observing the data, forming ranked hypotheses, gathering evidence for each, and delivering a final assessment. The square-bracket placeholders let you swap in your own data schema, risk level, and domain-specific examples without rewriting the reasoning structure. For high-stakes domains like finance, healthcare, or security operations, always route the final assessment through human review before taking action.

textCopy
You are an anomaly investigation analyst. When presented with data, you will investigate systematically by following a reasoning pattern demonstrated in the examples below. Do not jump to conclusions. Work through investigation steps, form multiple hypotheses, rank them by likelihood, and cite specific evidence before delivering your final assessment.

[EXAMPLES]

---

Now apply the same systematic investigation pattern to the following data:

[DATA]

Data schema: [DATA_SCHEMA]

Investigation constraints: [CONSTRAINTS]

Risk level: [RISK_LEVEL]

Output format: [OUTPUT_SCHEMA]

Begin your investigation.

Adapting the template: Replace [EXAMPLES] with 2-4 worked demonstrations that show the full reasoning chain for your domain. Each example should include the raw data, the step-by-step investigation, multiple hypotheses with likelihood rankings, evidence for and against each hypothesis, and a final assessment. The [DATA_SCHEMA] placeholder should describe your data fields, units, and expected ranges so the model knows what normal looks like. Set [RISK_LEVEL] to low, medium, high, or critical to adjust the investigation depth and caution language. The [OUTPUT_SCHEMA] should specify the exact structure you need, such as JSON with fields for investigation_steps, hypotheses, evidence, ranked_findings, and final_assessment. For production use, validate the output against this schema before surfacing results to users or downstream systems. If the model skips investigation steps or produces only one hypothesis, treat that as a validation failure and retry with stronger constraint language or additional negative examples showing incomplete investigations.

This prompt is designed to be called programmatically by an incident management bot or a data pipeline, not as a one-off chat interaction. The system sending the prompt must construct the [INPUT] with structured telemetry, the [CONTEXT] with historical baselines and recent changes, and the [OUTPUT_SCHEMA] as a strict JSON schema. The model's response must be parsed as JSON and stored as a timestamped entry in the incident timeline. Never expose the raw model output directly to a status page or customer-facing communication without validation and, for high-severity incidents, human review.

Implement a retry wrapper around the model call that validates the parsed JSON for the presence and type of two critical fields: investigation_steps (must be a non-empty array of strings) and ranked_hypotheses (must be a non-empty array of objects, each with hypothesis, likelihood, and supporting_evidence fields). If the model fails to produce valid JSON or these required fields are missing or incorrectly typed, retry once with a stricter system message that explicitly states: 'You MUST respond with ONLY a valid JSON object containing the keys "investigation_steps" and "ranked_hypotheses". No other text is permitted.' Log the raw prompt and the raw completion for every attempt to ensure auditability and to enable prompt debugging if failures persist. Do not implement infinite retries; after one retry, escalate the failure to an on-call engineer with the logged context.

For incidents classified as sev-0 or sev-1 in the triggering system, the validated and parsed output must be routed to a human on-call for review via a Slack message, PagerDuty alert, or a dedicated review queue. The human should approve, edit, or reject the hypotheses before any summary is posted to an internal or external status page. Under no circumstances should the model's output be used to automatically execute remediation steps, runbooks, or infrastructure changes. The model's role is strictly analytical: it proposes investigation paths and hypotheses, but a human operator or a deterministic, pre-approved script must decide and act on them.

When wiring this into a data pipeline, ensure the [INPUT] placeholder is populated with a structured object containing the anomaly's time window, affected metrics, deviation magnitude, and a link to the relevant dashboard. The [CONTEXT] should be assembled by querying a feature store or metrics database for the 7-day baseline average, the most recent deployment timestamps, and any currently open incidents. This assembly logic should live in the application layer, not in the prompt. After the validated output is stored, trigger a follow-up evaluation step that checks whether the ranked_hypotheses list includes a comparison to the baseline period; if it does not, flag the output for a potential confirmation bias failure mode and append a note to the incident timeline.