Home Nsights Could Decision Models Fix Alert Fatigue in Perimeter Security?

By Ricardo Assaad October 7, 2026 14 min. read

Could Decision Models Fix Alert Fatigue in Perimeter Security?

AI & Security Perimeter SecurityAI Video AnalyticsComputer Vision

An open logbook and a two-way radio under a desk lamp in a guardhouse at night, with a closed gate and a floodlit fence line in the window.

A fence-line camera flags a person at 3 a.m. The operator has cleared two hundred alerts tonight, and every one was nothing. This one gets the same two seconds as the rest.

That moment is where a lot of perimeter security succeeds or fails, and a sharper camera doesn’t change it. In September a new kind of AI model arrived that is built for this sort of snap judgment. Nobody has shown that it works for security. This piece sets out the argument on both sides, and the questions I can’t answer yet.

False alarms are older than the cameras

False alarms were swamping security long before anyone put AI on a camera. A U.S. Justice Department guide on false burglar alarms, first published in 2007 and updated in 2011, reports that between 94 and 98 percent of alarm calls were false. Those calls made up 10 to 25 percent of all calls to police. In 2002 alone, U.S. police answered about 36 million alarm activations at an estimated cost of $1.8 billion.

Hospitals have the same problem and gave it a name. The Joint Commission’s 2013 alert on medical device alarms cited estimates that 85 to 99 percent of alarm signals need no clinical intervention. It called the result alarm fatigue, and it counted 98 reported alarm-related events over three and a half years, 80 of them fatal.

The pattern is the same in both fields. When nearly every alert is nothing, people learn to treat every alert as nothing, and the real one arrives looking like all the others.

Those figures are old and come from neighboring fields. I have not found an independent, published false-alert rate for AI video analytics on perimeters. Most of the numbers in circulation come from vendors selling the fix, and that missing baseline is the first open question in this piece.

Why better detection hasn’t ended it

Two things keep the alert count high even as detectors improve.

The first is arithmetic. Picture a site that logs 10,000 motion events a week, and one of them is a real intrusion. Give that site a detector that is right 99% of the time in both directions. It still raises about 100 false alerts for the one real one, so roughly 99 in every 100 alerts are noise. Those numbers are an illustration, not a measurement, but rare events do this to any detector, however good.

The second is that the detector answers a narrower question than the operator’s. It can say “person, north fence, 3:12 a.m.” It can’t say whether that person is the night guard on his usual round, a contractor who stayed late, or someone who just cut the fence. That depends on things outside the frame: the shift roster, the access log, the contractor schedule, whether gate 2 was left open.

Today the gap between detecting and deciding is filled by fixed rules and by the operator’s attention. Rules can’t anticipate every exception, and attention wears down over a shift.

What a decision model is

On September 15, a startup called TypeSafe AI opened early access to Jev, a model that reads text the way a chatbot does and cannot write a word. You hand it a block of context and a set of typed questions. It returns a yes/no probability, a score on a scale you define, or a pick from options you list, each with a probability attached.

TypeSafe’s launch post says it answers in 70 to 500 milliseconds and charges $0.042 per million input tokens, with output free. It also says the probabilities are calibrated, meaning that when the model says 80%, it should be right about 80% of the time. No paper or model weights back that claim yet.

Current as of October 7, 2026: Jev is at version 1.13. It takes text only, runs only on TypeSafe’s hosted service, and has no published paper or weights. TypeSafe says later versions will fix some of the weaknesses described below.

Jev can’t see. It takes text only, so in a security system it would sit after the detector and read a description of each event. Something like this:

Event: person, north fence zone, 03:12, walking along the fence line for 40 seconds. No badge-in during the last hour. Gate 2 closed. Contractor window ended at 18:00.
Question 1: Is this person likely to be authorized? (yes/no)
Question 2: How urgent is this, from 0 to 5?
Question 3: Who should get it: the guard desk, the supervisor, or the log?

TypeSafe calls these System One models. Commentators, Simon Willison among them, prefer “decision models”, and the idea has older relatives. Classifiers and rerankers have made this kind of call for years. What’s new is asking arbitrary questions in plain language with no training step.

The case that it helps

It aims at the right gap. The context an operator is missing mostly exists as text already: rosters, access logs, contractor schedules, site rules. A model that reads text and returns a judgment fits the hole between the detector and the person.

Probabilities let you rank instead of filter. A rule either fires or it doesn’t. A probability lets you sort the queue so the alert most likely to matter sits on top, and nothing has to be hidden. The 3 a.m. operator checks the top of a list instead of clearing all of it.

The price makes it possible to judge every event. A site sending 10,000 events a day, at roughly 1,000 tokens each, would spend about 42 cents a day at TypeSafe’s list price. That is my arithmetic on their published rate, with assumed volumes. At that cost you don’t have to sample.

Site rules could be written in plain language. Every site has its own exceptions. A safety manager could write “nobody on the loading dock roof without a second person” and have it applied the same day, without waiting for a vendor to code it.

The case that it doesn’t

It may be aimed at the wrong errors. If most false alerts come from perception (a shadow, a deer, headlights sweeping a fence at night), a text model downstream can’t help. It sees only what the detector told it, so a mislabeled event gets judged as labeled.

Security events are made of numbers. TypeSafe’s own documentation says the current version struggles with numbers, dates and double negatives. Timestamps, dwell times, counts and distances are most of what an event record contains.

A wrong call costs far more in one direction. Ranking a real intrusion at the bottom of the queue is a miss, and nobody finds out until later. A triage model that is wrong one time in twenty may suit support tickets and still be unacceptable on a fence line. It also always answers: if none of the options you listed fits, it picks one anyway.

It gives a number and no reason. After an incident, “the model scored it 0.12” won’t satisfy an investigator or an insurer.

In his write-up of Jev, Simon Willison had the model answer “Good city?” for each Bay Area city, and it put Cupertino on top and East Palo Alto at the bottom. He used it to warn that a bare score can hide bias nobody sees, and concluded that testing matters even more for a model like this than for ordinary large language model (LLM) projects. The security version of that risk is a score that quietly depends on how a person was described.

It can be talked into an answer. One review of TypeSafe’s stated limitations, from Respan, a company that sells a competing classifier, says the model doesn’t treat its input as hostile by default, and that injected text can move the result. Most software meets that risk now and then. A security system has an adversary by design, and any text an outsider can influence, such as a visitor log entry, is a possible lever.

It is closed, remote and three weeks old. Jev is a hosted service from one vendor. Many sites can’t send event data off the premises, and every site needs alerts to keep working when the link drops. The same review notes that model updates can shift the scores a threshold was tuned on. Open-source alternatives appeared within days, though early reports put most of them behind on quality.

What it would have to beat

A decision model has competition, most of it older and some of it already in the field.

Approach	Reads	Where it’s strong	Where it’s weak
Fixed rules (zones, schedules, dwell thresholds)	Event fields	Predictable and explainable, with no running cost	Brittle. Someone has to write each exception for each site
Classifier trained on a site’s own alert history	Event fields	Accurate once trained, and runs on site	Needs labeled history, which a new site doesn’t have
Vision-language model reviewing the clip	Pixels	Can catch what the detector described wrongly	Slower and costlier per event
General-purpose LLM reading the event	Text	Works through several steps and explains itself	Seconds per call, costly at volume, shaky confidence scores
Decision model	Text	Fast and cheap, with a probability on every answer	No reasons, weak on numbers, untested in this field

The vision-language row deserves attention. At an industry conference in June, an integrator described perimeter systems at high-security sites, including U.S. government facilities, that combine signal analytics, computer vision and vision-language models. Its session abstract promised a dramatic cut in alarms, with no baseline or measurement period behind it, and I can’t check it. If results like that hold, the strongest rival is a model that looks at the footage a second time.

The comparison I’d most like to see is the least glamorous one: a decision model against a well-kept rules engine plus a small classifier trained on the site’s own history.

What a fair test would look like

Any site with a labeled alert history can test this, much as it would test a detector’s accuracy on its own cameras, and the test is small.

Collect a few hundred logged events, each with an operator’s verdict: real, benign or unclear.
Build the baseline first. Write the rules you would actually deploy and record how they sort the same events.
Describe each event as text, ask the model the triage questions, and rank the events by its probabilities.
Count how many alerts an operator must open, working down each ranking, to reach every real event. Note whether any real event lands near the bottom.
Check calibration. Of the events the model scored at 90%, about nine in ten should have been right.
Try to break it. Change timestamps and counts, and plant instructions in the free-text fields.

A model that wins step 4 and survives step 6 has earned a pilot. One that only ties the rules adds cost and risk for nothing. I haven’t run this test yet.

Questions I can’t answer yet

How many false alerts are perception errors, and how many are context errors? If a site’s noise is mostly shadows and animals, no text model will touch it. I don’t know the split, and I doubt any two sites share one.
Who is accountable when triage is wrong? If a ranking layer puts a real intrusion last and it gets missed, the fault could sit with the integrator, the software vendor, the model provider or the site. I don’t know whether today’s contracts settle that.
Does a ranked queue help operators, or teach them to skip? Sorting should focus attention on the top of the list. It might also give people permission to ignore the bottom half, where a missed intrusion would be hiding.
Does calibration survive a new domain? A probability that is honest on support tickets may be less honest on fence-line events the model never saw in training.
Should a safety manager write detection policy in plain English? It removes a bottleneck. It also removes the engineer who would have asked what the rule does at shift change.
Would an insurer or an auditor accept a probability as a record? A rule can be read back after an incident. A score can only be reported.
Does cheaper judgment mean fewer alerts, or more? TypeSafe named its model after William Stanley Jevons, the economist who saw that more efficient steam engines raised the demand for coal. Cheap decisions could tempt sites to add cameras and rules until the queue is as long as it was.

Where I land for now

I build video analytics at Nsightify, so I have a stake in this gap, and you should weigh my view with that in mind.

My working guess is that a decision model could earn a place as a ranking layer for alerts that turn on context. I expect it to do nothing for perception errors, and I wouldn’t yet let one hide an alert from a person. All three are guesses until someone runs the test.

I’m more confident about where the remaining work is. Detection has improved faster than the judgment that follows it, and the 3 a.m. operator is still making that judgment alone.

If you run a site with a labeled alert history and want to see how the test comes out, I’d like to compare notes. Reach me through the contact form.

Frequently asked questions

What is alert fatigue?

Alert fatigue, which hospitals call alarm fatigue, is what happens when nearly every alert turns out to be nothing: people learn to treat every alert as nothing, and the real one arrives looking like all the others. The Joint Commission’s 2013 alert on medical device alarms cited estimates that 85 to 99 percent of alarm signals need no clinical intervention. A U.S. Justice Department guide reports that 94 to 98 percent of burglar alarm calls were false.

What is a decision model in AI?

A decision model reads text and returns a judgment instead of writing anything back: a yes/no probability, a score on a scale you define, or a pick from options you list, each with a probability attached. TypeSafe AI released one, Jev, in early access on September 15, 2026, and calls it a System One model. Classifiers and rerankers have made this kind of call for years. What’s new is asking arbitrary questions in plain language with no training step.

Why do accurate detectors still produce mostly false alerts?

Because real events are rare. Picture a site that logs 10,000 motion events a week, one of them a real intrusion, watched by a detector that is right 99% of the time in both directions. It still raises about 100 false alerts for the one real one, so roughly 99 in every 100 alerts are noise. The numbers are an illustration, not a measurement, but rare events do this to any detector.

Can a decision model reduce false alarms from perimeter cameras?

Only the ones that turn on context. A decision model reads a text description of each event, so it can weigh a shift roster, an access log or a contractor schedule, but it cannot see the footage. A false alert caused by a shadow, an animal or headlights gets judged exactly as the detector labeled it. Nobody has yet shown that decision models work for security alerts.

How would a site test a decision model on its own alerts?

Start with a few hundred logged events that operators have already marked real, benign or unclear. Write the rules you would actually deploy and record how they sort the same events. Then describe each event as text, rank the events by the model’s probabilities, and count how many alerts an operator must open to reach every real one. Check calibration, then try to break it by changing timestamps and planting instructions in free-text fields.