diff --git a/doc/README.rst b/doc/README.rst
deleted file mode 100644
index 5201814..0000000
--- a/doc/README.rst
+++ /dev/null
@@ -1,8 +0,0 @@
-OPENSTACK CONFIG ANALYZER DATA MODEL
-====================================
-
-This document proposes data model which allows to describe any OpenStack
-installation. The model includes data regarding physical infrastructure, logical
-topology of services and mapping between the two.
-
-
diff --git a/doc/architecture_model.rst b/doc/architecture_model.rst
index 4fb19a0..1115d08 100644
--- a/doc/architecture_model.rst
+++ b/doc/architecture_model.rst
@@ -1,6 +1,10 @@
-= Arhitecture Data Model
+=======================
+ARCHITECTURE DATA MODEL
+=======================
 
-== Overview
+--------
+Overview
+--------
 
 Architecture data model produced by Joker could be consumed by configuration
 validator tool (Dark Knight), by architecture graph (Stencil) and others. 
@@ -20,7 +24,9 @@ support contract pricing purposes.
 The model could be used to perform automated/guided hardening of OpenStack
 architecture and configuration.
 
-== Data Format
+-----------
+Data Format
+-----------
 
 This section proposes data model format which allows to describe any OpenStack
 installation. The model includes data regarding physical infrastructure, logical
diff --git a/doc/images/src/mvp0_demo_preparation_plan.txt b/doc/images/src/mvp0_demo_preparation_plan.txt
new file mode 100644
index 0000000..16de79c
--- /dev/null
+++ b/doc/images/src/mvp0_demo_preparation_plan.txt
@@ -0,0 +1,30 @@
+@startuml
+frame "Peter" {
+          [network emulation]
+                cloud {
+                                [demo scenario]
+                                      }
+}
+frame "Sergey" {
+          [network emulation] --> [salt bootstrap]
+                [salt bootstrap] --> [nodes discovery]
+}
+
+frame "Max" {
+          [config files collector]
+                [config-inspector] -up-> [demo scenario]
+}
+frame "Ilya" {
+          [tripleo-image-elements] --> [os-collect-config]
+                [tripleo-heat-templates] --> [os-collect-config]
+}
+frame "Kirill" {
+          [rules editing engine] <-- [config-inspector]
+                [rules editing engine] --> [demo scenario]
+}
+[nodes discovery] --> nodelist
+nodelist --> [config files collector]
+[config files collector] --> JSON
+JSON --> [config-inspector]
+[os-collect-config] --> JSON
+@enduml
diff --git a/doc/openstack_integration.txt b/doc/images/src/openstack_integration.txt
similarity index 100%
rename from doc/openstack_integration.txt
rename to doc/images/src/openstack_integration.txt
diff --git a/doc/openstack_integration.rst b/doc/openstack_integration.rst
index 2198f0f..41c421b 100644
--- a/doc/openstack_integration.rst
+++ b/doc/openstack_integration.rst
@@ -1,6 +1,9 @@
-= VALIDATOR INTEGRATION WITH OPENSTACK
+VALIDATOR INTEGRATION WITH OPENSTACK
+====================================
 
-== Overview
+--------
+Overview
+--------
 
 OpenStack cloud life cycle consists of 2 distinct phases:
 
@@ -9,16 +12,24 @@ OpenStack cloud life cycle consists of 2 distinct phases:
 
 Success of the *initial deployment* stage means that upfront installation and
 configuration of the OpenStack platform is successful. Multiple projects work in
-that area: TripleO+Tuskar, Fuel, Packstack, Devstack to name a few. Most of
-these projects are pretty good in what they are doing, but once you installed
-and kicked off the cloud, things begin to change.
+that area: TripleO+Tuskar, Fuel, Packstack, Devstack to name a few. 
 
-On the other hand, *operation maintenance* phase is more or less abundant of
+Most of these projects are pretty good in what they are doing, but once you
+installed and kicked off the cloud, things begin to change. Cloud enters
+*operation maintenance* phase of its life cycle. 
+
+Changes to configuration, architecture and environment itself could reduce
+overall stability and performance of the platform. Eventually operators faces
+the situation when something goes wrong and service gets disrupted.
+
+That said, *operation maintenance* phase is more or less abundant of
 community-driven projects aimed to increase reliablility of cloud and
 resilience which allows to support the SLA at reasonably high level (think your
 favourite number of nines).
 
-== Proposal Summary
+----------------
+Proposal Summary
+----------------
 
 With this proposal we want to introduce a project aimed to enhance and simplify
 operatinal maintenance of OpenStack cloud. Project provides service which uses
@@ -26,12 +37,18 @@ rule-based engine (```lettuce```) to inspect configurations of OpenStack
 platform and find all kinds of architecture- and configuration-level glitches
 and inconsistencies.
 
-This engine will be eventually used to provide hints and best practices to
-increase reliability and operational resilience of the cloud.
+This engine will provide hints and best practices to increase reliability and
+operational resilience of the cloud.
 
-== Integration Points
+Rules engine
+------------
 
-=== TripleO integration points
+------------------
+Integration Points
+------------------
+
+TripleO integration points
+--------------------------
 
 .. image:: images/openstack_integration.png