Stress-testing dispatching logic across builds
WareMax lets robotics integrators regression-test dispatching logic against identical seeded scenarios across builds, so behaviour changes are attributable to code, not simulator noise.
When you change dispatching logic, you need to know whether behaviour changed because of your change or because the simulator rolled different dice. WareMax’s determinism makes that distinction crisp.
The regression loop
- Fix a suite of seeded scenarios.
- Run them against the previous build and the new build.
- Diff the trajectories — any difference is your code, not the RNG.
waremax benchmark scenario-suite/ --baseline results/main/The benchmark command detects regressions against a stored baseline, so a build that
quietly degrades cycle time is caught before it ships.
Extending the policy contract
A custom dispatcher implements a one-method Rust trait (TaskAllocationPolicy) plus a
one-arm change in policy_factory.rs. The same pattern applies to station assignment,
batching, priority, and traffic policies — so your logic slots into the same
deterministic harness.
Related: comparing dispatching policies · how it works. Built by Skelf Research.
Frequently Asked Questions
How does determinism help regression testing?
Because the same seed and action sequence produce a byte-identical trajectory, any difference between two builds is caused by the code change — not by simulator randomness. That makes regressions attributable.
Can I detect performance regressions automatically?
Yes. The waremax benchmark command runs scenarios and flags regressions against a baseline, so a build that quietly degrades throughput or cycle time is caught in CI.