What each waveform on screen is, and what it was drawn from. A drawn waveform is a pure function of the data for one signal over one window and a handful of display settings - so it does not belong in the model, and the model no longer holds it. What is kept here is the memo of that function: the SVG last made for each waveform, with the exact inputs it was made from. The view asks for the waveform it wants and gets it back without making it twice, and NOTHING here is consulted to decide what should happen next. Two things make the memo more than an optimisation. The first is the fallback. Where a signal's data has not arrived - the window moved and the answer is still on the wire - what is kept is what is on screen, and keeping it is better than emptying the row: waveforms a moment out of date are what a viewer over a wire looks like, a viewer that blanks itself on every scroll is what a broken one looks like. The stored Spec says which view the row is actually showing, which is how anything that has to agree with the screen - the hover tooltip - can be made to agree with it rather than with the controls. The second is that a render costs nothing when nothing changed. Issie renders the whole app on every message and does not memoise components, so this function is called for every waveform on every keystroke; without the memo each of those would rebuild a hundred SVGs. Module state, in the sense docs/mutableState.md allows: it is not model state written somewhere else, and no decision reads it. Discard it whenever the simulation it was drawn from is replaced - a driver index means something different in the next build, and a stale hit would draw the old design's signal under the new design's name.