diff --git a/sources/02_user_guide/02_execute/04_plugin.rst.txt b/sources/02_user_guide/02_execute/04_plugin.rst.txt
index 60ccc954..68d4888e 100644
--- a/sources/02_user_guide/02_execute/04_plugin.rst.txt
+++ b/sources/02_user_guide/02_execute/04_plugin.rst.txt
@@ -3,7 +3,7 @@
 Extending a QPU (by using Plugins)
 ==================================
 The QAT (for *Qaptiva Application Toolset*) library defines a concept, named **Plugin**, designed to extend the capabilities of a
-:ref:`QPU <qpu>`. In this framework, QPUs can execute jobs to return a result. This simple behavior reaches its limits when manipulating
+:ref:`QPU <qpu>`. In this framework, QPUs can execute jobs to return a result. This simple behaviour reaches its limits when manipulating
 advanced jobs, using a QPU not capable of executing the job (e.g. limited qubits connectivity, limited gate set, etc.)
 
 .. card:: Use case
@@ -18,15 +18,15 @@ advanced jobs, using a QPU not capable of executing the job (e.g. limited qubits
 
      - compile any incoming job
      - execute variational jobs (e.g. my QPU will use scipy to find the optimal value for any abstract variable)
-     - support observable measurement (e.g. incomming jobs will be decomposed into a list of sample jobs, and by post-processing
-       their result, my QPu will return an averable value)
+     - support observable measurement (e.g. incoming jobs will be decomposed into a list of sampler jobs, and by post-processing
+       their result, my QPU will return an observable value)
 
 **Plugins** are objects that can process a flow of quantum jobs on their way to a **QPU**, and/or process a flow of information (samples or values) on their way back from a **QPU**.
 
 Their API is composed of two methods:
 
-    * **compile** for the way in (i.e from the user to the **QPU**).
-      This method will take a :class:`~qat.core.Batch` together with some
+    * **compile** for the way in (i.e. from the user to the **QPU**).
+      This method will take a:class:`~qat.core.Batch` together with some
       :class:`~qat.core.HardwareSpecs` and return a new
       :class:`~qat.core.Batch`.
     * **post_process** for the way out (i.e from the **QPU** to the user).
@@ -52,7 +52,7 @@ Overall the information flow can be summed up as follows:
 
 |
 
-**Plugins** can be used to perform a wide range of transformation, our library provides a set of plugins defined in :mod:`qat.plugins`
+**Plugins** can be used to perform a wide range of transformations, our library provides a set of plugins defined in :mod:`qat.plugins`
 module but one can define its own plugin 
 
 .. _remote_plugin:
@@ -111,14 +111,14 @@ module but one can define its own plugin
 
             .. warning::
 
-                The connection is synchronous, therefore, if the client is disconnected during the pre-processing or the post-processing, result of the execution is lost
+                The connection is synchronous, therefore, if the client is disconnected during the pre-processing or the post-processing, the result of the execution is lost.
 
 A **Plugin** can re-submit batches to the QPU, nevertheless, the *QAT* library provides a subtype of plugin, called **Junction**, providing a more convenient API to design plugins
-resubmitting jobs sequentially (e.g. a plugin optimizing angles of a variational job)
+resubmitting jobs sequentially (e.g. a plugin optimizing angles of a variational job).
 
 .. warning::
 
     A plugin can post-process a result. Then, the batch returned by the compilation step may not be equal to the initial batch (the post-process method
-    can be used to repair a result, to return the expected result to the user)
+    can be used to repair a result, to return the expected result to the user).
 
 .. autocard::