RoadLife turns an ordinary municipal fleet into a rolling survey instrument — roof-mounted vibration sensors and cameras score pavement condition on every trip, and a survival model predicts which cracks become potholes after the next rain, weighted by traffic volume and ward equity, not just who complained loudest.
JRA and metro backlog reports describe the same cycle every wet season: hairline cracks let water into the sub-base, the sub-base fails, and what was a R200 crack-seal job becomes a R15,000 pothole repair — usually discovered only after a resident's complaint or a damaged vehicle claim. Reactive patching keeps crews permanently behind the deterioration curve instead of ahead of it.
A retrofit sensor pod on existing municipal bakkies captures accelerometer signatures and forward-facing pavement imagery on every normal trip — no dedicated survey vehicle required.
On-device models classify crack type and severity from the camera feed in real time, cross-referenced against the vibration signature for confidence.
A survival-analysis model estimates time-to-failure for each flagged section, factoring in rainfall forecasts, traffic load and pavement age — not just current condition.
The final worklist balances deterioration urgency, traffic volume and ward-level equity, so maintenance spend doesn't just chase the wards that complain most.
Vibration and camera data streams from every equipped vehicle during normal daily routes, no special survey trips needed.
Computer vision and accelerometer signatures are classified locally into crack type and severity, filtering noise before upload.
A survival model estimates time-to-pothole for each section, weighted by rainfall, traffic and pavement history.
Sections are ranked into a maintenance worklist that balances urgency against ward-level equity for fair, transparent scheduling.
The live dashboard mirrors the road schematic above but rebuilt continuously from fleet telemetry: a translucent priority heatmap over the road network, colour-coded by deterioration urgency, with the survey bakkie's live position and its most recent flagged sections shown as it drives its normal route.
RoadLife has not yet been deployed on a live municipal fleet — this platform is a proposal pending a fleet pilot agreement. The plan below sets out a phased rollout to seven fleet clusters, each requiring dedicated capacity from Claude, Azure OpenAI and Google Cloud as sensor volume and worklist complexity grow. It is presented here as a roadmap, not a current-state claim.
| Cluster | Phase | Scope | Status |
|---|---|---|---|
| JRA Region D (Johannesburg) | Phase 1 | Founding pilot fleet, model calibration against existing backlog data | Proposed — seeking agreement |
| Ekurhuleni fleet cluster | Phase 1 | Second calibration site, cross-metro validation of the survival model | Planned |
| City of Tshwane cluster | Phase 2 | First metro-scale retrofit once Phase 1 model performance is validated | Planned |
| eThekwini fleet cluster | Phase 2 | Coastal-climate validation — higher rainfall, different pavement failure profile | Planned |
| Cape Town fleet cluster | Phase 2 | Winter-rainfall climate validation | Planned |
| Buffalo City cluster | Phase 3 | Secondary-metro scale test of the multi-metro dashboard | Planned |
| Mangaung cluster | Phase 3 | Inland climate and lower-density network validation | Planned |
Cluster names above indicate target municipalities for outreach, not signed agreements. Each cluster requires a data-sharing agreement with the relevant roads department before any sensor deployment begins.
RoadLife's entire value proposition — turning raw fleet vibration and camera data into a fair, defensible maintenance worklist — depends on three AI providers doing distinct, non-substitutable jobs. Scaling from a single-fleet pilot to the seven-cluster rollout multiplies every one of these workloads simultaneously, which is why sustained capacity from all three is a precondition for the project succeeding, not an optional enhancement.
Claude is the layer that turns classified sensor data into decisions a municipality can act on and defend. Claude Haiku 4.5 performs cheap, fast triage across the fleet-wide raw sensor stream — screening thousands of vibration events and camera frames per day so only meaningful deterioration signals are escalated. Claude Sonnet 5 drives day-to-day dashboard summaries, drafts work orders for maintenance crews, and answers planner questions about why a given section was ranked where it was. Claude Opus 4.8 handles multi-season budget and crew scheduling — reasoning across a full maintenance season's worth of rainfall patterns, backlog history and crew capacity to produce a defensible annual plan. Claude Fable 5 is reserved for the hardest reasoning task in the system: balancing raw deterioration urgency against ward-level equity in the final worklist, so that spend doesn't simply chase the wards that complain loudest, while still producing a ranking a councillor can explain to residents. Without this layer, RoadLife is just a sensor network with no way to turn data into a fair, explainable schedule.
Every flagged pavement section needs a visual record a maintenance planner, auditor or councillor can actually look at — not just a coordinate and a risk score. Azure OpenAI's GPT-image models generate annotated before/after and evidence imagery for confirmed sections, overlaying the detected crack boundary and severity classification directly on the captured frame. This matters at the volume a multi-cluster fleet produces: a single metro-scale fleet can flag hundreds of sections a week, and manually annotating that volume of imagery is not viable with a human graphic-design workflow. As the rollout reaches seven clusters, this generation workload scales roughly linearly with fleet size — which is precisely why assured throughput from Azure OpenAI, not best-effort access, is a scaling requirement for Phase 2 and Phase 3.
GCP carries the computational backbone of the forecasting pipeline. Google Vertex AI trains and hosts the survival-analysis models that estimate time-to-failure for every flagged pavement section — this is genuinely heavy, recurring compute, since the model needs periodic retraining as new fleet data, rainfall patterns and repair outcomes accumulate across every cluster. Google Vision provides secondary cloud-side confirmation for edge-flagged imagery, catching classification errors that a lower-powered on-vehicle model might miss before a section reaches the worklist. Google Maps plots the full road network and live fleet position for both the internal planning dashboard and any public-facing status view a partner municipality wants to offer residents. None of these three functions are things the other two providers are built to do — GCP is the infrastructure layer the other two depend on to have anything to reason about or illustrate in the first place.
Handles the deep, multi-factor reasoning needed to balance deterioration urgency against ward-level equity in the final worklist.
Runs longer-horizon budget and crew scheduling across a full maintenance season, factoring in seasonal rainfall patterns.
Drives day-to-day dashboard summaries and work-order drafting for maintenance planners.
Cheaply screens the high-volume raw sensor stream across the fleet so only meaningful deterioration signals reach the heavier models.
Generates annotated before/after and evidence imagery for confirmed sections at the pace fleet-scale capture demands.
Trains and hosts the deterioration and time-to-failure models feeding the fleet.
Secondary cloud-side confirmation for edge-flagged pavement imagery, improving classification accuracy.
Plots the full road network and live fleet position for planning and public-facing status views.
| Phase | Scope | Estimate (ZAR) |
|---|---|---|
| Fleet pilot | Sensor pods across a small municipal fleet, model calibration | R3.2m – R5.1m |
| City-wide | Full fleet retrofit and network coverage across one metro | R40m – R75m |
| Analytics platform | Dashboard, model hosting, integrations | R1.1m – R2.0m p.a. |
Prioritisation is driven by measured deterioration and traffic data, not by which wards report issues most often through formal channels.
The equity weighting applied to every section is visible on the dashboard, so councillors and residents can see how the ranking was reached.
Camera capture is limited to road surface, not number plates or faces, and is processed under a data-sharing agreement with the municipality as responsible party.
Active-active or active-passive across AWS and GCP regions with CDN edge caching, so the dashboard stays reachable during exactly the moment it's needed most.
Circuit breakers isolate lagging or offline fleet units rather than blanking the dashboard; the last-known state is always shown with a clear staleness indicator.
All calls to Claude, Azure OpenAI and Vertex AI carry retry, timeout and fallback logic, with automated health checks documented against AWS and GCP Well-Architected review criteria.
"Every road tells you it's failing. We just listen sooner."
We work directly with roads and stormwater departments to scope a fleet pilot, agree data-sharing terms, and calibrate the deterioration model against your own backlog history before any city-wide commitment.
Tell us about your fleet and roads department — a liaison will follow up within 3 working days.