A smoke control panel does what it was programmed to do, and nothing else. The document that says what it should have been programmed to do is the cause and effect matrix. On a worrying number of projects that document is a spreadsheet produced at tender stage, never revised after the variations, and never checked line by line against the panel standing in the riser.
This covers what a cause and effect matrix contains, who produces which part of it, how it becomes panel programming, two worked examples, and what commissioning has to do to prove it.
What a Cause and Effect Matrix Actually Is
It’s a table. Rows are causes, the things that can happen to the system. Columns are effects, the things the system can do. Each cell states what that cause makes that effect do. The format isn’t the point. What matters is that the table is exhaustive: every input the panel can see, every output it can drive, and a defined behaviour for every pairing, including “no change”.
The fire strategy says what the building has to achieve. The design says how: shaft size, free area, fan duty, damper classification. The matrix sits between the design and the equipment, and it’s the only document in the set that a controls engineer can program from and a commissioning engineer can test against. If a behaviour isn’t written in the matrix, either it isn’t in the system, or it’s in the system and nobody has agreed to it. Both are problems.
One thing to get straight early. “Cause and effect” gets used for two different documents on the same job. The fire alarm cause and effect governs sounders, door releases, lift homing, plant shutdown and the signals sent out to other systems. The smoke control cause and effect governs vents, dampers, fans, inlet paths and the panel’s own indication. They overlap at exactly one point: the signals passed from the alarm panel to the smoke control panel. That overlap is where most of the errors live, because it’s the one part neither designer treats as fully theirs.
Who Writes It, and Who Fills In the Detail
The principles belong to the fire strategy. The fire engineer or strategy author decides how many smoke zones there are, what detection activates which zone, whether the stair vents on stair detection or on corridor detection, how the system behaves on a second alarm, and what the firefighter controls are permitted to override. These are life safety decisions and they aren’t a contractor’s to invent.
The smoke control specialist then produces the detailed matrix. That means turning “the fire floor lobby damper opens and all others close” into a table that names Damper D-05, panel input 5, panel output 12, and states the position of every other damper on the shaft while D-05 is open. This is where the strategy meets real assets, real panel input and output counts, and real device addresses.
The fire alarm designer produces the alarm-side matrix in parallel, and someone has to cross-check the two. Fire alarm zones and smoke control zones are numbered by different people for different reasons, and they line up by luck more often than by design. Projects come unstuck because alarm zone 3 was assumed to be smoke zone 3.
BS 7346-8 is the code of practice covering planning, design, installation, commissioning and maintenance of smoke control systems, and it includes sections on documentation and responsibility as well as commissioning, certification and acceptance. It’s the standard to point at when nobody will own the document. On the alarm side, BS 5839-1:2025 recommends that a cause and effect matrix, or a text description of how the cause and effect operates, forms part of the documentation handed to the purchaser or user of the system.
What Goes In: Inputs, Outputs and States
Inputs. Detection zone signals from the fire alarm system, usually one per smoke zone. Manual control points and break glass units. Firefighter switch positions, typically open, close and auto. Fault inputs from actuators, dampers, fans and power supplies. Position feedback from vents and dampers. Anything else the panel is wired to see.
Then there are inputs that must not drive fire mode: rain and wind sensors, temperature sensors, timeclocks and any building management signal used for day-to-day natural ventilation. These belong in the matrix precisely so their limits are written down. Fire mode overrides all of them, always, and the matrix should say so on its own line rather than leaving it as an assumption. That principle is one of the reasons HVAC controls are not suitable for smoke ventilation duty.
Outputs. Every vent, every damper, every fan, every powered inlet path, every actuator group the panel drives. Add the indication and signalling: fire and fault relays back to the alarm panel, status indication at the fire brigade access level, remote monitoring outputs, and anything feeding a building management system for information only.
States. This is the part that gets skipped. A matrix that only defines fire mode is half a document. It needs to cover:
- Normal standby, including whether vents sit closed or in a ventilation position
- Fire, per zone
- A second alarm in a different zone while the first is still active
- Fault, distinguishing a device fault from a loss of mains
- Manual override from each firefighter switch position
- Reset, and what has to be true before reset is permitted
- Test mode, and what is inhibited while it runs
The second alarm line matters more than its length suggests. In a shaft-served block, whether the system holds the original fire zone as primary or switches to the newer alarm is a fire strategy decision with real consequences for anyone still escaping. There is no universal answer. What there must be is a written one.
Worked Example: A Single Stairwell AOV Block
The most common arrangement in UK residential stock: a single stair, an automatic opening vent at the head of the stair, an inlet at the entrance level, one smoke control panel. Simplified, the matrix looks like this.
| Cause | Stair head AOV | Entrance inlet | Indication |
|---|---|---|---|
| Normal standby | Closed | Closed | Healthy |
| Detection signal, stair zone | Open, full travel | Open | Fire |
| Manual control point, entrance level | Open, full travel | Open | Fire |
| Firefighter switch to OPEN | Open, full travel | Open | Manual override |
| Firefighter switch to CLOSE | Close | Close | Manual override |
| Actuator or line fault | No change | No change | Fault, relay to alarm panel |
| Mains failure | Hold position, standby supply active | Hold position | Fault, relay to alarm panel |
| Reset at panel | Close | Close | Healthy |
Even at this size the table forces decisions. Does corridor or lobby detection open the stair vent, or only stair detection? That depends on the strategy and on whether the corridors have their own ventilation, and it’s the single most common thing left ambiguous on small blocks. Does the firefighter switch stay live in standby, or only once the system is in fire mode? Does a fault on the inlet inhibit the vent, or just report? Write the answer down or the panel will end up with somebody’s default.
Worked Example: A Smoke Shaft With Per-Floor Dampers
Now a ten-storey block with a smoke shaft, a damper in each lobby, a vent at the shaft head and a stair AOV. Take detection on level 5. The behaviour that matters is primary zone lockout: the fire floor damper opens, every other damper stays shut, and the shaft is not allowed to become a distribution route to the floors above.
| Cause | Level 5 damper | All other dampers | Shaft head vent | Extract fan | Stair AOV |
|---|---|---|---|---|---|
| Normal standby | Closed | Closed | Closed | Off | Closed |
| Detection, level 5 lobby | Open | Closed and locked | Open | Run, fire duty | Per strategy |
| Second detection, level 8 | Open, held | Closed and locked | Open | Run, fire duty | Per strategy |
| Firefighter switch, level 5 | Open | Closed and locked | Open | Run, fire duty | Open |
| Damper fault, level 5 | Fault reported | Closed | Open | Per strategy | Per strategy |
| Reset at panel | Closed | Closed | Closed | Off | Closed |
Two cells in that table say “per strategy” on purpose. Whether the stair AOV opens on lobby detection, and what a mechanical system does when the fire floor damper reports a fault, are decisions the fire engineer makes for that building. A generic matrix that fills those cells with a manufacturer default is worse than one that leaves them flagged for the strategy author to answer.
The second detection row is the one to argue about at design stage rather than on site. Holding level 5 as the primary zone keeps the extract where the fire is. Switching to level 8 abandons it. Either can be right depending on the detection layout and the escape strategy, and neither should be discovered by a commissioning engineer pressing two test buttons and writing down what happened.
The Fire Alarm Interface
For natural systems the interface is usually volt-free contacts: one pair per smoke zone from the fire alarm panel to an input on the smoke control panel, plus fault and reset signals coming back. On larger systems it’s an addressable interface unit, or a network connection where the equipment supports it. Either way, the circuits should be monitored so that a broken interface is a detected fault rather than a silent one.
The matrix has to state the mapping explicitly: alarm zone to smoke zone, contact by contact, on the same page. Where a project goes wrong is nearly always here. A single common fire relay for the whole building tells the smoke control panel that there is a fire but not where, which means the panel cannot open the right damper and lock out the rest. It’s still installed on refurbishment jobs where the existing alarm system had one spare pair of contacts and nobody wanted to pay for more.
The other recurring interface problem is reset. If the alarm panel latches and the smoke control panel latches, and neither clears until the other does, somebody has designed a building that stays in fire mode until an engineer attends. That behaviour belongs in the matrix, agreed by both designers, before the panels are ordered.
Smoke control panels are specified against BS 7346-8 in the UK while the European product standard for control panels remains in draft. We’ve set out the current position on prEN 12101-9 separately.
From Matrix to Panel Programming
Programming is transcription. The engineer takes each row of the matrix and configures the panel to produce those outputs from those inputs. Nothing in that process should require judgement, and where it does, the matrix is incomplete.
How the panel stores that configuration decides how checkable it is later. Older panels set zone behaviour with dip switches and jumpers, so the configuration exists physically inside the enclosure and nowhere else. Read it back and you’re reading switch positions, then comparing them against a matrix that may have been revised twice since. Nothing records who changed what, or when. We’ve written about why dip switches undermine Golden Thread compliance in more detail.
Addressable panels hold the configuration in software and can log events and changes. That turns the check into a document comparison: the panel’s stored configuration against the current matrix revision, both readable, both dated. The O Range panel is addressable across 1 to 60 zones with no dip switches, and logs events for Golden Thread evidence. The general principle holds whichever addressable panel is used: a configuration you can read and export is a configuration you can audit.
Where Matrices Fail on Real Projects
The matrix is never updated after variations. A floor is added, a lobby is reconfigured, a damper is deleted, detection moves. The drawings get revised. The matrix, held by nobody in particular, does not. By handover the document describes a building that was never built.
The panel is programmed from memory. An engineer who has commissioned forty similar blocks configures the forty-first the same way, because the matrix was three revisions old or nobody could find it. The panel then works, in the sense that vents open, but it implements a generic strategy rather than this building’s.
Nobody witnesses the test against the document. The engineer tests, the engineer signs, and the certificate says cause and effect verified. Verified against what, and observed by whom, is left unstated. Where sample testing is used, the sample almost always covers the zones that are easy to reach.
Fault, reset and override are undefined. The fire lines get tested. The fault lines never do, because there’s no row to test. Then a damper fails in service and nobody can say whether the system’s response was correct.
The matrix isn’t handed over. It stays on a project server, the contractor changes, and the maintenance engineer arriving three years later tests the system against what it does rather than what it should do. At that point the system has quietly redefined its own design intent.
The scale of this isn’t theoretical. A report published by CROSS from an engineer testing residential smoke control systems gave an initial estimate that 60 to 80 per cent of the buildings tested had failed cause and effect testing, with vents opening in the wrong direction, design-critical vents not opening at all, and lockout failing so that multiple floors vented at once. The expert panel response also made the point that cause and effect testing is done cold, without smoke, so it proves the logic rather than the aerodynamics. That’s a limit worth understanding: passing the matrix is necessary, not sufficient.
Proving the Matrix, and Keeping It in the Golden Thread
Commissioning proves every line. Not a sample, not the ground and top floors, every line. Each input is applied at source, the resulting outputs are observed at the device rather than assumed from a panel LED, and the result is recorded against the row reference in the matrix revision being tested. A commissioning record that references matrix revision C, row by row, is evidence. One that says “cause and effect tested satisfactorily” is a sentence.
That means the witness test needs the right people in the room with the current document in hand, and it needs enough programme time that failures can be corrected and re-tested rather than noted and carried forward. Cause and effect is also the stage where the discrepancies between the alarm-side and smoke-side matrices surface, which is another argument for both designers being present. Our commissioning best practice guide covers the wider sequence this sits inside.
After handover, the matrix belongs in the golden thread. Under the Building Safety Act 2022 the accountable person for a higher-risk building has to hold building safety information that is accurate and current, and the smoke control system is squarely inside that. The matrix is the document that states what the system is supposed to do. Without it, the commissioning record proves nothing, because there’s no benchmark to have tested against, and no future engineer can tell a fault from a design decision.
Keep it versioned, keep it with the fire strategy and the as-installed drawings, and put it under change control. A variation changes the matrix. A changed matrix means a re-configured panel. A re-configured panel means the affected rows are re-tested and the record updated. Break that chain at any point and the building’s evidence trail has a hole in it that only shows up under audit, or after an incident.
Practical Takeaway
Ask for the matrix by revision number, not by name. If the version in the O&M manual is older than the last variation, it’s not a record of your building. Check that fault, reset, second alarm and every firefighter switch position have their own rows, because a matrix covering fire mode alone is half a document. Check the alarm zone to smoke zone mapping is written out contact by contact, and that a single common fire relay hasn’t been used where the panel needs to know which floor.
At commissioning, require the test to run line by line against a named revision, witnessed, with the result recorded per row. After handover, keep the matrix under change control alongside the fire strategy, and re-test the affected rows whenever the configuration changes. That’s the whole discipline. It isn’t complicated, which is what makes the failure rate hard to defend.
Further Reading
- Commissioning Best Practices for Smoke Ventilation Systems
- Primary Zone Lockout Explained
- The Golden Thread and Smoke Ventilation Under the Building Safety Act
- Anatomy of a Smoke Control System
- Smoke ventilation glossary
- From Fire Strategy to Smoke Control Spec
- Smoke Control Handover: The Documents to Demand Before Practical Completion
Sources
Official guidance and standards referenced in this article:
- BS 7346-8:2013, BSI Knowledge
- BS 5839-1:2025, BSI Knowledge
- Testing of smoke control systems, CROSS Safety Report
- Building Safety Act 2022, legislation.gov.uk
- Approved Document B (fire safety), GOV.UK
- Smoke Control Association
Programming a Panel Against a New Matrix?
We supply smoke control panels and the smoke and natural dampers they drive, with UK stock in Poole and next-working-day despatch on most lines. Our technical team can sanity-check a cause and effect matrix against the panel’s input and output count before you order, which is a cheaper conversation than finding the shortfall at commissioning.
Call 01202 725 689 or email info@vent-trade.co.uk.
