Case study 01 · Granite Construction · Aug–Sep 2026
STCKY Luck vs. Success
Reading every incident report in the region all the way through, and showing regional leadership that the high-potential events they were looking for had been in the data the whole time.
- My role
- Project owner: research design, classifier build, review workbook, analysis, leadership presentation.
- Users
- Regional safety leadership and supervisors who set controls on jobs; the safety manager who has to defend the number.
- Methods
- Document analysis · stakeholder interviews · AI-assisted classification with human review · data storytelling
- Tools
- Copilot Studio agent · Power Automate · Excel review workbook · HCSS incident export
- Timeline
- A few weeks, August to September 2026. The full regional export was read in a single day.
- Outcome
- Presented to leadership with two decisions requested: a company-wide read, and one definition of "adequate controls".
What "STCKY" means, and why one ratio matters so much
STCKY is Granite's shorthand for incidents with serious-injury potential. For every incident report the company asks two questions in order. Did this event have the potential for a serious injury? If yes, did a control stop it, or was it luck? Leadership sees the answer as a single ratio, Luck vs. Success, and it is meant to tell them how often the company is relying on chance.
Did it have serious-injury potential?
If no, it is Non-STCKY. A rolled ankle or a broken window with nobody nearby doesn't count, no matter how it was filed.
Did it actually happen?
If someone was seriously hurt, it is STCKY Injury.
Were adequate controls in place and followed?
Yes is Success: a control stopped it. No is Luck: nothing stopped it, and the only reason the outcome wasn't worse was chance.
The ratio leadership saw was built from a handful of events
The quarterly all-hands showed a company-wide Luck vs. Success ratio. Working backwards from the source deck and the incident export, I found it came from a handful of tagged events across the whole company. Across years of historical cases in the regional export, almost none carried a STCKY tag at all. The tag was a free-text field that had never been part of anyone's job, and "adequate controls", the phrase that decides Luck from Success, was not defined anywhere: not in the fact sheet, the decision tree, or the procedure.
The number wasn't wrong for the data that had a tag. The tag was missing almost every time.
03 · Method
One day, no new forms, and a person signs off
Read every narrative, not the tag
The incident export is fed to a classifier agent that applies Granite's own STCKY fact sheet and decision tree to each report. It is deliberately strict: first aid, sprains, minor damage and contained spills are Non-STCKY unless the narrative describes a credible path to a serious injury.
Every answer shows its work
Each report gets a worst-credible outcome, a Luck or Success call, the control gap, what information is missing, and a confidence score. Reports the agent can't read are marked Needs Investigation, not guessed at.
A person approves it before it counts
Every classification lands as a draft in a review workbook. Low-confidence cases are reviewed first. Corrections update every tally immediately, so the numbers in the deck are always the reviewed numbers.
Nothing changes for the field. Same reports, same system, read all the way through for the first time.
Far more reports described a high-potential event than the tag had ever caught
A large share of the region's reports met the strict definition. Almost all of them were luck. The few successes were physical barriers, not paperwork.
What leadership was shown
A ratio built from a handful of tagged events, company-wide.
Only a couple of those events came from this region. The rest of the region's history had no tag to count.Same region, every report read
Luck outnumbered success many times over.
From one day of reading. For every time a control stopped an event, there were many more times nothing did.- Mosthigh-potential events were recorded as property damage, no injury, or not stated. They were invisible to every injury metric leadership reviews.
- Noneof the reports had the "Steps to Prevent" field filled in. The one field built to capture the lesson was empty every time.
- Manynever said whether a control was in place. Without that line, Luck and Success cannot be told apart.
- One monthwas the worst of the year: all luck, zero injury records. It did not register anywhere. The injury dashboard stayed green.
Things nobody could see one report at a time
Reading across reports, instead of filing them one by one, is where the findings came from. Two hazard types, public vehicles in the work zone and digging into live utilities, accounted for most of the events, and a few jobs carried a large share of them.
One job struck live utilities month after month
Separate "utility damage" reports, no injuries, no STCKY tags, and most of them silent on what controls were in place. Each one looked routine on its own. Together they are one job digging blind for much of the year.
Nobody was reading the reports next to each other.
Public vehicles kept entering one work zone. The only saves were a barrier.
When a truck-mounted attenuator was positioned as the shadow vehicle, it absorbed a highway-speed impact and the crew walked away. The other times, nothing was between the public and the crew. Same site, same hazard: the control was the only variable.
This is the finding that tells leadership which fixes to buy.
Designing the presentation so a skeptic could check every number
The audience was regional leadership in a supervisor meeting, with a safety manager transition underway. I built the deck around one headline, walked one real report through the decision tree in under a minute, and closed with a backup slide listing where every figure came from. I also wrote a plain-language numbers guide so that anyone who picked up the deck later could defend each figure without me in the room.
One report, one minute
A work truck parked inside the work area with lights flashing. A crew member opened the door as a public vehicle passed, and the door was struck. In the system: a vehicle-damage report, no STCKY tag.
- Q1
Serious-injury potential? Yes.
- Q2
Luck, or a control? Luck.
- Q3
What was missing? No lane closure or buffer. The door opened toward live traffic.
What I asked leadership for
- 01
Approve the company-wide read
Run the same read-and-review on every region. If this region is typical, every business unit has uncounted high-potential events. Cost: about a day of reading per region.
- 02
Define "adequate controls"
One shared definition, and one required line in the report: what was in place. That alone closes most of the gap.
- 03
Name a sponsor and confirm an owner
So the work survives the leadership change, and the findings reach the people who set controls on jobs.
The form was designed for the person filing it, not the person reading it
The most useful finding wasn't that a model could classify reports. It was that the incident form asked a tired reporter to make a judgment call ("adequate controls?") that nobody had defined, then buried the answer in a free-text field nobody reviewed. Fixing the definition and adding one required line does more than any classifier.
Making the tally recalculate as reviewers corrected rows changed the conversation. Skeptics stopped arguing with the number and started reviewing cases, which was the point.
Leadership trusts what they can check. Putting sources on the last slide got more questions answered than anything on the first.