Technical guide

Fire alarm cause-and-effect testing before handover

A cause-and-effect matrix is only useful when the intended response can be traced to installed systems, executed under controlled conditions and evidenced clearly enough for acceptance and operation.

Start with consequence, not row count

  • Do not treat every matrix line as equal. Prioritise sequences that affect evacuation, smoke control, suppression, access, lifts, monitoring or operator decisions.
  • Group repeated low-risk outputs so witness time is reserved for complex dependencies.

Test the dependency chain

  • For each scenario, identify the initiating event, fire panel logic, interfaces, receiving systems, feedback, operator action and reset path.
  • A pass at the fire panel is not a pass for the building-wide response.

Control prerequisites and temporary conditions

  • Record isolations, overrides, temporary software, disabled outputs and incomplete systems before the test begins.
  • State whether the observed result is representative of the final operational condition.

Capture evidence that can be audited

  • Use a unique scenario reference, expected result, observed result, timestamps, logs, witness names, defects and retest link.
  • Photographs are supporting evidence, not a substitute for a structured record.

Classify deviations consistently

  • Separate safety-critical failure, acceptance blocker, partial response, evidence weakness and minor observation.
  • Avoid closing a technical issue solely because an administrative status changed.

Close the loop

  • Retest against the same expected outcome after correction.
  • Update the final matrix, scripts, defect register and handover record so they tell the same story.
Use proportionately. This guide supports project preparation; the applicable fire strategy, specification, legislation and standards determine the actual project requirements.