Batched
Wait for a window, then assign everything that accumulated during it, together.
This is the policy the interface exists for. Every rule above answers immediately and could have been a function; this one consumes simulated time, and while it is waiting the board keeps filling. Deciding later over more information is the trade this makes: a load that arrives just after a window opens waits the whole of it, and in exchange the fleet is allocated over a set of tasks rather than one at a time in arrival order. Whether that pays depends on the layout and the load, which is precisely why it is a policy a modeller can measure rather than a behaviour built into a dispatcher.
It is also the demonstration that this design needed a dispatcher with a process of its own. Under the passive paradigm there is nowhere to put this: the decision is made inside an entity's own process at the instant it asks, so "wait and see what else arrives" would mean making that entity wait for reasons that have nothing to do with it.
The window runs from when the dispatcher wakes, so an idle fleet still pays it. A model that wants batching only under load should compose this behind a rule that checks the board first.
Parameters
how long to accumulate, in simulated time
what to do with the batch once it has accumulated