Mobile Safety Auditing: Building a Traceable Record

A useful mobile safety audit record should show what someone found, what action followed and how the outcome was checked. We recommend designing for that sequence before choosing an app or replacing a paper form. Treat the record as evidence for a decision, rather than treating a completed checklist as the decision itself.

That is a practical recommendation for field operations, not a claim that a phone app fulfils building safety law. Start by separating the statutory golden thread from the broader goal of keeping a traceable workplace safety record.

Keep the golden thread in its proper scope

The Building Safety Regulator's golden thread guidance applies to England and identifies the dutyholders who must keep digital building information. It covers clients, principal designers and principal contractors working on projects involving higher-risk buildings, and accountable persons or principal accountable persons responsible for high-rise residential buildings, as set out in the guidance.

For that information, the regulator specifies digital storage, protection from unauthorised access, availability and presentation that people can use. In its section on clients' responsibilities, it says the record-keeping system should have version control so users can see changes.

The earlier Building Regulations Advisory Committee report describes both building information and the management needed to keep it accurate, understandable, accessible and current. Read that as the policy background, rather than as a replacement for the regulator's later guidance.

For a workplace audit outside that regime, use precise language such as inspection history or corrective-action record. Do not label an app compliant merely because it stores photographs or records edits. Confirm the applicable duties with suitably qualified advisers before turning them into software requirements. This article offers design recommendations, not legal advice or a complete specification of statutory duties.

Define the record before the form

Our suggested starting point is a single finding and its follow-up, not a dashboard. Give the finding a stable reference and record the relevant location or asset, the observation, who made it and when it was made. Keep the question asked and the checklist version alongside the answer, so a later reviewer has the context needed to interpret it.

Where a photograph is useful, link it to the finding and add an explanation of what it shows. Ask the person recording the issue to distinguish an observation from an assessment that requires specialist judgement. Avoid forcing an answer when the right response is that an item could not be inspected.

Make exceptions explicit in the form. We recommend a reason for an unanswered question, a route for reporting an immediate concern and a clear owner for follow-up. Agree the response procedure with the people responsible for safety, rather than asking the software team to invent one.

Make action and verification separate steps

HSE's Managing for health and safety uses the Plan, Do, Check, Act approach. Its review guidance says to ensure remedial actions have been carried out and check that the measures work.

For a mobile workflow, we recommend separate states for a recorded finding, an assigned action, reported completion and reviewed closure. Attach an owner and an agreed target date to the action. Ask the reviewer to record the evidence considered and the reason for closing or reopening it.

Consider a hypothetical inspection that finds a damaged barrier. In the proposed workflow, the finding would identify the location and the immediate response, with any supporting photograph. The person arranging the repair would record the work undertaken, then a designated reviewer would check the result against the agreed acceptance criteria. Use the example to discuss responsibilities, not as an instruction for managing a particular hazard.

Do not make an uploaded photograph the universal condition for closure. Decide what evidence is appropriate to the task with a competent person. For some findings, specify a further inspection or a documented test rather than asking a reviewer to infer the outcome from an image.

Specify what happens without a connection

For teams that need offline capture, write the expected behaviour into the acceptance criteria. Require the interface to distinguish a record saved on the device from one received by the shared system. Show pending submissions and failed transfers, and provide a way to retry without silently creating another finding.

Keep the observation time separate from the receipt time in the proposed record. Agree how conflicting edits should be handled before testing them. Include a test in which two authorised people update the same action while one device is offline, then inspect the resulting history together.

These are suggested acceptance tests, not claims about every mobile platform. Test them on the devices and network conditions intended for use. Do not describe a locally saved record as available to the rest of the team until receipt has been confirmed.

Preserve context and review the outcome

We recommend retaining the previous value, the changed value, the person making a correction and the reason for it where the record needs a change history. Set access rules for viewing, correcting and closing findings. Agree retention and export requirements with the responsible information owners before implementation.

Avoid using immutable as a substitute for a written correction policy. Specify how a reviewer will find the current record and understand earlier versions. For information subject to the building safety regime, check that design against the regulator's information management and version-control guidance, rather than assuming that an activity log is sufficient.

HSE also advises managers to plan what action they will take when performance measures indicate a need for improvement. Before building a report, ask who will use it and what decision it supports. Start with a review of unresolved findings and disputed closures, then agree which measures deserve continuing attention.

For a first delivery, we recommend following one finding from capture through correction, review and export. Ask a field worker and a reviewer to walk through that record together. Make the acceptance decision about whether the evidence and responsibilities are clear, not whether the demonstration looks polished.

Update, October 2026

Our later engineering article, Closing the Loop to Full Autonomy, describes independent review gates in software delivery. The useful comparison here is a recommendation to separate a claim of completion from the check that accepts it, not to delegate safety judgement to an agent.

Sources

• Building Safety Regulator, "Keeping information about a higher-risk building: the golden thread", 29 February 2024, updated 18 September 2024.
• Building Regulations Advisory Committee, "Building Regulations Advisory Committee: golden thread report", 21 July 2021.
• Health and Safety Executive, "Managing for health and safety", third edition, 2013, publication year only.
• Dendro Logic, "Closing the Loop to Full Autonomy", 17 July 2026, linked only in the October 2026 update.