From Fire Strategy to Test Sheet: Building a Cause & Effect Matrix That Works

6 September 2026 by Ryan Bishop

A fire strategy might say that the fire alarm should release doors, recall lifts, shut down ventilation and initiate smoke control. That sets out the intended outcome, but it does not yet give a programmer enough information to configure the panel or a commissioning engineer enough information to test the completed system.

The missing step is a clear cause-and-effect matrix.

In a previous article, I looked at the problems that appear when cause and effect is invented at the panel, built around unnecessary device-level logic or tested one relay at a time. This time, I want to look at the document itself: what needs to go into it, how detailed it should be and how to make it useful on site.

The documentation position has changed

BS 5839-1:2025 is the current code of practice for fire detection and alarm systems in non-domestic premises.

The Fire Industry Association's guide to the 2025 changes draws attention to a new recommendation. The documentation provided to the purchaser or user should now include a cause-and-effect matrix or a written description of how the cause and effect operates.

That does not mean every small, simultaneous-evacuation system needs an enormous spreadsheet. Where the operation really is simple, a short written description may be perfectly proportionate. Once a system includes phased evacuation, investigation delays, coincidence, smoke control, lifts, access control, fire doors or plant shutdowns, a matrix is usually the clearest way to describe it.

There is a wider handover requirement as well. Approved Document B's Regulation 38 guidance says that the detailed record for a complex building should include an outline cause-and-effect matrix or strategy. The purpose is practical. The person responsible for the building needs enough information to understand, operate and maintain its fire safety systems.

If the document only makes sense to the original panel programmer, it is not doing that job.

Sort out the source information first

It is tempting to open a blank spreadsheet and start filling in cells. That tends to bring panel programming decisions into the process too early.

Before drawing the matrix, gather the information that is supposed to drive it:

the current fire strategy and evacuation strategy;
the fire alarm specification and system category;
fire detection zones and alarm zones;
interface schedules and schematics;
smoke-control, lift, door, access-control and plant requirements;
any agreed investigation periods, dependencies or staged responses;
the building's normal operating modes;
the party responsible for each connected system; and
approved variations or later design changes.

On a real project, those documents do not always agree. The fire strategy may use one smoke-control zone reference while the panel specification uses another. A door schedule may show a release that is missing from the fire alarm interface schedule. The evacuation sequence may have changed without the cause and effect being updated.

Do not quietly choose an answer and bury it in the matrix. Record the conflict and send it back to the responsible designer or design team. A neatly formatted assumption is still an assumption.

Set the boundaries

The document needs to say what it covers.

Does it describe the fire alarm outputs only, or the complete response of the connected systems? Does a smoke-control column mean that the fire alarm interface changes state, or that the damper and fan sequence has reached its required condition? Does "lift recall" refer to a relay at the fire alarm panel or the lift arriving at the designated floor?

These questions affect who has to test what.

The fire alarm contractor may be able to prove that an output module changes state. The lift specialist may need to prove that the lift then completes the required recall sequence. A joint test may be needed to demonstrate the whole path from detector to final outcome.

The matrix should make those boundaries visible. Otherwise, every contractor can complete their own small test while nobody proves that the building response works from end to end.

Use causes that match the required response

A cause should represent a meaningful initiating event, not simply the easiest item to select in the programming software.

Depending on the building, suitable causes might include:

automatic fire detection in Zone 04;
operation of any manual call point;
confirmed detection within a defined area;
sprinkler flow signal;
suppression-system discharge signal;
fire in a particular smoke-control zone;
operation of an evacuation control; or
an alarm signal received from another panel on the network.

There is no benefit in creating a separate row for every detector if all those detectors produce exactly the same response. It makes the document longer and creates more places for later changes to be missed.

The opposite mistake is grouping too much. A detector in a lift shaft, plant room or suppression area may require different logic from the rest of its geographical zone. The right level of detail is the point at which the required building response changes.

Describe what should physically happen

An effect labelled Output group 17 operates might help the panel programmer, but it tells the person commissioning the system very little.

Effects should describe observable functions, for example:

general alarm throughout the building;
alert signal on Levels 5 and 6;
release access-controlled doors on the affected escape routes;
recall passenger lifts to the designated floor;
close smoke dampers serving Compartment 2;
start the Level 4 smoke extract sequence;
shut down the air-handling unit; or
transmit a confirmed fire signal to the alarm receiving centre.

Panel references, output-group numbers and interface addresses are still useful. Include them in supporting columns or schedules, but do not use them in place of the function being controlled.

This distinction becomes important during testing. A relay changing state proves that the relay changed state. It does not prove that a door released, a lift recalled or a smoke-control system reached the correct operating condition.

Make the action language unambiguous

A tick in a matrix can mean almost anything. It might mean immediate operation, operation after a delay, operation only after confirmation, or simply that the programmer needs to look at a separate note.

Use a small and clearly defined action key. A project might use something like:

I: operate immediately;
D30: operate after 30 seconds;
C: operate after the stated confirmation condition;
A: alert state;
E: evacuation state;
R: release;
S: shut down; and
-: no action required.

Those symbols are examples, not a recommended universal key. The vocabulary should suit the project and be printed on the document. Avoid abbreviations that need a separate manual to decode.

Conditions also need to be visible. Typical examples include occupied and unoccupied modes, one-device and two-device responses, investigation timers, manual call point escalation, sprinkler confirmation, timer cancellation and firefighter overrides.

The normal fire sequence is only part of the story. Reset, latching, disablement and fault behaviour may also matter. If a smoke-control command is sent but the confirmation never returns, what is indicated? If a network link fails, can the initiating panel still produce the required local response? If a delayed output is isolated, who is warned?

Some of that information may be too detailed for a single cell. Notes and referenced logic descriptions are fine, provided they remain controlled as part of the same document set.

A small example

Here is a deliberately simple matrix:

Cause	General alarm	Door release	Lift recall	Notes
Any manual call point	I	R	I	Immediate evacuation
Automatic detection, Zone 04	D30	R	I	Delay cancelled by second device or MCP
Confirmed fire, Zone 04	I	R	I	Start associated smoke-control sequence
Sprinkler flow	I	R	I	Transmit confirmed fire signal to ARC

This is not a design for a real building. It just shows the difference between describing a functional response and listing relay numbers.

The rows are recognisable events. The columns are outcomes that can be observed. The action codes are defined, and the notes hold the conditions that should not be reduced to a tick.

A real project may need separate sections for alarm zones, smoke-control actions, damper positions, plant states, monitoring signals and feedback indications. Splitting the matrix into sensible sections is usually better than shrinking one huge table until it is unreadable.

Write it with commissioning in mind

Each cause in the matrix should be capable of becoming a test scenario. For each row, the commissioning team needs to know:

how the initiating condition will be created;
the starting condition and operating mode;
which effects should occur;
which effects should not occur;
the permitted sequence and timing;
the indication or feedback expected at each system;
who needs to witness each part; and
what evidence will record the result.

The negative checks matter. In a phased building, a fire on Level 4 might cause evacuation on selected floors while other floors remain in alert. Proving that the active outputs operated is only half of the test. The team also needs to confirm that unrelated outputs did not operate.

The test should reach the outcome described by the approved design. "Smoke extract initiated" does not necessarily prove that the correct dampers moved, that the fan ran in the correct direction or that the required airflow was achieved. Those checks need the relevant competent people and the correct test method.

Keep it under document control

At minimum, an issued matrix should identify the project, building, system scope, document reference, revision, issue status and date. It should also record the author and checker where applicable, along with the source documents, assumptions, exclusions and relevant drawing or schedule references.

The approved matrix, the panel configuration and the test evidence should tell the same story.

If the cause and effect changes, keep the previous revision. Record what changed, why it changed, who accepted it, which configuration implements it and how the revised sequence was tested. This is far more useful than a folder containing final.xlsx, final-2.xlsx and final-revised.xlsx with no reliable history.

Using FireSecure Studio

This workflow is one of the reasons FireSecure Studio includes a Logic Designer.

It can be used to build a bespoke matrix with named causes, named effects and a consistent action key. The document can be saved for later editing and exported to PDF with revision details, issue information, author and checker fields, notes and verification statements.

Wide matrices are divided into readable PDF sections with the relevant headings repeated. There is also a separate workflow for reviewing cause-and-effect data from supported Advanced MxPro configuration files.

FireSecure Studio is currently preview software, so keep an independent backup and check the output against the approved fire strategy, project specification, panel configuration and commissioning procedure. It is a documentation and engineering aid. It does not decide the fire strategy or approve design assumptions.

That distinction is important. Good software can remove a lot of the friction involved in producing and revising the document, but the content still depends on competent design, coordination and testing.

A matrix should be usable by the next engineer

The final test is straightforward. Give the matrix to a competent engineer who did not write it and see whether they can establish what initiates each sequence, what every connected system should do, what conditions or delays apply and how the completed response will be proved.

If they can, the matrix can support programming, commissioning, maintenance, modification and handover. If they cannot, more coloured cells will not solve the problem.

A good cause-and-effect matrix is simply an agreed, controlled and testable description of how the building is supposed to respond to fire. That is what makes it useful long after the original programmer has left site.