From alert to resolution: with an owner, a procedure and a deadline

At four in the morning there is one person in front of the screen. What they need isn’t more information: it’s knowing what to do. So the incident doesn’t arrive alone, it arrives with its script: the steps, in order, with the critical ones marked. A step can demand that you write what was done before it counts as done. And an incident can be closed with steps left unvalidated, but the reason has to be written, it’s stored with a name and a time, and it takes a separate permission to do it at all.

An alert nobody picks up can’t just sit there. Each policy is a ladder: who gets it first, how long we wait, who gets it next. Answering stops the climb — taking it, validating it, commenting on it — even if it doesn’t solve anything yet. If a schedule has been left empty, the alert jumps to the next rung instead of falling silent; once every rung is spent, it goes to the last-resort destination. And before a policy goes live it can be simulated without sending a thing: it tells you who would be alerted and, above all, which alerts would have nobody behind them.

Then there’s the question almost no video system asks itself: how much noise is this producing, and can one person keep up with it? IRIS measures it in alerts per operator per hour and compares that against the thresholds published by alarm-management practice. It shows which camera and which rule are flooding the room, so they can be tuned instead of turned off blind. Repeats can be folded into one row with a counter, but folding never deletes: the detail stays and the count adds up. And it records who muted what, because an inconvenient alert must not vanish without a trace.

And then there’s the afterward. Every incident keeps its full timeline: who saw it, who changed it, what they wrote and the exact time they closed it. The log only accepts additions and is chained, so a later edit shows up. One button packs the case file for an insurer, a court or an auditor, with the fingerprint of every file and a page that checks it offline. All of this travels over a single port, 443, and it works without reaching the internet: not one image and not one record leaves for a third party.

Who answers at four in the morning on a Sunday isn’t an org-chart question: it’s a question the system has to answer on its own. The schedule lives inside, with its layers, its rotations and its rules by day, time band and month; and a stand-in overrides everything else for as long as it lasts. When the alert goes out, the recipient can be a person, a group or the whole shift: if it’s the shift, the person is resolved at the moment of firing, never before. And if the send fails, the clock doesn’t advance and the same rung is retried, because an alert that never went out can’t burn a rung in silence. Six months later you can ask again who was on call that Tuesday and get the right answer, because the schedule is never overwritten: each version is closed and kept.

Closing isn’t making a row disappear. On closing you fill in whatever actions-taken form the organization has defined, and the answers stay as data: they can be grouped by type, by camera, by zone, by shift and by operator. The report can be pre-filled from the real timeline — what was expected, what happened and why — but nothing’s saved until a person reviews it, and it keeps their name and the time. That’s where the two numbers for the monthly meeting come from: how long it takes to respond and how long to resolve. And where the system can’t work something out, it writes that down instead of printing a zero: if the camera isn’t calibrated there is no speed, and a dash never means the value is zero.