BS 8644-1 is moving digital fire safety records from a nice-to-have PDF bundle to a structured, queryable dataset that can be trusted across design, construction and occupation. The standard doesn’t push a single platform; it sets expectations about information types, data structure, and traceability so the “golden thread” can actually be delivered under UK project pressures.
TL;DR
/>
– Use a CDE that can handle structured fire data, not just documents, and align naming, metadata and roles to BS 8644-1 expectations.
– Capture evidence in the field with timestamps, locations, product references and installer competence, then link it to the model and the asset register.
– Keep the fire strategy and compartmentation model as the reference point; all inspections, deviations and approvals should tie back to it.
– Focus on interoperability (IFC, CSV, open APIs) so records survive platform changes and hand over cleanly to the client.
– Build a change-control loop that flags fire-affecting variations early to the principal designer and fire engineer.
Plain-English: what BS 8644-1 expects of your digital fire information
/> At heart, BS 8644-1 wants consistency: a shared approach to structuring, naming and connecting fire-critical information. That covers the strategy drawings, the compartmentation data, the asset registers (doors, dampers, alarms, emergency lighting), the product documentation and the performance evidence. Each item should be traceable to its source, its approval and its as-built state.
It also wants roles and workflows to be explicit. Who sets the information requirements for fire? How are they carried into the design model and the spec? When something changes, who is notified, and how is acceptance (or rejection) recorded? The standard aligns with good information management practice so that fire data is not a separate system but a defined part of your CDE, BIM and QA regimes.
Finally, it pushes long-term usability. Records should be findable, rugged against software churn, and meaningful to the people who inherit them—soft FM teams, RP-appointed dutyholders, insurers, and the fire service.
How the toolset actually works on UK projects
/>
A BS 8644-1-aligned stack usually looks like this:
– A CDE that manages both files and structured data fields, with permissioned workflows.
– A model environment where the fire strategy and compartmentation are explicit—through classifications, zones or dedicated views.
– Field capture tools that record installation, inspection and commissioning events with photos, barcodes/QRs, location and timestamps.
– Issue management that links clashes, deviations or non-conformances to the model and routes them to the right decision-maker.
– Exportable registers and reports—open formats for long-term storage, and APIs for integration with CAFM/BMS on handover.
If you keep those layers speaking the same classification language (Uniclass, asset tags, space IDs) the data holds together through design changes and programme wobble.
# A live retrofit scenario under schedule pressure
/> An occupied 18-storey housing block in the North West is receiving new fire doors, fire-stopping around risers, and a partial alarm upgrade. The principal contractor is holding night shifts due to resident access windows; the M&E subcontractor is overlapping on three floors. The fire engineer has updated the compartmentation zones after discoveries in voids, which means the model differs from the week-old drawings on site. A gang installs four doorsets to the old schedule, then logs them in the field app—photos attached, but the zone IDs don’t match the latest model. During QA, the digital coordinator spots the mismatch and raises a BCF-linked issue to the principal designer and clerk of works. Two doorsets must be reworked; the others are accepted after the model is corrected and the metadata is updated. Because the asset register, issues and approvals are tied to the strategy and zone references, the fix is painful but contained, and the golden thread stays intact.
Selecting and integrating tools against the standard
/>
– Start with the employer’s information requirements for fire. Whether client-led or developed with the principal designer, these define the attributes, formats and acceptance evidence for every fire-relevant element. Bake them into the CDE templates and the field app forms before procurement meets site.
– Make the fire strategy the anchor. In the model, use zones and classifications that reflect real compartments, shafts and fire-resisting elements. Every record—install photos, inspection sign-offs, commissioning sheets—should reference these zones or element IDs.
– Choose field tools that capture context automatically. Time stamps, user IDs, geolocation or QR scans reduce disputes. Tie each record to a product reference and an install method statement so the evidence is actionable if something goes wrong later.
– Keep formats future-proof. Store live data in your platform of choice, but agree open deliverables: IFC for model views, CSV/JSON for registers, PDF/A for key certificates, and readable, documented naming conventions. If the client or FM provider changes software, your data lives on.
– Build an issues loop that respects roles. A deviation that alters a fire boundary must not be closed in the field. Route it to the principal designer and fire engineer, capture the decision, and show the impact on the model and schedule—BS 8644-1 expects this join-up.
– Test the handover early. Run a dry-run export of the fire asset register, strategy views, and a sample of evidence packs. Hand it to the asset manager and ask: can you find, trust and use this to maintain the building? If not, adjust now, not at PC.
On-site checklist for BS 8644-1-aligned records
/>
– Confirm that the latest fire strategy views and zone IDs are visible in the CDE and field app before works start each shift.
– Tag every fire door, damper and penetration with a durable ID (QR/barcode) linked to a structured asset register.
– Capture install evidence with product type, batch/label, installer competency record, method used, and photos showing context and measurement.
– Log any deviation that affects fire performance as a formal issue tied to the model element and route it to the design dutyholder.
– Reconcile weekly: sync field records with the model zones and verify there are no “orphan” entries lacking a compartment reference.
– Export a rolling evidence pack for each floor/zone and have the clerk of works or fire engineer sample-check for completeness.
– Lock down approvals: once accepted, mark the instance as “as-built” with date, approver identity, and any residual risks noted.
# Common mistakes
/>
– Treating fire data as a document dump. Without structured attributes and IDs, you cannot prove traceability when challenged months later.
– Letting the model and site IDs drift apart. If zones or element IDs change, update tags and forms fast or the register fragments.
– Closing issues in the wrong forum. Field teams sometimes “resolve” a fire-affecting change without design approval; that unpicks later.
– Ignoring product substitution impact. A like-for-like swap rarely is; missing evidence on compatibility with the tested system creates holes.
Pitfalls and practical fixes that save hours
/>
– Pitfall: Doorset inspections clog the workflow because evidence is inconsistent across three subcontractors. Fix: Standardise the form with mandatory photos, a drop-down for classification, and a scan of the door label; run a 30-minute toolbox to align everyone.
– Pitfall: The CDE can store data but the FM provider cannot ingest it. Fix: Agree the handover schema and test an API/CSV transfer in month one; keep a plain-language data dictionary alongside.
– Pitfall: Fire-stopping is installed to drawing, then reworked after ceiling changes. Fix: Tie penetrations to the services model via unique hole IDs; hold a pre-install clash session and publish a penetrations schedule with the fire system references.
– Pitfall: Commissioning certificates are filed but not linked to assets. Fix: Assign certificates to asset IDs in the register and generate a view per zone that proves coverage and sign-off status.
What to watch next in the UK market for fire data
/> Expect tighter alignment between the fire strategy model and asset management systems, with more clients asking for dataset validation rather than just documents. Toolmakers are adding automated checks that flag records lacking a compartment reference or an approval trail—useful if configured early.
If you’re short of time, focus on three things: make the strategy model the single anchor, enforce structured field capture, and prove your handover can be read without your software licence. The projects getting this right are the ones where design and site teams agree the schema before the first penetration is drilled.
FAQ
# How do I specify BS 8644-1 requirements in tender documents?
/> Set out the fire-related information requirements as a schedule: attributes per asset type, reference to zones/compartments, evidence types, and acceptance workflow. Ask bidders to confirm tool compatibility with structured data in the CDE and to price field capture, issue routing and handover exports. Keep formats open and name who is accountable for approval steps.
# Do I need a special CDE, or can I adapt our current one?
/> Most mainstream CDEs can support structured records if configured properly, but you may need add-ons for field capture or asset tagging. The key is whether you can create and enforce metadata, link records to model elements, and export interoperable datasets. Trial a pilot process on a small zone to expose gaps before full rollout.
# Who owns the digital fire records at handover?
/> Clients typically take ownership, but the contract should define this explicitly, including licensing for any proprietary formats. During construction, the principal contractor maintains the live record with input from subcontractors and the design team. Ensure the final deliverable is usable by the client’s FM team without ongoing platform dependence.
# How should subcontractors be onboarded to the digital process?
/> Hold a kickoff focused solely on fire data: explain IDs, required photos, evidence standards and who approves deviations. Provide ready-to-use forms in the field app and a quick reference guide with examples of acceptable evidence. Tie payment milestones to evidence completeness to keep consistency across trades.
# What happens when site conditions force a change that affects fire strategy?
/> Raise a formal issue in the CDE referencing the affected zone or element, attach photos and a short description of the constraint, and route it to the principal designer and fire engineer. Do not proceed with permanent works until an approved resolution is recorded and reflected in the model or drawings. Update the asset register and evidence trail to match the agreed change.
