Incidents

An incident is the something happened record — an injury, a near miss, damage, a spill, a security event. SimOps carries it as a positioned pin on the site plan with the reporter's own words, the people involved, the evidence, and a workflow that walks it from a private draft to a formal, reviewed H&S record. It is deliberately the sibling of the Observation (the something was seen record), and the two sit side by side in the Health & Safety panel.

What it does for you

• Reported where it happened, by whoever was there. Any member can raise an incident and stamp it on the map — three taps and a sentence from a phone, standing in front of it. Until they submit it, the draft is theirs alone.
• A review gate, not a filing cabinet. Submission hands the record to the H&S desk, which moves it into review and then approves or rejects. The reporter's edit window closes at submission, so the reviewed record is the one that was reported.
• The classification stays honest. H&S may amend an incident's type and severity after submission — layered on top with a from/to and a reason, never a silent overwrite, and never a state flip. Everything else about a submitted incident is immutable.
• A discussion beside the evidence, not mixed into it. The thread is multi-user, Mention-bearing and fully editable with version history, but comment attachments live in their own table — "show me the formal H&S evidence" stays a clean question.
• Deleting is reversible, forever. A submitted-or-later incident judged not to be a genuine record is soft-deleted with a required reason and can be restored to exactly the stage it held. There is no hard-destruction path.
• Injury and lost time meet in one place. Capture asks one three-chip question — did the work stop, slow down, or carry on? — and where a firm that lost the time can be read unambiguously, a Blocker is minted from it. Where it cannot, the answer becomes a Task for a human to name the firm, never a machine's guess.

The workflow at a glance

draft → submitted → in_review → approved, with rejected as the off-ramp. The reporter owns the draft; the H&S band owns everything after it. This status is the workflow axis and is deliberately distinct from the record's archive lifecycle and from the reversible soft-delete, which leaves the status untouched so a restore lands where it left.

Investigating, not just recording

An approved incident is where the real work starts. The investigation apparatus rates recurrence risk on its own 5×5 Investigation risk axes — likelihood × consequence — deriving an Investigation level that sizes how deep to go, kept separate from the flat severity that classifies the outcome. Causes are repeatable Incident cause rows, each optionally pinned to the Barrier layer it breached — organisation, supervision, conditions, unsafe acts, technical failure — so the column is the app's Swiss-Cheese model. An Investigator can be named, and closure is derived: an incident is closed when its workflow is terminal and every child Action is terminal. Nobody ticks a case-closed box that could contradict the record.

See it / try it

Where to go next

• Observations — the sibling something was seen record and its triage gate.
• Corrective actions — the tracker an incident investigation hands its findings to.
• Blockers & lost time — where the stoppage an incident caused is counted.