The Schedule Doesn’t Know What Happened After It Was Written

The Schedule Doesn’t Know What Happened After It Was Written

A schedule is a prediction, written once, at a single moment, from whatever was known then. The trouble starts the moment it is published, because the operation keeps moving and the schedule does not. The schedule doesn’t know what happened after it was written.

A bin that was half full when the route was planned can be overflowing by midweek. A quiet stop can turn busy, and a busy one can go quiet. None of it reaches the schedule, because the schedule was finished before any of it happened.

This is not a problem you fix with a better prediction. The flaw is that a prediction, once made, stops listening. A schedule has no way to take in what changes after it is set. It commits, and then it goes deaf.

Signal works the other way. It never stops listening. The condition at each point reports continuously, and the work follows what is true now instead of what was predicted earlier. There is no prediction to go stale, because the work waits for the condition.

A schedule is finished the moment it is written. Signal is never finished, because the condition keeps reporting and the work keeps following it. That is what it means for service to run on signal, not schedule.

‍