Corrective actions

Finding a problem is the easy half. An Action is SimOps' answer to the other half: one corrective work item, owned by one responsible company, tracked to an H&S sign-off. Observations, inspections and incident investigations all produce findings, and all three converge on this single tracker rather than each growing a private to-do list.

What it does for you

• A company owes it, not a person. An action is raised against a Contractor, never a user — people move between jobs and firms do not. There is no draft state: creation names the responsible company, so a new action is live from the moment it exists.
• It remembers what it came from. The optional Parent reference is the polymorphic link back to the finding it remediates — an Observation, an incident, or an inspection Item result — so "why does this exist?" always has an answer. Ad-hoc actions are legal too.
• Closing it out means showing the fix. Action close-out is the responsible company's evidence-backed claim: a solution narrative plus photo evidence, hard-required. Nobody marks their own homework as merely done.
• Someone else says it is finished. Action review is the H&S sign-off. Accept is terminal; reject is not a state but an audited transition back to assigned with a required reason and a rework count kept on the record.
• Routing respects who you can speak for. Members may route only within their own and supervised companies; the coordinator, H&S, site-manager and admin band route to any firm on the site.
• The due date chases itself. A due-soon reminder fires ahead of the date and an overdue reminder after it, each landing once. Overdue is derived from the due date and never becomes a state of its own.

The lifecycle at a glance

assigned → pending_review → accepted, with cancelled as the terminal escape from either live state. Close-out makes the first move; review makes the second. A rejection re-enters assigned — the loop is an audited transition, deliberately not a fifth state to reason about.

Where actions come from

• Observation triage — accepting an observation raises one action by default, prefilled and skippable.
• A failed inspection item — submitting a walk offers one prefilled action per fail, with the Auditee as the responsible firm; several fails sharing one underlying cause can be merged into a single action, and this is where Action priority is required rather than optional.
• An incident investigation — findings become actions, and an incident's derived closure waits on every one of them reaching a terminal state.
• Ad hoc — somebody just needs something fixed.

An action has no pin of its own; it rides as a badge on its parent's pin, and the per-user ping that points at one is a Task in My Tasks — the two are different things and the vocabulary keeps them apart.

See it / try it

Where to go next

• Observations — the triage that offers the first action.
• Inspections — the walk whose failed items raise them.
• Incidents — where derived closure waits on every child action.