root-cause-analysis

What it does

Structured methodology for investigating failures across software engineering, data quality, AI/ML systems, and UK legal/regulatory compliance. Combines blameless postmortem culture, regulatory expectations, ISO standards, and CAPA into a single executable framework.

How it works

• Triggers when a failure or incident is identified (RCA, root cause, postmortem, incident, breach, CAPA, 5 whys).
• Step 0: Classify the incident by type and severity to select methodology path.
• Step 1: Gather evidence and build a timeline from data sources (logs, deployment/config, communications, pipeline, review queue, user reports) and capture seven key timestamps (deployment, incident start, detection, first responder, root cause identified, mitigation, resolution).
• Step 2: Analyze contributing factors using Ishikawa categories (Software/DevOps and Legal/Compliance) and apply the Five Whys to drill to root causes. Classify factors as Root Cause, Contributing Factor, or Mitigator, and rank by impact, recurrence, and remediation cost.
• Step 3: Determine Corrective and Preventive Actions (CAPA) with action item types: Detect, Prevent, Mitigate, Process, Document. Each item must include fields for id, description, type, owner, due_date, urgency, tracker, and acceptance criteria, with defined SLAs.
• Step 4: Produce the RCA Report using a structured template covering summary, impact, timeline, contributing factors with Five Whys, lessons, action items, audit trail, and sign-off. Includes an incident-specific Section A (Software), Section B (Data Quality), Section C (AI/ML), etc., with diagnostic questions.

When to use it

Use when there is a system failure, data quality issue, AI/ML misbehavior, or regulatory/nonconformity. Trigger conditions include outages, data issues, hallucinations, breaches, or postmortem requests. Severity guidance applies when the incident could recur or has regulatory implications.

What it can touch

Relies on tools and artifacts such as monitoring logs, deployment/config data, communication records, pipeline audit logs, review queues, and user reports. Action items reference external trackers (e.g., JIRA/Linear/GitHub URL) and require owners and due dates.

Caveats

Blameless analysis and regulatory alignment are emphasized; outcomes depend on collected evidence. The framework prescribes structure and documentation, including a tamper-evident record for posterity and compliance.