Safety policies: writing and acknowledging the rules

What this is

A safety policy is a written rule your crew is expected to follow: how PPE gets worn on a mold job, what happens after a chemical exposure, who signs off before a vehicle leaves the yard. Carriers and OSHA inspectors both want the same thing from a restoration contractor: not just that the rule exists in someone's head, but that it is written down, dated, versioned, and that the crew has actually seen it. Safety Policies is the part of the Safety section built specifically for that: a small document generator for writing the policy, a library for keeping every version straight, and a running count of who on the team has acknowledged each one.

Verinode does not decide what your policies should say and does not stand in for legal or safety-consulting advice. It gives you a place to write the rule, a place to see who has signed off, and a clear read on whether your policy library is current or falling behind. You write it, your crew acknowledges it, Verinode keeps the record straight.

This article covers the Safety Policies generator itself, the six policy categories, what you see when you open a written policy, and exactly how "policy currency" is calculated. For the rest of the Safety section (incidents, insurance, the stance-first detail deck shared across all four record kinds), see The Safety section: your operational-risk radar and Opening a safety record: the polymorphic detail deck.

Where to find it

Open Safety from the sidebar, under the Compliance group, at iq.verinode.ai/safety. Safety is a Premier-tier section and must be switched on before it runs; see Certifications: activation and Premier gating for how that works (identical mechanism across sections).

On the Safety home page, the Take Action row (the first row under the hero) carries four launch tiles. The third one is Safety Policies, subtitled "Write the rules your crew follows." Tap it and it opens as a full overlay on top of the Safety home, with three tabs across the top: Overview, Library, and Write a policy.

The Overview tab

This is the first thing you see when the deck opens. It leads with a short line on what the tool is and why it matters ("Put your safety rules in writing... A written, acknowledged policy is what an OSHA inspector and a carrier both want to see"), then a labeled section, What you'll get, showing a worked example: a sample policy titled "Hazard Communication (HazCom)," tagged OSHA, version 1, status Active, with three example rule lines (staff trained on chemical labels and safety data sheets, an SDS binder kept on every active job site, refresher training every January). That example is a static sample, not one of your own policies, it exists to show you the shape of the finished document before you write your first one.

Below the example, a second labeled section, Your policies once you write one, shows a plain placeholder list of two lines describing what will appear there once you have real policies on file:

• Each policy with its version
• Who on the crew has acknowledged it

This placeholder never fakes numbers. It disappears once you have at least one real policy, replaced by the Library tab actually filling in.

The Library tab

The Library tab lists every policy you've written, one row per policy: the policy's title on the left, its category and version on the right (for example, "PPE · v1"). The tab's label carries a running count next to it, matching how many policies you have on file.

The six policy categories

Every policy you write gets tagged with exactly one category, picked from a fixed list of six:

• OSHA, general regulatory / recordkeeping policies
• PPE, personal protective equipment requirements
• Vehicle, driving, fleet, and job-site vehicle rules
• Emergency, response procedures for on-site emergencies
• Chemical, chemical handling, storage, and exposure
• General, anything that doesn't fit the other five

The category shows up in three places: the dropdown when you write a policy, the Library row next to the version number, and the Category field on the policy's own detail page. There's no seventh option and no way to add a custom category from this tool today, if you need a policy that spans more than one of these, pick whichever category is the closer fit.

Write a policy

The third tab is a flat form, three fields and a save button, no wizard:

1. 1Type a title. A short input labeled "Policy title." This is the only required field, the Save button stays disabled until there's something in it.
2. 2Pick a category. A dropdown defaulted to OSHA, with all six categories listed above as options.
3. 3Write what the policy requires. A multi-line text box labeled "What does this policy require?" This is optional, you can save a titled, categorized policy with no body text and fill in the language later, though in practice a policy with no requirements written down won't do much for you in front of an auditor.
4. 4Tap Save the policy. The button shows a loading state while it saves. On success, the form is replaced with a single confirmation line: "Saved. Your team can acknowledge it under Library." If the save fails, an error line appears in red above the button with the specific reason, or "Could not save the policy" if none is given.

A policy saved through this form goes live immediately as an Active policy, not a draft you have to separately approve. It does not get an effective date or a review date automatically, those are set later (through the platform's normal ingestion and editing paths), which means a brand-new policy shows "no review date set" on its own detail page until one is added. See How policy currency is measured below for why that matters.

Opening a policy: the detail sections

Every policy you've written can be opened from the Library tab or from the Safety section's own All Safety list, where it flips into the shared detail deck every safety record uses (see Opening a safety record for the stance-pill mechanics that apply across incidents, policies, and insurance alike). For a policy specifically, three things sit in the Details tab:

Policy Overview. The category, the version number, the effective date (when set), and the review-due date (when set).

Acknowledgments. How many of your active team members have acknowledged this policy, out of your total active team, shown as a count ("6 of 9 team members have acknowledged"). Below that, up to eight names on record, each with the date they acknowledged. This section only appears once you have an active team to measure against, an operator with no team members on file won't see it.

Version History. A list of the policy's earlier versions, each showing its version number, its effective date, and its status (Draft, Active, Under Review, or Archived). This is what lets you point at a specific, dated revision when a carrier or inspector asks whether a rule was in force on a given day, rather than just showing the current text and hoping it hasn't changed since the incident in question.

The same three fields also surface at the top of the record as quick KPIs: Review (the next review date), Version (the current version number), Acknowledged (the fraction and percentage of your team who've signed off), and Status (the policy's current state).

How a policy's stance is read

Every safety record, including policies, carries a stance pill (Healthy, Drift, Exposed, Breaching, or Watching) that drives what you're told to do next. For a policy, the stance runs entirely off the policy's own status and review date, no peer comparison is involved in this particular judgment:

• An archived policy reads Watching: "No action, archived policy," since archived policies exist as history, not active exposure.
• A draft policy reads Drift: "Finalize and activate the policy," with the note that a draft doesn't count toward compliance, you're exposed on paper only until it's active.
• An active policy with no review date set reads Drift: "Set the next review date," since policies without a review cycle fail most program audits automatically.
• An active policy whose review date is more than 90 days overdue reads Exposed: "Review and reapprove this policy now," most carrier audits flag anything that's gone over 12 months without review.
• An active policy whose review date is overdue but within 90 days reads Drift: "Schedule a review and refresh the language."
• An active policy whose review date is within the next 60 days reads Drift: "Calendar the review before the deadline," this is Verinode's early warning, not a real problem yet.
• An active policy whose review date is more than 60 days out reads Healthy: nothing needs attention until the window opens.

How policy currency is measured

Policy Currency is the single number Verinode uses to answer "is my written policy library actually up to date," and it appears in three places: a tile on the Safety home's Explore row, a peer-comparison row labeled "Policy review currency" on the Safety Benchmarks tab, and inside the section's own Standing view.

The calculation is simple and entirely your own book, no peer thresholds involved in the math itself: take every policy you have marked Active, and count how many of those have a review date that has not yet passed. Divide that count by your total active-policy count, multiply by 100. A policy that's Draft or Archived doesn't enter the calculation at all, only Active policies are measured. If you have zero active policies on file, the figure defaults to 100%, nothing is overdue because nothing exists yet to be overdue, it is not a claim that your policy program is complete.

The tile and the Standing card color the result three ways: green at 90% or above, amber from 70% to 89%, and copper below 70%, with a marker line drawn at the 90% threshold so you can see at a glance how far you are from clean. On the Benchmarks tab, your percentage sits next to the peer cohort's figure at whatever scope (National or State) you have selected, higher is better on this metric, a policy library that stays inside its own review cycle reads as healthier than one that's let reviews slip.

Best-practice example

Say your Policy Currency tile reads 62%, amber, with four active policies and one review 40 days overdue. Open the overdue policy from Library, it reads Drift, "Schedule a review and refresh the language." Read the Version History to see how long it's actually been since the language changed versus just the date it was stamped, then use Write a policy to save the updated version once you've reviewed it (Verinode keeps the prior version in history rather than erasing it). Check Acknowledgments on any policy under 90% signed, a rule your crew hasn't seen yet does nothing for you in an audit no matter how current its review date reads. As acknowledgments and reviews catch up, the Explore tile and the Benchmarks row move together, since both read off the same underlying calculation.

Data sources

Related articles

• The Safety section: your operational-risk radar
• Opening a safety record: the polymorphic detail deck
• How benchmarks work
• Reading a benchmark
• The decision workspace