Service Runs on Signal, Not Schedule

Service Runs on Signal, Not Schedule

Most service operations start with a schedule. The schedule decides when service happens, whether the point needs it or not. On-Demand Service starts somewhere else, with the condition of the point itself. Service runs on signal, not schedule, triggered by what is actually happening at each point instead of a date set in advance.

A signal is the condition reporting itself. A container that is full, a dispenser that is low, a tank down to a level worth a trip. The point tells you it needs service, so you stop guessing from a date.

A schedule is what you use when you can’t see condition. With no way to know which points need service, a fixed cadence was the best available guess, and for a long time it was the only one on offer. Once the condition at each point becomes visible, the schedule has nothing left to decide. The trigger moves from the calendar to the point.

The route does not disappear. It changes basis. Instead of running every point on a cadence, the route forms around the points that have crossed the line, in the order they crossed it. The work still happens. It just stops happening where it was not needed.

A calendar starts from the date and works outward to every point. Signal starts from the point and works back to the day it needs service. The schedule commits before it knows anything. Signal waits until there is something worth doing.

There is no perfect interval to find, because the interval was never the thing that needed fixing. The work responds to the point, at the moment the point needs it. That is what it means for service to run on signal, not schedule.