Methodology & accuracy
Bridget has no servers of its own and is not an official live feed. It watches the live drive time across each drawbridge's approach and compares it to the drive time on an empty road — what Apple Maps predicts for 3 a.m. A big slowdown means the bridge is backing up traffic — whether from an opening or ordinary congestion. Bridget's math runs on your iPhone, and the reading is an inference from traffic — there is no sensor on the bridge.
It is honest about two limits: it reacts to congestion as it forms (so it helps you avoid a jam, it doesn't predict a raise), and it's only confident on the bridges where the evidence backs it up — for most bridges that evidence is the city's official records; for two whose records went dark, it's the statistical fingerprint of their own opening history (how that was validated: see the September 2026 update at the end of this page).
We collected CI every ~3 minutes for all seven Seattle bridges over a week (~23,000 readings) and cross-checked every reading against the City of Seattle's official drawbridge opening records (SDOT Open Data, dataset gm8h-9449) — 248 real openings in the window. We then measured, per bridge: how reliably CI catches a real opening (recall), how often it fires on normal traffic (false alarms), separability (ROC-AUC), and — combining our measurements with the city's long-term opening frequency — the calibrated probability that a flagged bridge is genuinely delayed.
| Bridge | Confidence | Notes |
|---|---|---|
| Ballard | High | Catches ~97% of openings (July study); calm baseline; the clearest signal. Alerts all day. Thresholds retuned September 2026 — see the update below. |
| Montlake | Medium | Catches openings reliably, but its normal rush-hour traffic also spikes — so it alerts off-peak only, when a spike is meaningful. |
| Fremont | Low (board-only) | Opens most often, but short openings let traffic divert, so CI can't cleanly separate them. Shown on the board; no proactive alerts. |
| South Park | Promising, not yet validated | Excellent separation but too few openings in the window to confirm. Board-only for now. |
| 1st Ave S | Board-only | Opens rarely; congestion there is usually port/rail, not the bridge. |
| University, Spokane St | Board-only (promoted September 2026 — see the update below) | Absent from the city feed during the study (no openings recorded), so we had no ground truth to validate them at the time. |
Added 2026-09-13; ships with v1.1. The sections above describe the original July study and are kept as written, with inline pointers where this update changes the current picture.
In late August 2026 we ran a second, longer study: 14 days, 70,511 readings — two complete weekly cycles. It was pre-registered (the pass/fail rules were written down and frozen before the data existed) and it answered the question the table above left open: what to do about University and Spokane St, whose openings the city's public record stopped capturing (their bridges still open; the record's sensor path went quiet).
How we calibrated bridges with no usable city record — distribution matching. You can't check individual alarms against a record that isn't there. But a bridge's openings leave a statistical fingerprint that doesn't depend on any single event: how often traffic spikes relative to that bridge's own normal, how those spikes spread across the hours of the week (openings are banned during commute rush, which carves a distinctive weekly shape), and how long they last. We chose each bridge's alert threshold so that the pattern of what it flags matches the pattern of that bridge's own opening history — no event-by-event pairing needed. Before trusting the method, we tested it blind on the two bridges where we DO have a usable record: we hid Ballard's and Fremont's records, asked the method to find their thresholds from the traffic pattern alone, and compared its answers to the answers computed with the records. It landed inside the accepted range on both (Fremont: 2.00 vs a supervised range of 1.80–2.10; Ballard: 2.50, where the record-based score is within 0.003 of its best). That test — pass or fail — was defined before we looked.
Result: University and Spokane St now alert off-peak only (the same cautious tier as Montlake), with thresholds recovered by this method. They are deliberately capped there: a bridge validated by pattern-matching alone never gets the top tier.
The second study also retuned every existing threshold. With roughly twice the opening coverage of the July study, all seven bridges' numbers were recomputed from scratch. The visible effect: Ballard's alert thresholds rose (its off-peak bar most of all), so Ballard alerts somewhat less often than before — the larger dataset showed its earlier off-peak bar was set too low, flagging some ordinary heavy traffic. Fewer, better alerts is the intended trade. Montlake's tier and alert threshold are unchanged (its board levels moved with everything else's): the second study re-tested its behavior directly (a pass/fail rule fixed before the data existed) and it passed with more than four-fold margin (3.7% measured, against a pre-set 15.6% limit).
A caveat we measured, not assumed — the city record is a lower bound. By independently sampling the city's own live status page for 11 days and comparing it to the published record, we measured how much the record undercounts: it captured ~98% of the openings we observed at Ballard, ~88% at Fremont, ~84% at Montlake — and ~35% at South Park and ~7% at 1st Ave S. Every “false alarm” rate we compute against the record is therefore an upper bound (some “false” alarms are real openings the record missed), and the two newly validated bridges' calibration rests on the pattern of their history, not on its completeness.
We never use a live city or government feed in the app, never receive your data (the only data that leaves your iPhone goes to Apple: Maps search, routes and traffic, and App Store tips), and never describe Bridget as receiving official bridge status. The city records are used only offline, to tune the thresholds — the shipping app has no servers.