Root Cause Analysis (RCA) Toolkits

Chapter 1
Foundations and Strategic Context of Root Cause Analysis

Post Graduate Program in Total Quality Management
Root Cause Analysis (RCA) Toolkits   •   Post Graduate

Foundations and Strategic Context of Root Cause Analysis

Introduction

Root Cause Analysis (RCA) is a disciplined approach for understanding why an undesirable event, defect, failure, or performance gap occurred and for preventing its recurrence. Although the term is widely used in quality, safety, engineering, healthcare, information technology, logistics, and public administration, RCA is often misunderstood. It is not simply asking “Why?” repeatedly, assigning blame, or producing a plausible explanation after an incident. High-quality RCA is an evidence-based investigation of causal relationships within a system.

For a postgraduate quality professional, RCA should be understood as both a problem-solving method and a management philosophy. It connects operational events with processes, controls, decisions, organizational conditions, and external influences. Its purpose is not merely to restore performance after failure, but to improve the capability of the system that produced the outcome.

RCA is therefore closely related to Total Quality Management (TQM). TQM emphasizes customer focus, process management, prevention, continual improvement, employee involvement, leadership responsibility, and decisions based on evidence. RCA provides a structured means of converting an observed problem into organizational learning and corrective action.

Learning Objectives

By the end of this chapter, the reader should be able to:

  1. Define RCA and distinguish its principal terms.
  2. Explain the historical development of modern RCA practices.
  3. Differentiate symptoms, apparent causes, contributing factors, and root causes.
  4. Apply systems thinking to quality and operational failures.
  5. Relate RCA to TQM, the Plan–Do–Check–Act cycle, corrective action, risk management, and continual improvement.
  6. Evaluate the strengths and limitations of common RCA approaches.
  7. Formulate an evidence-based causal explanation without prematurely assigning blame.
  8. Recognize ethical, governance, and implementation requirements for effective RCA.

1. The Meaning and Purpose of RCA

A useful definition is:

Root Cause Analysis is a structured process for identifying and validating the underlying conditions and causal mechanisms that allowed an undesirable outcome to occur, with the aim of implementing effective and sustainable controls.

Several features are important in this definition.

Structured means that the investigation follows a transparent method rather than intuition alone. Identifying means generating possible explanations. Validating means testing those explanations against evidence. Underlying conditions include process design, resources, competence, technology, communication, incentives, and governance. Causal mechanisms explain how conditions combined to produce the event. Finally, sustainable controls are actions that reduce recurrence risk rather than merely correcting the immediate error.

RCA is usually initiated by an outcome such as:

  • a product nonconformance;
  • a customer complaint;
  • a service delay;
  • an equipment failure;
  • a safety incident or near miss;
  • a data-quality error;
  • a regulatory deviation;
  • an information-security event; or
  • a recurring process variation.

The existence of an undesirable outcome does not automatically imply that one person, one machine, or one decision is the cause. Complex outcomes commonly arise from interactions among multiple conditions. A sound investigation therefore asks not only, “What failed?” but also, “Why did the system make this failure possible, likely, or difficult to detect?”

RCA terminology

TermMeaningTypical question
Problem statementA precise description of the undesired gap or eventWhat happened, where, when, and compared with what requirement?
SymptomThe visible manifestation of a problemWhat was observed?
Failure modeThe manner in which a process, product, or control failedHow did failure appear?
Apparent causeThe first plausible explanation identifiedWhat seems to have caused it?
Contributing factorA condition that increased likelihood or severityWhat helped the event occur or worsen?
Proximate causeThe condition immediately preceding the outcomeWhat directly produced the event?
Root causeA validated underlying cause whose control materially reduces recurrenceWhat must change to prevent recurrence?
Corrective actionAction taken to eliminate the cause of a detected nonconformityWhat will prevent this problem from recurring?
CorrectionAction taken to contain or remedy the immediate problemWhat restores the situation now?
EffectivenessThe extent to which action achieves its intended resultDid the action work sustainably?

These categories are analytically distinct but may overlap in ordinary conversation. For example, “operator entered the wrong value” may be a proximate cause. The deeper contributing factors may include a confusing interface, inadequate verification, workload pressure, and a procedure that does not specify an independent check.

2. Symptoms, Causes, and the Causal Chain

A symptom is an observable indication that performance differs from a requirement or expectation. A shipment delivered two days late, a component dimension outside tolerance, or a patient receiving an incorrect appointment time are symptoms or outcomes. They are important, but they do not explain themselves.

An apparent cause is a plausible explanation that has not yet been adequately tested. Investigators often stop at apparent causes because they are visible and easy to describe. This creates a risk of superficial corrective action. If a report states that “human error caused the defect,” it may be factually accurate at one level but incomplete as an explanation.

A contributing factor does not necessarily create the event by itself. It changes the probability, timing, severity, or detectability of the event. Examples include inadequate staffing, ambiguous specifications, poor lighting, unstable suppliers, ineffective escalation, and excessive process complexity.

A root cause is not necessarily the first or deepest cause in an unlimited philosophical sense. In practical quality management, it is a cause that is sufficiently fundamental, evidence-supported, and actionable that controlling it significantly reduces the likelihood of recurrence. A single event may have several root causes, especially when independent causal pathways converge.

A useful causal chain is:

Outcome → proximate cause → contributing conditions → systemic causes → control improvement

For example:

Late delivery → order released after the daily dispatch cut-off → planner lacked current capacity information → planning system and performance measures were not integrated → establish real-time capacity visibility and revise release controls.

The final action is stronger than simply instructing the planner to “be more careful.” It changes the conditions under which the error occurred.

3. Historical Development

RCA has no single inventor. It developed through several overlapping traditions.

Industrial quality and statistical thinking

Early twentieth-century quality work shifted attention from final inspection toward process control. Walter A. Shewhart demonstrated that variation should be understood statistically and that stable processes require different responses from unusual, assignable causes. W. Edwards Deming extended this view by emphasizing systems, management responsibility, variation, and learning. Joseph M. Juran distinguished between sporadic problems and chronic problems and promoted systematic improvement through managerial control and planning.

This historical transition was significant. If defects are treated only as the result of careless individuals, organizations tend to increase inspection or discipline. If defects are treated as signals of process variation and system design, organizations investigate inputs, methods, controls, and feedback.

Japanese quality practices and structured problem solving

Japanese manufacturing organizations developed highly visual and participative approaches to problem solving. The 5 Whys method became associated with tracing a problem through successive causal questions. The fishbone diagram, also called the Ishikawa or cause-and-effect diagram, organized possible causes into categories such as people, methods, machines, materials, measurement, and environment.

These methods are useful for generating and organizing hypotheses. They do not, by themselves, prove causation. A cause-and-effect diagram is a reasoning aid, not empirical evidence.

Reliability, safety, and human-factors engineering

Reliability engineering introduced tools such as Failure Mode and Effects Analysis (FMEA), fault-tree analysis, event-tree analysis, and reliability-centered maintenance. Safety-critical industries developed more formal methods because failures could have catastrophic consequences. Human-factors research further challenged the assumption that errors are isolated personal failures. It examined workload, interface design, training, organizational decisions, communication, and defenses.

James Reason’s “Swiss cheese” model popularized the idea that accidents often occur when weaknesses in multiple defensive layers align. Contemporary safety approaches increasingly distinguish Safety-I, which focuses on preventing adverse outcomes, from Safety-II, which studies how everyday work usually succeeds and how performance adapts under varying conditions.

Management systems and corrective action

International management standards institutionalized requirements for nonconformity control, corrective action, documented evidence, risk-based thinking, and continual improvement. Modern RCA is consequently embedded in broader management systems rather than treated as an isolated investigation technique.

4. Systems Thinking and Causation

Linear and systems explanations

A linear explanation treats an event as a sequence with a dominant cause: A caused B, which caused C. This can be appropriate for simple mechanical failures. However, organizational failures are often nonlinear. Outcomes emerge from interactions among people, technologies, processes, suppliers, regulations, and changing conditions.

Systems thinking examines:

  • boundaries: what is included in the investigation and what is excluded;
  • elements: people, equipment, information, materials, rules, and resources;
  • relationships: dependencies, handoffs, feedback, and communication;
  • purpose: the goals the system is expected to achieve;
  • constraints: time, cost, capacity, regulation, and safety requirements;
  • feedback: information used to adjust performance; and
  • unintended consequences: effects created by apparently reasonable decisions.

A system may produce a failure even when each individual acts according to local incentives. For example, a purchasing department may reduce unit cost, production may maximize utilization, and distribution may minimize inventory. Together, these decisions can produce long lead times and poor customer service.

Necessary, sufficient, and enabling conditions

A cause may be necessary if the outcome would not occur without it. It is sufficient if its presence alone can produce the outcome under specified conditions. Many organizational causes are neither individually necessary nor sufficient; they are enabling or contributing conditions that combine with others.

RCA should therefore avoid the false assumption that every event has one unique cause. A more defensible question is: “Which conditions and mechanisms made the outcome possible, and which interventions would most effectively reduce recurrence risk?”

The hierarchy of controls

In safety and quality improvement, controls can be considered in terms of their strength. Elimination of a hazardous step is generally stronger than relying on memory. Engineering controls, automation, interlocks, physical separation, standardization, training, warnings, and personal vigilance differ in reliability. Administrative instructions alone may be necessary but are often vulnerable to workload, turnover, and variation in interpretation.

This principle applies beyond safety. A barcode validation rule is usually a stronger error control than a reminder to check a label. A system constraint preventing an invalid transaction is stronger than post-event inspection.

5. RCA Within Total Quality Management

RCA supports TQM through several linkages.

Customer focus

The problem definition should identify the affected customer or stakeholder and the relevant requirement. A defect is not defined only by internal inconvenience; it is defined in relation to customer value, contractual obligation, safety, reliability, or regulatory expectation.

Process orientation

TQM views results as outputs of processes. RCA maps the process that produced the outcome, including upstream inputs and downstream consequences. This prevents the investigation from focusing narrowly on the final point of failure.

Prevention rather than detection

Inspection can identify nonconforming output, but it does not necessarily prevent the conditions that produced it. RCA seeks preventive and mistake-proofing controls. Detection remains valuable, particularly where prevention is impossible, but detection alone may permit waste and repeated failure.

PDCA and improvement

RCA can be integrated with the Plan–Do–Check–Act cycle:

  • Plan: define the problem, collect evidence, analyze causes, and select actions;
  • Do: implement actions on an appropriate scale;
  • Check: measure recurrence, process performance, and unintended effects;
  • Act: standardize successful changes and revise the system when results are inadequate.

RCA is therefore not complete when a report is approved. It is complete only when actions are implemented, verified, and incorporated into organizational learning.

Corrective action and risk management

Corrective action addresses the cause of an existing nonconformity. Preventive thinking addresses potential failure before it occurs. Contemporary quality systems often integrate both through risk-based thinking. RCA provides retrospective learning; tools such as FMEA provide prospective analysis. They are complementary rather than interchangeable.

6. A Disciplined RCA Logic

A robust investigation usually follows these stages:

  1. Recognize and contain the problem. Protect customers, people, assets, and data. Containment is not the same as root-cause correction.
  2. Define the problem precisely. State what happened, where, when, magnitude, requirement, and impact. Avoid causal language in the initial statement.
  3. Establish the facts. Preserve records, samples, system logs, photographs, measurements, interviews, and timelines.
  4. Map the process and event sequence. Identify handoffs, decisions, controls, and deviations.
  5. Generate possible causes. Use brainstorming, 5 Whys, cause-and-effect diagrams, fault trees, process analysis, or data stratification.
  6. Test causes against evidence. Ask whether the proposed cause was present, whether it could produce the effect, and whether similar cases support the relationship.
  7. Identify systemic opportunities. Examine design, training, workload, technology, supplier management, supervision, metrics, and governance.
  8. Select actions. Prefer actions that remove, prevent, detect, or contain the causal mechanism in a reliable manner.
  9. Implement and verify. Assign ownership, deadlines, resources, and success measures.
  10. Share learning. Update procedures, standards, training, risk registers, and related processes.

The 5 Whys: value and limitations

The 5 Whys is a questioning discipline, not a rule requiring exactly five questions. The number of questions depends on the complexity of the causal chain. It is most effective for relatively focused problems and when each answer is supported by evidence.

Its limitations include:

  • producing a single-chain explanation for a multifactor event;
  • confusing correlation with causation;
  • accepting unsupported answers;
  • stopping at individual behavior; and
  • overlooking conditions outside the immediate process.

For complex events, the 5 Whys should be supplemented by timelines, causal trees, data analysis, and cross-functional review.

Cause-and-effect diagrams

A fishbone diagram helps a team organize hypotheses under categories. Common categories in manufacturing are the 6 Ms: Manpower, Machine, Method, Material, Measurement, and Mother Nature or environment. Service organizations may use people, process, technology, policy, information, and environment. Categories should be adapted to the system rather than treated as universal law.

Fault-tree and event-tree reasoning

Fault-tree analysis begins with an undesired top event and decomposes it through logical relationships. An OR gate means any listed event may produce the higher-level event; an AND gate means all specified conditions are required in the modeled logic. Event-tree analysis begins with an initiating event and examines possible consequences according to the success or failure of safeguards. These approaches are valuable where safety, reliability, or regulatory assurance requires explicit logic.

7. Illustrative Case: Recurring Incorrect Medication Labels

The following is a fictional illustrative case designed for educational purposes.

Background

A hospital pharmacy reported six incorrect medication labels over three months. No patient received a harmful dose because the errors were detected during final verification. Management initially proposed retraining pharmacy technicians.

Problem definition

The problem was defined as: “Six labels containing incorrect dosage instructions were generated during the evening dispensing process between January and March, compared with the requirement that every label accurately reflect the authorized prescription.” This statement identifies the outcome, location, period, and standard without presuming the cause.

Analysis

A review of records showed that all six errors occurred during periods of high workload. The dispensing software displayed the dosage in one field and the pharmacist’s verification screen displayed it in another. In four cases, the prescription had been amended shortly before dispensing. The amendment indicator was visually subtle. Technicians were expected to compare the original prescription, amended order, and generated label manually.

Interviews found that technicians had received training and could describe the procedure. However, the procedure did not define a separate confirmation step for amended prescriptions. Staffing levels were based on average volume rather than peak evening demand. The final pharmacist check detected the errors, but the process provided no feedback trend to the software or staffing teams.

Causal interpretation

The immediate cause was a mismatch between the authorized dosage and the printed label. Human transcription or selection error was a proximate cause in several cases. Contributing factors included workload peaks, visually weak amendment alerts, multiple information displays, and reliance on manual comparison. A systemic root cause was inadequate design and governance of the amended-prescription workflow: the system did not reliably distinguish changed orders or force an independent verification before label generation.

Approach and solution

The team implemented four actions:

  1. The software was modified to display amendments prominently and require acknowledgment.
  2. Label generation was blocked until the amended order was confirmed.
  3. Evening staffing was reviewed using hourly demand data.
  4. A monthly dashboard tracked labeling errors, near misses, detection points, and recurrence.

Retraining was retained as a supporting action, but it was not treated as the primary control.

Outcome

During the following six months, no incorrect medication labels were reported. Audits showed increased compliance with amendment confirmation, and the number of errors detected only at final verification declined. The team also identified a similar risk in outpatient prescriptions and extended the software control.

Learning points

The case illustrates five principles:

  • a symptom can be detected without its cause being understood;
  • “human error” may describe what happened but not why the system permitted it;
  • controls embedded in workflow are generally stronger than reminders;
  • near misses provide valuable RCA evidence; and
  • effectiveness requires follow-up measurement and transfer of learning.

8. Governance, Ethics, and Professional Judgment

RCA has ethical consequences because findings may affect careers, contracts, regulatory reporting, and public trust. Investigators should distinguish accountability from blame. Accountability asks whether responsibilities, controls, and decisions were appropriate; blame prematurely attributes moral fault without examining context and evidence.

A fair investigation should:

  • use a clearly defined scope;
  • preserve confidentiality where appropriate;
  • protect good-faith reporting;
  • avoid retrospective judgment based on information unavailable at the time;
  • include relevant workers and subject-matter experts;
  • document evidence and uncertainty;
  • separate fact, inference, and opinion; and
  • ensure that recommendations are proportionate to risk.

RCA should not be used to conceal misconduct, avoid mandatory reporting, or replace formal disciplinary or legal processes where those are required. Conversely, disciplinary action should not be used as a substitute for understanding system weaknesses.

9. Technology, Data, and Contemporary Developments

Digital systems improve RCA by providing timestamps, audit trails, sensor data, workflow histories, and trend information. Process mining can reconstruct actual process paths from event logs and reveal rework, bottlenecks, and deviations from standard workflows. Statistical monitoring can identify recurrence patterns and stratify problems by product, shift, supplier, location, or process step.

Artificial intelligence can assist with document review, event clustering, anomaly detection, and generation of candidate causal hypotheses. However, AI-generated explanations are not automatically causal findings. They may reflect biased data, omit undocumented work, confuse correlation with mechanism, or reproduce historical assumptions. Human investigators remain responsible for validating evidence, protecting sensitive information, and judging whether an intervention is ethically and operationally appropriate.

Contemporary RCA increasingly integrates resilience engineering, human factors, complexity theory, safety science, and operational learning. The focus is moving from isolated incident investigation toward continuous monitoring of weak signals, adaptations, and conditions that make failure more or less likely.

10. Challenges and Limitations

RCA is powerful but not infallible. Common challenges include:

  • incomplete or altered evidence;
  • hindsight bias;
  • pressure to close investigations quickly;
  • organizational defensiveness;
  • inadequate technical expertise;
  • confusing coincidence with causation;
  • selecting actions that are easy rather than effective;
  • excessive focus on a single event;
  • failure to consider normal work and successful recovery; and
  • lack of resources for implementation.

RCA also has boundaries. It cannot eliminate all uncertainty, predict every future failure, or guarantee that an action will work under changed conditions. A causal explanation is always related to a defined system boundary, time period, and evidence base. Therefore, conclusions should be stated with appropriate confidence rather than absolute certainty.

Best-Practice Principles

  1. Define the problem before proposing causes.
  2. Use evidence, not plausibility alone.
  3. Involve the people who perform and manage the work.
  4. Examine process design and organizational conditions.
  5. Treat human error as a starting point for inquiry, not an endpoint.
  6. Consider multiple causal pathways.
  7. Prefer robust controls over reminders and retraining alone.
  8. Assign owners, resources, deadlines, and measures to actions.
  9. Verify effectiveness after implementation.
  10. Share learning across comparable processes.
  11. Record uncertainty and alternative explanations.
  12. Maintain fairness, confidentiality, and proportionality.

Chapter Summary

Root Cause Analysis is a structured, evidence-based method for understanding why undesirable outcomes occur and for designing controls that reduce recurrence. Its central distinction is between the visible symptom, the proximate or apparent cause, contributing factors, and validated systemic root causes. RCA developed from statistical quality control, industrial engineering, reliability analysis, safety science, human-factors research, and management-system practice.

Systems thinking is essential because organizational failures commonly arise from interactions among people, processes, technology, resources, incentives, and external conditions. RCA supports TQM through customer focus, process orientation, prevention, PDCA, corrective action, risk-based thinking, and continual improvement. Tools such as the 5 Whys, fishbone diagrams, fault trees, process mapping, and data analysis support reasoning, but none replaces evidence-based judgment.

Effective RCA separates containment from correction, avoids premature blame, tests causal explanations, selects strong controls, and verifies results. Ethical practice requires fairness, transparency, protection of good-faith reporting, and a clear distinction between learning and discipline. Digital technologies and AI can strengthen evidence gathering and pattern recognition, but causal conclusions require human validation and responsible governance.

Key Terms

Root Cause Analysis: A structured investigation of underlying causes and causal mechanisms of an undesirable outcome.

Symptom: The observable manifestation or consequence of a problem.

Problem statement: A precise description of an undesired gap, event, requirement, and impact.

Failure mode: The manner in which a process, product, or control fails.

Apparent cause: A plausible explanation that has not yet been sufficiently validated.

Proximate cause: The condition immediately preceding and directly producing an outcome.

Contributing factor: A condition that increases the likelihood, severity, or detectability of an event.

Root cause: An evidence-supported underlying cause whose control materially reduces recurrence.

Correction: Immediate action taken to contain or remedy an identified problem.

Corrective action: Action taken to eliminate the cause of a detected nonconformity.

Systems thinking: Analysis of elements, relationships, boundaries, purposes, constraints, and feedback within a system.

5 Whys: An iterative questioning method used to explore causal relationships.

Fishbone diagram: A structured cause-and-effect diagram for organizing possible causes.

Fault-tree analysis: A top-down logical analysis of combinations of events leading to an undesired outcome.

PDCA: Plan–Do–Check–Act cycle for controlled continual improvement.

Human factors: The study of how people interact with tasks, technologies, environments, and organizations.

Containment: Temporary action that limits impact while causes are investigated.

Effectiveness: The degree to which an implemented action achieves its intended result.

Near miss: An event that could have caused harm or nonconformity but did not.

Just culture: An approach that balances learning, fair accountability, and appropriate responsibility.

Review Questions

5 Short Answer Questions

  1. Define Root Cause Analysis and explain its principal purpose.
  2. What is the difference between a symptom and a root cause?
  3. Why is “human error” usually an incomplete RCA conclusion?
  4. State two ways in which RCA supports Total Quality Management.
  5. What is the purpose of containment during an investigation?

5 Long Answer Questions

  1. Explain the historical development of RCA from statistical quality control, reliability engineering, and safety science.
  2. Compare linear causation with systems thinking in the investigation of organizational failures.
  3. Describe a disciplined RCA process from problem definition through effectiveness verification.
  4. Explain the strengths and limitations of the 5 Whys and fishbone diagram.
  5. Discuss the ethical responsibilities of an RCA team when findings may affect individual employees.

3 Analytical / Application Questions

  1. A manufacturing line produces repeated defects only during the night shift. Develop a problem statement, identify possible contributing factors, and propose evidence needed to distinguish an apparent cause from a root cause.
  2. A service organization responds to recurring delays by instructing employees to “work more carefully.” Evaluate this action using systems thinking and recommend stronger controls.
  3. Using the illustrative medication-label case, explain how the investigation could have failed if it had stopped at “technician made a selection error.” Propose two additional measures for verifying long-term effectiveness.

Multiple Choice Questions with Answers

Question 1

Which statement best defines Root Cause Analysis?

A. A method for assigning responsibility to the person nearest the failure

B. A structured investigation of underlying causes and causal mechanisms to reduce recurrence

C. A final inspection performed after a process is completed

D. A technique used only for equipment breakdowns

Correct Answer: B. A structured investigation of underlying causes and causal mechanisms to reduce recurrence

Question 2

Which of the following is a symptom rather than a root cause?

A. A confusing software interface

B. Insufficient peak-period staffing

C. A shipment delivered two days late

D. Lack of capacity information

Correct Answer: C. A shipment delivered two days late

Question 3

Why should an RCA team avoid stopping at “human error”?

A. Human errors never occur in organizations

B. It may describe the action but not the conditions that made the error likely

C. Human error is always caused by equipment failure

D. It prevents any form of corrective action

Correct Answer: B. It may describe the action but not the conditions that made the error likely

Question 4

What is the principal purpose of containment?

A. To permanently eliminate every possible cause

B. To limit immediate impact while the causes are investigated

C. To replace evidence collection

D. To assign disciplinary responsibility

Correct Answer: B. To limit immediate impact while the causes are investigated

Question 5

Which TQM principle is most directly supported when RCA examines the process that produced a defect?

A. Process orientation

B. Market segmentation

C. Financial depreciation

D. Product advertising

Correct Answer: A. Process orientation

Question 6

What is a major limitation of the 5 Whys?

A. It cannot be used to ask causal questions

B. It always requires exactly five answers

C. It may oversimplify multifactor events into a single causal chain

D. It is suitable only for statistical calculations

Correct Answer: C. It may oversimplify multifactor events into a single causal chain

Question 7

Which action is generally a stronger control than a reminder to check a label?

A. A poster near the workstation

B. An instruction to be more careful

C. A system rule that blocks label generation until an amended order is confirmed

D. A verbal warning after an error

Correct Answer: C. A system rule that blocks label generation until an amended order is confirmed

Question 8

In the PDCA cycle, checking whether corrective action reduced recurrence belongs primarily to which stage?

A. Plan

B. Do

C. Check

D. Act

Correct Answer: C. Check

Question 9

Which statement about an apparent cause is correct?

A. It is always the deepest possible explanation

B. It is a plausible explanation that still requires validation

C. It is identical to a symptom

D. It cannot be changed through corrective action

Correct Answer: B. It is a plausible explanation that still requires validation

Question 10

Why should AI-generated causal explanations be validated by human investigators?

A. AI cannot process any operational data

B. AI outputs may confuse correlation with causation or reflect biased data

C. AI is legally prohibited from identifying patterns

D. Human investigators do not need evidence

Correct Answer: B. AI outputs may confuse correlation with causation or reflect biased data

Root Cause Analysis (RCA) Toolkits
Chapter 1 of 14