How to learn more from an accident or near miss: why each decision made sense to the people involved at the time, and what to change in the system so it doesn’t happen again.
Choosing an event, comparing the effort fairly, and handling additional recommendations.
Part 1 · CAST’s Focus
Why the Same Accidents Keep Happening
After an accident, there’s strong pressure to find a root cause, fix it, and move on. John Carroll called this “root cause seduction.” The fix usually deals with a symptom. The conditions that produced the accident stay in place, so the next accident looks different on the surface but has the same causes underneath. Safety teams play whack-a-mole: there are so many incidents that each one gets only a quick look.
Nancy Leveson, who created CAST, was once asked by the head of safety at an oil refinery how to choose which of their hundreds of incidents a year to investigate. Her answer was to investigate a few of them in depth, and then there wouldn’t be hundreds.
What a Quick Investigation Tends to Leave Out
Why people’s actions made sense to them at the time, beyond what they did wrong.
Decisions made above the front line: by managers and regulators, about procedures, staffing, and budgets.
Earlier incidents with the same causes, and why those causes weren’t fixed.
Why people believed what they did, given the full context and their past experience.
Why the equipment and software were designed to work the way they did.
The Operator’s Control Loop
The operator’s control loop doesn’t show what’s under the bridge.
Example: The Jet Bridge
A jet bridge is the movable walkway between the terminal and an aircraft door. An operator in a cab at the end raises and lowers it with a joystick. At one airline, operators kept lowering bridges onto vehicles parked underneath, and the cost of the damage kept rising.
Each time, the conclusion was human error: the operator had made a mistake and had not followed the proper procedure. The fixes were aimed at the operators, with discipline, more training, and more specific procedures. One fix was a sign in the cab: “Caution: Do not lower bridge too far… There are designated vehicle parking spots under jet bridge.” Someone had written “Why?” on it in pen. More than a year later, bridges were still coming down on vehicles.
The airline then analyzed the events with CAST, working with Dr. John Thomas. CAST starts by asking why lowering the bridge made sense to the operator. The operator can raise and lower the bridge. The equipment shows them its height, its mode, and any faults, but not what’s under the bridge. They can’t see vehicles below from the cab, they aren’t alerted when a vehicle moves in after they last looked, and the height that counts as “too low” isn’t marked. The procedure was for the operator to step outside and walk around to check the area below. In practice that isn’t always practical, and vehicles can still move in once the operator is back inside the bridge and can’t see them. So the operator lowers the bridge believing there’s room. Given what they last saw, and the information they don’t have, that belief makes sense.
The Loop Above the Operator
CAST then works up the control structure, and the loop above the operator was broken too. Gate Operations Management oversees the jet bridge procedures at the airline, and coordinates with the other groups whose crews work around the aircraft.
Operators had raised concerns about vehicles parked under the bridges. Management didn’t see them as a legitimate operational issue. Managers believed the bridges were safe as long as operators followed the procedure and didn’t lower them “too far,” so they saw no need to change the procedures or the equipment, or to take the concerns up with the groups whose vehicles were parked there. That belief was wrong: bridges kept coming down on vehicles, again and again, with different teams at the controls.
Control Structure (Simplified)
Red marks the incorrect belief and the control actions that contributed.
Role
Oversees the jet bridge procedures, and coordinates with the other groups whose crews work around the aircraft.
Process model (incorrect belief)
Believed the bridges were safe as long as operators followed the procedure and didn’t lower them “too far.”
Feedback
The operators’ concerns about parked vehicles reached management and weren’t seen as a legitimate operational concern.
What the Airline Did
The CAST took less than a day, and STPA was applied to some of the new fixes being considered. Airlines often don’t own or maintain the jet bridges, so until then nobody had looked closely at the equipment the operators were using, or at solutions there. The control structure above pointed to a new solution: feedback from a camera under the bridge, with a screen in the cab showing the area below. It paid for itself within a couple of months, and it was far more effective than the operator-focused fixes the airline had tried for more than a year. Other airlines soon adopted it. The airline also worked to remove the parking spots under the bridges. Before the CAST, removing them hadn’t seemed necessary or feasible, since the approach had been to tell operators to be more careful.
Two Ways to Explain What Happened
Old View
Causes
Human error
The operator was distracted
The operator violated the procedure
The operator was negligent
Solutions
Retrain the operator
Discipline the operator
Write more specific procedures
Fix the person.
New View
Causes
The operator believed there was room to lower the bridge
Vehicles under the bridge weren’t visible from the cab
The sign said not to lower the bridge too far, without saying how to tell
Management believed the procedure kept the bridges safe, so the operators’ concerns about parked vehicles weren’t acted on
Solutions
Remove the parking spots under the bridges
Show the operator what’s under the bridge
Alert the operator when something moves in underneath
Mark the lowest safe height
Treat operators’ reports about vehicles under the bridge as safety feedback, assign someone to act on them, and check that they do
Fix the system.
Which Fixes Work Best
System safety standards rank fixes by how well they work. This is the order in MIL-STD-882E, the U.S. Department of Defense’s standard practice for system safety. The sign, the training, and the more specific procedures all sit at the bottom.
aEliminate the hazard
bReduce the risk by changing the designNo parking underneath
cAdd engineered features or devicesThe camera
dProvide warning devices
eSigns, procedures, training, and protective equipmentThe sign
MIL-STD-882E’s order for fixes, from most to least effective, with the jet bridge fixes tagged.
Most effective: fix the system that people operate in.
Least effective: fix the people who operate in the system.
Once you know how an accident ended, the warning signs look obvious. At the time, the people involved didn’t know which signs mattered, and many of them looked routine. Accident reports show this in phrases like “should have noticed.”
At a chemical plant, the board operator closed the valve into a tank, a light said it was closed, and the flow meter showed no flow. By every indication, nothing was going into the tank. The tank’s high-level alarm had been broken for 18 months. Another alarm did sound, but it went off falsely about once a month, and a more serious alarm elsewhere in the plant needed attention at the same moment. Despite every indication, the tank was actually filling, and it kept filling until it overflowed and released sulfur dioxide. The investigators themselves couldn’t explain why it was filling. Still, knowing things the operator did not know, and how it would end, they concluded that the board operator should have noticed the level rising in the tank.
CAST starts from the assumption that the people involved were trying to do the right thing, and asks why their actions made sense to them at the time.
Two Reports on One Accident
In January 1982, Air Florida Flight 90 took off in snow from Washington National Airport and crashed into a bridge over the Potomac River. Gerry Bruggink, who taught accident investigation, rewrote the official report’s conclusion using the same facts. C.O. Miller published both conclusions side by side in 1991, and a version appears in the CAST Handbook.
Accusatory · Who
Probable Cause
The flight crew’s failure to use engine anti-icing on the ground and during takeoff
Their decision to take off with snow or ice on the wings
The captain’s failure to reject the takeoff when his attention was called to unusual engine readings
Contributing Factors
A long delay between de-icing and takeoff clearance
The aircraft type’s known tendency to pitch up when the front edge of the wing carries even a little snow or ice
The crew’s limited experience flying jets in winter
Recommendations focus on the crew.
Explanatory · What and Why
What Happened
Both engines gave less thrust than the gauges showed, and the wings were contaminated, so the aircraft couldn’t climb away after liftoff.
Why the Thrust Was Low
Engine anti-icing wasn’t used, and the operations manual’s criteria for “wet snow” didn’t call for it
Ice blocked the engine probes, so the gauges read high
One crew member noticed the odd readings and didn’t connect them with iced probes
False thrust readings in winter had happened before, and the regulator and the industry hadn’t dealt with them
Why the Wings Were Contaminated
Deficient de-icing procedures
Techniques the crew used that went against the flight manual and made the contamination worse
Air traffic control procedures that left 49 minutes between leaving the gate and takeoff clearance
Recommendations cover the manual, the instruments, de-icing, air traffic control, and the regulator.
Words That Assign Blame
Report writers often use phrases that pass judgment before anyone has asked why. CAST describes what happened in neutral, factual terms, which helps minimize hindsight bias and blame.
Report Wording
What CAST Writes or Asks
“The captain’s failure to reject the takeoff”
“The captain did not reject the takeoff.” The next step is to understand why, by looking at the control structure the captain was part of.
“The operator should have noticed”
What could the operator see at the time, and what else needed their attention?
“Human error”
A CAST explains why the error happened by finding out why the action made sense to the person at the time.
“The software failed”
Software runs the logic it was given. Why was it written to behave this way, and where did that requirement come from?
“The company failed to learn from earlier events”
Were the earlier events recorded? Were they easy to find, and did they reach people who could act on them? If not, why not?
The steps overlap in practice. Each one raises questions, and the answers send you back to earlier steps. By the end, every question has an answer or is marked as needing more study.
1
What you do
Assemble the Basic Information
Define the system and the boundary of the analysis, the loss, the hazard, and the safety constraints that were violated. Describe what happened without conclusions or blame, and write down the questions the events raise.
What you get
The Questions to Answer
A starting list of “why” questions. More are added at every step.
2
What you do
Model the Safety Control Structure
Model the controllers that were meant to prevent this kind of loss, from the front line up through management and regulators. The model is a diagram: a box for each controller, and labeled arrows for the control actions and feedback between them.
What you get
A Model of the Controls
Who was responsible for what, how each could act, and what each could see. The same model can be reused for later analyses.
3
What you do
Analyze Each Component in the Loss
Start at the bottom of the control structure. For each controller, record its responsibilities, what it did or didn’t do that contributed, what it believed, and the context that shaped those beliefs and actions.
What you get
Why Each Decision Made Sense
An explanation of each contribution, and new questions about the controllers above.
4
What you do
Identify Control Structure Flaws
Look across the whole structure for causes that involve several controllers at once: communication and coordination, safety culture, the safety information system, changes over time, and economic pressure.
What you get
Systemic Factors
Causes that span several controllers. Fixing them tends to prevent a wider range of future losses.
5
What you do
Create an Improvement Program
Write recommendations that address the causes found, decide who carries them out, and follow up on whether they worked.
What you get
Recommendations That Trace Back
Each recommendation traces back to the beliefs, context, or systemic factors it addresses, so every cause is covered and every change has a stated reason.
Part 4 · How CAST Works
Steps 1–5: A Worked Example
Choose an example:
A 55-year-old man had a needle biopsy of a small nodule in his right lung, guided by CT scans. At the clinic beforehand, his doctor and nurse told him to expect minor discomfort and said he wouldn’t need to stay overnight. During the biopsy, air leaked into the space around his lung, and part of the lung collapsed. A small collapse like this one, about 10% of the lung, is a common complication of the procedure. The radiologist and the resident both saw it on the scan. The patient, still partly sedated, said he had no pain or shortness of breath.
Back in the short-stay unit, no one checked on him for 45 minutes. His pulse oximeter kept sounding a low-oxygen alarm, and he kept silencing it, as he had learned to do. He felt pain in his chest when he breathed in, but he thought it would pass and didn’t call the nurse. A nurse finally saw him silencing the alarm and grimacing. His blood pressure, heart rate and breathing rate were all up, and the radiology notes in his chart were impossible to read. An X-ray showed that half of the lung had collapsed. A surgical resident put in a chest tube, and the patient went home four days after the biopsy.
The same kind of event had happened before. Afterward, residents were given awareness training, and follow-up chest X-rays were required within 2 hours of the procedure.
The event is a teaching case, written by the VA National Center for Patient Safety (part of the U.S. Department of Veterans Affairs) to train staff in root cause analysis. A patient safety officer at the VA Boston Healthcare System analyzed the case with the VA’s root cause analysis process. Meaghan O’Neil analyzed the same case with CAST for her master’s thesis at MIT in 2014, using an early form of CAST that came before the CAST Handbook. The steps below build on that analysis and extend it with new analysis of hospital management, the questions in Step 1, and most of Step 4. The case says little about management, so some details in the added parts are assumed. At the end, the CAST’s results are compared side by side with the VA’s root cause analysis.
1
Step 1: The Basic Information
Loss and Hazard
L-1A patient is seriously harmed after a lung biopsy
H-1A patient with a partly collapsed lung is left without close monitoring [L-1]
Safety Constraint
SC-1A patient with a partly collapsed lung must be monitored closely enough to catch any worsening early [H-1]
What you get
Questions to Answer
Q-1Why did no one check on the patient for 45 minutes?
Q-2Why didn’t the alarms bring a nurse?
Q-3Why didn’t the patient mention his chest pain?
Q-4Why didn’t the fixes after an earlier event prevent this one?
The questions ask why, not who. Asking who should have checked on the patient would only find someone to blame.
2
Step 2: The Control Structure
The patient passed between two groups. The interventional radiology team did the biopsy: the interventional radiologist, a radiology resident who was learning the procedure, and a procedure nurse. Nurses in the short-stay unit (SSU), which the hospital had opened two months earlier, looked after him before and after the biopsy.
Information about the biopsy traveled with the patient in a handwritten paper chart and in the nurses’ handoff. The resident also dictated the procedure notes for the electronic record, and dictated notes can take up to a day to appear there.
Hospital management oversees both groups. Management opened the short-stay unit, set its staffing and the rule that patients are checked every 5 minutes after a procedure, and receives the incident reports from both groups.
Control Structure (Simplified)
Simplified, after O’Neil (2014), with hospital management added.
3
Step 3: Why Each Controller Acted as It Did
Step 3 starts at the bottom of the control structure and works up. In this event the patient played a part, so the analysis starts with him.
Patient
Tell staff about pain or other symptoms
Follow the staff’s instructions
Silenced the low-oxygen alarm, several times
Did not tell the nurse about the pain in his chest
The VA’s root cause analysis stops here. CAST goes further, into the reasons for the patient’s decisions: what he believed, and why those beliefs made sense at the time.
Believed the chest pain was the minor discomfort he had been told to expect, and would pass
Believed a nurse would come if something were really wrong
At the clinic, he was told to expect minor discomfort and that he wouldn’t need to stay overnight.
He was still partly sedated when staff asked about pain after the biopsy.
He had learned earlier how to silence the alarm, and the monitor let him do it.
The case doesn’t say whether anyone told him his lung had partly collapsed, or checked that he understood his instructions.
The short-stay unit is one open room, in view of the nurses’ station.
SSU Nurse
Watch the patient for signs of getting worse
Take the handoff and read the procedure notes
Call the radiologist if the patient’s condition changes
Did not check on the patient for 45 minutes, where patients are usually checked every 5 minutes after a procedure
Did not read the procedure notes until the patient showed signs of distress
Believed she would hear an alarm or see signs of distress if he needed help
Believed the patient was recovering normally
Believed the handoff had told her everything she needed
The patient silenced the alarm before she heard it.
After the biopsy, the patient said he had no pain.
The handwritten procedure notes couldn’t be read, and the dictated notes weren’t yet in the electronic record.
In an open unit, a nurse can be with another patient a few feet away, behind a curtain.
The short-stay unit had opened two months earlier.
When the nurse called radiology, she couldn’t reach the radiologist.
Further Up the Control Structure
Procedure Nurse
Believed the SSU nurse would see the collapsed lung in the chart.
Context: the patient waited 15 minutes for transport, and the VA’s review found no handoff from radiology to the short-stay unit.
Radiology Resident
Believed the recovery staff could read his handwriting, or wouldn’t need the details.
Context: residents assist with procedures to learn them, the radiologist evaluates their work, and the full notes went through dictation.
Interventional Radiologist
Believed the SSU nurse knew about the collapsed lung and would watch the patient closely.
Context: the radiologist was probably in another procedure when the nurse called, and had left the notes to the resident.
Hospital Management
Believed the new short-stay unit was running as planned, and that the changes made after the earlier event had fixed the problem.
Context: the unit was designed as one open room so that nurses could see every patient from their station, and it was staffed on that basis. The unit had filed few incident reports, and the facility director heard about this event a day later.
The VA case gives only a page of facts, with no one to ask follow-up questions. In a live investigation, CAST produces questions to ask the people involved.
What you get
New Questions (Examples)
What is the handoff procedure between radiology and the short-stay unit, and was it followed?
How was the new short-stay unit staffed, and did that staffing allow a check every 5 minutes?
How was the nurse supposed to reach radiology when the radiologist was busy?
How had the patient learned to silence the alarm? Had he seen staff do it?
Did the patient understand that his lung had partly collapsed, and what that meant?
Was the patient’s risk of a collapsed lung assessed before the biopsy?
4
Step 4: Control Structure Flaws
Step 3 looked at each controller in turn. Step 4 looks across the whole control structure for causes that involve several controllers at once.
Communication
News of the collapsed lung had to pass from the radiology team to the SSU nurse and to the patient. The VA’s review found no handoff at all, the handwritten notes couldn’t be read, dictated notes take up to a day to appear in the electronic record, and the case doesn’t say whether anyone told the patient.
Feedback
Two of the nurse’s three kinds of feedback, the alarm and what the patient told her, depended on the patient understanding his situation. The patient believed the pain was expected, so he silenced the alarm and kept quiet. The third kind, her own checks, depended on staffing, and didn’t happen for 45 minutes.
Learning from Incidents
The same kind of event had happened before. Management’s response then, training for residents and a deadline for the follow-up X-ray, changed only the radiology side. The new unit had filed few incident reports, so management had little to go on about how recovering patients were watched.
Safety Culture
After the earlier event, the main response was awareness training for residents, which treated the event as a lapse by individuals. Staff who see problems handled that way have little reason to report them, which may be why the new unit filed few incident reports.
Change
Management opened the short-stay unit two months earlier and staffed it on the assumption that nurses could see every patient in the open room. No one went back to check whether that assumption held once the unit was busy.
Economic Pressure
The 15-minute wait for transport, the unanswered call to radiology and the 45 minutes without a check all suggest that staff were stretched. O’Neil traced those delays back to how procedures and staff are scheduled. The new unit was staffed to a tight budget, and management saw no sign of the strain in its incident reports.
5
Step 5: Recommendations
The VA’s Root Cause Analysis
Causes
The complication wasn’t passed on to the patient or the recovery team
No one assessed the patient soon enough after the procedure
The patient silenced his own alarm
If she was a registered nurse, the nurse worked outside her scope of practice and should have called a physician
Recommendations
Lock the pulse oximeter so the patient can’t use its controls
Hold face-to-face handoffs with checklists
Handle practice issues through peer review and the nurse’s supervisor
The VA gives this action plan as an example that would earn the top score in its own quality review of root cause analyses.
The CAST Analysis
Recommendations (Examples)
Treat patients with a collapsed lung as high risk, and check them more often during recovery
Set up a handoff between the radiology team and the recovery nurses that confirms both the spoken and the written information, including the patient’s risks
Before opening a new unit, check that its staffing allows the monitoring its patients need
Make sure the recovery nurse can always reach the radiologist or the resident
Give patients written instructions before the procedure and again on arrival in recovery, covering any complications and what to report, and check that they understood
Look at the patient’s risk factors for a collapsed lung before the biopsy, and act on them
When an event happens again, review the patient’s whole path through the hospital, from the clinic to discharge
Each one traces back to a belief or a contextual factor found in Steps 3 and 4.
Beyond the Recovery Room
The VA’s root cause analysis looked at the hour after the biopsy. The CAST also looked at the clinic visit, where the patient was told to expect minor discomfort, and at the biopsy itself, including the patient’s risk of a collapsed lung and how the radiologist keeps the needle on a safe path. Those parts of the analysis produced recommendations, such as checking risk factors before the biopsy and writing instructions down, that the root cause analysis didn’t cover.
Before dawn on August 27, 2006, Comair Flight 5191 was cleared to take off from Runway 22 at Blue Grass Airport in Lexington, Kentucky. The crew lined up on Runway 26 instead. Runway 26 was half as long, and its lights were out of service. The airplane ran off the end of the runway and crashed into trees. Of the 50 people on board, 49 died.
The National Transportation Safety Board (NTSB) investigated the accident and published its report in 2007. Paul Nelson, a Comair pilot who worked on the investigation for the pilots’ union, analyzed the accident again with CAST for his master’s thesis at Lund University in 2008, using an early form of CAST that came before the CAST Handbook. The steps below follow his analysis, simplified, and extend it in three ways: they add facts from the NTSB report, they sort his findings in Step 4 into the CAST Handbook’s categories, and they add the recommendations in Step 5, which the thesis doesn’t list. At the end, the CAST’s results are compared side by side with the NTSB’s conclusions and recommendations.
1
Step 1: The Basic Information
Loss and Hazard
L-1People on board an aircraft are killed or injured
H-1An aircraft is taking off with less runway ahead than it needs [L-1]
Safety Constraint
SC-1Aircraft must begin a takeoff only on a runway long enough for it [H-1]
What you get
Questions to Answer
Q-1Why did the crew believe Runway 26 was Runway 22?
Q-2Why didn’t the crew’s checks before takeoff catch the wrong runway?
Q-3Why didn’t the controller notice the wrong runway?
Q-4Why didn’t the crew’s chart, paperwork, or broadcast show the new taxi route?
2
Step 2: The Control Structure
Two organizations, each with its own management, shared the job of getting the airplane onto the right runway: Comair, through its flight crew, and the FAA, through the controller in the tower.
The crew had three sources of information about the airport: an airport chart from a chart company, notices in the flight paperwork from Comair’s dispatchers, and a recorded broadcast that the controller updates for pilots.
Control Structure (Simplified)
Simplified, after Nelson (2008). The airport authority and the chart company aren’t shown.
3
Step 3: Why Each Controller Acted as It Did
Step 3 starts at the bottom of the control structure and works up. The investigators found nothing wrong with the airplane, so the analysis starts with the flight crew.
Flight Crew
Taxi to the runway named in the clearance, and confirm the airplane is on it before takeoff
Follow company procedures, including a full taxi briefing and avoiding unrelated conversation while taxiing
Taxied onto Runway 26 and began the takeoff there
Gave a shortened taxi briefing, and talked about unrelated topics while taxiing
Didn’t compare the compass heading with the runway’s heading before takeoff
The NTSB’s probable cause stops here. CAST goes further, into the reasons for the crew’s decisions: what they believed, and why those beliefs made sense at the time.
Believed the taxi route to Runway 22 was the same as on their earlier flights from Lexington
Believed their chart showed the airport as it was
Believed they were on Runway 22 when they began the takeoff
Believed a dark runway was normal that morning, since lights were out in many places
A week earlier, construction had changed the taxi route to Runway 22. The new route kept the old name, taxiway A.
The crew’s chart, dated January 2006, still showed the old layout. The chart company’s software, as programmed, skipped updates that arrived after business hours, and the Lexington update had arrived after hours on a Friday.
The notice that part of taxiway A was closed wasn’t in the flight paperwork. The airport’s recorded broadcast had included it every morning that week, but not that morning.
The paperwork listed several runway lights as out of service, among them the centerline lights on Runway 22 and the edge lights on Runway 26. The first officer had said that lights were “out all over the place.”
From where the airplane stopped, the view of Runway 26 looked much like the view that pilots knew from the Runway 22 hold line.
Comair’s checklist didn’t include a heading check. The NTSB had asked for one after two wrong-runway takeoffs in Houston in 1989, and closed the request when the FAA said nearly every airline had added it.
Tower Controller
Issue taxi and takeoff clearances
Include closures that affect the way onto a runway in the recorded broadcast
Cleared the takeoff without noticing that the airplane had stopped at the wrong runway
Turned to a traffic count instead of watching the takeoff
Left the taxiway closure out of that morning’s broadcast
Believed the airplane had taxied to Runway 22
Didn’t expect any problems with the taxi to Runway 22
Didn’t know that pilots found the new taxi route confusing
He was the only controller on duty, working both the tower and the radar.
He had slept about two hours in the previous 24, on a schedule that switched quickly between day and night shifts.
Controllers weren’t required to watch a takeoff they had cleared, and he didn’t always do so.
From the tower, the ends of Runways 22 and 26 appeared to overlap, so it was hard to tell which runway an airplane was on.
Under FAA rules, “taxi to Runway 22” also cleared the airplane to cross Runway 26, so the clearance didn’t mention it.
Further Up the Control Structure
Comair Management
Role: left local notices, such as the closure of part of taxiway A, out of the flight paperwork.
Believed the airport’s broadcast would give crews any local notices that the flight paperwork left out.
Context: dispatchers took the notices for the paperwork from the chart company’s data feed, which didn’t include local notices. The airport had faxed its notice about taxiway A to Comair. The airline was also going through bankruptcy.
Tower Manager
Role: staffed the midnight shift with one controller, working both the tower and the radar.
Believed he had some flexibility with the FAA’s spoken guidance to staff two controllers on every shift.
Context: his staffing studies in 2005 and his request in January 2006 for two more controllers weren’t acted on, and his overtime budget was tight.
FAA Air Traffic Organization
Role: gave its guidance to staff two controllers on every shift only in person, never in writing.
Believed towers were following its guidance to staff two controllers.
Context: the FAA checked the guidance only through what managers said at quarterly meetings. The shift schedules, approved by the FAA and the controllers’ union, left little time for sleep.
Airport Authority
Role: gave the new taxi route the old route’s name, and relied on notices and the minimum required signs to tell pilots about the change.
Believed charts and notices would tell pilots about the changes, and that pilots would report anything confusing.
Context: the construction plan was changed in June 2006, the day before the deadline for chart changes, at a meeting with an FAA office but without any pilots. Crews were confused by the new route that week, but the airport didn’t receive any reports.
This CAST is based on the investigation’s records. In a live investigation, CAST produces questions to ask the people involved.
What you get
New Questions (Examples)
Why was the new taxi route given the old route’s name?
Why did the flight paperwork leave out local notices?
Why was the two-controller rule never written down or checked?
Why didn’t Comair’s checklist include the heading check that the NTSB asked for in 1989?
How were pilots supposed to report a confusing layout during construction?
4
Step 4: Control Structure Flaws
Step 3 looked at each controller on its own. Step 4 looks at the control structure as a whole, for problems that affected several controllers at once. The CAST Handbook uses Nelson’s control structure to show how to do this: he drew the communication channels that were missing or not working that morning as dotted lines. The diagram below does the same for the news of the construction change, with dashed lines.
News of the Construction Change
Simplified, after Nelson (2008) and Figure 18 of the CAST Handbook.
Communication
The crew had three sources of news about the airport: the chart, the flight paperwork, and the recorded broadcast. All three were missing the change that morning, and nobody was responsible for checking that crews got complete information. Crews who found the new route confusing that week didn’t have a simple way to report it.
Safety Information
Lessons from 1989 were on record but weren’t used. After two airline flights took off from a closed runway, extra signs and markings were added there, but Lexington used only the required minimum. After two wrong-runway takeoffs in Houston, the NTSB asked for a heading check before takeoff, and closed the request when the FAA said nearly every airline had added one.
Safety Management
The FAA’s rule for two controllers on every shift was spoken, never written, and checked only by asking managers at quarterly meetings. The FAA didn’t audit what towers actually did, and the tower manager’s requests for more controllers went unanswered.
Safety Culture
The airport authority took passing every FAA inspection as proof that the airport was safe during construction. The FAA’s airports office relied on notices to warn pilots because that was the usual practice. The CAST Handbook calls this a culture of compliance.
Change
The construction changed the airport faster than charts are updated. The plan was changed at short notice, at a meeting without any pilots, and it relied on notices to cover the difference. The crew never got the notices.
Economics
A tight overtime budget kept one controller on the midnight shift, against the FAA’s guidance. Comair was going through bankruptcy and asking its pilots for large pay cuts.
5
Step 5: Recommendations
The NTSB Report
Probable Cause
The crew’s failure to use available cues and aids to identify the airplane’s location during taxi
Their failure to cross-check and verify that the airplane was on the correct runway
Contributing: the crew’s “nonpertinent conversation during taxi,” and the FAA’s failure to require a specific clearance for every runway crossing
Set Aside
The out-of-date chart “would not have misled the pilots”
Whether staffing the tower with one controller contributed “cannot be determined”
The effect of the closure missing from the broadcast couldn’t be determined either
Recommendations
Require crews to confirm they’re at the right runway before crossing the hold line
Install moving map displays, or alerts for a takeoff on the wrong runway
Add enhanced markings at runway entrances
Hold the takeoff clearance until an airplane has crossed every runway on its way
Tell controllers to put off administrative tasks while aircraft are moving
Change controller schedules to reduce fatigue
Most of these add a check at the runway. None covers why the chart, the paperwork, and the broadcast all missed the change, or why the tower had one controller.
The CAST Analysis
Recommendations (Examples)
When construction changes a taxi route, give the new route a new name, and add temporary signs and markings
Include pilots in planning how construction will affect taxi routes
Put every notice about the departure airport in the flight paperwork, in plain language, with taxi changes first
Give pilots, controllers, and airport workers a simple way to report a confusing layout, and have the airport act on the reports
Add a heading check to every airline’s checklist, and confirm that each airline has it
Put the two-controller rule in writing, fund it, and check that towers follow it
Build controller schedules that leave time for enough sleep
Each one traces back to a belief or a contextual factor found in Steps 3 and 4.
CAST and STPA are based on the same model of how accidents happen, and they use the same kind of control structure. STPA looks ahead for the range of scenarios that could lead to a loss. CAST looks back at a loss or a near miss to uncover the complex factors behind it, and the high-leverage changes that will do the most to improve safety and prevent future losses.
Which One Fits?
CAST
An accident happened, with injuries or major losses.
A near miss happened: nobody was hurt, but it could have been serious.
A minor disruption happened, or the same small problem keeps happening.
STPA
A change is planned to something that already exists, such as equipment, a procedure, or the way work is organized.
Something new is being developed, such as a new concept, a new organizational structure, or new technology.
The question decides which method to use, even for the same equipment. Two airlines had questions about the evacuation slides on their aircraft doors. One had dozens of slides deploy by accident in a year and wanted to know why it kept happening: a question for CAST. The other was changing how its crews arm and disarm the slides, to meet new FAA rules, and wanted to know whether the new procedures brought new risks: a question for STPA.
In a healthy safety management system, STPA and CAST work as a loop. Before something new is put in place, whether new technology, equipment, or a way of operating, the team making the change uses STPA to find and prevent problems. Once it’s in use, incidents and near misses are investigated with CAST. If the investigators identify broken assumptions or gaps in the controls, those go back to the teams making the next changes. Both sides can work from the same control structure and keep it up to date.
Proactive and Reactive Safety in One Loop
Adapted from John Thomas’s CAST class.
Part 6 · Putting CAST to Use
Your First CAST
Choosing the Event
A Lower-Severity Event
Advantages
Lighter, more predictable effort
Easier to bound and finish
Drawbacks
A weaker case to leadership
More resistance to the recommendations, since leadership may not see the event as worth changing course for
A Higher-Severity Event
Advantages
A more compelling case to leadership
Recommendations are adopted more readily
Drawbacks
More effort, and harder to predict how much
Easier to get overwhelmed, especially on a first CAST without an experienced facilitator
Whichever you choose, use it to look at the areas your usual investigations tend to skip: why each action looked reasonable, the management and incentives above the front line, or software and requirements.
Counting the Hours
Gathering the facts about an event takes about as long for a CAST as for any other investigation. The difference is in the questions asked and how the answers are used. CAST often raises more questions, and answering them can take extra time. They’re questions investigators want answered but don’t always think to ask.
A team’s first CAST can feel slow, because everyone is learning the method as they go, and it takes longer without an experienced CAST facilitator on the team. So don’t go by how slow it felt: track the hours. Then compare the total with the time that a traditional analysis of the same event took. Keep in mind that you’re comparing a first try with CAST against a method the team has used for years. Later analyses go faster. Teams have reported finishing a CAST about eight times faster once they have more experience. And the control structure built for the first CAST can be reused, so later analyses start partway done.
Too Many Recommendations?
Some people worry that CAST produces too many recommendations. A long list gives you more flexibility to identify the changes that do the most good, often with less cost, and that fit what your organization can do now. An investigation that finds only one or two causes leaves a hard choice among a few weak options. The list doesn’t have to be done all at once: some changes can be made right away, and some, like a change in regulation, take years.
When Recommendations Aren’t Accepted
Some recommendations won’t be accepted. Record each one anyway, along with the organization, group, or person who decided not to act on it. If the same kind of loss happens again because a recommendation was turned down, the next CAST will need to look at that decision and why it was made. That isn’t possible if the decision was never written down. Recording who turned down which recommendations often changes the decisions, too. It makes clear who is responsible for each decision and for the risk that comes with it, and decision-makers become more willing to accept the recommendations.
