A changed schedule needs a stated reason, not just a new final assignment

What it is

When a task moves from one robot to another, the system needs to state why the change happened, not just display the new assignment and leave the supervisor to guess or dig through logs. A reallocation explanation answers a different question than allocation rationale does — not "why does the scheduler assign this way in general," but "why is this one different from the last one."

Why it happens

This builds on allocation rationale being visible in the first place, and targets the moment that is most prone to confusion: change itself. A static assignment can be understood through a rationale summary, but once assignments start shifting, the expectations a supervisor built around the previous plan break. Without an immediate account of the cause — a robot failure, a higher-priority task cutting in, or routine load balancing — the supervisor treats every change as a possible anomaly, even when it is business as usual. That unnecessary vigilance eats into attention that should be reserved for genuine anomalies, and over time either exhausts the supervisor or trains them to tune out change notifications altogether. Put another way, allocation rationale and change explanation answer two different questions: rationale explains how this result was computed, while change explanation explains what condition shifted, relative to last time, to trigger the re-solve. Showing only the new rationale without the delta still leaves the supervisor doing a mental diff between two snapshots — and closing that gap is exactly the job a change explanation is meant to do.

Studying it

A standard test constructs a mix of routine and anomalous scheduling changes and compares an outcome-only display against one that also states the triggering cause, measuring whether supervisors can correctly separate routine changes from ones worth attention, and how quickly. Mission completion rate alone is not a sufficient outcome measure here — it can look fine even after the supervisor has silently lost track of the plan, since task success does not require the supervisor to still understand what the system is doing.

Where it stops holding

Stating a cause depends on the scheduler being able to attribute each change to something concrete: if the underlying algorithm re-solves from scratch as a black box rather than following an explicit trigger-then-reassign logic, accurate attribution can be a genuine engineering problem, and a coarse category (load balancing versus failure response) is still better than nothing. Solvers also commonly have several numerically near-equivalent solutions, so a small input perturbation can trigger a large reorder with no single natural-language cause to point to, and flooding the interface with every minor change notification buries the ones that actually matter. A related edge case is cascading change: a single failure can trigger reassignment across five or six robots at once, and if each is explained separately, the supervisor has to read through five or six statements to realize they are all one chain reaction from the same root cause. Changes sharing a root cause should be grouped into one summary instead of letting the display itself generate extra cognitive load.

Applying it

Log every reassignment against its triggering event rather than storing only before-and-after snapshots, and group changes in the interface by that trigger, surfacing dropped tasks, near-deadline effects, and cross-region impact as the high-cost categories to highlight; add switching cost or hysteresis where numeric instability is causing jittery reordering. Verify it by auditing a period of schedule-change logs against sensor-jitter, robot-failure, and urgent-insertion scenarios, checking whether the stated cause matches the actual triggering constraint, and flag change types that cannot be attributed instead of fabricating a reason for them. For cascading changes, check whether the interface correctly collapses multiple reassignments sharing one root cause into a single summary instead of repeating the same failure source line after line.

Related

• Same group: X7.06.1 The logic behind multi-robot task allocation must be visible to the supervisor · X7.06.3 Overriding a schedule must be as easy to reach as accepting it · X7.06.4 Opaque scheduling logic leaves supervisors unable to anticipate the system's next move
• Nearby: X7.05 Comprehensibility of collective behavior · X3.07 Explainable Decision Basis
• Search terms: schedule change explanation · plan repair · human-swarm interaction