diff --git a/README.md b/README.md
index dd04b16..604c83f 100644
--- a/README.md
+++ b/README.md
@@ -11,7 +11,7 @@
 [Apigee Setup Ansible](https://github.com/carlosfrias/apigee-opdk-playbook-setup-ansible) project for details. 
 * Install Apigee OPDK ansible roles.
 * Update ~/.apigee/credentials.yml.
-* Update your inventory file.
+* Update your inventory file [Updating your Inventory File](https://github.com/carlosfrias/apigee-opdk-playbook-setup-ansible/inventory.md).
 * Update your ansible configuration file with your inventory file or folder name, the remote-user and ssh private_key_file.
 
 Functionality Available
@@ -96,78 +96,4 @@
 You can dispose of the VM to recover disk space with:
 
     vagrant destroy -f
- 
-Updating your inventory file
-============================
-
-We use a standard Ansible inventory file with some semantic conventions applied to it. The semantic model applied to the 
-Ansible inventory file is described in the following sections.
- 
-## Ansible Inventory Files
-Ansible provides rich semantics for inventory files. We leverage the ansible model by applying a semantic convention 
-that is based on the Apigee Private Cloud domain model for referencing server nodes as collections of planets and 
-regions. This means that the normal Ansible inventory files are used as is with the exception of the semantic conventions
-for inventory group names. 
-
-## Inventory File Conventions
-These roles depend on use of conventions in the inventory file. Specifically inventory file conventions are ansible 
-groups names that are defined around Apigee semantics. These ansible groups are semantically linked to the documentation. 
-The ansible groups used as conventions correspond to the installation roles and server categorizations called out in 
-the Apigee Private Cloud Installation and Configuration Guide. It has been useful to use planet and region designations 
-combined with the documented installation role names to create categorization semantics that should be fairly intuitive 
-once you read the Apigee Private Cloud Installation and Configuration Guide. 
-   
-## Inventory Planet, Region and Installation Role Conventions
-A planet refers to all server nodes across all data centers. These semantics are held via the use of group names for  
-all nodes that fulfill a specific purpose. The installation roles provide the semantic model we followed. The inventory 
-file group names for planet level semantics are listed in the template inventory file below. 
-
-A region represents subset of a planet. The semantics used for installation roles are congruent with a region. Region 
-have been referenced as data centers. The internal configurations of OPDK and BaaS support many regions as dc-1, dc-2 
-and so forth. Following this historical precedent we also define the regions with their corresponding installation role
-to provide a semantic model as follows:
- 
-    # Listing that references all data centers that compose a planet. 
-    [planet]
-    dc-1
-
-    [dc-1]
-    # Listing of all nodes in data center 1 (dc-1)
-    
-    [ds:children]
-    # Listing of all the Cassandra and Zookeeper nodes across the planet
-    dc-1-ds
-    
-    [dc-1-ds]
-    # Listing of all the Cassandra and Zookeeper nodes in dc-1
-    
-    [dc-1-ms]
-    # Listing of all the Management Server nodes in dc-1
-     
-    [dc-1-ldap]
-    # Listing of all OpenLDAP nodes in dc-1
-    
-    [dc-1-rmp]
-    # Listing of all Router and Message Processor nodes in dc-1
-    
-    [dc-1-qpid]
-    # Listing of all Qpid nodes in dc-1
-    
-    [dc-1-pg]
-    # Listing of all Postgres nodes in dc-1
-    
-    [dc-1-pgmaster]
-    # Listing of the single Postgres master node in dc-1
-    
-    [dc-1-pgstandby]
-    # Listing of the single Postgres standby node in dc-1
-    
-    [dc-1-ui]
-    # Listing of the UI node in dc-1
-    
-## Zookeeper Observer Nodes
-Zookeeper nodes can be designated as an observer node. Ansible inventory files allow variables to be assigned to servers.
-These roles will update the silent installation configuration file correctly for any zookeeper node that is assigned the 
- variable zk_observer.
-  
-     zk_observer=true
+ 
\ No newline at end of file
diff --git a/inventory.md b/inventory.md
new file mode 100644
index 0000000..2ffce66
--- /dev/null
+++ b/inventory.md
@@ -0,0 +1,86 @@
+Updating your inventory file
+============================
+
+We use a standard Ansible inventory file with some semantic conventions 
+applied to Ansible groups. The semantic model applied to the Ansible 
+inventory file is described in the following sections.
+ 
+## Ansible Inventory Files
+Ansible provides rich semantics for inventory files. We leverage the 
+ansible model by applying a semantic convention that is based on the 
+Apigee Private Cloud domain model for referencing server nodes as 
+collections of planets and regions. This means that the normal Ansible 
+inventory files are used as is with the exception of the semantic 
+conventions for inventory group names. 
+
+## Inventory File Conventions
+These roles depend on use of conventions in the inventory file. 
+Specifically inventory file conventions are ansible groups names that 
+are defined around Apigee semantics. These ansible groups are 
+semantically linked to the documentation. The ansible groups used as 
+conventions correspond to the installation roles and server 
+categorizations called out in the Apigee Private Cloud Installation and 
+Configuration Guide. It has been useful to use planet and region 
+designations combined with the documented installation role names to 
+create categorization semantics that should be fairly intuitive once you 
+read the Apigee Private Cloud Installation and Configuration Guide. 
+   
+## Inventory Planet, Region and Installation Role Conventions
+A planet refers to all server nodes across all data centers. These 
+semantics are held via the use of group names for all nodes that fulfill 
+a specific purpose. The installation roles provide the semantic model we 
+followed. The inventory file group names for planet level semantics are 
+listed in the template inventory file below. 
+
+A region represents subset of a planet. The semantics used for 
+installation roles are congruent with a region. Region have been 
+referenced as data centers. The internal configurations of OPDK and BaaS 
+support many regions as dc-1, dc-2 and so forth. Following this 
+historical precedent we also define the regions with their corresponding 
+installation role to provide a semantic model as follows:
+ 
+    # Listing that references all data centers that compose a planet. 
+    [planet]
+    dc-1
+
+    [dc-1]
+    # Listing of all nodes in data center 1 (dc-1)
+    
+    [ds:children]
+    # Listing of all the Cassandra and Zookeeper nodes across the planet
+    dc-1-ds
+    
+    [dc-1-ds]
+    # Listing of all the Cassandra and Zookeeper nodes in dc-1
+    
+    [dc-1-ms]
+    # Listing of all the Management Server nodes in dc-1
+     
+    [dc-1-ldap]
+    # Listing of all OpenLDAP nodes in dc-1
+    
+    [dc-1-rmp]
+    # Listing of all Router and Message Processor nodes in dc-1
+    
+    [dc-1-qpid]
+    # Listing of all Qpid nodes in dc-1
+    
+    [dc-1-pg]
+    # Listing of all Postgres nodes in dc-1
+    
+    [dc-1-pgmaster]
+    # Listing of the single Postgres master node in dc-1
+    
+    [dc-1-pgstandby]
+    # Listing of the single Postgres standby node in dc-1
+    
+    [dc-1-ui]
+    # Listing of the UI node in dc-1
+    
+## Zookeeper Observer Nodes
+Zookeeper nodes can be designated as an observer node. Ansible inventory 
+files allow variables to be assigned to servers. These roles will update 
+the silent installation configuration file correctly for any zookeeper 
+node that is assigned the variable zk_observer.
+  
+     zk_observer=true