What alert triage is for.
Triage is deciding what to look at first. On a quiet night it barely matters: one alert arrives, the guard looks at it. It matters when three cameras go off at once, a patrol is calling in on the radio and a client is on the phone. In that minute, the order of the queue decides whether the person climbing the fence gets seen before or after the delivery driver at the front gate.
Good triage does three things. It puts the most urgent event on top. It never hides an event just because software thinks it is harmless. And it lets the guard, who knows the site, change the order.
A four-level model that works on a monitoring desk.
Most desks do well with a small number of levels. More than five and guards stop distinguishing between them. Fewer than three and everything is “urgent.” This four-level model separates urgency from uncertainty, which is the part most systems get wrong.
| Level | What it means | Typical examples | Expected handling |
|---|---|---|---|
| Critical | Clearly visible immediate danger | A person forcing a door, a fight, someone on a roof edge | Review now; follow emergency post orders |
| High | Activity that merits attention in this site’s context | A person in a closed yard after hours, a vehicle at a gate at 3 a.m. | Review promptly; decide on talk-down, patrol or client call |
| Unassessed | Activity detected, not yet assessed | A new person or vehicle detection waiting for review | Treat as open; never as harmless |
| Low | Reviewed and judged routine by a guard | A known cleaner, a resident at the mailbox | Close after review or leave for the record |
Why “Unassessed” is its own level.
The most common design mistake is folding unknown activity into Low. If an alert has not been looked at yet, by the AI or the guard, it is not low priority; it is unknown. Keeping it in its own level means a new detection is never buried beneath routine items, and a model that returns “nothing notable” does not quietly demote it.
Why Low is a guard decision.
Assigning Low automatically is how real events get dismissed. Reserve it for cards a person has reviewed. That keeps the lowest level trustworthy.
Ordering inside each level.
Within a level, oldest first is the right default. It prevents a burst of new alerts from pushing an older unreviewed event down the list forever. Closed cards drop to the bottom, visible for the record but out of the way.
Guard overrides.
The guard knows things no model does: the contractor on site this week, the client’s instruction about the side gate, what the patrol just radioed in. Priority overrides are how that knowledge gets into the queue.
- Any level, either direction. A guard can raise an alert to Critical or drop it to Low, with an optional reason.
- Overrides stick. An AI result about frames captured before the guard’s decision should not overwrite it. Otherwise guards learn their input does not count.
- New evidence can still escalate. If something genuinely new happens on that camera, priority can rise again. A lowered card is not a muted camera.
- Every change is recorded. Who changed it, when and why. That matters at shift handoff and in incident reports.
Escalation rules.
Escalation is what moves an alert up, and what happens once it is up. Write it down alongside your post orders for camera monitoring.
- Automatic escalation only goes up. Software may raise priority when it sees urgent activity. It should never lower priority or close a card on its own.
- Higher priority reopens attention. If an acknowledged alert is escalated, it should come back to the top of the guard’s attention, not stay marked as seen.
- Cooldowns never block urgency. After a guard closes an event, routine repeats can wait briefly, but urgent activity always gets through.
- Response steps follow the level. Map each level to actions: Critical to the emergency call tree, High to a talk-down or patrol, and so on. Guards should not have to improvise under pressure.
- Nothing closes itself. A quiet sample, a camera going offline or a model error should never resolve an open incident.
Priority labels from AI are triage suggestions. The guard’s decision is the one that counts, and the queue should be built so it always does.
Where Semaphor fits.
Semaphor implements this model in its guard inbox. New activity from local person and vehicle detection appears immediately as Unassessed. A vision-language model then reviews the frames and suggests a level: an urgent response maps to Critical, a review response to High. An AI “none” answer does not automatically downgrade or resolve the card. Low is assigned only by a guard.
With alert prioritization, badges show whether a level came from the AI or a guard, and why. Guard overrides survive restarts, and an AI result about older frames cannot undo them. Escalation reopens attention, and new urgent activity bypasses the cooldown that follows a guard’s close. Every card keeps the original evidence beside the assessment through the evidence and audit trail.
Want to see it on a busy queue? Book a live demo on your own camera screens, or start a pilot on your busiest station.
Triage questions.
How many priority levels should security alerts have?
Three to five. A common, workable design is Critical, High, Unassessed and Low, which separates urgency from alerts nobody has assessed yet.
Should AI be allowed to close low-priority alerts?
No. Automatic closing is where missed events hide. AI can suggest a level; a guard reviews and closes.
What is alert escalation in video monitoring?
It is the process that raises an alert’s priority when new evidence appears, and the response steps tied to each level, from a talk-down to calling police.
What happens if a guard disagrees with the AI?
The guard overrides the priority with an optional reason. In Semaphor, that decision stands unless genuinely newer evidence raises it again.