Review a cause-and-effect matrix

What you should be able to do

Read an approved cause-and-effect matrix, identify the expected response to a defined condition, and distinguish design intent from verified performance. This lesson uses an original abstract classroom matrix. It is not a building evacuation design, programming instruction or live test procedure.

What The Matrix Does

A cause-and-effect matrix organizes relationships between initiating conditions and resulting actions. Rows commonly represent input conditions; columns commonly represent outputs or functions. Always read the document's own orientation, legend, notes and revision before interpreting a cell.

A matrix may show what happens for an alarm, supervisory condition, trouble or other defined event. These states are not interchangeable. An input address tells you which point is involved, while its state and approved sequence tell you what response is intended. A device's descriptive label does not establish the response by itself.

Sources

Worked through

Assume two abstract initiating demands, A and B, and three abstract outputs. All outputs are initially inactive. Each demand independently requests its assigned outputs. There are no delays, inhibitions, priorities or latching in this simplified exercise. These assumptions apply only to the exercise.

Row 1: A only — Output 1 active, Output 2 inactive, Output 3 active. Row 2: B only — Output 1 inactive, Output 2 active, Output 3 active. Row 3: A and B together — all three outputs active.

X means activation is expected. The dash means the output remains inactive for that stated scenario. The dash is not an unknown or “do not test.” A blank, question mark or other symbol would require its own definition. Never interpret an undefined blank as permission to ignore an action.

Output 3 responds to either A or B under the stated exercise assumptions. This is an OR relationship, not an AND requirement. The third row explicitly records the combined-event expectation so a reviewer does not need to guess it.

Read Across, Then Down

Reading across A only gives three expected states, including one inactive state. A review that checks only the X cells misses unintended activation. Reading down Output 3 shows that each listed scenario calls for activation. Both directions help reveal inconsistent or omitted mapping.

Three scenarios multiplied by three output columns gives nine expected-state checks. There are seven active states and two inactive states: 7 + 2 = 9. This arithmetic counts expectations. It does not mean nine tests were performed, nor that three scenarios cover every condition in a real system.

Output Names Need Definitions

A real matrix must identify the actual output or function, its equipment/interface reference and the required resulting action. “Relay operates” may be too vague unless the approved documentation defines the commanded state and what the receiving system must do. Physical contact state, software command and final mechanical action are separate observations.

Do not assume that energized means open, that de-energized means released, or that a command proves motion occurred. Those relationships depend on the approved design and listed equipment. Documentation should distinguish commanded output from required feedback or independently verified final condition where applicable.

Look For Conditions That A Simple Grid Cannot Explain

Review the approved sequence notes for timing, priorities, dependencies, latching, silence, reset and restoration. Determine how simultaneous inputs are handled. Identify applicable conditions following power loss or communication faults through the design documents. Do not invent missing behavior.

Some functions require specialized system coordination. Elevator recall, smoke control, emergency communications, door control and other interfaces cannot be designed by copying an unrelated classroom row. A low-voltage apprentice should identify missing references and bring them to the responsible designer and qualified specialists.

Make A Review Record

Record the matrix document number, revision and approval status. Link each row to the relevant input points or conditions, and each column to output identifiers or function references. Confirm agreement with point schedules, drawings, sequence narratives and the equipment configuration basis.

For each unresolved item, state exactly what is missing or contradictory. “Check matrix” is less useful than “Row A-only indicates Output 2 inactive, but the referenced sequence paragraph requires Output 2 active.” Preserve the discrepancy until the authorized design decision resolves it. Do not alter programming merely to make one document agree with another.

Expected Results Are Not Observed Results

A verification record needs separate fields for expected behavior, actual observation, evidence, result, date and responsible personnel. “Expected active” is design intent; “observed active” needs real evidence. Do not copy expected states into an actual-results column.

For this desk exercise, suppose a supplied fictional observation says all three outputs activated during A only. Outputs 1 and 3 match. Output 2 does not match. Record that difference and the scenario assumptions. Do not hide the mismatch by changing the legend or excluding the inactive-state check.

Any actual testing belongs to the approved site process, with authorized personnel, coordinated notifications and required protection/restoration arrangements. No field test or impairment is authorized or performed by this lesson.

Check Your Understanding

Sources

Where beginners go wrong

Paper Practice

For the original matrix, write the three expected outputs for B only. Compare them with this fictional observation: Outputs 1, 2 and 3 are all active. Identify the mismatch and the evidence needed before closing it.

Answer guide: B only expects Output 1 inactive and Outputs 2 and 3 active. Output 1 is unexpectedly active. Record the scenario, matrix revision and supplied observation, then refer the discrepancy for authorized investigation and verification; changing the expected row to match the observation does not resolve it.