← Writing
Architecture · 2026

The configuration is the state: a different shape for the optimization loop

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.

Two places state can live

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.

Promoting the configuration

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.

The output is demoted from solution to signal. The writable configuration is promoted from parameter settings to computational state. That single inversion is what the rest of the design follows from.

Why this helps under drift

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.

What stays on our side

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.

This is an architectural account, not an implementation. The update rule itself is never shipped, described in formula, or embedded in the client.
Run it on your workload →See pricing