Reading WareMax delay attribution
Every completed task decomposes into five buckets — assignment, travel, queue, congestion, service — summing to cycle time. Read it and use it as reward.
A single throughput number tells you nothing about where the time went. WareMax decomposes every completed task’s cycle time into five buckets that sum to the whole.
The five buckets
| Bucket | What it measures |
|---|---|
assignment | Time the task waited before a robot was assigned |
travel | Robot travel time to the pickup |
queue | Time queued at the pick station |
congestion | Extra time lost to traffic / wait-at-node |
service | Station service time |
For a task with cycle=33.1s, a decomposition might read
assign=0.2 travel=11.2 queue=5.4 service=5.5 congestion=10.8.
Why the split matters for dispatching
Only some of that time is controllable by the dispatcher. A robot’s service time at a
station is not a dispatching decision; the assignment wait and travel-to-pickup are.
That is exactly the split the routed reward mode uses — it charges the agent only for
what it can influence, which is why it is the recommended default for
RL training.
Reading it in practice
The per-task decomposition is exported alongside the event log and time-series. Aggregate it across a run to see whether your bottleneck is travel (fix routing), queue (add station concurrency), or congestion (relieve traffic) — before you blame the dispatching policy.
Related: verifying determinism · comparing dispatching policies. Built by Skelf Research.
Frequently Asked Questions
Do the five buckets always sum to cycle time?
Yes. The decomposition is a partition of the task's cycle time into assignment wait, travel, station queue, congestion, and service. It is designed to sum exactly to the observed cycle time.
How is attribution used as a reward?
The attribution reward mode uses the full per-task decomposition; the routed mode charges only the controllable part — assignment wait plus travel to pickup — which is what a dispatcher can actually influence.