Information required to display a waveform. One waveform the viewer knows about: which signal it is, what it is called and where its data lies. What it LOOKS like is not here - see WaveDrawn, which memoises that as a function of this and the view. It used to be: every Wave carried its SVG and the five view settings that SVG had been made under, so the model held a picture of the screen that had to be kept in step with the screen, and "is this waveform up to date" was a question about the model rather than about what is drawn. What the .NET simulator is doing, as far as the renderer knows - and therefore what a synchronous question about it can be answered with. **This is the "is building" state that keeps everything else synchronous.** Building a design and running it are the only things a simulator does that take long enough not to be answerable while a frame is drawn, and both are commands the renderer issues. So they are modelled the Elmish way - a message that starts one, a message that says it finished, and this in the model in between - and every other question about the simulator is answered at once, with "nothing yet" exactly while this says a build is in flight. See the module note on SimInterface. It was module-level state in SidecarSession, on the argument that what another process holds is not model state. It is: what the renderer BELIEVES about that process is a fact about the renderer, the UI has to draw it, and a belief the view can only reach through a side channel is one the view cannot draw from. Identifies one asynchronous operation asked of the .NET simulator: sent with the request, returned with the answer, and the key under which the model remembers what the operation was. **Its own numbering, not the wire's correlation id.** `SidecarClient` gives every REQUEST a correlation id and the sidecar echoes it, which is how a promise finds its reply. An operation is not a request: a build is `sendDesign` - itself one frame per sheet - followed by `SimBuild`, and a fetch is a run followed by a read. One id per request cannot name a thing made of several, so this numbers the operations and `SidecarClient` goes on numbering the frames. Unique among the operations OUTSTANDING, not for all time. An entry leaves the table when its answer arrives and there are never many, so a uint32 wrapping cannot collide with anything still in it.