Skip to content
RISE

Safety assurance

A finding, an owner, a verified closure

Most operations find problems well and close them poorly. An action agreed in a meeting lives in that meeting’s notes. This is the half that turns a finding into something you can show somebody.

The safety assurance action register: 62 actions, 32 active, 18 overdue and 12 completed, each with its status, dates, assignee, priority and what it relates to, beside a worker in hi-vis checking a phone

Working the case is building the report

Every finding keeps its owner, its dates, its fix and the evidence the fix held. When somebody asks how it was closed, the answer is already written rather than reassembled from a year of email.

Case register

One record, from the finding to the proof

A safety case takes an issue the whole way: root cause analysis, a correction plan, a monitoring method, reassessment, and verification at the end. The stages are gated rather than advisory, so a case cannot move on to monitoring until it has both a plan and a way of monitoring it.

It cannot be marked resolved at all without a verifier, a verification date and verification notes. Resolved is the end of the line, and it means somebody with a name said this worked.

  • Root cause analysis on the record itself
  • Correction plan and monitoring method, both required
  • Verifier, date and notes required to resolve
A blocked fire exit safety case at step 2 of 4, analysis, with the first of five whys answered: pallets from a delivery stored in front of the exit because the loading bay was full

Action register

Every action, wherever it came from

Actions raised out of an evaluation, a control, an audit, an inspection, a hazard or incident report or a meeting agenda item all land in the same register, and each one remembers where it came from. One list is the whole of what this operation owes itself.

Each action goes to one named person, with a due date and a priority, and it can repeat if it is the kind of thing that has to happen every month. The assignee is told when it lands and told again if it goes past due.

  • One register, fed by every part of the system
  • Assigned to a person, not a team or a role
  • Priority, due date, and repeats where you need them
  • Each action knows the record it came from
An action to clear a blocked fire exit, assigned to Morgan Ellery with start and due dates, needing verification to complete, and linked to the hazard report and safety case it came from

Verified closure

Closing it is not the same as saying it is closed

An action can be set to require verification. Once it is, it cannot simply be marked complete. The only way to close it is to add some level of verification. There has to be a note, a file, or a link to the record that proves it.

RISE records who added the verification, so a closure is traceable to a person. Closing writes its own entry in the log, kept separate from an ordinary completion. That is the difference between a record that says the work was done and one that shows it.

  • Completion refused until verification is done
  • A note, a file, or a linked record, not a date alone
  • Who verified it is recorded against the closure
  • Verified is recorded separately from completed
Verifying an action to replace an exit sign: verified by Morgan Ellery with a date and a note that the new sign was installed, tested and stays lit on battery backup, and the test report attached as evidence

Inspections

Inspection templates you write yourself

Inspection templates are yours to write: sections, items, guidance notes for whoever is holding the tablet, evidence required on the items where a photograph is the point, and a default severity so a finding arrives already weighted.

You write the response options as well, and you say which of them counts as a finding. When an inspector marks an item with that response, a corrective action is raised from it.

  • Templates you write, not a catalog you pick from
  • Your own response scale, with your own wording
  • The response you mark as a finding raises an action
  • Evidence required per item, enforced
An inspection template's response scale: pass is acceptable, fail requires action, N/A is excluded, with evidence required on any item that requires action and a Fire Safety section being added

Internal audits

Conformance, with the evidence attached

Audits run off templates with a regulatory reference on the items that have one, conformance recorded per item, and evidence required where it should be, enforced when the audit is finalized. Findings become corrective actions in the same register as everything else. Set a review frequency and the system tells you when the next one is coming, rather than when it has already passed.

  • Conformance and evidence, item by item
  • Findings become tracked corrective actions
  • Review frequency, with notice before it is due
  • The finished audit goes out as a safety promotion
A quarterly fire safety audit with all 10 items recorded: 6 conforming, 3 partially conforming and 1 nonconforming, findings by severity, and an item being marked partially conforming, ready to finalize

Safety advisories

The warning, at the moment it is relevant

An advisory attaches to the equipment or the people it concerns, and surfaces on the report when that equipment is involved. Not filed under notices, not sent once and forgotten: in front of the person filling in the form, at the moment it applies to them.

  • Targeted at specific assets, or all of them
  • Surfaced on the report, not buried in a folder
A severe weather advisory being written: high winds forecast from 14:00, stop all crane and roof work until the all-clear, sourced to the emergency procedures manual

The record

Who changed what, and when

Every record carries its own activity log, and it is in the app rather than in a database somebody has to be asked to query. It reads in plain language, because it stores the label rather than the number underneath it, and deleting is soft throughout, so the history of a record outlives the record.

  • An activity log on every record, visible to you
  • Plain language, not internal values
  • Accepted, verified and closed recorded separately
  • Nothing is really deleted
A safety case's activity log in plain language: Morgan commented asking whether the forklift was tagged out, changed the finding type to equipment failure and the severity to medium, each with its time, beside a new comment for Jordan Okafor

Questions

Questions people ask

Does RISE chase overdue actions?
An overdue action changes status and an email goes to the person it is assigned to. What keeps the work moving is that every action sits in one register with an owner and a date on it, visible to whoever is looking, so nothing has to be chased out of somebody's inbox.
Can we require evidence before an action is closed?
Yes. An action can be set to require verification. Once it is, it cannot simply be marked complete. The only way to close it is to add some level of verification: a date plus a note, a file, or a link to a record. Who added the verification is recorded against the action.
Can we write our own audit and inspection templates?
Yes. Both libraries have a catalog of ready-made templates and a place for the ones your account owns, with a button to start a new one. Inspection templates let you define your own response scale, and the option you mark as a finding is the one that raises a corrective action.

Discover how RISE can empower your safety program

A guided walkthrough of how RISE handles reporting, evaluation, resolution and insight, with time to talk about how your own operation runs today.