Two alerts that are not the same thing
Corridor systems produce two families of notification, and treating them as one is the most common design mistake we see.
The first is operational: travel time, congestion state, queue length, patterns over a shift. It is addressed to members — a maintenance crew, a duty supervisor, a fleet operator, a public subscriber list — and it is useful precisely because it is routine.
The second is a BOLO — be-on-the-lookout. A law enforcement agency has asked to be told when a specific plate appears. It is addressed to a named party, it is not routine, and its value collapses if it is delayed.
Why quiet hours exist, and why they must not apply to everything
Notification fatigue is the failure mode that ends most alerting deployments. Not a missed event — a muted channel. Once a duty phone has buzzed forty times in a night for traffic that was merely heavy, the forty-first message is ignored, and it is the one that mattered.
The fix is to make the schedule a first-class setting rather than an afterthought:
- Alerting hours per day of week. Weekday peaks and weekend patterns are rarely the same, and a single on/off switch cannot express that.
- Quiet hours that hold non-critical notices and deliver one digest when the window ends. Nothing is discarded — it is deferred.
- Block-out windows that suppress entirely, for planned resurfacing or a closed plaza, so a known event does not generate a night of noise.
- Re-alert cool-down, so one long jam produces one conversation rather than forty messages.
And then the exception that makes the rest safe: a critical override. BOLO matches and wrong-way detections ignore quiet hours and block-outs by design. Because those two categories always break through, everything else can be scheduled honestly — which is what keeps members from muting the channel outright.
What a good BOLO record contains
A watchlist entry is only as useful as the context attached to it. A plate on its own tells an operator nothing about what to do next.
| Field | Why it changes the response |
|---|---|
| Category | Stolen, wanted, Amber Alert, parole, expired registration — a compliance flag and a felony warrant are not the same call. |
| Priority | Drives the channel. A high-priority record can escalate to a voice call; a routine one should not. |
| Match mode | Exact or partial. A partial record still matches when only some characters are known, and the operator must know which they are looking at. |
| Issuing party | The alert should reach the officer or agency that raised it — not a shared inbox nobody owns. |
| Handling note | What the operator should and should not do. "Log the sighting; do not initiate a stop from the plaza" prevents a great deal of trouble. |
Travel time is an alert too — just a patient one
Travel-time information is the most-used output of a corridor system and the least dramatic. Its job is to be accurate and timely enough to change a decision: whether to take the corridor at all, whether to hold a crew, whether to post a message on a sign.
Because it is routine, it is the right candidate for scheduling and digesting. A member who asked for corridor conditions between 06:00 and 09:00 should get them then, and a summary rather than a stream. The discipline of deciding what is routine is what earns the right to interrupt when something is not.
The path a match actually takes
For a watchlist hit, the useful measure is not detection accuracy in isolation but the whole path: read at the lane, matched against every active record, raised on the operator console, and routed to the party named on that record — with the plate, the reason, the reader, the lane and direction, the read confidence, and the frame attached.
Every one of those fields exists to answer a question the recipient will ask within the first ten seconds. A match that arrives without them generates a phone call instead of a decision, and the phone call is where the time goes.
Governing the list itself
A watchlist is a set of assertions about people, maintained by humans, and it decays. Entries are added during an incident and never removed. Someone leaves the agency and their records outlive them. A plate is reassigned to a new owner.
So the list needs the same governance as the data it matches against: every issue, edit and deletion logged against the person who made it; a stated review cycle; and retention rules that expire matches on a schedule rather than accumulating them indefinitely. An alert is only defensible if the record behind it is.