Introduction

SteadyOn is a health & safety compliance app for smaller organisations. It gives you one place to identify hazards, log incidents, run inspections, and close out the corrective actions that come out of any of the above — with a live status that tells you what’s overdue and what’s heading that way.

This page explains what’s in the app, how the modules fit together, and the assumptions SteadyOn makes about your safety programme. If you’d rather just look around, jump to the Quick Tour.

What problem SteadyOn solves

Every employer has a duty to identify hazards, assess the risks, and manage them — and to be able to show, on demand, what they did and when. In small organisations the answer is usually a folder, a whiteboard, or a spreadsheet that nobody opens between audits. None of those pass the “show me your records” test when an inspector turns up or, worse, when something has actually gone wrong.

SteadyOn replaces those with a structured register that is:

• Live — every hazard, incident, action, and inspection has a status that updates automatically.
• Auditable — every change is recorded with the actor’s name and a timestamp that doesn’t go away even if the actor leaves.
• Linked — incidents reference the hazards they relate to, actions reference the inspection finding that raised them, and so on.
• Simple — designed for owners, supervisors, and safety reps to use themselves, not just consultants.

What’s in the app

SteadyOn organises work around six core modules and a few supporting ones.

Core modules — the H&S programme

Module	What it’s for
Hazards	Your hazard register. Identify hazards, assess inherent risk, add controls, calculate residual risk, and schedule reviews.
Incidents	Report incidents and near-misses. Track investigations, capture root causes, and decide whether the regulator needs to know.
Actions	Corrective and preventive actions (CAPA). Standalone, or raised from a hazard, incident, or inspection finding.
Inspections	Templates and runs. Build a checklist once, schedule it, conduct it on a phone, and raise actions for any failures.
Documents	Policies, procedures, SDS, and other safety documents — versioned, categorised, and stored centrally.
Sites	The physical locations your hazards, incidents, and inspections live at. Each site can carry an address and capacity.

Supporting modules — who does what

Module	What it’s for
Roles	Named responsibilities (“First Aider”, “Site Supervisor”). Some roles are universal — they apply to every person automatically.
People	Your roster. People can optionally be linked to user accounts, but a person is not the same thing as a user — many people in your roster won’t have logins.
Training Courses	Courses people complete (CPR, working at heights, etc.) with default validity periods.
Reports	Standard H&S reports — risk matrix, hazard register, incident summary, action close-out, inspection summary, and an AI-assisted board report.

How a working programme uses them together

A typical week in SteadyOn looks like this:

1. A new hazard is identified during a walk-through. It’s added to the register, assessed (likelihood × severity), given a control, and assigned a responsible person.
2. An employee reports a near-miss via the public link. It lands in Incidents as a new row to triage.
3. The investigation surfaces a control gap. An action is raised from the incident and assigned to the supervisor with a due date.
4. A monthly inspection runs from a template. One item fails; an action is raised from the failure and linked back to the inspection.
5. The dashboard’s BRAG counts now show one red action, one amber hazard review coming due, and a green pass rate on inspections.

Every link above is a real cross-reference inside the app — you can click from incident to hazard to action and back, and the audit log records every change.

Assumptions SteadyOn makes

SteadyOn isn’t a blank database. It’s opinionated about a few things:

• One organisation = one workspace. All your data lives under one org. People can belong to multiple orgs (employees of one, consultant to another), but data doesn’t cross.
• Lookups are yours. Statuses, types, priorities, and severities ship with sensible defaults but you can rename, recolour, or retire any of them at any time.
• BRAG is computed, not typed. Red/Amber/Green/Blue is calculated from the actual state of an entity (overdue review, no controls, past due date, etc.) — not something you set manually. This is what keeps the dashboard honest.
• Audit is forever. Every list shows Created and Modified columns and every detail page shows a “Created by … on … Last modified by … on …” footer. Names are snapshotted at the time of the change, so even if a user is later deleted or renamed, the historical record stays.

What’s not in v1

To keep first-version scope tight, the following are deliberately out:

• Mobile native app — the responsive web app works on phones; a native Expo app is planned.
• Search across modules — list-page search and filters work today; a global Cmd-K search is planned.
• Email/SMS notifications — the configuration UI exists; delivery is not yet enabled.
• Saved reports — the schema exists; the UI is not yet wired.

These are tracked in docs/ROADMAP.md in the codebase.

Next

Take the Quick Tour to learn the shell, or jump straight into Tutorial 1: Set Up Your Organisation to start using the app on your own data.