diff --git a/docs/dev/synchronizers.md b/docs/dev/synchronizers.md
index b75e4c5..100b5cd 100644
--- a/docs/dev/synchronizers.md
+++ b/docs/dev/synchronizers.md
@@ -18,25 +18,31 @@
 
 ## Overview of the synchronizer framework APIs
 
-This section is intended to be a reference for the commonly used APIs exposed by the synchronizer framework.
+This section is intended to be a reference for the commonly used APIs exposed
+by the synchronizer framework.
 
 ### Model Policies
 
-Model Policies can be seen as `post-save` hooks and they are generally defined in the `xos/synchronizer/model_policies` folder of your service.
+Model Policies can be seen as `post-save` hooks and they are generally defined
+in the `xos/synchronizer/model_policies` folder of your service.
 
-Model policies are generally used to dynamically create a service chain (when a ServiceInstance is created it will create a ServiceInstance of its east side Service)
+Model policies are generally used to dynamically create a service chain (when a
+ServiceInstance is created it will create a ServiceInstance of its east side
+Service)
 
-> Note that you'll need to add this folder in your synchronizer configuration file as 
->```yaml
+> NOTE: You'll need to add this folder in your synchronizer configuration file
+> as:
+>
+> ```yaml
 > model_policies_dir: "/opt/xos/synchronizers/<synchronizer_name>/model_policies"
->```
+> ```
 
-A model policy is a class that inherits from `Policy`
+A model policy is a class that inherits from `Policy`:
 
 ```python
 from synchronizers.new_base.modelaccessor import MyServiceInstance, ServiceInstanceLink, model_accessor
 from synchronizers.new_base.policy import Policy
- 
+
 class MyServiceInstancePolicy(Policy):
     model_name = "MyServiceInstance"
 ```
@@ -54,19 +60,22 @@
 ```python
 def handle_delete(self, model):
 ```
-> where model is the instance of the model that has been created
+
+Where `model` is the instance of the model that has been created.
 
 ### Sync Steps
 
-Sync Steps are the actual piece of code that provide the mapping between your models and your backend. 
-You will need to define a sync step for each model.
+Sync Steps are the actual piece of code that provide the mapping between your
+models and your backend.  You will need to define a sync step for each model.
 
-> Note that you'll need to add this folder in your synchronizer configuration file as 
->```yaml
+> NOTE: You'll need to add this folder in your synchronizer configuration file
+> as:
+>
+> ```yaml
 > steps_dir: "/opt/xos/synchronizers/<synchronizer_name>/steps"
->```
+> ```
 
-A Sync Step is a class that inherits from `SyncStep`
+A Sync Step is a class that inherits from `SyncStep`:
 
 ```python
 
@@ -75,9 +84,9 @@
 
 from xosconfig import Config
 from multistructlog import create_logger
- 
+
 log = create_logger(Config().get('logging'))
- 
+
 class SyncMyModel(SyncStep):
     provides = [MyModel]
 
@@ -85,6 +94,7 @@
 ```
 
 and provides these methods:
+
 ```python
 def sync_record(self, o):
     log.info("sync'ing object", object=str(o), **o.tologdict())
@@ -95,19 +105,22 @@
     log.info("deleting object", object=str(o), **o.tologdict())
 ```
 
-This methods will be invoked anytime there is change in the model passing as argument the changed models.
-After performing the required operations to sync the model state with the backend state the synchronizer 
-framework will update the models with the operational informations needed.
+This methods will be invoked anytime there is change in the model passing as
+argument the changed models.  After performing the required operations to sync
+the model state with the backend state the synchronizer framework will update
+the models with the operational informations needed.
 
 ### Pull Steps
 
-Pull Steps can be used to observe the surrounding environment and update the data-model
-accordingly.
+Pull Steps can be used to observe the surrounding environment and update the
+data-model accordingly.
 
-> Note that you'll need to add this folder in your synchronizer configuration file as 
->```yaml
+> NOTE:  You'll need to add this folder in your synchronizer configuration file
+> as:
+>
+> ```yaml
 > pull_steps_dir: "/opt/xos/synchronizers/<synchronizer_name>/pull_steps"
->```
+> ```
 
 A Sync Step is a class that inherits from `PullStep`
 
@@ -139,4 +152,4 @@
     o.foo = 'bar'
     o.no_sync = True # this is required to prevent the synchronizer to be invoked and start a loop
     o.save()
-```
\ No newline at end of file
+```
diff --git a/docs/tutorials/local_synchronizer_dev_loop.md b/docs/tutorials/local_synchronizer_dev_loop.md
index 31ae872..08a08ca 100644
--- a/docs/tutorials/local_synchronizer_dev_loop.md
+++ b/docs/tutorials/local_synchronizer_dev_loop.md
@@ -6,7 +6,7 @@
 as long as:
 
 * The VNF independently executes somewhere that you can connect to
-from your local machine.
+  from your local machine.
 * The VNF does not require OpenStack be deployed as part of the POD.
 
 > Note: The following assumes: (1) you have a local scenario up and