root-cause-analysis

Use when investigating a KPI movement, spike, drop, or concentration in a dataset and the AI should structure evidence, candidate causes, confidence, and next checks in a disciplined way.

Root Cause Analysis

Purpose

Diagnose a KPI movement in a way that is analytically disciplined and decision-ready.

When to use

Use this skill when:

  • a metric moved unexpectedly
  • the user asks "why did this change," "what drove this drop," or "what explains these numbers"
  • a dataset, export, or KPI table shows a clear spike, drop, or concentration that needs explanation
  • someone wants an explanation, not just a trend report
  • there are multiple candidate drivers to evaluate

When not to use

Do not use this skill when:

  • you only need to define the metric
  • there is not enough evidence to go beyond framing and hypothesis generation

Required thinking discipline

  • Keep observation, inference, hypothesis, and recommendation separate.
  • Include measurement risk as a possible explanation.
  • Avoid causal certainty unless evidence supports it.
  • Evidence constraint: Every conclusion must cite specific data — a number, a rate, a segment, or a timeframe. Do not speculate without evidential basis. If data is insufficient, state what is missing rather than asserting an unsupported inference.

Workflow

  1. State the metric, timeframe, and baseline.
  2. Summarize what changed in direct observational terms.
  3. Break down the change by key segments or driver components.
  4. Evaluate candidate causes against the available evidence.
  5. State confidence level for each likely driver.
  6. End with recommended next checks or actions.

Output format

  • Metric change summary
  • Key observations
  • Likely drivers
  • Alternative explanations
  • Confidence and uncertainty
  • Recommended next steps

Good example

Observation: refund-adjusted revenue fell 9% week over week, concentrated in two EU markets.
Inference: the decline is unlikely to be broad-based demand weakness.
Hypothesis: a payment routing issue is the leading candidate because authorization rate fell at the same time.
Recommendation: confirm processor logs and compare fallback success by country.

Bad example

Revenue dropped because the pricing update upset customers.

Why this is bad:

  • it jumps from change to cause
  • it does not show evidence
  • it ignores competing explanations

Practical notes

  • If evidence is weak, say "leading hypothesis" instead of "root cause."
  • If multiple mechanisms exist, rank them instead of forcing one explanation.
  • For generic asks, this is the default diagnostic mode once the metric, timeframe, and baseline are clear.

Optional variants

  • Product incidents: emphasize instrumentation, rollout timing, and affected cohorts.
  • Operations issues: emphasize bottleneck stage and exception categories.