Safety Policies — Overview
Org and project rules that tune every safety workflow — talk cascades, walk escalation, permit behaviour, and incident close-out gates.
Safety Policies are the rules that shape how each safety workflow behaves on your project. They're found under Admin → Safety → Policies and resolve in a chain: system defaults → organization → project, so a project can override the org, and the org can override the built-in defaults.
Safety is in beta
Safety Policies are part of the Safety module, which is in beta — in production and usable, but not yet part of a versioned release of its own.
How Scopes Resolve
| Scope | Role |
|---|---|
| System defaults | The built-in starting point the form pre-fills from — not a scope you edit |
| Organization | Defaults for every project in the org |
| Project | Overrides that win for this project only |
Set once, override where needed
Set your standards at the organization level so every new project inherits them. Only override at the project level when a specific job needs different rules.
Toolbox Talk Policies
| Policy | What It Controls |
|---|---|
| Cascade roles | The ordered roles a talk routes through (default: deliverer → PMC → safety head) |
| Final step mode | Whether the last role acknowledges (confirms seen) or approves (formally signs off) |
| Allow return | Whether reviewers can send a talk back for changes |
Safety Walk Policies
| Policy | What It Controls |
|---|---|
| Auto-create issue | Automatically raise a safety issue when an observation above good practice is logged |
| Escalation threshold | Auto-escalate to an incident when an observation is at or above a chosen severity (or off) |
Permit Policies
| Policy | What It Controls |
|---|---|
| Auto-create issue on reject | Raise a safety issue for the requester when a permit is rejected |
| Block work area with no active permit | Signal that an area shouldn't be worked without an active permit |
| Allow extension | Whether requesters can extend a permit's validity window before it expires |
Incident Policies
| Policy | What It Controls |
|---|---|
| Root cause before close | Require a root cause to be filled before an incident can close |
| Corrective actions before close | Require every corrective action to be marked done before an incident can close |
Close-out gates are strict
When the incident close-out gates are on, the close button stays blocked until every requirement is met — and the outstanding items are shown. This keeps investigations from being closed prematurely.
Next Steps
- Toolbox Talks — the cascade these policies drive
- Safety Walks — issue creation and escalation
- Incidents — the close-out these gates protect