← All articles

A Short History of Computer-Aided Dispatch in Seattle

Published May 9, 2026 · 10 minute read

The data on the Seattle Breaking live map is generated by a Computer-Aided Dispatch (CAD) system — software that helps emergency dispatchers route calls to available units in real time. CAD seems like an unremarkable piece of plumbing today, but the path from paper run-cards to the CAD systems that Seattle Fire and the city's 911 center use now spans decades and involves a long series of technology and procurement decisions that shaped which units arrive at your door today. This article is a brief tour of that history.

The pre-CAD era: paper, magnetic boards, and grease pencils

Through the 1960s and into the early 1970s, Seattle Fire and Seattle Police both operated dispatch centers that ran on paper. A 911 call (or, before 911 service arrived, a call to a seven-digit emergency number) was answered by a call-taker who scribbled the address and complaint onto a run-card and handed it physically to a dispatcher. The dispatcher kept a mental or paper-based map of which units were in service and which were on calls, and decided who to send. The work demanded extraordinary memory and routing intuition from senior dispatchers, who often had decades of experience and knew the city block by block.

Tracking the status of units was done on a magnetic status board — a metal panel with magnetic strips for each unit, labeled with each unit's call sign and color-coded by status. Available units were in one column. Dispatched units were moved into the column for their call. On-scene units were moved again. Status updates happened by hand, in real time, by dispatchers who never sat down during their shifts.

This system worked surprisingly well. It also occasionally broke spectacularly. Misplaced run-cards. Forgotten move-ups. Units sent to addresses across town from where they were needed. The pressure for automation was visible by the late 1960s, but the technology wasn't ready.

The 1970s: mainframe-era CAD

The first generation of computer-aided dispatch, in Seattle as elsewhere, belonged to the mainframe era: central computers accessed by dispatchers through CRT terminals. Systems of that generation maintained a database of streets and addresses, tracked unit status, generated incident numbers, and produced printed dispatch tickets. They generally did not do automatic recommendation of which units to send — that was still a human decision — but it removed the paper handling and the magnetic status board.

Police dispatch ran on its own, separately chosen and configured system. Keeping the two separate reflects real differences in how the two agencies work, and it had consequences that last into the present: fire and police dispatch in Seattle still run on separate CAD systems.

The 1980s and 1990s: AVL, mobile data, and routing engines

The two innovations that distinguish modern CAD from 1970s CAD are automatic vehicle location (AVL) and routing engines. AVL — the ability to know in real time where every unit physically is, via GPS or its predecessors — arrived in fire apparatus and police vehicles in stages through the 1980s and 1990s. Early systems used commercial radio triangulation; GPS-based AVL became practical by the late 1990s and standard by the early 2000s.

Once dispatch knew where units actually were, the routing engine could replace the dispatcher's intuition about who was closest with an actual computed answer. Modern CAD recommends a response plan and a specific set of units, and the dispatcher accepts or modifies that recommendation. The dispatcher's role shifted from "who do I send" to "the system recommends X, do I have any reason to override that." For a typical call, the answer is no, and the routing recommendation is what gets dispatched.

Mobile data terminals — screens in the front of the apparatus that receive dispatch information directly — arrived in fire apparatus and patrol cars in the following decades. Before MDTs, dispatch was voice-only over radio. After MDTs, the unit got a printed-or-screen ticket with the address, the call type, the building access details, and any prior-call history at that location. This shifted some workload off the radio (which is a scarce resource) and produced richer dispatch records as a side effect.

Why fire and police CAD stayed separate

Unifying fire and police CAD onto a single platform has obvious appeal — shared dispatch data, better mutual-aid coordination, lower licensing costs, a single training pipeline for dispatchers. The execution is harder. Fire and police dispatch workflows are different at a fundamental level (fire calls are about apparatus and stations, police calls are about districts and individual officers), and CAD products tend to be stronger on one side or the other.

In Seattle, the two dispatch operations have stayed on separate systems. Calls that need both agencies are passed between the two centers, but the systems remain separate products with separate interfaces, separate databases, and separate update cycles. That is also why the City publishes fire and police dispatch as two different datasets.

The 2010s and 2020s: regionalization and PSERN

The defining infrastructural project of the 2010s for Puget Sound public safety was the Puget Sound Emergency Radio Network (PSERN), a regional voter-approved replacement of the aging public-safety radio infrastructure across King County. Approved by King County voters in 2015, PSERN brought Seattle, Bellevue, King County Sheriff, and dozens of smaller agencies onto a single P25 trunked digital radio system; it came into service in stages, and Seattle's transition took place from March to May 2023.

PSERN matters for CAD because radio infrastructure and dispatch software are tightly coupled. A unified radio system makes cross-agency dispatch much cleaner — a Bellevue engine responding to a Seattle call is on the same radio network as Seattle's own units, with no patch or interoperability gateway required. Mutual-aid responses, automatic-aid agreements, and major-incident command structures all became more efficient as PSERN came online.

CAD software itself has changed over the same period. The current generation runs on commodity servers rather than mainframes, includes richer GIS integration, works alongside newer 911 capabilities such as text-to-911, and can feed data export pipelines. The export pipeline is what produces the Seattle Real Time Fire 911 dataset and the SPD Call Data dataset that this site uses.

The 2020s: open data and encryption

Two trends define the current decade. One is the maturing of the open-data publication pipeline. The Seattle Open Data portal, launched around 2010, has continuously expanded the public-safety datasets it publishes. Today it includes near-real-time fire dispatch data, daily-updated police call data, historical archives, and supporting reference datasets such as fire station locations. Civic tech projects — including this site — depend on those publications.

The other trend is encryption. As discussed in our scanner-listening article, SPD and Seattle Fire both encrypted their tactical radio channels in 2026, while keeping their dispatch channels open. The encryption decisions were specifically about radio audio, not CAD data — the open-data exports continued — but they took much of the on-scene radio traffic away from scanner listeners, a longstanding source of independent verification. The public can still hear where units are being sent, but much of what is said once they arrive is no longer audible.

What this means for the live feed

Three concrete consequences for what you see on Seattle Breaking:

The data we surface today reflects decades of incremental infrastructure decisions. The history is mostly invisible to a reader looking at a map of dispatch pins, but it shapes what is on that map and what is not.

← All articles