Information from episode participants
Information from episode witnesses.
Information from programmers.
Information from controllers.

Model uses
Application procedure

Figure 4-1 Change Tracking Matrix Format
Figure 4-2 Change Tracking Matrix Example 1
Figure 4-3 Change Tracking Matrix Example 2

Go to Guide: 0 1 2 3 4 5 6 7 8 9 10 11

A continuing challenge for investigators during investigations is trying to locate nd acquire information about what happened, and transforming it into inputs that can be used to describe what happened. Numerous tools are available to help investigators acquire information to transform into input data building blocks for STEP-MES matrix arrays.

This Guide presents some of the more helpful approaches and tools for finding and acquiring such information. It includes tools for finding and acquiring information from people, things, and observations of changes. Additional examples of tools for acquiring data from energy flows, loss charts and a safety system model are located in Guides 5-9. A 1997 FPP publication “Guide 2 Accident investigation,” available on line, contains further details about information source identification and acquisition available on line at http://www.ludwigbenner.org/manuals/Guide-2%20AI.pdf

Note: That 20 year old publication uses the ambiguous word “event” in lieu of today’s definitive term, “data BB” and a linear cause construct in lieu of today’s more definitive and versatile input/output terminology. Otherwise its content is still informative.

OBJECTIVE

The objective of this Guide is to give investigator guidance to enable them to find sources and acquire information they can transform into building blocks (BBs) to develop descriptions of episodic occurrences.

The data sources include people involved in an episode (participants), people who witnessed an episode (witnesses), people who established participants’s behaviors during the episode (programmers.) and occasionally people who want to be heard even though they have no information about the episode to offer (volunteers.) Objects include those inflicting damage during an episode (participants), those that “witnessed” the episode (witnesses) and those that exercised control during the episode (controllers.) It is helpful to think of all as "witness plates" on which data was implanted during the episode.

HOW TO IDENTIFY SOURCES

The first step ti identifying sources of information for potential BBs is creating an inventory of the names of all the individuals and objects that were involved in the episode. The list will grow as relevant new people, objects energies are discovered. This list can be used to label the actor coordinate of the STEP-MES matrix. The list is initiated during site “walk throughs” of the episode scene, and off site, from photos or videos of the scene, descriptions of the scene by others, manufacturers’ manuals, design and s built drawings and specifications, operational records, episode history, training materials, test or simulation results, hazard analyses, cods and standards and people’s recollections of the episode can be sources of information for you. Expand the list as the investigation leads to other sources. Any data BB can be a starting point.

ACQUIRING INPUTS FROM PEOPLE

Human frailties make people the least reliable sources of information to transform into input data BBs. Nevertheless, investigators must include them as information sources during investigations, but also take steps to avoid misinformation finding its way into a STEP-MES array. Investigators must treat participants, observers, and programmers differently to acquire the information they need. All three have their specific information limits, recall capabilities and interests as investigation information sources.

Participants have a limited view of what happened because of the episode dynamics, and are reluctant to disclose what they know because of their concern about culpability and their self interests to protect themselves.

Observers may be reluctant to get involved with something in which they have no direct interest , but may be willing to share their observations as a societal obligation with proper treatment.

Programmers may also be reluctant sources because of their concerns about their potential culpability for the episode, but they can provide the premises, assumptions decisions and actions influencing the equipment or procedures involved in the episode.

Recognizing these influences, some tools can help investigators get information that they need. Individual coming forward to offer information can be categorized quickly as witness with useful information and volunteers without useful information about the episode. It is important to remember Axioms 5 and 6: see Top 10 Axioms for investigators

6. Observer (witness) has it, you need it, and observer (witness) doesn’t have to give it to you.

5. Things react predictably without thinking during episodes and tell all but only if you can "read or hear" what they have to "tell"

Information from episode participants

Participants are people, objects or energies that may be directly involved in episodes, such as operators, responders, supervisors, injured parties, or clean up crew members or people, objects or energies inflicting harm. These individual “actors” have the potential to describe data BBs directly to investigators, requiring minimal transformation, or other information leading to data BBs.

People involved in episodes typically respond to what they think is happening during episodes, and based on their diagnosis, apply “cookbook” responses or devise innovative responses. They may try to respond to questioning with what they think the investigator should hear (experiential bias), or wants to hear (confirmation bias.)

Objects, on the other hand, offer no such resistance and will respond truthfully to investigators’ inquiries if investigators know how to do that. The Investigator’s General Decision Model and its application provide an information acquisition process that can bring out information from people or objects for needed data BBs.

Information from episode witnesses.

Witnesses may be individuals who were in a position for their five senses to acquire inputs during an episode, and remember them for retrieval later. They may recall some or all of the steps for each action being pursued by investigators. Object witnesses are any “witness plates” that capture information during an episode, such as flight data or other kinds of event recorders, logs, temperature tracking gauges, damaged equipment or debris.

Information from episode programmers

Actions by designers, trainers, supervisors, executives, companions or c-workers, relatives, opponents, marketers and other often influence what participants or witnesses did during episodes. Investigators need to look for inputs to each step of the investigators' General Decision Model to identify influences that were necessary to produce them. Using the STEP-MES matrix helps investigators do that.

Information from controllers involved

Another group of influences are controller of actions by people and objects. Controllers may be individuals who control behaviors of others, or devices that control equipment functions dependent on inputs from sensors, for example. In that case, investigators can also pursue them with the Investigators’ General Decision Model.

Source: (Original) FOUR ACCIDENT INVESTIGATION GAMES, Appendix V-F, Lufred Industries (now Ludwig Benner & Associates) Oakton, VA 1982

This model flow charts the general process which leads investigators to identify actions by people, objects or energies during episodes. Episodes end when a decision maker or object redirects the process to a desired outcome. An experienced investigation practitioner developed this model byr by consolidating observations during interviews of many accident investigation witnesses, and acquisition of data from objects. Guidance for applying the model in investigations follows the model.

This Model describes the general process for investigators to use to lead them to information about actions by people, objects and energies during any kind of episode. It helps with people interviews and object examinations. The model helps investigators discover and define changes, signals they emit; their detection, communication, and diagnosis; decisions required during the process, decision influences, and the outcomes of those decisions. The decisions may be made by human beings or objects with physical, electronic or other controls, for example.

Model uses

By investigating each block and necessary inputs, investigators can find the influences of supervision, training, design, procedures, supervisory direction, management presentations and policies, and other "programmer" input sources influencing each of these blocks, investigators can link specific prior experiences and actions or "human factors" or designed controls to each block.

This tracking of each action-taking process element enables investigators to define data BBs and build arrays showing specific relationships among actions as inputs for subsequent user actions. It also helps investigators pinpoint the places to look for concrete actions (behaviors) that will serve user's responsive action needs. The specificity of BBs avoids the problems with data characterizing or data or lessons learned in subjective, ambiguous or abstract "human factors" terms such as errors, failures, causes, malfunctions, neglect, inattention, inadequate, wrong, unsafe, skill errors, latent failures, active failures, "did nots" etc.

Application procedure

To apply this Model during investigation interviews or examinations, identify people or objects that appear to have had a role in the episode. Then begin to look for changes in the episode process or its environment that would have created an original need for action by some person or object to keep the process progressing toward its intended outcome. Then follow the same procedure for subsequent changes until the incident is understood and documented.

1. When you identify a change, determine if it displayed or emitted some kind on signal , active or passive, that the person or sensor objects could have noticed. If it didn't, explore why it didn't and what effect that had on the outcome.
2. If it did emit a signal, explore whether the person or sensor saw, heard, felt or otherwise "observed" the signal. If not, explore why not, and what effect that had on the outcome.
3. If the person or sensor observed the signal, was the signal diagnosed correctly, in the sense that the person or controller was able predict the consequence of the change from the signal and their knowledge of the system and its operation. If not, explore why not, and its effects.
4. If the predicted consequences of the change were correctly identified, did the person or controller recognize a need to do something to counter those consequences? If not, explore why not, and its effects.
5. If so, did the person or controller identify the choices for action that were available for successful intervention? Was this a new situation were the action had to be invented (adaptive response), or was this something that prior training or experience anticipated and provided the responses to implement (cook book response)? In other words, was the person or controller confronted by an adaptive or habituated response? (Here, you start to get into a person's decision making process, and potential personal judgment and values issues, so explore this area with empathy toward the witness, particularly for adaptive responses.)
6. If any response actions were identified, did the person chose the"best" or an effective response to implement? If a successful response was not chosen, explore why it wasn't. To this point, you are asking for observations during an interview.
   
7. If a potentially successful response was chosen, did the person or designer successfully implement the desired action? If not, explore why not.
8. If a suitable response was implemented, the episode adapted to the change without an loss or harm. If the response did not achieve a no-harm outcome, explore why it didn't. Often this leads you to discovery of invalid system design assumptions or other design actions or programmer issues.

   After working with this model, investigators are in a much better position to acquire the data BBs needed to describe and document what happened than when a so-called "human error" or"failure" is alleged. Users will also be in a better position to identify data the need for their response actions after the episode.

   y

   Contact: Ludwig Benner, (luben) for support at ludwigbenner.org