The objective of this Guide1 is to describe the procedures investigators can use to produce the basic building blocks needed to describe and explain phenomena. This is an indispensable skill for all investigators.

An investigator's initial challenge is to acquire and transform observed investigation data into the building blocks (BBs) needed to develop investigation work products. This documentation challenge generally stated is to:

1. Observe and list by specific name the people, objects and energies (actors) whose actions during the episode resulted in the outcome of interest.

2. Determine by observing surviving sources what each actor did during the episode, and what that action produced.

3. Transform each such observation into a building block in a format suitable for describing and analyzing the progressive interactions that occurred.Record each action advancing the process toward its outcome as

4. Document and preserve the sources of the recorded building blocks.

Procedures for this task are contained in this Guide. They cover manual and software-supported procedures.

The STEP/MESS (Sequential Timed Events Plotting / Multilinear Events Sequencing) technology -based investigation process is a universally applicable body of investigation concepts, principles and procedures. It enables an investigator to develop and document an understanding and explanatory description of an episodic phenomenon. It can also help users define, plan and evaluate future actions.

One fundamental component of the STEP/MES process is the data structure on which all other work rests. This data structure is defined by the data Building Block (BB). A BB is defined as one action by one person, object.or energy.

1 actor + 1 action = 1 data Building Block.

A continuing challenge for investigators is to document their work with the proper words. Investigators must transform their observations into concrete words that permit readers of their words to visualize what happened. They must use words that readers can "see" rather than abstract words that blur their vision. For example, Hayakawa in his book "Language in Thought and Action" points out that an object can be described at various levels of abstraction. His "ladder of abstraction" demonstrates how a specific object, Bessie the Cow, can be described with increasing levels of abstraction, from Bessie - an object we can see and touch - to the word "animal" which is a category into which Bessie fits, but does not help enable one to visualize the specific Bessie. Using increasingly generalized words such as hoofed species to mammal to animal to living creature he moves up the ladder of abstraction. Each higher level further impedes the ability to visualize the specific Bessie, which is necessary to understand what happened. Recognition that investigators must work at the bottom of the ladder - the most concrete words - to develop their descriptions of episodes is essential to all that follows.

Another word problem is the term "event." As now used an event can be the episode, or events within the episode or something else. These Guides use BBs rather than events, because the term "event" is so ubiquitous that its general usage usually results in undisciplined descriptions, ambiguity, logic errors and controversy. BBs, with their single actor and single action structure avoid use of "event." This helps investigators cast acquired data into this necessary BB actor+action format. It is part of the basic knowledge required to do STEP/MES-based or any other investigations.

Investigators investigate processes that produce outcomes of interest. For investigation purposes, an understanding of any process and its outcome(s) must begin with an awareness that a process consists of interacting components working together to produce the outcome. The STEP/MES technology uses the following model to illustrate what a process is, for investigation purposes.

The process outcome is driven by actions of people, objects and energies which change other process components to produce the outcome of interest.

To meet this challenge, the investigator must first transform data from all sources into documented words that clearly define the actor that changed something, and what that actor did. Those sources can vary widely in their origin, nature, structure and content, Figure 1-2 describes the kinds of input data an investigator has to process, for example, in an environmental insult or fire investigation or crime.

All data acquired by the investigator must be processed to transform it into the data language required to describe the episode. This skill is basic to every investigation task that follows. Now for the details.

The objective of this Guide1 is to describe the procedures investigators can use to produce the basic building blocks needed to describe and explain phenomena.

Any observations or data about what happened acquired during an investigation can be transformed into BBs.

Data required during investigations is defined by the input data BB format, and the integration of the data BBs. An input data BB has this form: actor and action. The procedure can use any observed or recorded data about actors or actions from any source. It can accommodate direct observations by an investigator, reported observations or data provided by animate or inanimate "observers" of the episode, and logical reasoning based on knowledge of how something actually functions or was intended to function. When BBs are organized, they help define actors or actions still required by the investigator. See Guide 2 for information about actor/action matrix development and identification of data needs.

Data for BBs is acquired by investigators' interactions with people during interviews. and direct observations of and inferences drawn from observations of accessible equipment or parts, documents, records, surviving states, instrument redings, measurements, recorder, calculations, tests, and examinations, etc.

BASIC BB FORMAT AND CONTENT

To implement the basic investigation data language demands, each BB must be in a specific and consistent format, contain common minimum elements, and satisfy prescribed quality standards. The format and elements are shown in Figure1-3.

These are the common minimum elements of the investigator's building blocks. They are called BBs rather than events, because the term "event" is so ubiquitous that its general usage usually results in undisciplined descriptions, ambiguity, logic errors and controversy.

ACTOR is anyone or anything that does something to initiate a change of state during the process required to produce the outcome achieved. An actor has only one name. Ambiguous, duplicate, compound or plural names are absolutely, positively unacceptable. NEVER BREAK THIS RULE.

ACTION is one specific act by one specific actor which affected another actor. Investigators focus on actions that helped initiate or sustain the process which produced the outcome. If difficulties arise while defining the act of an actor with a single verb, divide the action into more action verbs or divide the actor into more actors, each with its own action. At the early stages of an investigation, focus on what the actor did, not what the actor should have done. That task is introduced later in the investigation process.

 DESCRIPTOR in used to expand the description of what the actor did. Use it to describe what the actor acted on, or otherwise define the act so it is uniquely described, can be visualized and then can be tied to other BBs.

 TIME is the data component required to sequence BBs. Times can be estimated, observed or relative.

SOURCE is the person, object, document or other origin for the data transformed into a BB.

The major pitfalls to guard against in the preparation of BBs are an almost overwhelming tendency of investigators to try to take shortcuts, to record "did nots," to let their experience seep into the BBs they produce, to break some of the rules of this procedure, or to fall back on abstractions to cover up uncertainties about the actors or actions.

Shortcuts.

Shortcuts are tempting but self defeating. Skipping any of the essential elements of a BB or assuming actors or actions rather than entering placeholders for unknowns are two frequent sources of problems. The former will require backtracking to get the information later, while the latter may seriously misdirect the investigation, overlook documentation of needed data or increase the vulnerability of the work products to later criticism.

The focus must be on what people or objects did, rather than what they did not do. Did nots mask the need to determine what actors actually did do. Did nots presume ideal behavior standards, and assume what actors actually did was not valid. This can thwart understanding and discovery..

A second major pitfall is interpreting observed data on the basis of personal experience, and using that experience as the basis for formulating a BB. For example, an investigator who has operating experience is tempted to adopt operator’s assumptions rather than probe the operator’s actual tasks, constraints and decision process in a given case. Probably the most frequent abuse is the introduction of "did not" BBs based on what the investigator "knows" or thinks should have happened. This undermines the more productive investigation challenge of finding out what actually did happen based on what the data can tell the investigator.

Breaking STEP/MES rules.

This pitfall often involves intellectual laziness, as when an investigator elects to use "crew" or similar plural actor name because the name of the specific actor was not determined as it should have been. The rules are provided primarily because they are needed to ensure the satisfactory subsequent use of the BBs, but also in part to enable the conscientious investigator to exercise self discipline during an investigation.

Another debilitating pitfall is the use of abstractions to describe an actor or action that should be described with specificity and concretely. Abstractions are symptoms of investigation problems, as when an investigator either

• does not want to acknowledge the uncertainties due to the inadequacy of the available data.

• is forced to fit incompatible observed data into preconceived categories demanded by form designers or managers,

• is unwilling to make the effort to develop the needed data during the investigation or

• knows abstractions will not be challenged by the users of the investigator’s work product.

It is sometimes easier for investigators to substitute experiential opinions, subjective interpretations and abstractions than to follow these procedural rules. Follow the rules, even if it requires some hard thinking to define the actions, break down the actions or define uncertainties to avoid subsequent controversy.

Caution: Try to avoid stating what people or objects didn't do during the development of the description of what happened. After an investigator understands what happened, a comparison with what was expected to happen can be introduced to discover and define problem with either actions and expectations.

Use the following guidance to prepare your BBs during an investigation.

Development of descriptions of what happened requires investigators to identify the people and objects involved, and what each had to do to produce the outcome. "Who or what was involved and what did they do" is the investigator’s constant question. Investigators must identify objects and people that can provide information about those interactions. They must seek the data that helps them discover and define each person or object involved, and then determine who or what did what when and where, and to whom or what. A constant question is who or what was there, and what did they do?

When investigators see an action, they must document it in some manner. Each action can be represented by a BB. During an investigation, keep listening and looking for actors whose actions might have influenced the progression of interactions in the process being investigated. Base actor names on data acquired during the investigation. The data should be as value-free as possible, that is, based on observations of this episode, rather than opinions or experience or conclusions or past investigation results or known problems. Save speculation for later, and work with observed data initially.

During an investigation investigators identify and track actors involved and what they did to produce the outcome. Actors can be people or things. Give each actor a specific and unique name. Use suffixes like A or 1 when recording general names like "driver 1" and "driver 2" or use unique job titles or chemical names instead of trade names. Keep a list of the actual name used for each general name with a suffix, so you do not duplicate any names.

Enter only one specific name, and KEEP USING IT. Pronouns (they, she, it, he, etc.) and plural or composite names (the band, the crowd, the fire fighters, crew, maintenance workers) lead to big problems, so avoid them.

The actor named must be the doer of the action which affected someone or something else later in time. Do not enter the name of someone or something that was acted on or had something done TO them as the actor.

An actor may be "broken down" or "decomposed" into two or more actors, with a separate action for each, to overcome naming or transformation difficulties. For example, it may be desirable to track what a person's hands and feet were doing separately during a fall down a set of stairs. Something may separate into two actors during the episode, (like a wheel came off a car) and become two objects that produce further changes. Select each actor so the actor can be doing only one action at a time.

The actor's name must be followed only by the action word (verb) describing the action that initiated a change of state in someone or something else during the episode. This is often one of the most difficult steps in investigations. We are not used to describing actions this explicitly in our everyday language. Focusing on a specific action verb, however, is a useful forcing function for investigators. It compels them to define concretely and precisely what happened. When an investigator must resort to abstractions it shows everyone that the investigators does not understand what is being described, and is trying to cover up this problem..

What are actions?

View actions broadly. PEOPLE ACTIONS include

THINGS ACTIONS should be described as physical actions that can be visualized by using concrete words and descriptors/objects. For example, shook, rose, fell, descended, struck, scored, broke into two parts, lit, etc. help create visual images.

Avoid words that reflect investigator conclusions or judgments. Saying that "part failed" is ambiguous and can not be visualized. Saying a weld cracked in tension between part A and part B in a specific location and time is much more useful.

ENERGY ACTIONS should also be described concretely,

As with the actor name, use the ? placeholder to show that the action is an unanswered question, or is not understood. A good example of the use of the ? is when someone was at the scene of the episode for a specific time, but the actions they describe to investigators do not fill up all the time they were present. Another example is when a thing comes apart, but the investigator can't figure out yet what it actually did during the breakup.

A verb may be supplemented or limited by adding additional quantitative or qualitative descriptor/object phrases, such as "200 feet in 4 seconds" after the words "aircraft descended." "___ struck car2 gasoline tank fill pipe cap" can be visualized if the car2 system is understood. Such supplemental defining data are termed "DESCRIPTORS." (or OBJECTS in the software.) This space can also be used to identify what the actor acted on to change a state, or the "stressee" to further define the action, and lead to the next action. The objective is to provide a way to define the action sufficiently to permit its visualization, using descriptive words to make the action concrete and unique.

6. Then add date and time action started/ended.

SUPPLEMENTAL BB ENTRIES

9. BB number.

BB DEVELOPMENT TIMING CHOICES

During the first case, investigators have to hustle to capture the BBs. The press of time may require some hurry-up techniques. In the second situation, investigators have more time, but the range of techniques can be different.

Rule 1: record sources. A good rule is to try to record (audio or video) such data for later, more detailed perusal. There are times when this is not possible. When we talk to people for example, we can listen faster than we can write. Further complicating the task, people can state what they did, or what they observed others doing. Either type of data may be reported explicitly or implicitly by the person talking. Awareness of both is necessary while listening to someone. Be prepared to capture both. That's why it is a good idea to - at the very least - try to record the discussion verbatim, and review it later for accuracy and completeness.

If you are observing objects, same rule applies. Record the observations on film or some alternative recording medium.

Rule 2. Get permission to record. Getting permission to record individuals or capture images of private property can be a sensitive issue, but permission should be sought and hopefully received before doing any recording. Permission to record implies cooperation by the interviewee. Gaining that cooperation is another essential investigation skill.

If recording is not possible, use the BB shortcut techniques described below.

Rule 3. Use BB shorthand. During a discussion, listen for descriptions or inferences of actions by the individual or by other people or things. When an interviewee describes an action, write down the actors name (or initials if pressed for time) and the action verb that accompanies the actor. Use ? liberally if necessary and then go back and use the ? to pinpoint followup questions. Alternatively, have a second interviewer alternate in asking questions and recording the answers. As soon as feasible, before memory fades, transfer notes about events into the BB format.

During interviews, make mental movies to track and remember the person's movements and actions, and to determine whether the person's actions during the episode were covered adequately. A preferred order of precedence for asking questions of people is to ask what the person observed other people or things do. The ask about what the person did (physical and mental actions). Then ask about the decision process that was involved with selected actions. Finally, ask questions requiring value judgments - these are sometimes the most uncomfortable for a person to answer, and may turn a person off. Learn as much as possible before asking threatening questions.

When working from documents, development of BBs is somewhat less stressful, because it is possible to use a supplementary technique to capture the BBs. From a written document (like a interviewee statement or accident report) proceed as follows.

IMPLEMENTING PROCEDURES

BBs can be created manually on paper, or with the assistance of computer software.

Computer assistance in creating and ordering BBs can be used or developed with spreadsheet or graphic software. For small investigations, software for producing BBs on labels is available at http://www.ludwigbenner.org/MDQA/MDQAkit.html.

Prototype Investigation Catalyst software was created to experiment with implementation of the STEP/MES investigation system. The software facilitates data BB entry, and manual sequencing, integration and linking of BBs into a matrix array. The development of the data to enter is as described above. See open source code. It has not been updated for compatibility with the latest operating systems, but many functions still work on them.

Data can also be captured, less efficiently, on spread sheets by enlarging cells and ordering with the sort function it as it is acquired. links between BBs can also be entere in a sortable column. Alternatively, data can be captured in drawing applications and laid out as a flow chart, using the computer screen to organize the BBs as they are acquired.

Creating BBs is to use the MDQA word processor themplate that has merge and label preparation capability. Set up a table with the column titles of actor, action and other BB elements on the first row. Then add rows containing the entries for each BB element and using the label setup functions, set up the files to print labels, and print out data in each row on a label. Each printed label will be a separate BB. The labels are then used in subsequent steps as described in guides 2-10. The tables provide a way to make changes on any of the labels before final printing..