What is network-level pavement management?

If you've sat through a budget meeting where someone asks "how do we decide which roads get resurfaced this year," you've already bumped into the network-level versus project-level question, even if nobody used those words.

Network-level vs project-level: two different jobs

A pavement management system, at its core, answers two very different questions, and most agencies run both without always separating them cleanly.

Project-level work is what happens once a road is already on the list. An engineer walks or drives the corridor, digs into cores or FWD data, and figures out the right fix: mill-and-fill, full-depth reclamation, a chip seal, whatever the distress pattern and traffic loading call for. It's detailed, it's segment-specific, and it assumes you already know this road needs attention.

Network-level pavement management is the step before that. It's how you decide which roads make the list in the first place, out of every mile the agency owns. Instead of engineering detail on one corridor, you're looking at condition across the whole network, usually scored into a handful of classes, so you can rank segments against each other and build a program that spends the resurfacing budget where it does the most good.

The distinction matters because the data you need is different. Project-level design wants deflection testing, core samples, subgrade information. Network-level prioritization wants consistent condition scoring across every mile, collected the same way, so you're ranking County Road 9 against State Route 40 on the same scale instead of guessing which crew's rating was harsher.

Why most agencies run network-level management on incomplete data

Most network-level programs run on whatever got surveyed that year, a partial slice of the network rather than the whole thing. Windshield surveys are real work: a crew, a truck, a rating sheet, miles of road, and a limited number of weeks before the data's due. Most agencies can't afford to send a crew down every lane-mile every year, so they sample, or they rotate through districts on a multi-year cycle, or they lean on complaints and the squeaky-wheel list to fill the gaps.

None of that is wrong exactly. It's just thin. If a third of your network hasn't been rated since two winters ago, your network-level condition index is really a network-level estimate, and the ranked list coming out the other end is only as good as the sampling behind it. A corridor that's deteriorating fast but wasn't in this year's rotation doesn't show up until someone calls it in or a windshield crew happens to pass it.

The basics of a pavement management system don't change this problem; they just formalize it. PCI, PASER, or whatever condition index your agency uses still needs condition data entered against every segment before the prioritization math means anything. Garbage in, garbage ranked.

What a full-network picture actually changes

This is the part network-level management is supposed to solve, and the part that's hardest to do with field crews alone: a condition reading on every segment, collected the same way, on the same schedule, so the ranked list reflects the whole network instead of whichever third got driven this cycle.

That's the gap Road Surface Condition is built around. It reads VHR satellite or aerial imagery across the full network once a year and classifies where cracking, ravelling, and patching are concentrated, segment by segment, so the network map and the ranked priority list going into budget season are built from a consistent annual pass instead of a partial survey.

For an engineer building the resurfacing program, that's what "network-level" should mean: a dataset wide enough that the ranking reflects every segment the agency owns, rated the same way, on the same schedule.

If you're tired of defending a priority list built on gaps in the survey, it might be worth seeing what a full-network annual pass looks like for your roads.