The situation
A fiber cut is one of the few failures in a network that is both expensive and almost entirely physical. Someone digs in the wrong place, and the result is an outage, a truck roll, an SLA exposure and a day of firefighting. Across this operator's roughly 70,000 km pan-India network, the operations team knew cuts were not evenly distributed — some stretches were obviously worse than others — but "obviously worse" was institutional memory, not something you could staff or budget against. There was no data-driven way to say, this month, which stretches to watch.
Everything about the response was reactive. The question we were asked was whether the history could be made predictive.
How it works
Divide the route
The network is split into comparable squares on a map.
Score every square
Each is rated on what runs ahead of a cut — above all, nearby civil work picking up.
Flag a zone, not a point
The exact dig spot is unknowable, so the model marks the stretch around it.
Hand it to the field
A colour-coded map, refreshed weekly, that ops plan crews against.
Why this was harder than it looksThe technical detail
The modelling difficulty here is not the algorithm. It is deciding what a single observation is, and what a prediction is allowed to claim.
First: what counts as one observation
A fiber cut is a rare event distributed along a continuous line. Treat the network as the unit and every route looks equally average. Go too fine-grained and most cells contain no incidents at all, so there is nothing to learn from. We tested grid sizes from 50×50 metres up to 600×600 metres and found 300×300 metres gave the best trade-off between precision and recall for this network — coarse enough to accumulate real evidence, fine enough to still point at somewhere a crew can be sent. That trade-off isn't universal: it depends on how dense and how deep the fiber geometry is in a given region, so we re-run the same sweep rather than assume one grid size travels everywhere.
Second: risk is not one number
Civil and construction activity near the route turned out to be the strongest single signal — specifically, how fast that activity was changing, not just how much of it there was. But the factors behind a cut don't collapse cleanly into one number without losing the reason a given square is risky, which the ops team needs in order to decide what to actually do about it.
Third: the location is genuinely ambiguous — and this is the one that moved the result
An underground cut's exact location is never knowable in advance — at best you can bound where the next dig is likely to land. Early versions of the model scored individual grid squares as if a single point could carry that prediction, and recall sat around 50%: half of actual cuts fell outside what we'd flagged. The fix wasn't a better algorithm. It was admitting the location is genuinely ambiguous and having the model say so — predicting a region at risk rather than a single square. That one change took recall from 50% to 92%, with precision at 75%.
Get the unit of analysis wrong and no model recovers it. Get it right and a fairly simple model is enough.
What we built
A grid decomposition of the route
Sized per-region by sweeping from 50m to 600m and picking the trade-off that held up best against that area's own fiber geometry and density — 300m for this network.
Risk scored metric by metric
The rate of change in nearby civil and construction activity as the leading signal, kept separate from the other contributing factors rather than averaged away.
A risk-region output instead of a point prediction
The decisive design choice. Because the exact dig location can't be known in advance, the model flags the zone most likely to contain the next cut, which is what took recall from a 50% baseline to 92%.
Risk tiers and a colour-coded network map
The fiber route is drawn tier-by-tier and a network engineer reads it directly, rather than a table that needs an analyst to interpret.
A weekly-refreshing pipeline
Scoring the network again as new incident data comes in, backed by a detailed report and a dashboard for the ops team's own use.
The outcome
- 92% recall, 75% precision on the zones carrying a high likelihood of a cut — up from a 50% recall baseline before the shift to region-based prediction.
- 22 of 25 actual cuts the following month fell inside the zones the model had already flagged as high-risk, on data the model hadn't seen when it was built.
- Faster restoration, through better-planned human resource allocation ahead of where cuts were likely, rather than scrambling after the fact.
- A map the ops team uses directly, replacing institutional memory with something inspectable, current, and refreshed weekly.
- Extended pan-India on the strength of these results, and the client commissioned a second engagement — historical risk analytics for a large additional region — off the back of this one.
If you're facing something similar
In any geospatial risk problem, the unit of analysis is the model. Before arguing about which algorithm to use, sweep the grid size and work out the smallest area that still accumulates enough events to be worth scoring — and expect that answer to change from one region to the next, not to travel as a constant.
And when the thing you're predicting has a genuinely uncertain location — an underground asset, a diffuse risk, anything you can't pin to a point — don't force the model to pretend otherwise. Letting it predict a region instead of a point can be the single highest-leverage change available, as it was here: it alone moved recall from 50% to 92%.