The Dates DOTs Publish Aren’t the Dates They Hit

You did the responsible thing. Before quoting the haul you checked the corridor, found the ramp closure scheduled to start August 3, and planned around it. Three weeks later the truck arrives and the ramp is open — the job was pushed to August 24. Nobody lied to you. The DOT revised its own estimate eleven days ago, published the revision, and your copy of the date was simply the one you took a snapshot of.

This is the failure mode that survives even after you solve the hard part. Getting forward-looking schedules into one queryable schema answers what is planned. It does not tell you how much that plan is worth — and a start date with no track record behind it is a number, not information.

A Date Field Is a Snapshot. You Need the Record.

Every planned-construction record we carry has an estimated_start_time and an estimated_end_time. Read them today and you get the agency’s current intent. Read them tomorrow and you may get a different answer, with nothing in the payload to tell you it changed, how far it moved, or whether this is the fourth time.

So we keep the change log. Every time a source republishes a project with a different projected start or end, we record the old value, the new value, and when we saw it. That log is a first-class, queryable dataset — not an internal audit trail — and it converts a static date into something with a history you can weigh.

Seven Weeks of Watching Dates Move

Here is what the log actually holds as of today, on live North American data — not an illustration.

Across the 2,410 active planned-construction projects we carry (Virginia 1,182, Delaware 762, New Jersey 247, West Virginia 163, North Carolina 46, and a handful across New Brunswick, Idaho, PEI and Nevada), we have recorded 3,859 date revisions since the log began filling in early June — 2,358 revisions to a projected start, 1,501 to a projected end. Those revisions land on 1,345 distinct projects, 281 of which are still on the board right now.

The single most useful thing in that pile is the direction. Of the 3,859 revisions, 3,831 moved a date later and 28 moved one earlier. Schedule drift is not noise scattered around a central estimate; it is a one-way ratchet. A published date is, in practice, a floor.

The size of the moves is where planning slack actually comes from:

The median revision moves a start five days; the average is 4.2. Strip out the sub-day nudges and the typical real move is 5.6 days. The largest single revision we have on record pushed a Virginia ramp closure on VA-150N from July 2 to July 23 — 21 days in one edit. And 280 separate projects have taken at least one revision larger than a week.

None of that is knowable from a date field. All of it is knowable from the log.

Querying It

The change log is one endpoint. Filter it by what changed, on what kind of feature, over what window:

GET /api/v1/analytics/feature-history?
  feature_type=future_construction&
  change_type=estimated_start_time_change&
  limit=2

{
  "data": [
    {
      "id": 173250844,
      "feature_id": "VA-fcon-WZNO4652574-07212026-6",
      "source": "VA",
      "feature_type": "future_construction",
      "change_type": "estimated_start_time_change",
      "changed_field": "estimated_start_time",
      "old_value": "2026-07-23T15:00:00Z",
      "new_value": "2026-07-23T17:00:00Z",
      "recorded_at": "2026-07-23T16:11:25.751016Z"
    },
    {
      "id": 173250845,
      "feature_id": "VA-fcon-WZNW4643148-06252026-1",
      "source": "VA",
      "feature_type": "future_construction",
      "change_type": "estimated_start_time_change",
      "changed_field": "estimated_start_time",
      "old_value": "2026-07-23T12:00:00Z",
      "new_value": "2026-07-24T12:00:00Z",
      "recorded_at": "2026-07-23T16:11:25.751016Z"
    }
  ],
  "total": 2358,
  "limit": 2,
  "offset": 0,
  "has_more": true
}

Swap change_type for estimated_end_time_change to watch completion dates instead, add feature_id to pull the full history of one project you care about, or bound it with from and to and poll for what moved since your last run. The same endpoint carries created, deactivated and reactivated entries, so a project quietly dropped from an agency’s feed shows up as an event too, rather than just vanishing from your result set.

Entries are newest-first. The change log is analytics-tier (Pro and up); the future_construction records themselves are on every plan, free trial included.

Two Things Look Identical and Mean Opposite Things

This is the part worth internalizing before you wire an alert, because the naive version of this monitor will page you every night.

The most-revised project in our data is VA-fcon-WZNO4585395-12252025-137 — work on the I-66E Express Lanes between mile markers 43 and 65. Between July 3 and July 22 its dates were revised 38 times. That sounds like a project in freefall. It isn’t. Read the log and the pattern is unmistakable:

estimated_start_time  2026-07-02T13:00Z → 2026-07-03T13:00Z
estimated_start_time  2026-07-03T13:00Z → 2026-07-04T13:00Z
estimated_start_time  2026-07-04T13:00Z → 2026-07-05T13:00Z
estimated_start_time  2026-07-05T13:00Z → 2026-07-06T13:00Z
                              ... every night ...

Same eight-hour window, rolled forward by exactly one day, every day. That is not a job slipping — it is a recurring daily closure published as a single record whose window always points at the next occurrence. (The one break in the rhythm is instructive too: on July 11 the record went inactive, came back July 12, and jumped three days instead of one. It skipped the weekend.)

Now contrast a genuine slip. Eight Virginia projects across Rappahannock and Albemarle counties each took three revisions between July 9 and July 23 that added up to a net 22 days — distinct edits, days apart, each one pushing a real start date further out. Same endpoint, same change_type, completely different operational meaning.

The rule that separates them is simple and worth building into whatever you wire on top: a stream of uniform one-day moves is a schedule shape; a few irregular multi-day moves is a schedule failing. The 404 exactly-one-day revisions in the table above are mostly the former. The 320 revisions over a week are the ones that should reach a human.

What This Is Worth Downstream

• Pad the quote with evidence, not superstition. If the corridor’s projects historically move five days later and one in five moves more than a week, that is a number you can put in a bid instead of a gut feeling.
• Watch the jobs on your lanes. Poll feature-history with from set to your last check and get told when a date on a corridor you run has moved — before the truck finds out.
• Re-check permits that were issued against a moved date. An oversize permit written around an August closure window is worth revalidating when the closure walks into September.
• Rank your sources honestly. A project revised once and executed is a different planning risk from one revised six times, and the log is the only place that difference exists.
• Filter the noise out of your own alerts. Rolling nightly windows are the majority of raw revisions. Knowing that up front is the difference between a useful monitor and one everybody mutes.

The Honest Limits

Four of them, and they matter more than the headline numbers.

Today this signal is Virginia. All 3,859 revisions in the window come from VDOT’s feed. Delaware, New Jersey, West Virginia, North Carolina and the rest published zero date revisions over the same seven weeks — not because their projects run on time, but because those feeds don’t republish a revised date on the same record; a changed plan tends to arrive as a new record instead. We would rather say that plainly than average nine jurisdictions together and imply a continental drift statistic we cannot support. As more sources start revising in place, the same query picks them up with no change on your side.

The window is seven weeks, not seven years. The change log’s oldest entry is May 20, 2026, and projected-start revisions begin June 5. These are real observations over a short baseline — enough to characterize how dates move, not enough to claim a seasonal or multi-year pattern. It deepens every day.

We record what the agency published, not why. A revision tells you the date moved and when we saw it move. Whether that was weather, utilities, a contractor, or a clerical fix is not in any feed we consume, and we won’t invent a reason field to make the data look richer than it is.

An estimate remains an estimate. The point of the log is not to replace the DOT’s forecast with ours. It is to tell you how much that forecast has moved so far, which is the only honest input to how much slack you should carry.

The Same Mechanism, Beyond Construction

Schedule drift isn’t unique to roadwork — it is a property of anything published with an expected end. The same log carries 17,843 revisions to the projected end of weather alerts across 8,772 alerts, which is what a warning being extended hour by hour looks like when you record it instead of overwriting it. Any time-bounded feature type we carry — alerts, special events, seasonal restrictions — leaves the same trail, reachable with the same feature_type filter.

That is the general shape of the thing: not a new dataset, but the refusal to throw away the previous value. Most of the road-data problems we write about in the five road-data problems every NA fleet team hits come down to a feed telling you only about now. Keeping the record is what makes a plan auditable.

Try It

• API docs — /analytics/feature-history, plus the future_construction surface and its scheduled-window filters
• Planned construction, end to end — how the projects themselves are queried
• Free API key — no credit card, 14-day trial