Abstract topographic contour field in dark tones, with select elevation lines picked out in blue.
← Resources
article·

The Geofence Fallacy: Location Filters Aren't Mission Filters

A radius drawn on a map is not a relevance filter. Why geofence alerting fails moving teams in both directions, and how to run circle-based tools well.

By Gavin Quinn

The geofence fallacy is the assumption that a radius drawn around a location is a relevance filter: that everything inside the circle matters and everything outside it doesn't. Both halves are wrong, and every alerting product built on circles inherits both errors.

The point is not to argue against geofences, only against mistaking them for something they were never built to be.

What geofences get right

Start with the steelman, because geofences earned their place. They are better than nothing — a team with a circle around the venue knows more than a team watching nothing. They are trivially easy to set up (drop a pin, pick a radius, done), and in this line of work a tool the whole team can configure in thirty seconds has real value. And for the problem they were designed to solve, they are correct. Perimeter awareness around a fixed asset (a residence, a campus, a facility) is a static problem, and a static shape answers it. Something crossed into proximity of the thing I'm protecting; tell me. The geometry of the question and the geometry of the answer match.

The fallacy isn't using a geofence. The fallacy is pointing that static shape at a moving problem and calling the output mission-relevant. Geofence alerting limitations don't show up when you guard a building. They show up the moment the principal gets in the car.

The circle catches what doesn't matter

The first failure direction is false positives. Draw a 2km radius around an urban venue and you have subscribed to a district, not a mission. In a dense city, that circle pulls in every incident: the assault three neighborhoods away, the fire on a street you will never touch, the robbery at an hour when your team is somewhere else entirely. Most of it has no bearing on your movement.

The predictable result is alert fatigue, and fatigue ends the same way every time: the operator mutes the channel. That is the part worth sitting with. The cost of a noisy filter isn't the noise so much as the muting. A muted feed is indistinguishable from no feed, except that everyone believes coverage exists. The team that never set up alerting knows it's blind; the team that muted its geofence does not. I've written before about attention as the scarcest resource on a protective team — a filter that spends that resource on a district's ambient crime blotter is consuming the capacity you need for the signal that matters.

The circle misses what does

The second failure direction is false negatives. Missions are lines and windows, not points. A circle around each venue covers the venues — and nothing else. The route between them runs outside every circle you drew. The airport is 40km out. The hotel district where the team overnights is across town. The thing developing Tuesday that shapes your Friday movement is developing wherever it's developing, indifferent to your radii — the same collection gap that opens between the advance and execution.

And a geofence is time-blind in both directions. It fires on the protest that happens a week after you've left, because the circle doesn't know you left. It stays silent about the one permitted for your arrival day, because a permit application isn't an incident inside a radius yet. The circle has no concept of when you exist in that space, only that you drew a shape there once.

A geofence answers "did something happen near this point." A mission needs "does something affect this movement, during this window." Those are different questions, and the second cannot be assembled out of circles.

Geometry is the tell

Here's a test any advance lead can run in five minutes. Take a real movement, one you've actually worked, and draw what it is: points for the venues, lines for the routes, windows for the times, and a decision attached to each element. Primary or alternate route. This entrance or that one. Depart on schedule or hold. Now draw a circle over that sketch and look at how badly the shapes disagree. The circle covers ground the mission never touches and misses ground the mission depends on, and no radius fixes it — widen the circle and the false positives explode; tighten it and the route disappears entirely.

A circle is the geometry of a place. A mission has the geometry of a plan. When your filter's shape can't even trace your problem's shape, the filter was built for a different problem.

Distance is not relevance

Category-blindness compounds the geometry problem. Inside the circle, a geofence treats a homicide two blocks from the venue, road construction on your arrival street, and a transit strike identically: three alerts with the same weight and the same ping. Or it lets you filter by category lists ("crime," "weather," "civil unrest") that were defined by a product team, not by your plan, and don't map to the choices in front of you. The construction matters because it kills your primary approach. The homicide, two blocks off your axis at 0300, probably doesn't. The strike matters only if the principal's staff commutes by rail.

Relevance is one question: does this change a choice I have to make? No radius encodes that question, and no category taxonomy written in advance of your mission encodes it either. Distance is sometimes an input to relevance and never the definition.

What mission filtering looks like

One way we think about it: the filter should be built from the plan rather than the map. That means collection bounded by the plan's named places (venues, routes, choke points, the airport, the hotel), not a blob around one of them. Bounded by the movement window, so Tuesday's monitoring serves Friday's decision and stops when the mission ends. And bounded by the team's actual decision points, so what comes in gets read against the choices still open. This is the discipline laid out in what mission-scoped collection means, the companion definition to this argument. It is manual, craft-level work; nothing about it requires special tooling, just a plan specific enough to filter against.

It also requires a human pass. Someone reads what came in against the plan, every cycle, on a schedule, because no filter replaces judgment. Any tool worth using surfaces; the operator decides. A filter that promises to remove the reading step has stopped filtering and started guessing.

If a geofence tool is what you have

Most teams can't swap tools mid-contract, so run the circles deliberately:

  • Tight circles on true point-assets. The venue, the residence, the hotel — small radii, sized to the block, not the borough.
  • Separate circles on route choke points. Bridges, tunnels, the single viable freeway interchange. Several small circles beat one big blob, because each one maps to a decision.
  • Time-bound everything the tool allows. If it supports schedules, alerts exist only during the window. If it doesn't, turn circles on and off by hand as the mission moves.
  • Treat the feed as a cue, not an answer. An alert means "a human looks now and reads it against the plan," never "the tool decided this matters."

Imperfect tools run deliberately beat good tools run naively. The circle isn't the problem. Believing the circle is the mission — that's the fallacy.