Skip to content
IRIS NEURALContact
Back to capabilities

What happens to an alert once it goes off?

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

Detecting is not deciding. A system that only detects leaves a list of alerts nobody ever closes, and at four in the morning there is one person watching it. Here every alert becomes an incident: an owner, a status, a procedure, the shift that answers for it and a closing time. If nobody picks it up, it climbs on its own until someone answers.

At a glance

What it can do

  • No alert goes missing

    Every trigger opens its own incident, with its time and its frame. Even when a hundred repeats fold into a single row, the counter stays exact.

  • Each type, its own deadline

    Seventeen types ship as standard, each with its own urgency and its own minutes. A fire does not wait as long as a forgotten bag, and the queue sorts itself by what expires first.

  • Guided procedures

    The incident arrives with its steps, in order. Some steps are marked critical, and some cannot be ticked off without writing down what was actually done.

  • Escalation that never goes quiet

    If nobody attends to it in time, the alert climbs a rung. When the rungs run out it goes to a last-resort destination: it never ends in silence.

  • Who is on call right now

    Rotas, rotations and stand-ins live inside the system. The alert wakes whoever is on duty now, not whoever was on a list six months ago.

  • Shift handover in writing

    The handover is logged: who hands over, who takes over, what is still open and whether the incoming operator confirmed it. Unfinished work reaches the next shift.

  • Twenty-seven filters

    A queue of two hundred unfiltered alerts is a queue people stop reading. Each operator saves their own view and shares it with the team.

  • A case file you can hand over

    One button packs the whole incident: report, timeline, attachments and images, each with its fingerprint. It ships with its own verifier, which works offline.

  • Inside the on-call rota

    Stacked layers, daily, weekly or custom rotation, and rules by day, time band, month and exception, even from sunrise to sunset. And if nobody covers a slot, that gets declared: a blank gap would silence the alert; a declared gap pushes it to the next rung.

  • Who the alert reaches

    The recipient can be a person, a group or the whole on-call shift: if it is the shift, the person is resolved at the moment of firing, never before. And a failed send does not burn a rung — the same one is retried, because an alert that never went out cannot count as delivered.

  • Twenty alerts, one incident

    Grouping ships switched off and is a per-person preference: it merges rows, and that should not happen unless someone asked for it. If the incident representing the group stops being pending, the group closes and whatever comes next starts a fresh one.

  • Closing leaves a record

    On closing, the actions-taken form is filled in, and what is answered stays as usable data, not loose text. The report can be pre-filled from the incident’s real timeline, but nothing is saved until a person reviews it, under their name and the time they did it.

The control room

Detecting is not deciding

At four in the morning there is one person in front of the screen. What they need is not more information: it is knowing what to do. So the incident does not 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 is stored with a name and a time, and it takes a separate permission to do it at all.

An alert nobody picks up cannot 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 does not solve anything yet. If a rota 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 is 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 switched 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 is the afterwards. 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 is not an org-chart question: it is a question the system has to answer on its own. The rota 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 is the shift, the person is resolved at the moment of firing, never before. And if the send fails, the clock does not advance and the same rung is retried, because an alert that never went out cannot 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 rota is never overwritten: each version is closed and kept.

Closing is not making a row disappear. On closing you fill in whatever actions-taken form the organisation 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 is saved until a person reviews it, and it keeps their name and the time. That is 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 cannot work something out, it writes that down instead of printing a zero: if the camera is not calibrated there is no speed, and a dash never means the value is nought.

The figures

Counted, not estimated

  • 27combinable filters in the operator queue
  • 17incident types out of the box, each with its deadline
  • 41separate permissions deciding who may do what
  • 489distinct actions recorded in the audit trail
  • 16retention policies out of the box, one per category
  • 7states an incident moves through, with every transition checked

Questions

What happens if nobody attends to an alert?

It climbs. Every alert enters a ladder with its own waiting times: if the first one expires and nobody has answered, the next rung is alerted, and so on upwards. Answering means taking it, validating it, closing it or commenting on it; that stops the climb, even if it does not solve the case. If a rota has been left with nobody on call, the alert jumps to the next rung instead of falling silent. And when rungs and repeats run out, a last-resort destination is alerted. It never ends in silence.

How do you stop the control room drowning in alerts?

Three things. Repeats from the same camera fold into a single row with a counter, without deleting any of them: the detail is still stored and the count always adds up. The queue filters by 27 combinable criteria, and each operator saves their own view and shares it with the team. And a panel measures how many alerts each person receives per hour and points at the camera and the rule producing them, so they can be tuned rather than switched off. On top of that, there is a record of who muted what.

Can you prove afterwards what was done?

Yes. Every incident keeps its whole timeline: who opened it, who looked at it, what changed, what was written and when it was closed. The log only accepts additions, is cryptographically chained and can be verified on demand; if anything had been touched, it names the exact entry where the chain breaks. The case file downloads as a signed package with the fingerprint of every file and a page that checks it offline, with nothing to install. And whatever existed before chaining was switched on is declared as not verifiable, rather than passed off as verified.

And what if it is the escalation itself that fails?

An escalation that fails silently is worse than no escalation at all, so it is measured and shown. A panel says whether it is running, running but with alerts not getting through, or stopped, and gives the reason in plain words: switched off, never run, the last pass errored, it has not run for so many minutes. It also flags what nobody looks at until it is too late: that there is no active channel to go out through, or how many people on the team have no way of receiving an alert. And you can see, over the last 24 hours, how many escalations ended up with no recipient and how many times the last resort had to be used. On top of that, a fresh install starts disarmed on purpose: it only simulates and writes down the plan, and someone has to arm it server by server. A deployment must not start calling people on its own.

What if two operators open the same incident at once?

They see each other. The record says, by name, who else is looking at it right now; and if you are alone, it says that too. Taking it means claiming ownership, and that gesture is stamped with its time: it is also what stops the escalation, even though it does not solve anything yet. States cannot jump from any one to any other: the server checks every change and rejects the ones that do not belong, saying which state it tried to go from and to, so two people cannot leave the same incident in two different places. And everything both of them did stays on the same timeline: who opened it, who looked at it, who changed it and what each of them wrote.

The real interface, step by step

You set the rule once. IRIS applies it every time.

You will see a summary of the interface, played step by step and hands-free. Each round starts with another case. The complete tool does not fit in a demo.

  1. It lands in the tray
  2. You open it
  3. You confirm or dismiss
IRIS NEURAL
30ES
IRISDirectoGrabacionesGISIncidencias3996SituaciónCasosLPRAutomatizacionesIRIS DATA
Ask a question or make a request…Send
IRIS · Infinity Neural

And the best part

No building work, no trenches, no new cabling:the cameras are already up and already looking.

What changes is what happens to the picture. It used to be stored and never seen; now it is understood while it happens, on the same equipment you bought years ago.

Tell us your problem and we will say whether IRIS understands it, or not yet.

We reply the same working day.