Opaque scheduling logic leaves supervisors unable to anticipate the system's next move

What it is

Opaque scheduling logic leaves a supervisor unable to anticipate what the system will do next: they can read the current task table but cannot say who will get reassigned, what will be dropped, or which route will change once a new task, a robot failure, or an energy shift occurs. This is not a single defect — it is the compounded result of invisible allocation rationale, unexplained changes, and a hard-to-reach override, and its name is a loss of predictability.

Why it happens

Anticipating a system's next move requires a usable mental model of its allocation logic, and that model is built on two things: knowing what drives an assignment, and knowing why a change happens. Take both away, and the supervisor is reduced to passively watching outcomes, with no way to foresee what the system will do before it does it. That shows up directly in the timing of the supervisor's own actions — problems get noticed only after the fact, rather than anticipated early enough to pre-position resources or coordinate a response. At a deeper level, human foresight relies on holding a stable ranking of objective priorities, constraint weights, and trigger rules; if a scheduler's cost weights, hysteresis, or fallback logic are themselves hidden, the same class of input change can produce wildly different reorders at different times, repeatedly breaking the supervisor's mental model until they give up predicting altogether and settle into pure after-the-fact catch-up — a textbook case of automation surprise. Automation surprise has a compounding effect too: once a supervisor has been caught off guard, they instinctively lose confidence in their own reading of the plan and start re-checking the current schedule far more often just in case it changed again. That extra checking is a hidden cost of unpredictability — it never shows up as a single traceable error, but it steadily drags down the supervisor's normal working pace.

Studying it

A standard way to quantify anticipation has supervisors watch the system run for a while, predict the allocation for the next several steps before some event occurs, and compares that prediction against what actually happens — measuring accuracy, confidence calibration, and how fast they recover once a prediction turns out wrong. Scenarios need boundary conditions and several numerically near-equivalent solutions built in, to check whether supervisors are reciting rules rather than genuinely predicting the deployed system's behavior. This accuracy score is what lets different transparency and explainability designs be compared against each other — it is the summary measure of whether the earlier interface changes actually paid off.

Where it stops holding

Predictability does not require a supervisor to guess every specific assignment correctly — dynamic scheduling has legitimate uncertainty baked in, and randomization, online learning, and dependence on external service inputs can make a single determinate "next step" not exist in the first place; chasing case-by-case precision is neither realistic nor necessary. Exposing an overly precise scheduling strategy can also carry its own security or gaming risk. What predictability actually calls for is a supervisor holding a roughly correct directional expectation of how the system will respond; the interface should expose a candidate range and its uncertainty rather than promising a single guaranteed future.

Applying it

Make a supervisor's accuracy at predicting the next allocation the core acceptance metric for a scheduling system's visibility design, rather than settling for a checklist item like "does the interface show a reason." Show the current objective precedence, hard constraints, recent triggers, and a candidate range of reallocations under salient contingencies, with a short commitment horizon so the supervisor knows the plan will hold for at least that window. Verify it with a before-and-after prediction-accuracy test — have supervisors watch a run segment and predict the next allocation, then compare against the actual outcome — using failure, energy-threshold, and urgent-insertion scenarios to check whether directional prediction holds up, and recalibrate after every model update rather than assuming the old mental model still applies. The length of the commitment window itself needs calibration too: too short and it fails to stabilize expectations, too long and it can tie the scheduler's hands exactly when a fast response is needed — there is no universal default for this trade-off, and it has to be tuned to the actual pace of the task.

Related

• Same group: X7.06.1 The logic behind multi-robot task allocation must be visible to the supervisor · X7.06.2 A changed schedule needs a stated reason, not just a new final assignment · X7.06.3 Overriding a schedule must be as easy to reach as accepting it
• Nearby: X7.05 Comprehensibility of collective behavior · X3.07 Explainable Decision Basis
• Search terms: predictability · automation surprise · levels of automation