I run the experiment, then publish what went wrong.

Most technical writing describes an idea. A spin is the idea actually run — with the data it ran on, the code that produced it, the number it moved, and an honest account of where it fell apart.

Every spin follows the same seven sections in the same order, so you can skip straight to the part you came for.

Section five is the one that matters. A demo that only shows the working path teaches you nothing you can use. Everything here is MIT licensed and reproducible on a laptop.

Enterprises have run optimization software for thirty years. The models are rarely wrong in any way a solver would recognise — they hit the objective, satisfy every constraint they were given, and get overridden anyway.

The override is where the real constraint lives, and nobody writes it down. A planner knows a supplier overpromises in Q4. A dispatcher knows one unit runs behind. None of it is in the ERP, none of it is in the model, and all of it is why the plan gets rewritten on Monday morning.

Agents don't fix this. Left alone they make it worse — one more opaque recommender to argue with. What interests me is the loop that treats the override as the most valuable signal in the system rather than a failure to be trained out.

That's the thread running through every spin here.