diff --git a/Design:-Runtime-Editor-Split.md b/Design:-Runtime-Editor-Split.md
index 2661bad..9ae5ceb 100644
--- a/Design:-Runtime-Editor-Split.md
+++ b/Design:-Runtime-Editor-Split.md
@@ -24,59 +24,97 @@ The plan is to break them up into their own discrete packages to provide some mo
## Use Cases
### Headless
-
+
A device that runs a flow it is given. The flow is edited elsewhere and remotely pushed to the device (or hardcoded on the device).
- don't want the overhead of the editor that isn't going to be used
- supports http endpoints (just doesn't have full editor capability)
+
+
### Multi-user, single-tenet runtimes
+
- A single hosted instance of the editor is backed by multiple runtimes - one per user or group of users
- The user access the editor and the underlying api requests are proxied to the appropriate runtime
- Authentication is handled at the proxy layer
- API requests can be proxied unmodified (other than auth tokens)
+
+
### Multi-user, multi-tenet runtimes
+
- A single hosted instance of the editor is backed by multiple runtimes.
- The user access the editor and the underlying api requests are proxied to the appropriate runtime.
- Each runtime may host flows of different users that should not see each other
- The proxy layer provides a filtered view of the flow to ensure the editor only displays information available to the logged in user.
-### Scaled
+
+### Scaled
+
A node-red flow is edited in one place. When deployed, it gets sent to multiple runtimes to provide horizontal scaling.
- Custom actions are added behind the deploy action
- Serves up the editor without a local version of the runtime
-### Distributed
+
+### Distributed
+
A node-red flow is edited in one place. When deployed, it gets carved up and different parts are pushed to different runtimes, either local or remote.
- Custom actions are added behind the deploy action
- Serves up the editor without a local version of the runtime
-
+
### Repurposed Editor
-
+
The Node-RED editor is used for another system entirely that shares the same node/wire visualisation.
+
+
+---
## Packaging
At the top level, we'll have N npm packages (names tbc)
- - `node-red-core-runtime` - the core runtime of Node-RED
- - `node-red-core-nodes` - the default set of nodes in the palette
- - `node-red-core-editor` - the editor component
+ - `@node-red/runtime` - the core runtime of Node-RED
+ - `@node-red/core-nodes` - the default set of nodes in the palette
+ - `@node-red/editor` - the editor component
- `node-red` - the existing package that pulls the above packages together and delivers *exactly* the same experience as it does today
-### node-red-core-runtime
+### @node-red/runtime
-### node-red-core-nodes
+### @node-red/core-nodes
-### node-red-core-editor
+Moving the core nodes into their own repository poses some challenges in how they get loaded.
+
+#### Current core node load mechanism
+
+1. In the current code, the runtime starts at the path identified by `settings.coreNodesDir` and scans for js/html file pairs. `coreNodesDir` defaults to the `nodes` directory of the node-red module. It also walks up the tree from this directory looking for `node_modules` directories to scan.
+
+2. The scan of the core nodes happens before the scan for node modules - so the core nodes are guaranteed to appear first in the palette.
+
+3. The files are loaded as part of the `node-red` module namespace and there are various hardcoded shortcuts taken with the `node-red` namespace.
+
+4. A single message catalog is registered that covers all core nodes - rather than one-per node-set as is the requirement for nodes loaded from modules.
+
+#### Changes needed
+
+1. have a mechanism to prioritise loading of `@node-red/core-nodes` to ensure node ordering
+2. handle the migration case where `node-red` disappears from the list of nodes - if the auto-reinstall option is enabled (such as in IBM Cloud), we really don't want this to trigger a re-install as we know the nodes are being provided elsewhere
+3. Either:
+ 1. split up the message catalog to match the current file name scheme required of modules
+ 2. allow a node module to declare a single message catalog that is loaded for all nodes in the module
+4. Many nodes expect their message catalog namespace to be `node-red`. Need to either handle this as a special case, or update all the nodes to the correct catalog. Even then, there are 3rd party nodes that will be using `node-red:common.*` messages that must not change.
+
+
+
+
+
+### @node-red/editor
### node-red