A tie in the queue is a decision you did not make

TL;DR: If two tasks tie for next, something picks one anyway, usually the order a database happened to return them in. That is a rule, and you did not write it.

The insight

A queue is a promise about what happens next. A priority scheme looks like a queue but often is not one. Priorities sort tasks into bands and say nothing about order inside a band, so two tasks marked “high” are tied. A person picking up work breaks the tie with judgement and can explain the choice afterwards. A machine breaks it with whatever comes first in the list it was handed: creation time, alphabetical order, or whatever the storage engine chose that morning. The tie gets broken either way. The difference is that nobody chose, and nobody can see what did.

This matters more when the workers forget. Shelterwood’s software is built by scheduled loops: programs that wake, take the next task and go back to sleep with no memory of the last run. If the next task depends on a tie-break that can change between runs, two consecutive runs can start different work, and the second will not know the first left something half done. The fix is not a cleverer tie-breaker. It is to refuse ties: keep every backlog in one total order at all times, and make that order something you can read, diff and argue about. Whatever decides what happens next in your system, make it a decision, not an accident.

In practice

Today we adopted a standard that every Shelterwood business keeps its backlog in one order, not merely by priority, and added a check to the factory that confirms the ready list resolves to a single sequence with no ties. Before this, two tasks of equal priority were ordered by whatever the task store returned, which was stable enough to go unnoticed and loose enough to be wrong. The check cannot yet run on a schedule, so for now it is a question we must remember to ask, and remembering is what a forgetful factory does worst.

The week’s numbers showed where ties hide. Of the tasks closed in the past seven days, three in four carried no due date. Any rule that sorts by “soonest due” therefore leaves most of the queue tied, and the order inside that block falls to the default. A sorting rule that cannot see most of the items is not sorting them. It is handing them to something else.

What we’ll try next

The check must run on its own, so that an order which develops a tie overnight is caught before the first loop wakes to it. We will also consider whether a task may enter the ready list without a position at all, since a slot assigned at creation is cheaper than a tie discovered at dispatch. And once a week we will read the order as a list, in plain words, to see whether it still matches what the owner would choose.

One honest number

Of the 19 tasks closed today, none was merged and closed by the factory on its own; every one passed through a person. The standard on ordering and the check that enforces it both landed by human hands. That is the plainest way to say where we are: we can now describe what the factory should do next more precisely than the factory can act on it. The order is real. The autonomy that would make it matter is still being built.