diff --git a/documentation/operator-guide/initialization.rst b/documentation/operator-guide/initialization.rst
index ad81c5a0f20614a49aa42ce634954e58578722be..532cc2fcdf34fa1d252b8f5789808ca5b0f04c7e 100644
--- a/documentation/operator-guide/initialization.rst
+++ b/documentation/operator-guide/initialization.rst
@@ -3,39 +3,42 @@
 Initialization
 ==============
 
-In order to set up an instance of VS, the ``pvs_starter`` utility is
-recommended. It is distributed as a Python package, easily installed via
-``pip``.
+In order to set up an instance of the View Server (VS), the separate
+``pvs_starter`` utility is recommended.
+
+Running the Initialization
+--------------------------
+
+The ``pvs_starter`` utility is distributed as a Python package and easily
+installed via ``pip``.
 
 .. code-block:: bash
 
     pip3 install pvs_starter # TODO: git url
 
-
-Now the VS instance can be set up like this:
+Now a new VS instance can be set up like this:
 
 .. code-block:: bash
 
     python3 -m pvs_starter.cli config.yaml out/ -f
 
 This takes the initialization configuration ``config.yaml`` to generate
-the structure in the ``out/`` directory.
-
+the required structure of a new VS instance in the ``out/`` directory.
 
-Initialization config
----------------------
+Configuration of the Initialization
+-----------------------------------
 
-The important part of the initialization is the configuration. The format is
-structured in YAML and will be detailed here. It contains the following
+The important part of the initialization is the configuration. The file is
+structured in YAML as detailed below. It contains the following
 sections:
 
 ``database``
 ~~~~~~~~~~~~
 
-Here, access credentials of the database are stored. It defines the
-internal database name, user and password that will be created when the stack
+Here, access details and credentials of the database are stored. It defines the
+internal database name, user, and password that will be created when the stack
 is deployed. Note that there is no ``host`` setting, as this will be handled
-automatically.
+automatically within the Docker Swarm.
 
 .. code-block:: yaml
 
@@ -130,7 +133,7 @@ and ``mask`` types are to be generated.
 ~~~~~~~~~~~~~~~
 
 In the ``collections`` section, the collections are set up and it is defined
-which products of based on ``product_type`` and ``product_level`` will be inserted into them. The
+which products based on ``product_type`` and ``product_level`` will be inserted into them. The
 ``product_types`` must list types defined in the ``products`` section.
 
 .. code-block:: yaml
@@ -147,7 +150,7 @@ which products of based on ``product_type`` and ``product_level`` will be insert
 ~~~~~~~~~~~~
 
 Here, the three relevant storages can be configured: the ``source``,
-``preprocessed`` and ``cache`` storages.
+``preprocessed``, and ``cache`` storages.
 
 The ``source`` storage defines the location from which the original files will be
 downloaded to be preprocessed. Preprocessed images and metadata will then be
@@ -271,6 +274,6 @@ This section defines the exposed services, and how the layers shall be cached in
           title: VHR Image 2018 Level 3 NDVI
           abstract: VHR Image 2018 Level 3 NDVI
           style: earth
-          # grids? cache options?
+          # TODO grids? cache options?