Design/Frames.md

@@ -63,23 +63,31 @@ Data is synchronised and organised into discrete frames that are represented by
 * **3.1.2** One instance of `Feed` *owns* a given `Frame` id, including across a network.
 
 #### 3.2 General Protocol
-* **3.2.2** Received changes are marked as changes in the corresponding `Frame`.
-* **3.2.6** A dispatched `Frame` is marked as `flushed`.
+* **3.2.1** Received changes are marked as changes in the corresponding `Frame`.
+* **3.2.2** A dispatched `Frame` is marked as `flushed`.
 
 #### 3.3 Owner Protocol
 * **3.3.1** Received changes do not result in a dispatch event.
 * **3.3.2** Received changes are applied to a new `Frame` upon a frame creation request to `Feed`.
-* **3.2.3** Changes received flagged as `foreign` transition to `completed` in the `Frame`.
-* **3.2.4** Changes received without `foreign` transition to `foreign` in the `Frame`.
-* **3.2.7** A created `Frame` has its changes copied to persistent state for channels marked with a `persistent` storage type, before creation completes.
+* **3.3.3** Changes received flagged as `foreign` transition to `completed` in the `Frame`.
+* **3.3.4** Changes received without `foreign` transition to `foreign` in the `Frame`.
+* **3.3.5** A created `Frame` has its changes copied to persistent state for channels marked with a `persistent` storage type, before creation completes.
 
 #### 3.4 Non-Owner Protocol
-* **3.2.1** Received changes accumulate into a waiting `Frame` with correct timestamp.
-* **3.2.5** A `Frame` is dispatched once all changes are believed to have been received.
-* **3.2.7** A dispatched `Frame` has its changes copied to persistent state for channels marked with a `persistent` storage type.
-
-#### 3.3 Change Events
-* **3.3.1** Change events occur on any kind of received change (foreign forwards or not)
+* **3.4.1** Received changes accumulate into a waiting `Frame` with correct timestamp.
+* **3.4.2** A `Frame` is dispatched once all changes are believed to have been received.
+* **3.4.3** A dispatched `Frame` has its changes copied to persistent state for channels marked with a `persistent` storage type.
+* **3.4.4** `Frame` creation requests use state from most recent dispatch, excluding newly received changes that have not yet dispatched.
+
+#### 3.5 Change Events
+* **3.5.1** Change events occur on any kind of received change.
+* **3.5.2** Change events are dispatched immediately prior to completed `Frame` dispatch for a non-owner.
+* **3.5.3** Change events are dispatched immediately prior to creation of a `Frame` for an owner.
+* **3.5.4** Change events may occur in parallel but will be completed before dispatch or creation.
+* **3.5.5** One change event occurs per changed channel.
+* **3.5.6** `aggregate` channels with multiple changes result in a single event.
+* **3.5.7** `Frame` and channel number are provided to event handler.
+* **3.5.8** The provided `Frame` has all state changes applied, as provided at dispatch or creation.
 
 ### 4. Transmitting Frames