Why does density favor dynamic dispatch specifically?

When travel times between properties are short, the cost of re-deciding the next stop is tiny while the value is high — the fleet can constantly rebalance toward whatever is closest and most urgent. On sparse routes the long drives dominate and there is less to gain from re-optimizing.

Does a swarm cause vehicles to overlap on the same block?

It is designed against that. Anti-steal logic keeps a vehicle from grabbing a property right next to a peer already working that block, while density-cohesion sweeps a dense cluster before the fleet leaves it — coverage without ping-ponging.

How many machines do we need for a dense cluster?

Fewer than a fixed route implies, because idle and overlap time shrink when every machine is always taking its highest-value next property. The honest way to size it is to simulate the cluster at different vehicle counts before the season.

All posts

Route Density Dynamic Dispatch

The coverage math on high-density residential routes

When properties are packed tight and travel times are short, the way you assign the next stop decides how many driveways hit their window. A look at the numbers behind dense coverage.

By The Snowmass Team April 17, 2025

When people talk about coverage in snow removal, they usually mean it as a yes-or-no: is the property covered? But on a high-density residential portfolio — hundreds of driveways and walks packed into a few HOA and townhome blocks — coverage is really a question of timing under constraint. You have more properties than machines, every property has a window, and the windows overlap. How you assign the next stop is what decides how many of those windows you actually hit. This post looks at the math behind that decision.

The constraint that defines dense coverage

Dense residential work has a specific shape: many properties, packed tightly, short drives between them, and SLA windows that all press in around the same part of the storm. Because the driveways are close, travel is cheap — but because there are so many windows closing near each other, the pressure is high. The binding constraint is not distance. It is your ability to keep every machine doing the most valuable thing available at every moment, so that the maximum number of windows get hit before they close.

On dense residential work the scarce resource is not travel — it is machine-time near a closing window. Coverage is won or lost on how well you spend it.

Why the assignment method dominates

In a sparse operation, once you have a sane route, better assignment barely helps — the drives dominate. In a dense one, assignment is nearly everything. Two ways of spending the same fleet on the same properties can produce very different coverage, because the difference between a machine idling or overlapping a peer versus taking a property about to breach its window is pure coverage, gained or lost, at almost no travel cost.

This is why continuous claiming pulls away here. Each machine always taking its highest-value next property means the fleet is constantly steering machine-time toward the windows that need it, rebalancing every few seconds as the picture changes. A fixed route locks in one spending pattern up front and cannot adjust as windows tighten unevenly across the storm.

The two failure modes it avoids

Dense coverage is lost two ways, and good swarm logic guards against both. The first is scatter — machines chasing "best" properties all over the map and wasting the short-travel advantage on constant repositioning. Density cohesion counters this by sweeping a dense block before leaving it. The second is redundancy — two machines working the same block while another waits. Anti-steal logic counters this by discouraging a machine from grabbing a driveway right next to a peer already there. Together they keep coverage both tight and non-overlapping.

Sizing the fleet for a cluster

The natural next question is how many machines a dense cluster actually needs. The answer is usually fewer than a fixed-route estimate suggests, because so much of a fixed route's machine-time is lost to idle and overlap that dynamic claiming reclaims. But "usually fewer" is not a number you should stake a capital decision on — the honest way to size it is to simulate the specific cluster at different vehicle counts and watch where the coverage curve stops improving. That is a real answer for your real properties, not a rule of thumb.

Key takeaways

Dense coverage is a timing problem under constraint — many overlapping windows, cheap travel, more properties than machines.
The scarce resource is machine-time near a closing window, so the assignment method dominates outcomes.
Continuous claiming steers machine-time toward tightening windows; good swarm logic avoids both scatter and redundancy.
Size a cluster by simulating it at different vehicle counts, not by a fixed-route rule of thumb.

Frequently asked questions

Why does density favor dynamic dispatch specifically?: When travel times between properties are short, the cost of re-deciding the next stop is tiny while the value is high — the fleet can constantly rebalance toward whatever is closest and most urgent. On sparse routes the long drives dominate and there is less to gain from re-optimizing.
Does a swarm cause vehicles to overlap on the same block?: It is designed against that. Anti-steal logic keeps a vehicle from grabbing a property right next to a peer already working that block, while density-cohesion sweeps a dense cluster before the fleet leaves it — coverage without ping-ponging.
How many machines do we need for a dense cluster?: Fewer than a fixed route implies, because idle and overlap time shrink when every machine is always taking its highest-value next property. The honest way to size it is to simulate the cluster at different vehicle counts before the season.