Design/Frames.md

@@ -59,16 +59,24 @@ Data is synchronised and organised into discrete frames that are represented by
 
 ### 3. Receiving Frames
 #### 3.1 General Rules
-* **3.1.1** Receive state storage for `persistent` data is separate from send state.
+* **3.1.1** Non-owner receive state storage for `persistent` data is separate and different from send state as maintained by owners.
+* **3.1.2** One instance of `Feed` *owns* a given `Frame` id, including across a network.
 
-#### 3.2 Receiving Protocol
-* **3.2.1** Received changes accumulate into a waiting `Frame` with correct timestamp.
+#### 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.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.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.6** A dispatched `Frame` is marked as `flushed`.
-* **3.2.7** A dispatched and `flushed` `Frame` has its changes copied to persistent receive state for channels marked with a `persistent` storage type.
+* **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)