How this works, and its real limits
Every ~55 seconds this reads live predictions from MBTA's own public API for the Red Line, comparing each trip's predicted time against its scheduled time to get a real current delay, then checks whether two consecutive trips in the same direction are predicted to reach a shared upcoming stop closer together than a 3-minute minimum safe headway. When a conflict is found, a real CP-SAT constraint solver (Google OR-Tools) decides the cheapest way to restore that headway: hold the following train (up to 3 minutes), or short-turn it, whichever costs less in a simple objective.
Real limitations, stated plainly: this is a single-conflict-point model, not a full network cascade — it doesn't project how a hold ripples to stops further down the line, or across trips beyond the immediate pair. Passenger impact is approximated as one unit per stop, since no public per-stop ridership feed exists; a real dispatcher would weight a hold at a busy downtown stop very differently from a quiet one. Short-turn eligibility isn't checked against where each trip actually is relative to the Braintree/Ashmont branch split. This produces a what-if suggestion from one live data snapshot, not a dispatch recommendation — MBTA's actual dispatchers have real-time information and authority this system doesn't.