A modern road-condition program is four layers: capture (sensors on vehicles), inference (AI on the stream), review (engineering on the output), and audit (an immutable record of everything). Each layer has a different lifecycle. The audit layer is the one that outlives the others, and the one most often missed.
Most road-condition programs are described in terms of their visible output: a dashboard, a map, a score. That's the top of the iceberg. The useful way to think about a road-condition program is as a stack of four layers, each with different dynamics, different lifecycles and different failure modes. This piece walks through them, and explains why the fourth layer is the one that matters most in the long run.
Layer 1: capture
The capture layer is the one everyone sees. Sensors on vehicles (smartphone or specialised), capturing imagery, IMU telemetry and GPS. The engineering decisions here are about sampling rate, coverage strategy (which vehicles, which routes) and data integrity (is the phone mounted consistently, is the upload reliable).
The capture layer is also the shortest-lived of the four. Sensor hardware gets replaced every 2 to 3 years as phones improve. The specific app version changes every quarter. A useful test: if your capture layer is so tightly coupled to a specific hardware SKU that replacing the phone breaks the pipeline, the architecture is wrong. The data pipeline should survive hardware swaps.
Layer 2: inference
The inference layer is where the raw captured data becomes engineering-grade indices and detections. Computer-vision models produce PCI scores, detect potholes and cracks, identify assets. Telemetry pipelines produce IRI estimates, corrugation intensity, grade profiles. GPS and imagery combine to produce segment-level coordinate referencing.
The inference layer evolves every 6 to 12 months. New models ship. Detection classes get added (a new sign type, a new distress pattern). The accuracy envelope improves. A working program treats the inference layer as versioned: each detection is stamped with the model version that produced it, so a detection made in 2024 is traceable even after the 2026 model replaces the 2024 one.
Layer 3: review
The review layer is where engineers touch the system. The dashboard, the work-order integration, the filter queries, the export to the pavement-management system, the ward-level reports for councillors. This is where the data turns into decisions.
The review layer is shaped by whoever the operator is. A municipality runs it differently from a mining operation, which runs it differently from a toll-road concessionaire. The layer needs to be configurable rather than opinionated: the same underlying capture and inference layers should feed very different review experiences for different customer types.
Review is also where the system lives or dies on human factors. If engineers can't trust the data, they won't use it. Trust comes from three things: evidence-level traceability (every score drills down to the source frame), acceptable false-positive rates on the operator's specific network, and responsive feedback when operators mark detections as wrong.
Layer 4: audit
The audit layer is the one most programs skip and the one that matters most in the long run. It is the immutable record of everything that happened: every frame captured, every inference produced, every engineer review, every work order, every budget allocation decision, stored in a form that is:
- Independently verifiable. A stored record can be shown to be the record produced at that time, by that sensor, by that model version. Typically via cryptographic hashing on ingest.
- Vendor-independent. The audit trail survives a change in platform vendor. Data is exportable in open, documented formats. No proprietary schema lock-in.
- Long-tail. Retention measured in decades, not years. Road networks are 30-year assets; their condition record has to be legible in 2055.
- Tied to decisions. Every maintenance decision that consumed the data is traceable back to the specific evidence that informed it. This is the piece that defends engineering judgement in any subsequent dispute.
Why the audit layer matters
Consider the situations that actually test a road program:
A liability claim
Somebody hits a pothole, damages a car, sues. The defence is: we knew about it, here's when we detected it, here's when we scheduled the repair, here's the constraint that delayed it. Without an audit layer, that defence is "trust me." With an audit layer, the defence is a chain of timestamped, evidenced records.
A procurement review
The auditor asks why your budget went to roads A, B and C and not roads D, E and F. Without an audit layer, the answer is "engineering judgement." With an audit layer, the answer is "here is the condition trend on each, here are the deterioration curves, here is the cost-of-inaction model we applied."
A vendor change
You change road-AI platforms. The new vendor needs to understand the history of every segment. Without a proper audit layer, you lose 10 years of context. With one, the history migrates cleanly.
A political transition
The council changes. The new administration asks why their predecessors prioritised roads the way they did. Without an audit layer, the answer is politically vulnerable. With one, the previous engineering decisions defend themselves.
What to ask any vendor
Three questions that expose whether a vendor has thought about the audit layer:
- What happens to my historical data when I change vendor?
- Can I export every detection with its original evidence frame and model-version stamp?
- If a detection made in 2024 is challenged in 2029, how is the original evidence retrieved and verified?
Vendors with a serious audit layer have confident, specific answers. Vendors without one offer reassurance and deflection. The difference matters more than the dashboard prettiness, because the dashboard is Layer 3. You are buying Layer 4.