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 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
- Near-miss and incident records from jobs across the region, spanning several years of history.
- Outcome
- Confirmed intrusions surfaced from the general log; a build-ready scenario specification 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 serious hazards road crews face. 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 the incident records screened, only a few were confirmed intrusions. The rest were correctly excluded: rock chips, backing bumps, third-party claims within contract limits.
Confirmed intrusions by type, most to least common
- Closure violation
- General intrusion
- TMA breach
- Flagging breach
- Barrier impact
Most confirmed intrusions came from near-miss records, not incident reports. The data leadership looked at was the data with the least signal.
Severity was not evenly spread
A meaningful share of the confirmed intrusions were rated at the highest severity level, and most of the rest were one step below it: a vehicle or person had entered the protected area with crews present. These were not close calls in the abstract.
One definition, applied the same way every time
Built in Power Automate over the incident table. The last 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. Most were approved, a few were excluded for insufficient detail, and a handful were 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
Every record carries a confidence score. Low scores route to review rather than into the results.
Why the human step is not optional
The model did not decide. It returned a low confidence score, wrote out why the definition didn't cover the case, and set the row to Needs Review for a person to settle. A handful of 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.
A build-ready scenario specification
Clean classification became a specification the development partner could build and train against. They needed genuine work zone intrusions, not invented ones, and a set of 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.
Each scenario is marked must-have or nice-to-have and mapped to tiered alert levels: Warning, Threat, Intrusion.
Some scenarios exist to stay quiet
Part of the specification defines what must not trigger an intrusion alarm: utility strikes, equipment movement, plant hazards. A system that cries wolf gets ignored, and crew trust is what makes an alert useful.
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.