All posts

Operations

Judgment, Not Alarms

Two events, walked through twice — once as a single-signal system sees them, once with every available source joined. Fusion's value isn't that it sees more. It's that it concludes differently, and proportionately.

August 31, 20265 min readBy 9Squared
sensor fusion
verified response
graduated response
monitoring
incident review
Cover: Judgment, Not Alarms

The scarce resource in security is not sensors, and it is not manpower. It is judgment: deciding what an event means and what response it actually needs, within seconds.

The industry's dominant architecture doesn't produce judgment. It produces trips, and then asks a human with no context to supply the judgment by phone. This post walks two events through both versions — a single-signal system and one that joins every source available — because the difference is easier to see than to argue.

Both scenarios below are illustrative. The events are constructed; the sources, the joins, and the response ladder are how our system actually works.

Scenario one: the residential back door

9:47 p.m. A back door contact opens. That is the entire signal.

As a single-signal system sees it. A zone opened on a monitored premise after dark. The runbook is: call the primary keyholder, call the secondary, dispatch if neither answers. At 9:47 p.m. on a weeknight, neither answers about half the time. A patrol or police unit gets sent to look at a door.

With the sources joined:

Add the camera on that door. Nothing in frame in the ten seconds before or after the contact. Already the picture has changed — but "nothing in frame" is not by itself innocent, so the system doesn't stop here.

Add the weather feed. Sustained gusts of 40 mph at that location, and this door has tripped on wind three times in the past eighteen months, each time within an hour of a wind advisory.

Add the household's own context. Both phones associated with the premise are at home. The interior motion sensors have been quiet for forty minutes.

Conclusion: wind, at high confidence. Response: log it, notify the homeowner by text in the morning with the clip attached, no dispatch. If the homeowner disagrees, the event is one tap away from being reclassified — and that reclassification trains the site's thresholds.

Now change one detail. The camera shows a person at the door at 9:47, the phones are both twelve miles away, and there is no wind advisory. The same system that just declined to dispatch now escalates immediately, with a clip, a description, and a note that the premise is unoccupied — which is a materially better dispatch than "zone 4 opened," and it happens without a human having made a phone call first.

Why this matters more than it looks

Take a home with two door-open events a year: one weather, one real intrusion.

  • Single-signal: two dispatches, one of them wasted, and the real one arrives with no information — so it's handled, but badly. Genuine incidents correctly handled: effectively zero.
  • Fused: the real one is handled with evidence and context; the weather one costs a text message. Worst case, if the join is ambiguous, you waste one.

Going from zero to one on genuine incidents correctly handled is not an efficiency improvement. It's the difference between a system that works and one that doesn't.

Scenario two: the impossible badge swipe

9:12 p.m. A badge opens the server-room corridor. The badge belongs to a senior engineer. Access is authorized for that door, at that hour.

As a single-signal system sees it. Nothing. There is no event here. An authorized credential opened a door it is authorized to open. Even camera analytics on that corridor see an authorized badge and a person and correctly raise nothing.

With the sources joined:

Add the corporate directory and calendar. The engineer is on PTO this week.

Add the endpoint telemetry. Her laptop holds an active VPN session from a location 240 miles away, currently.

Add the camera. A person is in the corridor. It is not her.

Conclusion: a cloned or lent credential, in a sensitive area, right now.

Response — and this is the part that separates a good system from a loud one — is graduated. The credential is flagged and its access to the sensitive zone is suspended pending verification. The engineer gets a phone call, not an accusation. The corridor camera is routed to a live operator. Facilities is notified. Nobody's night is ruined by a siren, and the incident is contained in under a minute.

The structural point: no amount of camera intelligence finds this event, because the event does not exist in any single system. Each source independently passes. It exists only in the join.

The three tiers we join

Everything above comes from one of three tiers, and the ordering is deliberate — each tier is cheaper to add than the last is to improve.

Internal security systems. Cameras, access control, alarm panels, intrusion sensors, intercom. What the site's own equipment already knows.

Property and user context. Calendars, occupancy and phone presence, badge and directory data, work orders, lease and vendor schedules. This tier is where "is this person supposed to be here" gets answered, and it's the tier most monitoring operations ignore entirely.

External context. Weather, crime reports and local incident feeds, permits, utility and traffic events. Free, public, and the difference between "a door opened" and "a door opened during a wind advisory."

Every tier is data the customer already generates. None of it requires new hardware on the wall.

Response is a ladder, not a switch

The binary alarm forces a binary decision: dispatch or don't. Almost no real event deserves either.

A response ladder gives the system somewhere to put its intermediate confidence: log silently; notify the customer; ask the customer a question; route to a live operator; verify by a second channel; suspend a credential; dispatch a patrol; dispatch police. Confidence and severity together pick the rung, and every step up is available in seconds if the picture changes.

And every event, at every rung, gets an automated post-incident record: what fired, what was joined, what was concluded, what was done, and what a human changed. That record is how the operation gets better — it is also, on the day someone asks why a decision was made, the only acceptable answer.

Where this is weakest

More signals means more places to be wrong. A fused system that reaches a confident wrong conclusion is more dangerous than a dumb one that escalates everything, because people stop checking it. This is the risk we take most seriously, and it's why the ladder's lower rungs are cheap and reversible and why every conclusion carries its evidence.

Every added source is a privacy decision. Phone presence, calendars, and endpoint telemetry are not ours to take. They are opt-in, per source, per premise, and a system that can see them needs to be able to say who looked at what and when. A monitoring operation that cannot answer that question about its own staff should not be asking customers for this data.

Context degrades. A calendar that nobody maintains, a directory that lags terminations by a month, a phone that's out of battery — each of these makes a join quietly less reliable, and none of them announces itself. Sources need freshness monitoring, and a stale source should lower confidence rather than silently contributing to it.

The scenarios above are constructed. They're built from patterns we see, but they are illustrations, not case studies. The number to hold us to is not whether a storyboard is persuasive — it's dispatches avoided per genuine incident handled, measured on real sites over real months.

See SmartSentinel in action

Learn how 9Squared fuses every signal you already have into one continuously-updated security assessment.

Request a Demo