NETWORK FLOWS / DISPATCH
Which car takes
the next request?
The closest car is not always the best assignment. But the best assignment now can still lose later.
Synthetic scenario · not operational data
Both policies receive exactly the same requests, at the same times.
Reconstructing and independently checking both policies…
WHOLE OBSERVATION / 20 MINUTES
One workload. Two outcomes.
These totals stay fixed while you move the replay clock.
Wait times cover served riders only — always read them next to the unserved count. They don't compare the same riders across rules.
A car has an opportunity cost.
Your pending assignment
Choose request and car pairs. Apply the whole batch, or leave it empty to wait 30 seconds. Pending edits do not change accepted results.
Circles R1 to R8: request origins (r-001 to r-008 below). Rounded squares: counted vehicles. Solid paths: active travel legs. Dashed paths: currently feasible pairings. Coordinates and counts come from checked snapshots; this is not a street map.
Why is this car waiting?
Read this vehicle's full-observation event trace
Requests visible at this clock time
Which current assignments are feasible?
Pickup service ends 30 seconds after approach. Equality with the deadline succeeds. These are current-snapshot options.
Inspect phases, ledger and record identity
PRE_DISPATCH is a decision state before dispatch and expiry. POST_BOUNDARY is a completed decision/expiry state. OBSERVATION_END closes events and expiry but starts no new dispatch.
Internal consistency is not independent authenticity. Operational deployment permission: NONE.
An ops team would compare missed pickups and empty travel together: sending the nearest car now can leave the next rider without a feasible car.
Best now has a boundary.
Planned together maximizes assignments among current requests, then minimizes empty approach distance, then uses a fixed ID tie-break. It is exact for this one decision objective. It is not a full-horizon fleet optimizer.
Try a neutral case
Four co-located cars and riders. Both policies make the same choices.
Read assumptions and information limits
Integer coordinates on a 4-kilometer square; Manhattan travel at one minute per kilometer; 30-second pickup service. Decisions every 30 seconds. No pooling, traffic, charging or trained demand model. Future requests do not enter either policy until their arrival.
Ready / idle means dispatchable. COD means executing approach, pickup service or passenger travel. VOR means unavailable for dispatch: off the drive network, not off the pavement. This fixture has no VOR activities. These are FleetLab teaching labels.
Service rate is pickups within deadline and observation divided by admitted requests; completed trips are separate. The final population retains expired, pending, assigned and unfinished trips. No operator data or real-world safety conclusion.