
Most optimizers keep their state in software — a running estimate, a momentum buffer, a model of the landscape — and treat the physical device as a function they call. Stateful Wave Computing inverts that, and the inversion is the whole idea.
In a conventional loop, the optimizer’s state lives in software and the device is a black box you query. The device produces a number; the software updates its internal estimate; it picks the next query. The physical system is just an oracle.
But many systems already hold state in their writable parameters — the phase settings on a photonic mesh, the biases on a control, the setpoints on a plant. Those values persist between rounds whether or not your optimizer models them.
SWC treats that writable control configuration as the iterative state itself, updated in place. The plant’s output is demoted from ‘solution’ to ‘signal’ — a measurement whose only job is to drive the next configuration. The thing you were reading out as an answer becomes feedback; the thing you were treating as mere settings becomes the computation.
When state lives where the work physically happens, drift in the device is not a modeling error to chase — it is simply more signal. A loop that keeps its state in software has to notice that the world moved, update its internal model, and catch up. A loop whose state is the device just keeps folding each new measurement into the live configuration. That is why a single measurement per round can hold lock on a moving target where gradient estimators cannot even run.
The rule that converts a measured residual into the next configuration runs only on our endpoint. You send a measurement and a score; you receive the next configuration. Nothing about the method lands on your disk — which, conveniently, also means there is nothing to leak in either direction. Your data stays yours; the method stays ours; the loop runs across the boundary.