Work Zone Data Exchange (WZDx) Explained for Traffic Control Companies

Somewhere between the plan you drew and the driver approaching your taper, a new participant showed up: the phone on the dashboard, and increasingly the vehicle itself. It is routing around your closure, or failing to, based on data it got from somewhere.

For a growing number of agencies, that somewhere is a Work Zone Data Exchange feed — a machine-readable file describing where work zones are, which lanes they affect, and when. This is an explainer for traffic control companies: what WZDx is, who is actually publishing it, what is in a feed, and the practical question underneath it all — where does the data come from, and is any of it yours?

The short version

The Work Zone Data Exchange is a specification that lets infrastructure owners and operators publish harmonised work zone data for third-party use. FHWA describes the intent plainly: the specification "enables infrastructure owners and operators (IOOs) to make harmonized work zone data available for third party use," and states that "The intent is to make travel on public roads safer and more efficient through ubiquitous access to data on work zone activity." The project aims specifically to get work zone data into vehicles, to help automated driving systems and human drivers navigate more safely.

It is a data format and a publishing convention, not a device, a product, or a regulation that applies to contractors. The specification and its tooling are maintained publicly on the USDOT WZDx repository, and agencies that publish feeds register them with USDOT.

Why anyone built this

The problem WZDx addresses is that work zones are the least predictable thing on the road network and the least well described in the data vehicles use.

Permanent geometry is mapped. Signals are mapped. Speed limits are mapped. A lane closure that appears at 9 p.m. and is gone by 5 a.m. is, to a navigation system, either invisible or a permanent-looking mystery. The consequences show up in the crash data: FHWA's tabulation of 2022 FARS data records 891 work zone fatalities from 821 fatal crashes, with rear-end crashes at 21 percent and speeding a factor in 34 percent. Rear-end crashes in advance of a closure are, in large part, a problem of drivers not knowing soon enough.

The Work Zone Safety Information Clearinghouse's national table records 850 work zone fatalities in 763 fatal crashes in 2024, including 282 fatalities in truck-involved crashes. Heavy vehicles need the most advance notice of a closure and are the least able to react late.

Contractors experience the same problem from inside. In the 2026 AGC and HCSS highway work zone survey, 60 percent of contractors reported at least one crash involving a moving vehicle in their work zones over the past year, and more than half said crashes had delayed projects.

"Work zone safety must continue to be a focus for our industry," said Steve McGough, president and chief executive officer of HCSS, in the survey release. "Reducing deaths and serious injuries in work zones will require better awareness, stronger enforcement, and a shared commitment to safer driving behavior."

Better awareness, in 2026, includes the awareness a driver's routing app has.

Who is publishing feeds today

This is where a lot of vendor marketing gets ahead of reality, so it is worth looking at the actual register.

USDOT maintains the Work Zone Data Exchange Feed Registry as an open dataset. At the time of writing it contained 43 registered feeds, 42 of them marked active, from 42 distinct issuing organisations, with state or region entries covering roughly three dozen states plus the National Park Service. Forty-one of the feeds are published as GeoJSON. Thirteen require an API key; the rest are open.

The registry also shows how uneven adoption is in practice. Feed versions listed range from 3.1 through 4.2 — 14 feeds on 4.1, 12 on 4.2, 11 recorded simply as 4 — with four feeds on the newer Connected Work Zone standard.

The federal push behind this started with money: FHWA notes that USDOT awarded $2,372,254 on January 15, 2021 for WZDx Demonstration Grants funding 13 projects in 13 states.

Two honest conclusions follow. First, this is real: several dozen agencies publish live feeds, and consumers can and do read them. Second, it is early: there is no universal coverage, no single version everyone is on, and no requirement that a contractor participate.

What is in a feed

The specification is organised around feeds of typed objects. The two that matter most:

The work zone feed carries road events — high-level information about events on roadways related to work zones. In practice, that means: the geometry of the affected road segment, which lanes are affected and how, direction of travel, start and end times (planned and, where known, actual), whether workers are present, and identifiers linking back to the agency's own records.

The device feed carries information about field devices deployed in work zones — location, status and live data. This is where instrumented arrow boards, portable changeable message signs, and smart work zone systems can appear. Smart work zones and queue warning systems covers what those systems do on the ground.

FHWA notes that the Work Zone Data Working Group's version 4.0, released in December 2021, "reorganizes the feed to make room for smart work zone device data and non-work zone road restrictions as well as permitting road owners to share more nuanced information about worker presence in work zones." That worker-presence nuance matters: the difference between "a closure exists here" and "there are people on foot in that closure right now" is the difference between a routing hint and a safety warning.

A road restriction feed exists for restrictions that are not work zones — height, weight, width limits and similar.

Where the data comes from — the part contractors should care about

A feed is only as good as the record behind it, and the record behind it is usually the agency's permit, closure or lane-restriction system.

Follow the chain on a typical permitted lane closure:

1. A contractor requests a closure for specific dates, times and lanes.
2. The agency approves it, and the approval becomes a record in its system.
3. The agency's feed publishes that record as a road event.
4. Navigation apps and fleets consume the feed and warn drivers.

At which point the accuracy of what drivers are told is a function of the accuracy of what was requested and reported. Three failure modes are entirely within a contractor's control:

The closure does not happen. Weather cancels the night, and nobody tells the agency. The feed says a lane is closed; the lane is open. Drivers who reroute for nothing learn to ignore the warnings — and the next one is real.

The closure runs long. The permit said until 5 a.m.; the work finished at 7. For two hours, the data was wrong in the more dangerous direction.

The lanes are different from the permit. The plan closed the right lane; conditions moved it to the centre. Nobody updates the record.

None of those are new problems — they have always affected permits, restriction windows and agency relationships. What WZDx changes is the audience. A stale permit record used to be a paperwork discrepancy. In a published feed, it is a wrong instruction delivered to thousands of drivers in real time.

This is the practical argument for treating your own closure data as a deliverable. Multi-jurisdiction permit tracking and lane closure permits: how the process works cover the permit side; the operational half is having actual start, change and removal times recorded on the job instead of reconstructed later. Setting up and removing a work zone safely covers capturing those times as part of the setup routine.

Latency is the quality problem

A feed has two quality dimensions and the industry conversation usually only covers one.

Correctness — is the closure described accurately: the right lanes, the right limits, the right times — is the dimension everyone discusses, and it is largely a function of the permit record.

Latency — how quickly the feed reflects what is true right now — is the harder one and the one that determines whether a driver benefits. A closure that went in at 9 p.m. and appears in a feed at 6 a.m. was useless to everyone who drove it. A closure removed at 4 a.m. but still published at 8 a.m. is actively misleading, and repeated often enough it teaches consumers to discount the source.

That is why the actual-time fields matter more than they look. A planned start and end come from a permit. An actual start and end can only come from the field — from someone recording when the setup was complete and when the road reopened. Any agency that wants a low-latency feed will eventually need that from its contractors, because there is nowhere else to get it.

It is also why a phone-based field record beats a paper ticket for this purpose, independent of any feed: the paper version's timestamps are written at the end of a shift, from memory, and rounded to the nearest half hour.

The Connected Work Zone standard

The registry shows a handful of feeds published against a newer Connected Work Zone (CWZ) standard rather than a WZDx version number — four of the 43 at the time of writing, from state DOTs and one private organisation.

Two takeaways for a contractor. First, this space is still consolidating: a specification that has moved through versions 3.1 to 4.2 and now sits alongside a differently named standard is not finished. Second, none of that churn changes what you are asked to produce. The underlying facts — which lanes, where, from when to when, workers present or not — are stable no matter which schema an agency publishes them in. Build the record; let the agency map it.

What it does not mean

A few reasonable-sounding conclusions that are not supported:

It is not a compliance obligation for contractors. The publishers are agencies. No national rule requires a traffic control company to publish a feed. Agencies receiving federal-aid funds operate under the Work Zone Safety and Mobility rule at 23 CFR 630 Subpart J, which drives their data and process obligations, not yours — though what an agency owes can flow into what it asks you for in a contract.

It does not replace your traffic control. A feed is advance information. It is not a sign, a taper, a barrier or a flagger, and it does not change anything in Part 6 of the MUTCD, currently carrying Revision 1, effective March 5, 2026. The devices on the road remain the controlling communication with the driver.

It does not mean your devices are being tracked. The device feed can carry device data; whether anything of yours appears in one depends on an agency program and instrumented equipment. Most traffic control fleets are not instrumented for telemetry today, and nothing obliges them to be.

It is not a product you buy. It is an open specification. Vendors may implement it; the specification itself is public on GitHub.

What it could mean, over time

Three developments are worth watching, because each would change a contractor's work rather than just an agency's.

Contract clauses that require timely closure reporting. If an agency's feed quality depends on contractor reporting, it is a short step to putting reporting timeliness in the contract — the way daily ticket and inspection requirements already are. Companies whose closure records are made up at the end of the week will feel that first.

Device data as a deliverable. Agencies running smart work zone programs already require data from queue warning and portable message systems. Extending that to arrow boards or channelizing device telemetry is technically possible and already anticipated by the device feed.

Worker presence as a safety signal. The ability to say "workers are present now" is the most operationally interesting field in the specification, because it maps onto something a crew knows precisely and nobody else does. If that becomes a live input to in-vehicle warnings, a GPS time clock showing crews on site stops being only a payroll record.

None of this is guaranteed, and the timelines are agency timelines. The point is that the direction of travel is toward your operational records becoming other people's inputs.

What to actually do about it now

Nothing here requires buying anything. Five steps, in order of value.

1. Ask each agency you work for whether it publishes a feed, and what feeds it from. The answer tells you whether your permit and closure reporting is now public-facing. The registry linked above is a fast way to check whether the state DOT is listed.

2. Record actual times, not planned times. When the setup was completed, when the closure actually took effect, when lanes changed, when the road reopened. If your daily ticket already carries a GPS-stamped timeline, you are most of the way there. Preventing daily ticket disputes covers what that record should contain.

3. Close the loop on cancellations. A documented process for telling the agency when a permitted closure did not happen, or ended early, is cheap and immediately useful — it protects your standing with the agency regardless of any feed.

4. Keep lane-level detail. "Lane closure on Route 9" is not enough for a feed and is increasingly not enough for an agency. Which lane, which direction, between which points.

5. Do not instrument your fleet on spec. Device telemetry is a real cost with a real payback in some programs and none in others. Wait for an agency program or contract that pays for it, rather than buying ahead of the requirement. Renting vs buying traffic control equipment covers that class of decision.

The underlying point

WZDx is one symptom of something broader: work zone information is becoming machine-consumed. For decades the audience for your operational records was an agency inspector, a project manager and occasionally an attorney — all of whom could interpret a messy record. The new audience is software, which cannot.

The companies best positioned for that are not the ones with the most technology. They are the ones whose ordinary daily records — what was closed, which lanes, from when to when, by whom — are captured accurately at the time and in a structured form.

That is what Traffic OS was built to produce: GPS-stamped, signed daily tickets tied to the job and the permit, a GPS time clock recording when crews were actually on site, and device records showing what was deployed where. Flat monthly pricing — $499, $949 or $1,499 as of September 2026, with no per-user charge — is on the pricing page, the features page covers what is in each tier, and a walkthrough will show it against your own closures.

Whatever a state's data program does next, the input is the same: an accurate record of what you actually closed and when you actually opened it.

The standing caveat

WZDx participation, feed content, contract reporting requirements and smart work zone device programs vary by agency and by contract, and the registry contents cited here were current at the time of writing. This is a general explanation; confirm what your agencies require, and what they publish, with each authority having jurisdiction.