diff --git a/docs/user-guide.rst b/docs/user-guide.rst
index 0d7d4e6..bfac885 100644
--- a/docs/user-guide.rst
+++ b/docs/user-guide.rst
@@ -4,31 +4,63 @@
 
 Control loop in CLAMP
 ---------------------
-There is 2 control loop levels in CLAMP:
+There are 2 control loop levels in CLAMP:
 
 - Control loop template: This is created from the DCAE blueprint (designed in the DCAE designer), and distributed by SDC to CLAMP.
 - Control loop instance: Based on the template, it represents a physical control loop in the platform related to a service and a VNF.
-    This is created in CLAMP when receiving the SDC notification, as this one is related to a specific service/vnf.
 
-There is no way to design a control loop from scratch in CLAMP, you can only configure it and manage its life-cycle.
+There is no way to design the microservice components of the control loop from scratch in CLAMP, you can only configure it and manage its life-cycle.
 For more info on how to design the service in SDC, check this: https://wiki.onap.org/display/DW/CLAMP+videos#CLAMPvideos-DesignpartinSDC
 
-There is a specific menu to open distributed control loops in CLAMP UI. 
 
-|clamp-open-menu|
+There is a specific menu to view the available Control loop templates.
 
-Please note that the option "Create CL" can be used to create a control loop from the template distributed by SDC, you can therefore instantiate it for another service/vnf 
+|clamp-template-menu|
 
-Once you click on "Open CL", this dialog box is shown
 
-|clamp-open-box|
+Each microservice policies and operational policies is related to a Policy Model.
+Clamp either communicates with Policy Engine periodically to download the available Policy Models automatically or user can upload the Policy Model manually.
+Policy Models related operations could be found under Policy Models menu.
 
-Once the distributed control loop has been chosen, the control loop is shown to the user.
-From this view user can start configure empty control loop using **Closed loop modeller**.
+|clamp-policy-model-menu|
 
-|clamp-opened-closed-loop|
 
-Closed loop modeler has 3 main parts:
+Under the menu *Loop Instance*, there's a list of actions to perform regarding to the loops.
+
+|clamp-loop-menu|
+
+
+Option *Create* creates the loop from the templates distributed by SDC.
+
+|clamp-create-loop|
+
+
+Option *Open* opens the saved loops. Once the distributed control loop has been chosen, the control loop is shown to the user.
+
+|clamp-open-loop|
+
+
+Option *Close* will close the current opened loop.
+
+
+Option *Modify* opens the window to add/remove different Operational Policies to the loop.
+Tab *Add Operational Policies* lists all the available operational policies.
+Click *Add* button to add the selected operational policies to the loop.
+
+|clamp-add-operational-policies|
+
+Tab *Remove Operational Policies* lists all the operational policies added to the loop.
+Click *Remove* button to remove the selected operational policies from the loop.
+
+|clamp-remove-operational-policies|
+
+
+Once opened, the user can start configure empty control loop using **Closed loop modeller**.
+
+|clamp-opened-loop|
+
+
+Loop modeler has 3 main parts:
 
 #. Loop configuration view
     Visualizes event flow in Control Loop. This view is auto-generated by Clamp. To generate it Clamp parses DCAE_INVENTORY_BLUEPRINT from CSAR distributed by SDC.
@@ -40,133 +72,82 @@
 #. Loop logs
     Table with log data of opened loop
 
+
 Control Loop properties
 -----------------------
 In Dublin release this view shows what are deployment parameters or control Loop.
-To open it from *Closed Loop* menu select *Properties CL*
+To open it from *Loop Instance* menu select *Properties*
 
 |clamp-menu-prop|
 
 This opens a box with JSON object. It contains deployment parameters extracted from DCAE_INVENTORY_BLUEPRINT.
 It's not recommended to edit this JSON. Each of this parameters should be available in view shown to deploy analytic application.
 
-
 |clamp-prop-box|
 
-Operational and Guard policy properties
+
+Operational policy properties
 ---------------------------------------
-Operational policy is a parametrized drools (in Dublin) rule with logic performing action on resource.
-User can't chose his own rule. Clamp always tries to create operational policy that bases on rule bind with **ClosedLoopControlName** attribute available in Policy dictionary.
+Operational policies are added by the user using *Modify* window. The configuration view is generated using Policy Type assigned to selected operational policy.
 
-There is only one operational policy per control loop. More about operational policies can be found here `Control Loop Operational Policy <https://wiki.onap.org/display/DW/Control+Loop+Operational+Policy>`_.
+To configure operational policies, user has to click the corresponding operational policy boxes. Example popup dialog for operational policy looks like:
 
-Guard policy is policy securing operational policy calls. It defines a set of constraints that have to be matched before running operational policy.
-More about guard policies can be found here `Creating and Using Guard Policies <https://docs.onap.org/en/dublin/submodules/policy/engine.git/docs/platform/guardpolicy.html>`_.
+|clamp-op-policy-box-policy|
 
-To configure operational and guard policy user has to click *OperationalPolicy* box.
-
-Once clicked, it's possible to configure operational policy. Policy can have child policies, one per Recipe.
-
-|clamp-op-policy-box-policy1|
-
-1. Parent policy name
-2. Global time limit for this operational policies
-3. Specifies whether policy is abated
-4. Unique id for Control Loop.
-5. Button for creating child/parent policies
-    Child/parent policies are policies that depend on one another under certain circumstances (check point 12.)
-6. Unique id of Policy. (Clamp internal)
-7. Recipe/Operation triggered on controller/orchestrator
-    This recipe will be used by policy drools PDP when sending request to controller/orchestrator.
-    E.g. in case of *Health-Check* is selected here and *APPC* as actor PDP will trigger APPC LCM API triggering health-check operation.
-
-    List of options is predefined in Clamp code and can't be modified.
-    Possible options:
-        * Restart
-        * Rebuild
-        * Migrate
-        * Health-Check
-        * ModifyConfig
-        * VF Module Create
-        * VF Module Delete
-        * Reroute
-8. Maximum amount of retries that policy takes when triggering action
-9. Timeout for this operational policy
-10. Actor used to perform action. (Orchestrator/Controller)
-     Actor that will be used by drools PDP to perform action.
-     Possible options:
-        * APPC
-        * SO
-        * VFC
-        * SDNC
-        * SDNR
-11. Payload required by actor to perform an action
-12. Set of fields describing child/parend policies dependency.
-     E.g. when health-check receives timeout failure restart could be called.
-13. Set of fields specifying resource. On this resource Operational Policy should perform an action
-14. Checkbox enabling/disabling guard policy for this operational policy
-15. Guard Policy type (frequency limited or min max)
-16. Set of guard policy specific fields. Please check `Creating and Using Guard Policies <https://docs.onap.org/en/dublin/submodules/policy/engine.git/docs/platform/guardpolicy.html>`_.
 
 
 Micro-service policy properties
 -------------------------------
-Boxes between `VES` and `OperationalPolicy` are generated from blueprint. They can be one of ONAP predefined analytic microservices or custom analytics.
+Boxes between `VES` and `Operational Policies` are generated from blueprint. They can be one of ONAP predefined analytic microservices or custom analytics.
 Each of the boxes is clickable. Microservice configuration view is generated using Policy Type assigned to selected microservice.
 Clamp by default assumes that microservices have policy type **onap.policies.monitoring.cdap.tca.hi.lo.app**.
 
 After clicking microservice box Clamp opens popup dialog. Example popup dialog for microservice with default type looks like:
 
-|clamp-config-policy-tca1|
-
-|clamp-config-policy-tca2|
+|clamp-config-policy-tca|
 
 
-Saving Control loop
--------------------
-Policies are saved localy in Clamp after each configuration change
+
+In the *Loop Operations* menu, lists the operations to be perform to the loop.
+
+|clamp-loop-operation-menu|
 
 
 Submitting the Control loop to policy
 -------------------------------------
-In the "Manage Menu", the submit action can be used to send the configuration to policy engine.
+The SUBMIT operation can be used to send the configuration to policy engine.
+If everything is successful, the status to the policy will become *SENT*. Clamp should also show proper logs in logs view.
 
-
-|clamp-submit-cl|
-
-If everything is successful, this changes the status to "Submitted". Clamp should also show proper logs in logs view.
-
-|clamp-distributed|
+|clamp-policy-submitted|
 
 After Policies are submitted they should be visible in Policy PAP component.
 Please check  `Policy GUI <https://docs.onap.org/en/dublin/submodules/policy/engine.git/docs/platform/policygui.html>`_
 
-Deploy/undeploy the Control Loop to DCAE 
------------------------------------------
-Once sent to policy engine, Clamp can ask to DCAE to deploy the micro service
 
-|clamp-deploy|
+Deploy/undeploy the Control Loop to DCAE
+-----------------------------------------
+Once sent to policy engine, Clamp can ask to DCAE to DEPLOY the micro service
 
 This opens a window where the parameters of the DCAE micro service can be configured/tuned.
 The policy_id is automatically generated by Clamp in the previous steps.
 
 |clamp-deploy-params|
 
-Once deployed on DCAE the status Control loop status goes to ACTIVE, it can then be Undeployed/Stopped or even Updated (this is to push new policies on policy engine)
+Once deployed on DCAE the status of DCAE goes to *MICROSERVICE_INSTALLED_SUCCESSFULLY*, it can then be Undeployed/Stopped/Restart.
 
-|clamp-undeploy|
-
-.. |clamp-open-menu| image:: images/user-guide/open-menu.png
-.. |clamp-open-box| image:: images/user-guide/open-box.png
-.. |clamp-opened-closed-loop| image:: images/user-guide/opened-closed-loop.png
+.. |clamp-template-menu| image:: images/user-guide/template-menu.png
+.. |clamp-policy-model-menu| image:: images/user-guide/policy-model-menu.png
+.. |clamp-loop-menu| image:: images/user-guide/loop-menu.png
+.. |clamp-create-loop| image:: images/user-guide/create-loop.png
+.. |clamp-open-loop| image:: images/user-guide/open-loop.png
+.. |clamp-add-operational-policies| image:: images/user-guide/add-operational-policies.png
+.. |clamp-remove-operational-policies| image:: images/user-guide/remove-operational-policies.png
+.. |clamp-opened-loop| image:: images/user-guide/opened-loop.png
 .. |clamp-menu-prop| image:: images/user-guide/open-menu-prop.png
-.. |clamp-prop-box| image:: images/user-guide/prop-box.png
-.. |clamp-op-policy-box-policy1| image:: images/user-guide/op-policy-box-policy1.png
-.. |clamp-config-policy-tca1| image:: images/user-guide/config-policy-tca1.png
-.. |clamp-config-policy-tca2| image:: images/user-guide/config-policy-tca2.png
-.. |clamp-submit-cl| image:: images/user-guide/submit-menu.png
-.. |clamp-distributed| image:: images/user-guide/distributed.png
-.. |clamp-deploy| image:: images/user-guide/deploy.png
+.. |clamp-prop-box| image:: images/user-guide/loop-properties.png
+.. |clamp-op-policy-box-policy| image:: images/user-guide/op-policy-box-policy.png
+.. |clamp-config-policy-tca| image:: images/user-guide/config-policy-tca.png
+.. |clamp-loop-operation-menu| image:: images/user-guide/loop-operation-menu.png
+.. |clamp-policy-submitted| image:: images/user-guide/policy-submitted.png
 .. |clamp-deploy-params| image:: images/user-guide/deploy-params.png
-.. |clamp-undeploy| image:: images/user-guide/undeploy.png
-.. |blueprint-node| image:: images/user-guide/blueprint_node_type.png
\ No newline at end of file
+.. |blueprint-node| image:: images/user-guide/blueprint_node_type.png