Design/Frames.md

@@ -96,6 +96,8 @@ Data is synchronised and organised into discrete frames that are represented by
 #### 4.1 General Protocol
 * **4.1.1** Transmission (or recording) occurs upon flush.
 * **4.1.2** `flushing` can occur on a per channel or entire `Frame` basis.
+* **4.1.3** A sender may filter changes and not transmit to all parties.
+* **4.1.4** Filtering can occur at receivers request or subject to authorisation.
 
 #### 4.2 Owner Protocol
 * **4.2.1** Changes marked as `local` or `foreign` are transmitted.
@@ -105,12 +107,21 @@ Data is synchronised and organised into discrete frames that are represented by
 * **4.3.1** Changes marked as `local` are transmitted.
 * **4.3.2** `foreign` or `completed` changes are ignored.
 
+#### 4.4 Flush Events
+* **4.4.1** Flush events occur for `local` or `foreign` changes.
+* **4.4.2** Flush events are dispatched only after transmission has occurred.
+* **4.4.3** Flush events may occur in parallel.
+* **4.4.4** One flush event occurs per changed channel.
+* **4.4.5** `aggregate` channels with multiple changes result in a single event.
+* **4.4.6** `Frame` and channel number are provided to event handler.
+* **4.4.7** The change status remains on the channels within the `Frame`.
+
 ### 5. Memory Management
 * **5.1** `Frame`s are created from a memory pool.
 * **5.2** Upon destruction, channel data is not removed but is transferred to the pool.
 * **5.3** Channels are marked as `stale` if the data contents reflect old pool data.
 * **5.4** The pool should be maintained at a minimal size.
-* **5.5** The pool may expand or contract as necessary.
+* **5.5** The pool may expand or contract as necessary but infrequently.
 
 ## Discussion
 Each frame is involved in a number of stages within the system, these are: