Case study 02 · Granite Construction · Jun–Aug 2026
Work Zone Intrusion Classifier
A repeatable way to find the events that matter inside a general near-miss log, and a specification a development partner could build intrusion-detection AI against.
- My role
- Wrote the definition, built the classification flow, reviewed every record, wrote the 26-scenario specification.
- Users
- Regional safety leadership; a development partner building work-zone intrusion alerts; safety staff who maintain near-miss data.
- Methods
- Content analysis · definition design · human-in-the-loop classification · stakeholder review · specification writing
- Tools
- Power Automate · AI Builder / Copilot Studio agent · Excel review sheet
- Data
- 143 near-miss and incident records, January 2023 to June 2026, 86 jobs across 6 regions.
- Outcome
- 20 confirmed intrusions surfaced; 26 build-ready scenarios delivered; workflow adopted as the template for the STCKY project.
Incident data is only as good as the category the reporter picked in the field
A work zone intrusion is when a vehicle or person gets past traffic control and into the space where a crew is working. It is one of the most common ways road workers die. In the near-miss log, those events were filed next to windshield rock chips and parking-lot bumps, under whatever title the reporter typed.
No shared definition
The same event gets filed differently depending on who writes it up and how much time they have.
Free text, not data
Narratives are rich; the structured fields around them are thin, inconsistent, and hard to query.
Real events stay buried
Genuine intrusions sit inside a general log and never surface in the data that drives safety decisions.
How these arrived in the log, verbatim
Record titles as filed, typos and all. Every one of these turned out to be a real work zone intrusion.
Which data to trust
The project started on incident reports, because that is where leadership looks. After reviewing early results with safety leadership and the regional data owner, I made near-miss records the primary source and kept incident reports as a secondary check. Near-miss narratives described the traffic behavior; incident reports mostly described the damage. Of 143 incident records screened, only 4 were confirmed intrusions. The rest were correctly excluded: rock chips, backing bumps, third-party claims within contract limits.
Confirmed intrusions by type, both sources combined
35 confirmed intrusions across the region: 31 from near-miss records, 4 from incident reports.
- 143records classified, January 2023 to June 2026, 86 jobs, 6 regions
- 20confirmed work zone intrusions sitting inside the general log
- 10rated Catastrophic; 16 were Level 3, meaning a vehicle or person entered the protected area with crews present
One definition, applied the same way every time
Built in Power Automate over the incident table. The 143rd record is judged by exactly the same rule as the first: no drift, no fatigue, and a written rationale you can read and argue with.
One written definition
A single explicit definition of what counts as a work zone intrusion is supplied to the model, the same text for every record. Writing it was most of the work.
Machine classification
An agent reads each narrative and writes back threat level, category, severity, a confidence score, a rationale, and what information the record is missing.
Human verification
Every row is reviewed and set to Approved, Excluded, or Needs Review. Nothing publishes on the model's say-so. 139 approved, 4 excluded for insufficient detail, 2 escalated.
"Not stated in source data"
The model is forbidden from inventing time, weather, speed or lighting the record never captured. Gaps stay gaps.
Missing information is an output
Each record names what it lacks, turning data-quality problems into a list instead of a blind spot.
Confidence travels with the answer
Mean confidence 0.87 across 143 records. Low scores route to review rather than into the results.
Why the human step is not optional
The model did not decide. It returned 0.6 confidence, wrote out why the definition didn't cover the case, and set the row to Needs Review for a person to settle. Two records were escalated this way rather than guessed at. That behavior is the difference between a tool a safety team will trust and a tool they will quietly stop using.
26 build-ready scenarios
Clean classification became a specification the development partner could build and train against. They needed genuine work zone intrusions, not invented ones, and eight behavior profiles emerged from the classified data: impaired intruder, flagger bypasser, barrel clipper, loss of control, TMA striker, confused follower, emergency and pursuit, unauthorized actor.
15 must-have, 11 nice-to-have, three alert levels: Warning, Threat, Intrusion.
Two scenarios exist to stay quiet
Two of the 26 define what must not trigger an intrusion alarm: utility strikes, equipment movement, plant hazards. A system that cries wolf gets ignored, and crew trust is the thing that actually saves someone.
Where it goes next
Work zone intrusion was the proof case; the workflow is the asset. The definition is an input, so the same pipeline applies to near-miss reporting, safety observations, equipment damage, and quality or environmental records. It became the template for the STCKY project a month later.
Define before you classify. Design for the false alarm.
Most of what looked like a data problem was a language problem. Once the definition was written down and shared, people who had disagreed about individual records agreed on almost all of them.
A confidence score is a user-experience feature, not a statistic. It tells the reviewer where to spend their attention, and it tells leadership the tool knows the limits of what it read.
The scenarios people remembered were the ones about when not to alert. In safety, a tool's credibility is its usefulness.