WHY ENGLISH?
Turn a failure into evidence, causes and safer action
Use the routes to preserve the event, test causal explanations, write proportionate findings and connect corrective action to verification.
Open the full contents · See the How English Works hub
Full contents
Frame the event
Build evidence
Analyse causes
Design actions
Verify learning
Practice and next steps
Practice and next steps
Practice and next steps
Practice and next steps
A root cause analysis report explains why an unwanted event happened, which conditions allowed it, what evidence supports the explanation and how the organisation will reduce recurrence. English matters because a neat diagram can still be wrong if its causal verbs, certainty levels and action statements are vague.
People searching for root cause analysis reports, five whys, fishbone diagrams, incident investigations, corrective action reports or failure analysis often want a template. A sound report needs more: preserved evidence, a bounded question, chronology, tested causal links, distinction between root and contributing causes, human-and-system context, feasible actions, owners and verification.
NASA's published root cause analysis guidance describes RCA as part of investigating close calls, anomalies and failures. Its format for causes, findings and recommendations distinguishes dominant and contributing root causes, observations, findings and recommendations, while the current NASA mishap-investigation page notes that root cause analysis is necessary for mishaps even though not every analytical element appears in the final report. These sources belong to NASA's system; a school, laboratory, hospital or company must use its own applicable process and specialist standards.
Use the RCA map event, scope, consequence, immediate response, evidence, source, timestamp, state, barrier, change, deviation, condition, mechanism, cause, contributing factor, root cause, observation, finding, uncertainty, counterfactual, control, recommendation, corrective action, owner, due date, completion, effectiveness, recurrence, trend and learning. The goal is prevention through explanation, not blame through hindsight.
Define the event
Frame the investigation around the specific unwanted outcome or near miss being analysed. A precise event statement keeps analysis from turning into blame.
The causal story distorts when the investigation begins with why the team failed.
Preserve the boundary and write an observable event statement.
Event example. A batch exceeded the temperature limit for seventeen minutes before automatic shutdown The question is now investigable.
Did You Know? NASA's published framework distinguishes root and contributing causes, significant observations, findings and recommendations, showing why these labels should not be used interchangeably. This is why the specific unwanted outcome or near miss being analysed needs a precise, dated record.
State the consequence
Build evidence for the actual and potential effects on people, service, data, quality or assets before choosing an explanation.
Confirmation bias grows when severity is implied through emotional language.
Compare independent sources and quantify known effects and label uncertainty.
Evidence example. No injury occurred, twelve samples were unusable and a larger exposure was plausible The record can be challenged and checked.
Label estimated times, missing records and source conflicts rather than smoothing them away.
Set the scope
Test the processes, time period, locations and interfaces included as a causal mechanism, not merely a nearby fact.
The report stops too early when the report expands into every organisational weakness.
Use counterfactual and barrier questions, then justify boundaries and record excluded questions.
Cause example. The analysis covers sample preparation through freezer storage, not upstream recruitment The link is specific enough to support action.
Distinguish root cause, contributing cause, observation and finding under the authorised method.
Name the investigation authority
Translate the person or group authorised to preserve evidence, interview and approve findings into a stronger control and verification plan.
Learning fails when an informal team promises actions outside its remit.
Connect owner, due date, completion evidence and record sponsor, lead and independence safeguards.
Action example. A quality lead chairs while the line manager supplies records but does not approve the finding Implementation and effectiveness can be tested separately.
Keep interim controls visible until the permanent action is accepted and shown to work.
Separate response from analysis
Frame the investigation around the immediate steps to make the situation safe versus later causal work. A precise event statement keeps analysis from turning into blame.
The causal story distorts when containment is reported as prevention.
Preserve the boundary and label containment, correction and corrective action.
Event example. Quarantining the batch stops use; it does not explain the temperature excursion The question is now investigable.
Separate what happened, what it meant and what remains uncertain.
Preserve volatile evidence
Build evidence for the logs, configurations, physical state and memories that may change before choosing an explanation.
Confirmation bias grows when cleanup erases the event trail.
Compare independent sources and capture evidence under authorised controls.
Evidence example. System logs and alarm settings are exported before reset The record can be challenged and checked.
Did You Know? NASA's published framework distinguishes root and contributing causes, significant observations, findings and recommendations, showing why these labels should not be used interchangeably. This is why the logs, configurations, physical state and memories that may change needs a precise, dated record.
Create an evidence register
Test the source, custodian, time, relevance and integrity of each item as a causal mechanism, not merely a nearby fact.
The report stops too early when screenshots appear without context.
Use counterfactual and barrier questions, then assign identifiers and note limitations.
Cause example. A photo is linked to device, timestamp and photographer The link is specific enough to support action.
Distinguish root cause, contributing cause, observation and finding under the authorised method.
Assess source reliability
Translate the strengths and limits of records, interviews and measurements into a stronger control and verification plan.
Learning fails when a confident recollection overrides a system record automatically.
Connect owner, due date, completion evidence and compare independent sources and explain conflicts.
Action example. Two clock systems differ by four minutes and the timeline adjusts transparently Implementation and effectiveness can be tested separately.
Keep interim controls visible until the permanent action is accepted and shown to work.
Protect records and privacy
Frame the investigation around the access, retention and disclosure controls for investigation material. A precise event statement keeps analysis from turning into blame.
The causal story distorts when the lesson is published with unnecessary personal details.
Preserve the boundary and use need-to-know handling and redaction.
Event example. Training extracts remove names while preserving the control failure The question is now investigable.
Separate what happened, what it meant and what remains uncertain.
Build a common timeline
Build evidence for the ordered sequence of states, actions, signals and decisions before choosing an explanation.
Confirmation bias grows when the final failure is treated as the first cause.
Compare independent sources and synchronise clocks and mark estimated times.
Evidence example. The sensor alert preceded the operator screen freeze by ninety seconds The record can be challenged and checked.
Label estimated times, missing records and source conflicts rather than smoothing them away.
Describe normal work
Test the intended process, resources and decision points before comparing deviation as a causal mechanism, not merely a nearby fact.
The report stops too early when procedure text is assumed to equal actual practice.
Use counterfactual and barrier questions, then map work as designed and work as performed.
Cause example. The written checklist requires a second check, while staffing made simultaneous coverage difficult The link is specific enough to support action.
Did You Know? NASA's published framework distinguishes root and contributing causes, significant observations, findings and recommendations, showing why these labels should not be used interchangeably. This is why the intended process, resources and decision points before comparing deviation needs a precise, dated record.
Locate the change point
Translate the moment or condition when the process departed from expected control into a stronger control and verification plan.
Learning fails when every earlier imperfection is called causal.
Connect owner, due date, completion evidence and compare stable and failed cases.
Action example. Incidents began after a software update changed the default timeout Implementation and effectiveness can be tested separately.
Keep interim controls visible until the permanent action is accepted and shown to work.
Identify failed barriers
Frame the investigation around the controls intended to prevent, detect or reduce the event. A precise event statement keeps analysis from turning into blame.
The causal story distorts when absence of a rule is treated as the only problem.
Preserve the boundary and test whether barriers existed, were usable and worked.
Event example. An alarm fired but its message did not identify the affected freezer The question is now investigable.
Separate what happened, what it meant and what remains uncertain.
Distinguish active failure and latent condition
Build evidence for the immediate action versus the system conditions shaping it before choosing an explanation.
Confirmation bias grows when the last person touching the process becomes the root cause.
Compare independent sources and ask what made the action possible and likely.
Evidence example. A wrong selection occurred within an interface that displayed nearly identical labels The record can be challenged and checked.
Label estimated times, missing records and source conflicts rather than smoothing them away.
Use the five whys carefully
Test an iterative question that explores a causal chain as a causal mechanism, not merely a nearby fact.
The report stops too early when five answers are forced into one straight line.
Use counterfactual and barrier questions, then branch when evidence shows multiple mechanisms.
Cause example. Late calibration and ambiguous handover form separate contributing paths The link is specific enough to support action.
Distinguish root cause, contributing cause, observation and finding under the authorised method.
Use a cause map
Translate the network connecting conditions, actions, barriers and outcome into a stronger control and verification plan.
Learning fails when a fishbone category is treated as proof.
Connect owner, due date, completion evidence and attach evidence and confidence to each link.
Action example. Maintenance backlog is linked to a missed test through dated work orders Implementation and effectiveness can be tested separately.
Did You Know? NASA's published framework distinguishes root and contributing causes, significant observations, findings and recommendations, showing why these labels should not be used interchangeably. This is why the network connecting conditions, actions, barriers and outcome needs a precise, dated record.
Test causal language
Frame the investigation around whether the claimed factor helped produce the event rather than merely coexisted. A precise event statement keeps analysis from turning into blame.
The causal story distorts when because appears without a mechanism.
Preserve the boundary and write the physical, informational or decision pathway.
Event example. The seal leaked because uneven compression left a measured gap The question is now investigable.
Separate what happened, what it meant and what remains uncertain.
Use counterfactual questions
Build evidence for whether changing a factor would plausibly alter the event under the same conditions before choosing an explanation.
Confirmation bias grows when but for reasoning is treated as certainty.
Compare independent sources and test necessary and sufficient roles cautiously.
Evidence example. A clearer alert likely enables earlier response but does not prevent the sensor fault The record can be challenged and checked.
Label estimated times, missing records and source conflicts rather than smoothing them away.
Distinguish root and contributing causes
Test the basic system cause versus conditions that increased likelihood or severity as a causal mechanism, not merely a nearby fact.
The report stops too early when every item receives the prestigious root label.
Use counterfactual and barrier questions, then apply the organisation's defined criteria.
Cause example. Weak change control is root; high workload contributed to delayed detection The link is specific enough to support action.
Distinguish root cause, contributing cause, observation and finding under the authorised method.
Separate cause from observation
Translate an important fact that may not causally explain the event into a stronger control and verification plan.
Learning fails when all notable weaknesses become causes.
Connect owner, due date, completion evidence and classify observations and address them proportionately.
Action example. An outdated poster is corrected but did not influence this automated failure Implementation and effectiveness can be tested separately.
Keep interim controls visible until the permanent action is accepted and shown to work.
Write a finding
Frame the investigation around the evidence-based conclusion connecting requirement, condition and significance. A precise event statement keeps analysis from turning into blame.
The causal story distorts when a finding is just a topic label.
Preserve the boundary and state what should be, what was and why it matters.
Event example. Backup testing was required monthly, absent for three months and left recovery unverified The question is now investigable.
Did You Know? NASA's published framework distinguishes root and contributing causes, significant observations, findings and recommendations, showing why these labels should not be used interchangeably. This is why the evidence-based conclusion connecting requirement, condition and significance needs a precise, dated record.
Rate confidence
Build evidence for the strength of support and remaining uncertainty around each causal claim before choosing an explanation.
Confirmation bias grows when the report presents inference as measured fact.
Compare independent sources and use supported, probable, possible and unresolved consistently.
Evidence example. Log evidence strongly supports timeout change while motive remains unknown and irrelevant The record can be challenged and checked.
Label estimated times, missing records and source conflicts rather than smoothing them away.
Look for disconfirming evidence
Test records or cases that challenge the preferred explanation as a causal mechanism, not merely a nearby fact.
The report stops too early when the team gathers only confirming facts.
Use counterfactual and barrier questions, then test successful runs and alternative causes.
Cause example. Two successful shifts after the update reveal an additional network condition The link is specific enough to support action.
Distinguish root cause, contributing cause, observation and finding under the authorised method.
Avoid hindsight bias
Translate the difference between what is obvious now and what was visible then into a stronger control and verification plan.
Learning fails when operators are judged using later knowledge.
Connect owner, due date, completion evidence and reconstruct information available at each decision.
Action example. The dashboard did not display the sensor state during the event Implementation and effectiveness can be tested separately.
Keep interim controls visible until the permanent action is accepted and shown to work.
Analyse procedures
Frame the investigation around whether instructions were current, accessible, coherent and workable. A precise event statement keeps analysis from turning into blame.
The causal story distorts when the solution is automatically more training.
Preserve the boundary and compare procedure with task demand.
Event example. The reset instruction omitted the new confirmation screen The question is now investigable.
Separate what happened, what it meant and what remains uncertain.
Analyse competence and training
Build evidence for the knowledge, practice and support needed for the task before choosing an explanation.
Confirmation bias grows when human error replaces investigation.
Compare independent sources and identify the specific capability gap and its origin.
Evidence example. A technician had classroom training but no supervised recovery exercise The record can be challenged and checked.
Did You Know? NASA's published framework distinguishes root and contributing causes, significant observations, findings and recommendations, showing why these labels should not be used interchangeably. This is why the knowledge, practice and support needed for the task needs a precise, dated record.
Analyse workload and staffing
Test the timing, interruptions, fatigue and coverage influencing performance as a causal mechanism, not merely a nearby fact.
The report stops too early when busy is used as a complete cause.
Use counterfactual and barrier questions, then connect demand to a missed control.
Cause example. One person covered two simultaneous alarms and the escalation threshold was unclear The link is specific enough to support action.
Distinguish root cause, contributing cause, observation and finding under the authorised method.
Analyse design and usability
Translate the interfaces, labels, defaults and feedback shaping action into a stronger control and verification plan.
Learning fails when user carelessness hides predictable design traps.
Connect owner, due date, completion evidence and test the task with representative users.
Action example. Two destructive buttons share colour and location with no confirmation Implementation and effectiveness can be tested separately.
Keep interim controls visible until the permanent action is accepted and shown to work.
Analyse maintenance
Frame the investigation around the inspection, calibration, repair and life-cycle controls for equipment. A precise event statement keeps analysis from turning into blame.
The causal story distorts when age alone is called the cause.
Preserve the boundary and trace condition, work history and failure mechanism.
Event example. A skipped lubrication task increased measured bearing wear The question is now investigable.
Separate what happened, what it meant and what remains uncertain.
Analyse change management
Build evidence for the assessment, testing, approval and communication around change before choosing an explanation.
Confirmation bias grows when the new version is blamed because it is recent.
Compare independent sources and compare changed parameters and validation evidence.
Evidence example. A default timeout changed without regression testing the slow network path The record can be challenged and checked.
Label estimated times, missing records and source conflicts rather than smoothing them away.
Analyse supplier and interface factors
Test the responsibilities and information crossing organisational boundaries as a causal mechanism, not merely a nearby fact.
The report stops too early when the supplier becomes a convenient external cause.
Use counterfactual and barrier questions, then trace specifications, notices and acceptance evidence.
Cause example. A component tolerance met contract but not the buyer's unstated operating range The link is specific enough to support action.
Did You Know? NASA's published framework distinguishes root and contributing causes, significant observations, findings and recommendations, showing why these labels should not be used interchangeably. This is why the responsibilities and information crossing organisational boundaries needs a precise, dated record.
Analyse governance
Translate the priorities, resources, assurance and escalation systems shaping local work into a stronger control and verification plan.
Learning fails when culture is used as an untestable ending.
Connect owner, due date, completion evidence and connect decisions to concrete conditions.
Action example. Repeated deferral of replacement left staff dependent on a known unreliable sensor Implementation and effectiveness can be tested separately.
Keep interim controls visible until the permanent action is accepted and shown to work.
Write proportionate recommendations
Frame the investigation around the control change justified by the causal evidence and risk. A precise event statement keeps analysis from turning into blame.
The causal story distorts when the report recommends fixing everything discovered.
Preserve the boundary and prioritise actions that interrupt the mechanism.
Event example. An interlock prevents operation outside the calibrated range The question is now investigable.
Separate what happened, what it meant and what remains uncertain.
Prefer stronger controls
Build evidence for design, elimination, automation and verification before reminders alone before choosing an explanation.
Confirmation bias grows when training and caution signs carry every risk.
Compare independent sources and use the hierarchy appropriate to the domain.
Evidence example. A keyed connector removes the possibility of reversed installation The record can be challenged and checked.
Label estimated times, missing records and source conflicts rather than smoothing them away.
Keep action and cause traceable
Test the explicit link from each corrective action to the cause or finding it addresses as a causal mechanism, not merely a nearby fact.
The report stops too early when actions accumulate without rationale.
Use counterfactual and barrier questions, then assign identifiers and expected effect.
Cause example. Action CA-03 addresses the unvalidated timeout introduced under Cause RC-02 The link is specific enough to support action.
Distinguish root cause, contributing cause, observation and finding under the authorised method.
Assign an owner
Translate the role with authority and resources to deliver the action into a stronger control and verification plan.
Learning fails when the team or everyone owns it.
Connect owner, due date, completion evidence and name one accountable role and contributors.
Action example. The engineering manager owns interlock design while quality verifies testing Implementation and effectiveness can be tested separately.
Did You Know? NASA's published framework distinguishes root and contributing causes, significant observations, findings and recommendations, showing why these labels should not be used interchangeably. This is why the role with authority and resources to deliver the action needs a precise, dated record.
Set a completion measure
Frame the investigation around the evidence showing the action was implemented as specified. A precise event statement keeps analysis from turning into blame.
The causal story distorts when done means an email said complete.
Preserve the boundary and define artefact, inspection or test.
Event example. Completion requires approved code, deployed version and passed regression record The question is now investigable.
Separate what happened, what it meant and what remains uncertain.
Set an effectiveness measure
Build evidence for the later evidence showing the action reduced recurrence or mechanism before choosing an explanation.
Confirmation bias grows when implementation is assumed effective.
Compare independent sources and monitor leading and outcome indicators.
Evidence example. Alarm recognition time is sampled after redesign and no timeout failures recur over the review period The record can be challenged and checked.
Label estimated times, missing records and source conflicts rather than smoothing them away.
Manage interim controls
Test the temporary safeguards used before permanent correction as a causal mechanism, not merely a nearby fact.
The report stops too early when a workaround becomes the silent permanent system.
Use counterfactual and barrier questions, then give each interim measure an owner and expiry.
Cause example. A daily manual test continues until the interlock passes acceptance The link is specific enough to support action.
Distinguish root cause, contributing cause, observation and finding under the authorised method.
Track residual risk
Translate the risk remaining after confirmed controls and unresolved uncertainty into a stronger control and verification plan.
Learning fails when the report closes because actions were assigned.
Connect owner, due date, completion evidence and reassess with evidence and authority.
Action example. Rare sensor failure remains possible and receives a monitored acceptance decision Implementation and effectiveness can be tested separately.
Keep interim controls visible until the permanent action is accepted and shown to work.
Share learning safely
Frame the investigation around the information other teams need without blame or unnecessary disclosure. A precise event statement keeps analysis from turning into blame.
The causal story distorts when the report is either secret or published in full.
Preserve the boundary and create a redacted mechanism-and-control summary.
Event example. Other labs receive the timeout lesson and test method without personal interview notes The question is now investigable.
Did You Know? NASA's published framework distinguishes root and contributing causes, significant observations, findings and recommendations, showing why these labels should not be used interchangeably. This is why the information other teams need without blame or unnecessary disclosure needs a precise, dated record.
Look for recurrence and trends
Build evidence for similar weak signals across incidents, near misses and audits before choosing an explanation.
Confirmation bias grows when each event is isolated by its local label.
Compare independent sources and use common causal taxonomy cautiously.
Evidence example. Three different outages share untested configuration changes The record can be challenged and checked.
Label estimated times, missing records and source conflicts rather than smoothing them away.
Reopen when evidence changes
Test the process for revising findings after new logs, tests or events as a causal mechanism, not merely a nearby fact.
The report stops too early when publication makes the causal story untouchable.
Use counterfactual and barrier questions, then version the report and explain changes.
Cause example. A recovered controller log replaces a probable cause with a supported one The link is specific enough to support action.
Distinguish root cause, contributing cause, observation and finding under the authorised method.
Validate actions before wide release
Translate the controlled test showing a corrective change works without creating new hazards into a stronger control and verification plan.
Learning fails when a plausible solution is deployed everywhere immediately.
Connect owner, due date, completion evidence and test under representative and failure conditions.
Action example. The redesigned alarm is trialled on normal, delayed and disconnected network states before rollout Implementation and effectiveness can be tested separately.
Keep interim controls visible until the permanent action is accepted and shown to work.
Archive the investigation
Frame the investigation around the approved final report, evidence index, action record and later effectiveness review. A precise event statement keeps analysis from turning into blame.
The causal story distorts when important reasoning remains scattered across chat and personal folders.
Preserve the boundary and store the controlled record with access and retention rules.
Event example. A future investigator can retrieve the signed findings and see which action evidence closed each item The question is now investigable.
Separate what happened, what it meant and what remains uncertain.
A worked example
A laboratory freezer warms above its limit overnight. The first report says the technician forgot to check the alarm and recommends retraining everyone. It contains no synchronised timeline, alarm configuration, staffing context, maintenance history or test of the notification path.
The investigation preserves logs, aligns clocks, maps the normal response and finds that an update reset the notification timeout, the screen hid the sensor state and after-hours ownership was ambiguous. A manual check is introduced temporarily; permanent actions restore configuration control, redesign the alert, test escalation and assign one accountable service owner.
English turns the story from blame into a testable model. Contributed is different from caused; probable is different from proven; containment is different from corrective action; completed is different from effective. Those distinctions determine what the organisation actually learns.
A practical checklist
- Event and consequence bounded
- Authority and scope recorded
- Containment separated from analysis
- Evidence register built
- Timeline synchronised
- Normal and actual work compared
- Barriers and change points tested
- Causal links carry evidence
- Root and contributing causes distinguished
- Uncertainty and alternatives addressed
- Actions trace to causes
- Owners, completion and effectiveness measures set
Advice for students, parents and young adults
Students can practise RCA on a harmless event such as a missed assignment upload. Build a timeline, compare intended and actual process, test more than one cause, and design an action that changes the mechanism rather than blaming motivation.
Parents can support learning by asking what information was available at the time and what system could make the right action easier next time. Avoid turning ordinary mistakes into character judgements.
A root cause report does not replace emergency response, professional engineering, clinical review, legal duties, regulatory reporting or the organisation's authorised investigation method. High-stakes events need competent independent specialists and protected evidence.
Frequently asked questions
Is the root cause always one thing?
No. Complex events can have several interacting root and contributing causes. Use the definitions in the authorised method and preserve uncertainty.
Is human error a root cause?
Usually it is a starting point. Ask what information, design, workload, training, supervision or controls shaped the action and why barriers did not prevent harm.
Does five whys require exactly five questions?
No. It is a prompt for deeper causal inquiry, not a fixed number or proof method. Branch when evidence shows multiple pathways.
What is the difference between correction and corrective action?
Correction fixes the detected problem. Corrective action changes a cause or control to reduce recurrence.
How do we know an action worked?
Define an effectiveness measure, review period and owner. Implementation evidence alone does not prove risk reduction.
Should the full report be shared widely?
Not necessarily. Protect privacy, security, legal privilege and investigation integrity while sharing an appropriate learning summary.
The deeper English lesson
RCA English is causal-and-evidential language. Timelines constrain stories, mechanism verbs test links, confidence words expose uncertainty and action verbs create accountability. The report earns trust when a reader can see how evidence supports cause and how each control will be verified.
Useful next reading
Continue with writing a laboratory report, writing a workplace risk assessment, writing a technical change request, writing a project status update, and the How English Works.