   By eliminating the need for an Om parser to process all of this and centralizing the logic to a core set of functions
   that handle all of these concerns you gain a lot of simplicity.
 
-  So, let's look how we handle the explicit use-cases:
-
-  ### Use case - Initial load
-
-  In Om, you'd write a parser, set some initial state indicating 'I need to load this', and in your parser you'd return
+  ### Differences in Initial load
+
+  In Om you'd write a parser, set some initial state indicating 'I need to load this', and in your parser you'd return
   a remote `true` for that portion of the read when you hit it. The intention would then be that the server returning
   data would overwrite that marker and the resulting re-render would update the UI. If your UI query doesn't match what
   your server wants to hear, then you either write multiple UI-handling bits on the server, or you pre/post process the
   ROOT-centric query in your send function. Basically, you write a lot of plumbing. Server error handling is completely
   up to you in your send method.
 
-  In Untangled, initial load is an explicit step. You simply put calls to `load-data` in your app start callback.
-  State markers are put in place that allow you to then render the fact that you are loading data. Any number of separate
-  server queries can be queued, and the queries themselves are used for normalization. Post-processing of the response
-  is well-defined and trivial to access.
-
-  ```
-  (uc/new-untangled-client
-    :initial-state {}
-    :started-callback
-      (fn [app]
-        (df/load-data :query [{:items (om/get-query CollectionComponent)}]
-                                     :without #{:comments}
-                                     :post-mutation 'app/build-views)))
-  ```
-
-  In the above example the client is created (which must be mounted as a separate step). Once mounted the application
-  will call the `:started-callback` which in turn will trigger a load. This helper function is really a call to
-  om `transact!` that places `ready-to-load` markers in the app state, which in turn triggers the network plumbing. The
-  network plumbing pulls these and processes them via the server and all of the normalization bits of Om (and Untangled).
-
-  The `:without` parameter will elide portions of the query. So for example, if you'd like to lazy load some portion of the
-  collection (e.g. comments on each item) at a later time, you can prevent the server from being asked.
-
-  The `:post-mutation` parameter is the name of the mutation you'd like to run on a successful result of the query. If there
-  is a failure, then a failure marker will be placed in the app state, which you can have programmed your UI to react to
-  (e.g. showing a dialog that has user-driven recovery choices).
-
-
-  ### Global network activity marker
-
-  Untangled will automatically maintain a global network activity marker at the top level of the app state under the
-  keyword `:ui/loading-data`. This key will have a `true` value when there are network requests awaiting a response from
-  the server, and will have a `false` value when there are no network requests in process.
-
-  You can access this marker from any component that composes to root by including a link in your component's query:
-
-  ```
-  (defui Item ... )
-  (def ui-item (om/factory Item {:keyfn :id}))
-
-  (defui List
-    static om/IQuery (query [this] [:id :title {:items (om/get-query Item)} [:ui/loading-data '_]]
-    ...
-    (render [this]
-      (let [{:keys [title items ui/loading-data]} (om/props this)]
-        (if (and loading-data (empty? items))
-          (dom/div nil \"Loading...\")
-          (dom/div nil
-            (dom/h1 nil title)
-            (map ui-item items))))
-  ```
-  Because the global loading marker is at the top level of the application state, do not use the keyword as a follow-on
-  read to mutations because it may unnecessarily trigger a re-render of the entire application.
+  In Untangled, initial load is an explicit step. You simply put calls to `load` in your app start callback.
+
 ")

  from your server when the app initially loads, you must use `load-data` with the reconciler passed to the
  `:started-callback` function when creating a new untangled client application.

  #### Use case - Lazy loading

  One common operation is to load data in response to a user interaction. Interestingly, the query that you might
  have used in the initial load use case might have included UI queries for data you didn't want to fetch yet. So, we want

  the code to use the action-suffixed load instead. To learn more about the dangers of loads and lifecycle methods, see
  the [reference on loading data]().

  ### Using the `untangled/load` Mutation Directly

  The helper functions described above simply trigger a built-in Untangled mutation called `untangled/load`, which you are
  allowed (and sometimes encouraged) to use directly. The arguments to this mutation include:

  - `query`: The specific query you'd like to send to the server
  - `post-mutation`: A symbol indicating a mutation to run after the load completes
  - `post-mutation-params` - An optional map  that will be passed to the post-mutation when it is called. May only contain raw data, not code!
  - `without`: A set of keywords that should be (recursively) removed from `query`
  - `refresh`: A vector of keywords that should cause re-rendering after the load.
  - `parallel`: True or false. If true, bypasses the sequential network queue
