# Known system boundaries

These are intentional design limits, not faults. Knowing them keeps expectations realistic and saves time when something looks wrong but isn't.

## No proactive rebalancing

The dispatcher never moves a regular order out of a driver's route just to make room for a Platinum order. Platinum protection works only through the double simulation described in [Priority Customers (Platinum)](/books/console-yF7/page/priority-customers-platinum).

## Orders out for delivery are frozen

Once a driver has left the store with an order, that order is never touched again by the dispatcher. It is still used to estimate when that driver will be free, but it cannot be reassigned, revalidated or cancelled by the algorithm.

## Decisions are local, not global

Each assignment decision compares the current driver against one candidate driver. The dispatcher does not attempt to find a perfect overall solution across all drivers and all orders at once.

This is why two decisions that each look right individually can, together, look less than ideal in hindsight.

## Order urgency isn't a reassignment factor

Only driver priority matters when deciding whether to reassign. A very urgent regular order will not jump the queue over a less urgent one on its own. See [When an order changes driver](/books/console-yF7/page/when-an-order-changes-driver).

## Last-Option can exceed the normal delay tolerance

As a last resort, an order may be placed with a slightly later estimated arrival than the normal delay tolerance would otherwise allow, rather than being left unassigned. See [Last-Option: the final safety net](/books/console-yF7/page/last-option-the-final-safety-net).

## A store with no change is skipped

If nothing has changed for a store since the last run, it is skipped rather than re-processed. A run that appears to have "done nothing" for a quiet store is behaving correctly — see [The assignment cycle, step by step](/books/console-yF7/page/the-assignment-cycle-step-by-step).