DRT Research Platform

Problem

Demand-responsive transit policies behave differently as demand, fleet size, service area, and passenger behavior change. Comparing those policies requires more than a single simulation: the experiments need controlled scenarios, reproducible runs, consistent metrics, and a traceable path from configuration to result.

My role and ownership

As a graduate researcher at Korea National University of Transportation, I designed the experiment structure, implemented simulation and policy components, ran the study matrix, and built the analysis path from outputs to comparable evidence.

Constraints

• Stochastic simulations require repeated runs and controlled seeds.
• Policy comparisons are meaningless if scenario definitions or metrics drift.
• Passenger acceptance feeds back into what a learning policy observes.
• Large experiment matrices need automation and resumable records.
• Claims must stay tied to recorded configurations and approved results.

Architecture or walkthrough

Configurations define fleet, demand, service, and policy variants. An experiment orchestrator starts repeatable runs and connects the simulator to greedy, LinUCB, or Thompson Sampling policy selection. Simulated passenger responses become learning feedback. Metrics and artifacts are written to an analysis layer and MLflow for comparison.

Important decisions

1. Scenarios are versioned configuration

Context: Changing fleet size, demand, or service rules in code makes results hard to reproduce.

Choice: Represent experimental conditions as explicit configuration consumed by the orchestrator.

Reason: A recorded result should be traceable to the exact scenario that produced it.

Tradeoff: Configuration validation and migration become part of the research platform.

2. Policy choice is modular

Context: Greedy, LinUCB, and Thompson Sampling need to operate against the same simulation state.

Choice: Define a common selection boundary and keep policy state outside the transport lifecycle.

Reason: The comparison remains about the policy rather than a different simulator implementation.

Tradeoff: The shared interface limits policy-specific shortcuts.

3. User response closes the learning loop

Context: A selected option is not automatically an accepted service.

Choice: Model passenger response and feed that outcome back to the learning policy.

Reason: Learning from offered options alone would reward choices that passengers reject.

Tradeoff: Response assumptions become another experimental dependency that must be documented.

4. Metrics are emitted by the run, not reconstructed later

Context: Post-hoc scripts easily diverge as event schemas evolve.

Choice: Produce wait time, service rate, utilization, and policy artifacts through a consistent run output.

Reason: The evidence stays attached to the experiment and is easier to compare through MLflow.

Tradeoff: Metric contracts need versioning alongside the simulator.

Defensible outcome

The research matrix contains 900 simulation runs across 45 scenario variants. Approved results support the direction of the findings: LinUCB reduced mean waiting time relative to the greedy baseline, while Thompson Sampling produced the strongest service-rate improvement. Exact percentage ranges are intentionally omitted until they are tied to an approved result record.

What I would improve

I would add a stricter result registry that binds every published claim to a run manifest, metric definition, analysis revision, and approved citation. That would make the boundary between exploratory output and publishable evidence automatic.