RouteFlow: a passive fingerprint for what a route actually is
The pattern I keep hitting in carrier work is the same one. The institution will not capture the knowledge that walks out the door at retirement. So the carriers who do the work capture it themselves, with whatever tools they can build, on whatever budget they have. RouteLog.wiki was the first attempt. RouteFlow is the second.
Scope
RouteFlow is a passive sensing system for mail carriers. Two Pixel 3 phones, one mounted in the vehicle and one worn on the body, capture kinetic and GPS data while a carrier runs their route. The data syncs to a server at home over Wi-Fi when the carrier returns. There it gets fingerprinted into recognizable patterns: this is what an active CBU stop looks like, this is the carrier walking back to a missed delivery, this is the morning meetup with a neighboring route. No cloud. No subscriptions. The source is public, the captured data never leaves the carrier's own house.
It is a sibling to RouteLog.wiki. RouteLog captures explicit route knowledge, the things a carrier writes down. RouteFlow captures implicit route knowledge, the things a carrier does without thinking.
Logic
The institutional knowledge that walks out the door with every retirement is mostly the implicit kind. A carrier who has run their route for eighteen years knows where the dog is loose without thinking, knows which CBU has the broken latch, knows the order to hit the apartment buildings to dodge afternoon school traffic. Some of this can be written down. Most of it is muscle memory and rhythm, too quick to type and too obvious to mention.
RouteLog asked carriers to write things down. That works for the things they remember to write. RouteFlow does not ask. The phones run quietly, the carrier runs the route the way they always run it, and the system learns the pattern. After a week of data, "this is your CBU" stops being subjective. After a year, training a new carrier becomes "here is the rhythm; ride along once and feel it."
The CBU fingerprint is a fusion of two signals: the vehicle stops moving, and the body produces step deltas. Either signal alone is too noisy. The intersection of the two, in a small enough time bucket, is a CBU. Cluster those across enough days and the route's CBU map exists in the database without anyone having tagged a single location.
Fragility
The honest list of what the first version cannot do.
The Pixel 3 is end-of-life hardware running on aging batteries. Body mode targets a ten-hour shift. Whether it actually delivers ten hours depends on the specific phone and how much its battery has degraded. There is a calibration step that runs before any sensor pipeline ever does, just to find out.
The trigger to start capture is the device losing the home Wi-Fi network. It is robust most of the time. It also has corner cases that have to be debounced individually: brief micro-drops, a neighbor's network with the same name, captive portals at gas stations.
The HMAC-signed sync between phone and server is the only auth. No token rotation, no mutual TLS. Two devices, one closed home network, one carrier. If that ever stops being true, the auth needs to grow up.
There is no map view in this public log. Ever. The carrier reviews their data on the home server only. What goes here is the engineering: the patterns, the design decisions, the tradeoffs, the lessons.
Learning
This post stays as the project's current statement of intent. When the truth changes, when something the architecture assumed does not hold up, or when a new requirement reframes the whole thing, the next post in this category covers what was learned and why.
The pattern that produced both RouteLog.wiki and RouteFlow is the same. Identify what the official tooling refuses to do. Build it without permission. Ship it to the carriers who actually run the route. The institution will not capture this knowledge. So the carriers who do the work capture it themselves.