Unstructured input
What the system is told
- Disruption and cancellation reports
- Event and programme announcements
- Feedback from ongoing operations
AI Team Projects
AI Team Project / Intermodal mobility
FastMileUnified Mobility Platform for LLM-Guided Routing
A real-time routing platform that takes data from several mobility providers and, at the press of a button, brings a traveller to their destination across whichever modes fit. The student team builds the routing itself — the regular case, and above all the situations in which the plan stops being true.
The starting point
People judge the whole chain
Nobody chooses a mode of transport. People choose whether the entire journey — from leaving the house to arriving reliably — works for them.
This is why treating the last mile as a separate problem falls short. Optimising one leg does not help if the chain breaks somewhere else. Public transport, on-demand services, car sharing and micromobility are therefore treated as equal options: what makes a mode the right one for a part of the way is the journey it belongs to, not the provider it comes from.
Three situations to solve
The regular case is where it starts, not where it ends
The routing has to cover three situations. They are ordered by how far reality is allowed to drift from the plan — and the further it drifts, the more of the interesting work there is.
- 1
Scenario I
The regular journey
A recurring trip at a familiar time — the daily commute from the surrounding area into the city. High trip volumes, settled routines, and the case the system has to get right before anything else.
Predictable
- 2
Scenario II
A connection at risk, or gone
A train is cancelled or a transfer will not be made. The planned chain is now wrong, and it is wrong while the traveller is already on the way. The system has to notice, replan, and offer an alternative that actually exists.
Time-critical
- 3
Scenario III
The event case
A large event draws many people to one place at the same time — a place where parking is scarce and public transport does not reach far enough. The demand is foreseeable, but it arrives all at once.
Foreseeable, but bursty
The regular case
Plan the chain as a whole
Data-driven methods are combined with analytical route optimisation. What the traveller needs is weighed against what the network actually has available — which is what makes a genuinely intermodal chain possible rather than a feeder trip bolted onto a timetable.
- The chain is optimised as a whole, not leg by leg.
- Any combination of modes is possible — not only the feeder trip to the station.
- Availability and utilisation of the offers feed into the recommendation.
- The recommendation follows the current situation instead of being planned once and then held.
The special case
Two layers: read the situation, then check it
Disruptions do not arrive as clean parameters. They arrive as text: a cancellation notice, an event announcement, a remark from the control room. Pretrained language models are used to interpret such information semantically and turn it into candidate courses of action. The optimisation procedures then check those candidates against the modes, capacities and time constraints that actually exist. Rare or not fully specified situations become tractable this way.
Layer 1 — semantic reading
Language model interprets
- Classify what is actually happening
- Derive possible courses of action
- Hand them on as candidates, not as decisions
Layer 2 — formal check
Optimisation verifies
- Against available modes and vehicles
- Against capacities and utilisation
- Against the time the traveller actually has
What it runs on
The data behind a recommendation
Routing is only as good as what it knows. FastMile brings together scheduled and live data across providers — and the same pool is what the special cases are derived from.
| Source | Used for |
|---|---|
| Public transport timetables, stops, and real-time data | The basis for intermodal connections that work in practice |
| Utilisation of lines and vehicles | Capacity-aware recommendations, including at peak times |
| Trip data from on-demand services | Fleet state, pooling opportunities, demand patterns |
| Car-sharing and micromobility offers | Further modes available inside a single chain |
| Disruption reports and event announcements | The trigger for the special cases — unstructured, and arriving as text |
| Regional movement data | Movement patterns and gaps in the network |
The deliverable
A web application that routes on one button
Ingest data from several mobility providers
Compute a complete door-to-door chain at the press of a button
Derive special cases from the data rather than from a fixed list
Replan when the situation changes and offer a checked alternative
Make visible why a particular route was recommended
For students
Thinking about joining?
The project is about taking a research question through to a working product demonstrator: connecting provider data, route optimisation, the semantic interpretation of disruptions, and a web application that puts all of it behind a single button.
- You are comfortable writing Python.
- You are comfortable with git and working in a shared repository.
- You enjoy working in a mixed international team across two universities.
- Interest in machine learning helps—especially optimisation and reasoning over live data.
- Curiosity about how people actually travel, where a journey breaks down, and what makes an alternative acceptable matters as much as model experience.
What you walk away with
The experience of carrying a genuine research question all the way to a working system, in a mixed team across two universities and one shared repository.