Some of this is a model. Most of it is maths. We will tell you which.
An evaluator who finds one unsupported AI claim discounts everything else on the page, so here is the honest split: what runs on a language model, what is computer vision on the vehicle, what is statistical, what is optimisation, and what is a rule someone wrote down on purpose. All five are useful. Only two of them are "AI" in the sense the word is usually sold.
Genuinely a language model.
One capability in RouteSync runs on a large language model, and it is not a chatbot bolted to a help page.
Operations Assistant
Ask about your own operation in plain language — "which routes lost trips yesterday and why" — and it calls the platform's own engines to answer, rather than guessing from a summary. Answers come with the figures it used.
Bounded by your permissions
The assistant sees exactly what the person asking is allowed to see. It runs inside the same role-based access control as every screen, so it cannot become a route around your permissions.
It calls tools, not memory
Every answer is produced by running a real query against your data at the moment you ask. Nothing is recalled from training, and nothing is invented when the data is missing — it says the data is missing.
Models on the camera. Events on the platform.
The one place a trained neural network sits in the chain is on the vehicle: the cameras and edge recorder run computer-vision models for passenger counting, forward-collision and lane-departure events, driver drowsiness and distraction, and door-zone safety. The models can be the camera vendor's, or ours — a deployment can run either, and we will say which is fitted. What reaches the platform is the event, not the video; the platform ingests it, reconciles it and applies the same configured rules to it as to any other signal. Detection quality depends on the model, the mounting and the light, so we validate it on your vehicles rather than quote a figure.
Where inference runs
On the device — the camera or the edge recorder — so detection continues when the vehicle is off the network. Events are buffered and synchronised on reconnection.
Whose models
The camera vendor's or RouteSync's. Either can be fitted, and which one a deployment runs is stated for that deployment rather than left implied.
What crosses the network
Events, and clips retrieved on trigger. Not continuous video — the bandwidth and the retention cost of streaming every camera all day are not worth what they buy.
What we validate
Detection quality per deployment and per camera position, measured on your vehicles. We do not publish a universal accuracy figure, because there is not one.
Prediction, from your own history.
These forecast. They are regressions over your data, not neural networks, and they publish their own confidence so you can tell a strong signal from a weak one.
Ridership forecast
Least-squares trend over the recent series per route, projected forward. Where there is not enough history to fit a line, it says so instead of drawing one.
Battery remaining useful life
Linear regression of state-of-health over time gives a degradation slope; remaining life is the distance to the end-of-life threshold at that slope, with R² reported as confidence. Cell imbalance and thermal stress adjust it.
Component failure windows
Per-component predicted service dates extrapolated from measured trends — wear, efficiency drift, fault frequency. Derived from real signals only; nothing is simulated to fill a gap.
Algorithms with names, and answers you can reproduce.
The heaviest lifting in transport planning is combinatorial, not predictive. These are classical algorithms — which means the same inputs give the same answer, and the method can be stated in a technical proposal.
Stop placement
Demand-weighted DBSCAN clustering over movement data, then greedy maximal-coverage (MCLP) within a stop budget, or set-cover (LSCP) when full coverage is the requirement.
Run-cutting & blocking
Trips into vehicle blocks and blocks into legal driver duties, against your working-time rules, break rules and depot constraints.
Network & route optimisation
Route alignment and frequency against demand, coverage and fleet, with the assumptions versioned so a result can be re-run and defended months later.
Accessibility & isochrones
What a zone can reach within a time budget, computed over the real network with barriers respected — not a circle drawn around a centroid.
Pickup clustering & sequencing
Staff rosters into shared pickups and an ordered route, balancing ride time against vehicle count.
Road-network routing
Alignments snapped to real roads with real turn restrictions, so a planned kilometre is a kilometre a bus can drive.
And a great deal of it is simply rules — deliberately.
Exception detection, scoring and alerting are threshold logic you configure. That is the right design: an operations team has to be able to explain to a regulator why an alert fired, and "the model decided" is not an explanation.
Exceptions & alerts
Missed trips, headway breaches, geofence entries and exits, panic events, device silence — each with a threshold you set and can show.
Status logic
Green, amber and red on dashboards and management boards come from configured limits, so the same number means the same thing to everyone in the room.
Scoring
Driver behaviour, fatigue risk and demand scores are weighted rules. The weights are visible and adjustable, and a score can always be taken apart.
Ask it something about your own network.
The assistant is easiest to judge against data you know. Bring a question your team argues about.