Demand-responsive transit — DRT — is the category of services where there's no fixed route or schedule. A vehicle picks you up near where you are, drops you near where you need to go, dynamically routed based on who else is requesting service at the same time.

It's compelling for low-density areas where a fixed-route bus would run mostly empty. The problem is that how well it actually works depends heavily on which dispatch algorithm you use, what demand patterns look like, and what constraints you impose on detour time and fleet size. You can't deploy a fleet and iterate.

Simulation is the answer — but only if you can trust what the simulation tells you.

The architecture question that mattered

The DRT simulation platform I built at the Korea National University of Transportation is event-driven. Passengers arrive according to a demand model, request pickup, get assigned to a vehicle (or don't, based on capacity and timeout policy), ride to their destination, and exit. Vehicles move through a road network, pick up and drop off, recharge, and go offline at end of shift.

The first real design question was whether to model this with discrete time steps — advance a clock, check every entity's state — or pure events: process each meaningful moment in chronological order, skip the quiet intervals.

Pure events was the right call. Discrete time steps burn compute on ticks where nothing changes. At scale — large fleets, dense demand — that overhead compounds. Event-driven also forces you to be explicit about what constitutes a meaningful state transition, which makes the model easier to reason about.

Every significant transition emits a structured event: passenger requested, assignment attempted, pickup confirmed, vehicle rerouted. Those events are the log, the metrics source, and the replay mechanism.

Reproducibility isn't optional in research

A simulation result you can't reproduce six months later isn't a result — it's an anecdote.

I used MLflow to track every experiment run: hyperparameters, metrics, artifacts, and the code version that produced them. Ray handled distributed parameter sweeps — run a grid of 200 dispatch configurations in parallel, collect results, compare. The experiment itself is a first-class object, not a script you run and try to remember the flags for.

The practical payoff: when a result looks interesting, you can hand the run ID to someone else and they get the same numbers. When you want to compare a new dispatch variant against a baseline, the baseline is already frozen and retrievable.

This matters more in research than in production, because in production you can inspect the running system. In research, the simulation run is the artifact — if you can't reconstruct it, the finding is worthless.

What simulation doesn't tell you

Simulation results are only as good as the demand model and road network they run on. Real demand is messier than a Poisson distribution. Real roads have traffic, closures, and driver behavior that no model fully captures.

The platform is a tool for comparing relative performance of dispatch strategies under consistent assumptions. It narrows the decision space before anyone commits to infrastructure or policy. That's valuable — but it's a different claim than "this is what will happen when you deploy."

That distinction is easy to lose when a graph looks convincing. Building the platform made me more careful about stating it explicitly.