diff --git a/README.md b/README.md
index 60c99fc..dba97cc 100644
--- a/README.md
+++ b/README.md
@@ -1755,7 +1755,7 @@ The `visualizer@v1_support` object in [`client/hello`](#client--server-clienthel
 - `visualizer@v1_support`: object
   - `buffer_capacity`: integer - max total size in bytes of buffered visualizer binary messages, counting only each reassembled message's type byte, timestamp, and data
 
-The server MUST NOT send a message if its size plus the total size of previously sent visualizer messages with future timestamps on the server's clock would exceed `buffer_capacity`. Sending a visualizer `stream/clear` or `stream/end` resets this count.
+The server MUST NOT send a message if its size plus the total size of previously sent visualizer messages with future timestamps on the server's clock would exceed `buffer_capacity`. Sending a visualizer `stream/clear` or `stream/end` resets this count. An in-place `stream/start` does not.
 
 The requested data types, frame-rate cap, and spectrum configuration are dynamic and reported in the [`client/state`](#client--server-clientstate-visualizer-object) visualizer object.
 
@@ -1790,6 +1790,8 @@ The `visualizer` object in [`stream/start`](#server--client-streamstart) has thi
     - `f_min`: integer - lowest frequency in Hz
     - `f_max`: integer - highest frequency in Hz
 
+When the `visualizer` object updates an active stream, frames sent before this message use the previous configuration and frames sent after it use the new configuration. Clients MUST keep buffered frames and interpret each frame under the configuration in effect when it was received.
+
 ### Server → Client: `stream/clear` visualizer
 
 When [`stream/clear`](#server--client-streamclear) includes the visualizer role, clients MUST clear all buffered visualization data and continue with data received after this message.
diff --git a/roles/visualizer/v1.md b/roles/visualizer/v1.md
index 4618849..e0b7a8f 100644
--- a/roles/visualizer/v1.md
+++ b/roles/visualizer/v1.md
@@ -14,7 +14,7 @@ The `visualizer@v1_support` object in [`client/hello`](../../messaging.md#client
 - `visualizer@v1_support`: object
   - `buffer_capacity`: integer - max total size in bytes of buffered visualizer binary messages, counting only each reassembled message's type byte, timestamp, and data
 
-The server MUST NOT send a message if its size plus the total size of previously sent visualizer messages with future timestamps on the server's clock would exceed `buffer_capacity`. Sending a visualizer `stream/clear` or `stream/end` resets this count.
+The server MUST NOT send a message if its size plus the total size of previously sent visualizer messages with future timestamps on the server's clock would exceed `buffer_capacity`. Sending a visualizer `stream/clear` or `stream/end` resets this count. An in-place `stream/start` does not.
 
 The requested data types, frame-rate cap, and spectrum configuration are dynamic and reported in the [`client/state`](#client--server-clientstate-visualizer-object) visualizer object.
 
@@ -49,6 +49,8 @@ The `visualizer` object in [`stream/start`](../../messaging.md#server--client-st
     - `f_min`: integer - lowest frequency in Hz
     - `f_max`: integer - highest frequency in Hz
 
+When the `visualizer` object updates an active stream, frames sent before this message use the previous configuration and frames sent after it use the new configuration. Clients MUST keep buffered frames and interpret each frame under the configuration in effect when it was received.
+
 ### Server → Client: `stream/clear` visualizer
 
 When [`stream/clear`](../../messaging.md#server--client-streamclear) includes the visualizer role, clients MUST clear all buffered visualization data and continue with data received after this message.