← Features

Inspections

The scheduled, checklist-driven safety walk: a versioned template, a named firm being audited, item-by-item answers with comments and photos, a score, and a corrective action offered on every failure.

An Inspection is the planned half of site safety — the checklist walk-round, run against a named firm, as against the ad-hoc Observation somebody files because they happened to see something. An H&S inspector picks the template and the company being audited, walks the site answering item by item on a phone, and submits. What comes out is a scored, read-only record and, for anything that failed, a corrective Action with an owner.

What it does for you

  • The checklist is a versioned artefact, not a form somebody edited. An Inspection template is named and site-scoped; editing it mints a new immutable version, and a run references the exact version it used. History never mutates under you.
  • The firm being audited is a real reference. The Auditee comes from the site's contractor registry — a subcontractor or the principal contractor — never free text. It drives who owns the corrective actions and who gets told the walk is done.
  • Three answers, and N/A means N/A. Each Item result is pass ✓, fail ✗, or not-applicable, with comment and photo per the template item's flags. N/A items are excluded from the denominator, so the Pass score is passes over the items that actually applied.
  • You cannot submit an invalid walk. Submit is available iff the run is valid — every required comment written, every evidence-required item photographed.
  • Failures leave with an owner. Submitting offers one prefilled corrective action per failed item, mergeable where several fails share a cause. They are raised in the same transaction as the submit, so a walk either completes with its actions or does neither.
  • No approval theatre. The inspector is the H&S authority, so there is no second signature. A submitted inspection is terminal, read-only, site-visible and PDF-exportable.

The lifecycle at a glance

in_progress → completed. Two states, deliberately: submit is terminal, and a separate approval step would only be self-sign-off. The moment the walk completes, the score is denormalised onto the record and the run stops being editable — a correction is a new run, not a quiet edit of the old one.

The boundary that keeps the vocabulary clean

An inspection item that fails is never promoted into an Observation. The two surfaces answer different questions — "did this site pass its scheduled check?" against "what did someone notice today?" — and letting a failed item leak into the observation register would double-count the same finding in the report and the triage queue. A fail's onward path is the corrective action, and only that.

See it / try it

Where to go next

  • Corrective actions — where a failed item goes next.
  • Observations — the ad-hoc sibling this deliberately does not feed.
  • RAMS — the method the work was supposed to follow.
Was this page useful? Report a problem

No cookies and no third-party analytics. A verdict records this page's path — and a search that finds nothing records the words you typed — in this site's own server log.

Generated from source · SimOops living system reference