Resolve "MQ Topic Structure with operator appointed name"

Closes #14 (closed)

README.md

 
 For published messages, the message is published for a given a topic. 
 
-Clients create a subscription to a topic pattern which may include wildcards. 
+Clients create a subscription (stored in their config) to a topic pattern which may include wildcards. 
+It's important to note that the client config documents the subscription. To change a client 
+subscription it must be updated with the backbone.
 
-Messages with a topic matching a client's subscription pattern are delivered to that client.
+Published messages are delivered to all clients where 
+the message topic matches the client's subscription 
+topic pattern.
 
-Broadcast messages are delivered to all clients regardless of their subscription.
+Broadcast messages are delivered to all clients regardless of their subscription. 
 
 ### Field
 
 The topic should be set in the `message.header.destination` for published messages. 
-The desintation field should be set to `broadcast` for any messages sent using broadcast. 
+The `destination` field should be set to `broadcast` for any messages sent using broadcast. 
+
+Because the `destination` field is a topic it defines what the message relates to - not 
+who the intended recipient is. 
 
 ### Structure
 
 
 ### Terms
 
-The `header.destination` field contains the topic that messages will be published to.
-
-This is not the intended recipient of those messages.
-
-The autonomy engine/frontend/c2s are not represented in the topic.
-
-The topic describes what the message relates to.
-
-The client `subscription` will define which clients receive a message.
-
 * `prefix` - an agreed hard-coded/config setting prefix shared by all adapters and client subscriptions eg soar 
 * `operator` - human readable organisation name for the platform operator one of [noc|planet-ocean|hydrosurv] 
 * `platform_type` - one of [autosub|ecosub|reav?]
 * `platform_identifier` - human readable identifier for the platform eg ah1, eco1, reav1 
-* `to_platform|from_platform` -  eg ..to_platform.mission_plan, ..from_platform.platform_status
+* `to_platform|from_platform` - eg ..to_platform.mission_plan, ..from_platform.platform_status
+missions are sent `to_platform` to be executed and status updates are received `from_platform` containing 
+information about its position and health status
 * `message_type` - one of `[acknowledgement|mission_plan|observation|planning_configuration|platform_status...]`
 
 ### Subscriptions