The Intelligent Rail Network

June 02, 2026

I have been reading about rail networks for about six weeks. It started as general curiosity about how something this old and this large actually gets managed day to day. Somewhere along the way I realised the problems these engineers are solving is the same problems I work on. Not similar, the same! Just with steel and track instead of spreadsheets and APIs.

The United States has the largest rail network in the world, around 140K miles (~ 225K km), most of it freight (Association of American Railroads, 2026). China has the longest high-speed network at over 31K miles (~ 50K km) and still expanding (China State Railway Group, 2025). Russia's Trans-Siberian is the longest single continuous line, about 5.8K miles (~ 9.3K km) from Moscow to the Pacific coast (Encyclopaedia Britannica, n.d.). India's network carries over 23M passengers every single day across 41K miles (~ 67K km) of route (Indian Railways, 2023).

Approximate network size
─────────────────────────────────────────
USA (freight)   ████████████████  140K mi
India           ████████████      41K mi
China (HS)      █████████         31K mi
Trans-Siberian  ██                5.8K mi
─────────────────────────────────────────

The management problem underneath all of this is surprisingly concrete. Thousands of vehicles moving through a shared physical network, generating sensor data constantly, subject to weather, load, scheduling conflicts, and human decisions made under pressure. You cannot run that on intuition alone.

A modern freight locomotive has sensors on its axles, brakes, fuel system, and engine. These sensors records temperature, pressure, vibration, and load as the train moves. A single long-haul run can produce millions of readings before the locomotive pulls into the next yard. In machine learning, each individual measurement you feed into a model is called a feature, basically one column in a spreadsheet. For a locomotive that might be average wheel bearing temperature, vibration on a specific track section, signal errors logged in the past week, weight of the load, or rainfall at the departure station. None of these tell you much on their own. But a model with access to all of them, across tens of thousands of trips and months of data, starts finding relationships that nobody sat down and wrote by hand. It is not told that wet track combined with heavy load increases brake wear. It finds that, because the pattern is consistent enough in the numbers.

The most common setup for this is called supervised learning. You show the model historical trips with known outcomes, here are 10K past journeys and here is whether each arrived on time or was delayed. The model learns the shape of that relationship. When a new trip is about to depart with its own sensor readings, the model estimates what is likely to happen. Indian Railways has been building systems along these lines to improve punctuality prediction across its network (The Associated Chambers of Commerce and Industry of India, 2023). At 23M passengers a day a small improvement in accuracy is not a small thing.

flowchart LR
    A[Past trips + outcomes] --> B[Model training]
    B --> C[Trained model]
    D[New trip data] --> C
    C --> E[Predicted outcome]

Not every problem here is about predicting what happens next though. Sometimes the more useful question is what is already going on in the data that nobody has noticed. Clustering is where an algorithm groups similar data points together without being told what the groups should look like. For a rail network this might surface a set of stations that consistently underperforms together, not because anyone linked them in any system, but because they share aging signal infrastructure or their maintenance schedules have been misaligned for years. Without the analysis each of those stations just looks like a separate problem. With it, they look like one problem with one cause. Chinese researchers have used this same principle on real high-speed rail sensor data, though on readings rather than stations: unlabeled wheel-rail force measurements from a single Beijing-Tianjin line turnout, sorted automatically into normal, high-load, and extreme-load condition groups with nobody telling the algorithm what those groups should look like (Wang et al., 2025).

Then there is anomaly detection, which is probably the most immediately useful application in this space. A model that has learned what normal looks like for a specific vehicle on a specific route can tell you when something does not fit. Imagine a locomotive with consistent fuel consumption and temperature across hundreds of previous trips. One morning the fuel reading comes in slightly higher than usual, not dramatically, just enough to sit outside what the model expects. It flags it. The maintenance team checks at the next stop and finds a small injector fault. Left alone it would of gotten worse. Caught here it gets fixed before it turns into an unplanned failure somewhere out in the middle of nowhere. The model did not diagnose anything. It just noticed a number was different from what it normally sees, and that was enough. The EU Shift2Rail initiative has published research specifically on this kind of predictive maintenance, aimed at reducing unplanned downtime across the European network (Shift2Rail Joint Undertaking, 2019).

Regression is one of the oldest tools in the field and still one of the most useful. It lets you put a precise number on a relationship rather than just saying the relationship exists. Not just "weather affects delays" but "each additional 10mm of rainfall adds roughly 6 minutes to journey time on this corridor." That specificity is what makes the analysis something you can actually plan around. Japan's Shinkansen averages under two minutes of delay across the entire network (Central Japan Railway Company, 2023). That did not happen by accident. It came from years of measuring everything that could affect performance, modeling the relationships, and feeding that back into operations continuously.

Models make mistakes, and a confusion matrix is how you are honest about which kind.

                   Predicted: fault    Predicted: fine
Actual: fault      Caught              Missed  <-- the dangerous one
Actual: fine       False alarm         Correctly cleared

In a safety-critical environment a missed fault is a very different kind of failure than a false alarm. Models in this space are usually tuned to raise more alarms, accepting some unnecessary stops, in exchange for reducing the chance of missing something real. That is not just a technical setting, it is a values decision about acceptable risk. Honestly I think this is where a lot of organisations get it wrong, not technically but organisationally. The people tuning the model threshold and the people who actually bear the cost of a missed fault are rarely in the same room. Rail does not have that luxury. If you miss a fault on a track carrying 23M passengers a day, the consequences are not a bad quarterly metric. That pressure forces a kind of honesty about risk that most industries could use more of.

The last piece is real-time inference, which is just using a trained model on live data while things are actually happening. Researchers working with Transport for London's automatic fare-gate data built and tested a model that predicts platform and train crowding on the London Underground roughly 15 minutes ahead (Noursalehi et al., 2021). When a platform is predicted to hit a certain threshold, operators can adjust train frequency before the problem develops. The model is not running the network, an operator is. But the model is getting them better information earlier, and that changes what decisions are actually possible.

Rail turns out to be a good place to see all of this clearly. The failures are physical, the stakes are obvious, and nothing is dressed up in product language. The same methods that find patterns in customer behaviour finds them just as well in wheel bearing temperatures. The math does not care what the numbers represent. That is probably why I kept reading.

Somewhere along the way reading turned into building. I put together a small tool where you draw a rail route on an actual map of the US and its territories, freight or passenger and instead of a guess you get a number back. Things such as, what it would cost to build, how much steel and concrete it would take, how many truck or car trips it pulls off the road each year, how much carbon that saves. None of this is a model, to be honest. There is no training data and nothing here is learned, just formulas, applied consistently, built on constants that each cite where they came from.

It is a small don't guess, look it up, show your work tool rather than a clever one, and it is not shy about telling you when you have drawn something that does not exist. Send a route over open water and it tells you a bridge is needed, and that bridges are some of the most expensive track there is. Real ones run anywhere from about $10M to $85M or more a mile depending on span and depth, with the high end anchored on the longest bridge ever built, China's Danyang-Kunshan Grand Bridge, 102 miles long and $8.5B to build (Encyclopaedia Britannica, n.d.). Try to stack three passenger decks and it pushes back too. All the evacuation codes and rollover stability rule that out before it reaches a drawing board, and nobody, anywhere, has actually built one..

Anyways, here it is. Draw a route below and watch the numbers move, or open it in its own tab: Rail Network Sketchpad.

References