Walk a quarry the morning after a hand injury. I have done it more than once. The shift lead has the worker, the witnesses, the maintenance log on the loader, and a notebook full of fragments. By the time those fragments get typed into a form, reviewed, paired with a corrective action, and tied back to the relevant subpart of the regulation, three weeks have passed. The inspector arrives in two.
That delay — between the incident and the structured answer to why it happened — is where most EHS programs get caught flat-footed. The capture surface is usually fine. The synthesis is what falls apart. The analysis that turns a record into an answer the auditor can read in one sitting is almost always missing, or arrives too late to matter.
We built a piece of the platform specifically to close that gap. It runs inside the inspection workflow, produces a structured 5-Why analysis with every recommended corrective action cited back to a specific section of the regulation, and saves the analysis with the record. That is the short version. The longer version — what I almost got wrong, and the rule I would not bend — is below.
Why we went structured, not free-form
The first version of this feature did not have the 5-Why structure. I gave the analysis layer the incident context and let it write whatever felt right. The prose that came back was authoritative. It read well. I almost shipped it that way.
What stopped me was a conversation with an EHS director who looked at a sample output and said, politely, that no auditor was going to read it. Auditors do not score prose. They score citations and corrective actions, and the question they are answering is whether the action actually addresses the root cause. Beautiful prose with no citations is a writing exercise. So we tore that version up and rebuilt around a four-section structure that maps directly to what an auditor scans for:
- Immediate cause — the unsafe act or condition closest in time to the incident.
- Contributing factors — the conditions or system gaps that made the immediate cause possible.
- Root cause(s) — the systemic node that, if changed, prevents the next iteration.
- Recommended corrective actions — each tied to a specific section of the regulation, with the citation visible.
The fourth section is where the system earns its keep. A recommended action without a citation is a suggestion. With a citation, it is an audit defense. The EHS director who told me that was right.
Citations come from the regulation
Citations have to come from somewhere defensible. We curate a body of regulatory text — the relevant federal subparts for general industry, construction, and surface mining, plus the codes those subparts reference. When the analysis layer writes a recommended corrective action, the only citations available to it are passages already present in that body. If the relevant subpart is not in scope, the action ships without a citation, flagged for human review.
That last constraint is the one I would not let go of. Inventing a citation — a real-looking section number paired with text that does not actually appear in the regulation — is the single fastest way to make an EHS tool untrustworthy. I have seen it happen with general-purpose tooling. It is the reason a lot of EHS directors are skeptical of anything that uses inference for compliance work, and they are right to be skeptical. We treated no invented citations, ever as non-negotiable from day one. The platform would rather hand the EHS lead a half-finished corrective action with a clear gap than a confidently wrong reference number.
What we deliberately did not let it do
The negative space matters as much as the affirmative behavior. Three rules.
1. It does not invent citations.
Already covered above. The single most important line in the system. We audit it on every release.
2. It does not replace human investigation on serious incidents.
The analysis is a starting frame, not a substitute for a properly run investigation. For serious-injury or fatality events, the platform surfaces the structured analysis as evidence for the investigators and routes the record into a multi-investigator workflow with explicit sign-off. The analysis informs. It does not close. I want to be very direct about that — the platform is a tool, the investigation is human work.
3. It does not run silently in the background.
Every analysis is triggered by a person — usually the EHS lead or an inspector pulling up a record. Background batch-generation against the entire historical corpus is available but off by default. Programs where every record carries a machine-generated analysis tend to get worse, not better, because the human eye stops reading. We learned that the hard way watching a different category of tooling (not ours) at a customer site.
What I almost got wrong
Three things I would call out for anyone trying to build something similar.
First, I almost let the analysis run on every incident automatically. The design pressure to do that is real — it looks productive, the dashboards fill up, the demos land well. The problem is that machine-generated analysis on a routine incident reads as noise to the EHS team, and noise on routine records erodes signal on the records that matter. We pulled it back to on-demand only and the quality of attention the team paid the outputs went up immediately.
Second, I underestimated how important the human-readable source reference is. The first version showed the citation as a section number. That was not enough. Auditors and EHS leads want to see the actual passage from the regulation, in context, with the source document and page number, before they trust the recommendation. We rebuilt the reference layer to surface the passage on click. It is the single feature I get the most positive feedback on, and it was not in the original design.
Third, I was too clever with caching at first. The analysis layer is not free to run, so the early version cached aggressively. That worked fine until a customer updated the underlying regulation reference in their knowledge base and started seeing analyses cite passages that were no longer there. We rebuilt the cache logic so the underlying knowledge-base version is part of the cache key. Stale guidance is worse than slow guidance, in this category.
Where it sits in the workflow
The trigger order matters. An inspection is filed on the frontlines on a Pulse kiosk by card-tap. The record arrives in the dashboard with the asset bound. The EHS lead — or, later, an inspector working through last year's records — can ask the system for a structured analysis. The result appears on the incident detail page with the cited sections rendered as clickable references.
The practical effect for an inspector arriving on site: when they pull up an incident from six months ago, the analysis is already there, the citations are already there, and the corrective-action ledger is tied back to the section of the regulation they were about to ask about. The conversation moves immediately from what happened to what changed and when, which is the conversation everyone wanted to have in the first place.
What I'm working on next
- Cross-incident pattern surfacing. When the same root-cause node appears in multiple incidents inside a rolling window, an alert escalates and the associated corrective actions are tied back into the ledger. I am genuinely excited about this one — it is the first step toward EHS that anticipates instead of reacts.
- Regulation revision watchers. When the underlying regulation is updated, the affected analyses surface a delta for the EHS lead to review and accept. The cache-versioning work above made this possible.
- Voice capture continuity. Dictated incident descriptions feeding straight into the structured analysis path. Narrow scope, high-value handshake, and a feature I still find faintly miraculous when I watch it work in the field.
Get in touch
If you have feedback on this post — especially if you think I'm wrong about something — I'd like to hear it. The contact form is above. So is my email through it.
— Jeffrey