Similar to prevention controls, on the right hand side of the top event, controls are added that show how the scenario is to be managed in order to stop an accident from occurring.

These controls are considered to reduce the likelihood of the top event developing into a consequence as well as mitigating the severity of the consequence.

In our example of driving a car on a busy motorway, a reduction control would be anti-lock braking system (ABS) to constrain the loss of control parameters to not affect other motorway users. A mitigating control could be airbag activation acting against the fatality severity of the consequence.

Additional guidance (relevant to prevention and recovery controls)

Parallel versus sequential controls

Controls will usually be sequential e.g. if one fails then the next one would come into play. However, it is not uncommon for controls to be included which do not function in this way but rather have an ‘either/or’ type relationship (also known as ‘parallel controls’).

For example, consider the following aircraft loading scenario: Load and trim calculations are an important control against an incorrect distribution of load but there are several ways in which this might be achieved:

1. central control system;
2. manual load sheet;
3. electronic flight bag.

These could be depicted on the bowtie as three controls; however for any given departure only one will actually be used (e.g. they are parallel controls).

Bowtie diagrams do not model parallel controls specifically.

This is a trade off between being analytically correct and being an easily understandable tool.

Therefore it visually looks as though all controls are sequential. In this situation, what could be interpreted as three controls is in effect only one dependent on the operation type.

The important lesson is that it should not be assumed that controls are always sequential when building or referring to a bowtie. This is also one of several considerations that tend to make the counting of controls in order to determine sufficient protection a flawed technique.

Independence of controls

It is not uncommon for controls to be depicted which are not independent.

This occurs when it is desirable to highlight separate aspects of a control in order to depict specific escalation factors e.g. detecting a problem and then actioning the appropriate response.

Consider for example, fire detection and fire fighting. Clearly the two are not independent e.g. detection is not a standalone controls as it does nothing to stop a fire and fire fighting will not commence until the fire has been detected.

As with parallel controls, these dependencies degrade the validity of counting controls.

See Prevention controls for traps and t ips relevant to recovery control.