procedures, risk assessments, investigation outputs, and performance reports. These experiences span different commodities, operational models, and regulatory contexts. 3. STATE OF PRACTICE: HOW SYSTEMS DIFFER AND WHY IT MATTERS Across organisations, health and safety systems range from fully integrated with ORM to deliberately separate frameworks with occasional touchpoints. Some adopt a single taxonomy and risk matrix across operations, safety, and health; others maintain separate definitions, thresholds, and reporting lines. Variation in itself is not a problem: different designs can work when implementation choices are explicit, coherent, and well-communicated. The difficulty arises when the design rationale is undocumented or forgotten, leaving people to make local interpretations that gradually diverge. Over time, language, thresholds, and assurance routines slip out of alignment. A recurrent barrier is information architecture: critical‑control definitions, verifications, and status evidence are often scattered across risk registers, safety applications, work management systems, and spreadsheets. Without a clear single source of truth and stable identifiers, supervisors cannot be certain that the control information they are viewing is the latest version for today’s work area. At the frontline, this often presents as uncertainty about which controls matter most, who is responsible for verifying them, and where the evidence is kept. A second recurring pattern concerns the way risk assessments operate across different layers of the organisation. At the organisational level, risk assessments focus on material unwanted events, risk registers, and bowtie analyses. These artefacts are often technically robust, but frontline workers and supervisors are rarely involved in their development. As a result, the insights generated at this level, particularly around critical controls, do not always flow clearly to the people expected to apply them in daily operations. At the project or change-management layer, involvement from workers and supervisors is generally stronger, yet variability persists in how risk tools are selected and applied. Some organisations mandate a single method, while others allow multiple approaches depending on project scope or contractor preference. This flexibility enables projects to select the tools most suited to identifying potentially catastrophic scenarios, promoting deeper analysis and better engagement. Without deliberate integration mechanisms, valuable learning captured during projects can remain isolated rather than informing routine work. At the task-based layer, tools such as Job Safety Analysis (JSA)s are widely used, but many templates begin as a blank page and provide limited connection to the organisational risk assessments above them. In many cases, the design of the JSA form itself has not been approached with human-centred design principles in mind. Critical information such as the key controls identified at the organisational or project levels is not accessible or scaffolded within the tool. Workers are therefore required to reconstruct risk understanding from scratch, relying on memory or local norms, and to hunt across multiple systems for the “right” information without certainty that what they find is the most up‑to‑date control specification, which increases the likelihood that important controls are overlooked or inconsistently described. A recurring challenge at the frontline is the lack of clarity about whether the frontline tool (e.g. SLAM, Take 5) being used is intended as a genuine risk assessment or as a verification activity. If the tool is meant to function as a risk assessment, there must be a clear understanding 15
RkJQdWJsaXNoZXIy MTM0Mzk2