diff --git a/Documentation/CAMARAaaS-Architecture.png b/Documentation/CAMARAaaS-Architecture.png
index 77efc3199e9a3f2e4490dc483e47730fb3b4d438..16a8d378264e92aaf0d214026dd7a5883833d838 100644
Binary files a/Documentation/CAMARAaaS-Architecture.png and b/Documentation/CAMARAaaS-Architecture.png differ
diff --git a/QoDProvisioning/README.md b/QoDProvisioning/README.md
index c115a7d29382bcf34b7ffea8e9e80f45a6f65ede..4b827b4968d112ea47fdd7bc72913c4258ec229a 100644
--- a/QoDProvisioning/README.md
+++ b/QoDProvisioning/README.md
@@ -64,8 +64,6 @@ The *ServiceEventManager* subscribes to this topic to obtain and process the upd
 
 These results are then processed by the *CamaraResultsProcessor* class, which updates each provisioning accordingly in the database.
 
-
-
 ## General concepts of the QoD service (the 5G core provider service) and design it as OSL TMF  Service Specification
 
 Having chosen the candidate API, the first step is to find a way to map the possible requests to TMF Service characteristics of the operator’s service. Our apporach in general is the following:
@@ -118,7 +116,7 @@ In regard to the *camaraResults* characteristic, to allow interoperability, it m
 
 For this prototype, since we cannnot deliver a QoD service implementation for a specific commercial core, we created a Dummy QoD Kubernetes Operator Service which emulates the 5G Core configuration. In future releases of OSL we will offer solutions for some open source 5G cores.
 
-We will start by looking at the Dummy QoD Kubernetes Operator Service we have created to demonstrate this Add-on. This Service will be offered as simple Custom Resource deployed in a Kubernetes cluster. You may find its Custom Resource Definition under `/DummyOperatorService/crd.yaml` Look at the CRD fields. Please notice that these were defined according with what we discusssed inm previous section.
+We will start by looking at the Dummy QoD Kubernetes Operator Service we have created to demonstrate this Add-on. This Service will be offered as simple Custom Resource deployed in a Kubernetes cluster. You may find its Custom Resource Definition under `/DummyOperatorService/crd.yaml` Look at the CRD fields. Please notice that these were defined according with what we discussed inm previous section.
 
 The first step is then to install this CRD in your kubernetes cluster. To this end, you may use the following command: `make create-dummy-operator-crd`
 
diff --git a/README.md b/README.md
index bac050cb7cd3d7985ae56d7b3fb44459392444c0..59f5dbe4e616e15801c28cabde6a3aad487744f9 100644
--- a/README.md
+++ b/README.md
@@ -1,30 +1,34 @@
 
 # CAMARAaaS Add-on
 
-The **CAMARA as a Service (CAMARAaaS) OSL Add-on** is a prototype service developed by OSL and allows users of OSL to expose CAMARA APIs for their TMF based services. By doing so, it enables runtime operations, such as enforcing profiles on User Equipment (UEs) or updating 5G Network Slice characteristics, using standardized CAMARA API endpoints. The work is in progress for future enhancments (e.g. multitenancy, etc). 
+## Introduction
 
-In a nutchel CAMARAaaS add-on makes API transformations from CAMARA API model to TMF API model and vice-versa.
+The **CAMARA as a Service (CAMARAaaS) OSL Add-on** is a prototype service developed by OSL and allows users of OSL to expose CAMARA APIs for their TMF-based services. By doing so, it enables runtime operations, such as enforcing profiles on User Equipment (UEs) or updating 5G Network Slice characteristics, using standardized CAMARA API endpoints. The work is in progress for future enhancements (e.g. multi-tenancy, etc). 
 
-The supporintg use case is the following:
+In a nutshell, CAMARAaaS add-on performs API transformations from CAMARA API model to TMF API model and vice-versa.
 
-- An OSL Service provider (e.g. an Operator) has a running 5G core (e.g. from another service order in OSL)
-- The running service exposes already some characteristics (i.e. via TMF Service inventory) that can be configured and thus one can reconfigure it. (e.g. change the quality of a slice via a TMF API service request)
-- On a subsequent step, the service provider makes a service order in OSL to expose this running service via a CAMARA API endpoint
-- The CAMARAaaS add-on is a wrapper between the CAMARA requests and the TMF API service inventory models. These CAMARA APIs will then be used to control the lifecyle and the operations that shall take place in an already existing OSL Service.
+The supporting use case is the following:
+
+- An OSL Service Provider (e.g. an Operator) has a running 5G Core (e.g. from another service order in OSL).
+- The running service exposes already some characteristics (i.e. via TMF Service Inventory) that can be configured. Thus, someone can reconfigure the latter during runtime (e.g. change the quality of a slice via a TMF API service request).
+- On a subsequent step, the Service Provider makes a Service Order in OSL to expose this running 5G Core service via a CAMARA API endpoint.
+- The CAMARAaaS add-on is a wrapper between the CAMARA requests and the TMF API Service Inventory models. These CAMARA APIs will then be used to control the lifecycle and the operations that shall take place in an already existing OSL Service.
 
 Therefore, these are the key features of this add-on:
 
-- **Seamless Integration**: Operators can expose their existing OSL services through CAMARA APIs, maintaining consistency with the OSL framework while offering additional accessibility.
+- **Seamless Integration**: Operators can expose their existing OSL Services through CAMARA APIs, maintaining consistency with the OSL framework while offering additional accessibility.
 - **Dynamic Service Control**: Allows runtime updates to characteristics of 5G-related Services, such as UE profiles or Network Slices, via CAMARA REST API calls. The updated characteristics of a Service can then be consumed by a Kubernetes Custom Resource that will produce an operation according to the updated characteristics.
 
-## Architectural approach and service interactions
+## Architectural Approach and Service Interactions
 
 The add-on introduces a generic **CAMARA API Service**, which acts as a wrapper for existing (running) services registered in TMF Service Inventory. The architecture ensures:
 
-1. **API Exposure**: CAMARA APIs are orchestrated by OSL (offered as a service) and their endpoints are exposed to the end clients.
-2. **Service Mapping**: The CAMARA API Service references a running service (identified by a UUID), enabling targeted operations. The invoking of CAMARA API endpoints will results in updates in the running service’s characteristics.
+1. **API Exposure**: CAMARA APIs are orchestrated by OSL (offered as-a-service) and their endpoints are exposed to the end-users (clients).
+2. **Service Mapping**: The CAMARA API Service references a running service (identified by a unique UUID), enabling targeted operations. The invoking of CAMARA API endpoints will result in updates in the running service’s characteristics.
 3. **Operational Flow**: Updates triggered via CAMARA APIs are propagated to the operator's service through OSL's message queue (Active MQ), ensuring synchronization of service characteristics.
 
+> Assumption: The Operator already processes and exposes a 5G controlling running service
+
 This architectural approach is presented in the figure below:
 
 ![CAMARAaaS-Architecture](Documentation/CAMARAaaS-Architecture.png)
@@ -32,77 +36,83 @@ This architectural approach is presented in the figure below:
 ### **Components in the Architecture**
 
 1. **Service Specification Catalogue**:
-   - Stores the service specifications.
-   - Contains the `CAMARA API Controller` service specification, which defines the profile enforcer functionality.
+   - Stores the Service Specifications.
+   - Contains the `CAMARA API Controller` Service Specification, which defines/exposes the profile enforcer functionality.
 
-2. **Service Inventory Catalogue**:
+2. **Service Inventory**:
    - Tracks service instances (e.g., RFS - Resource-Facing Services) and their configurations.
    - Includes services such as:
-     - CAMARA API Exposure Profile Enforcer.
-     - 5G Network Slice.
-     - Network profiles and UE (User Equipment) services.
+     - CAMARA API Exposure Profile Enforcer
+     - 5G Network Slice
+     - Network profiles and UE (User Equipment) services
 
-3. **Resource Inventory Catalogue**:
-   - Holds information about resources provisioned in the system.
+3. **Resource Inventory**:
+   - Holds information about resources provisioned in the system, related with the respective RFSs.
    - Contains resources like:
-     - CAMARA API Exposure.
-     - Profile Enforcer.
+     - CAMARA API Exposure
+     - Profile Enforcer
      - 5G Core
-     - Configmaps (used for managing Kubernetes configurations).
+     - Configmaps (used for managing Kubernetes configurations)
 
 4. **Kubernetes Cluster**:
-   - Hosts and manages the 5G Core components.
-   - Hosts all our operators (OSL can manage all these through CRIDGE - not depicted)
-   - Facilitates configuration updates via ConfigMap and resource values.
+   - Hosts and manages the 5G Core components
+   - Hosts all OSL operators (OSL can manage them these through CRIDGE - not depicted)
+   - Facilitates configuration updates via ConfigMap and resource values
 
 5. **CAMARA API Controller**:
-   - Processes API exposure requests and orchestrates resources for API exposure.
-   - Generates the CAMARA API Exposure resource on demand.
+   - Processes API exposure requests and orchestrates resources for API exposure
+   - Generates the CAMARA API Exposure resource on demand
 
 ---
 
 ### **Processes in the Workflow**
 
-There are two workflows depicted
-
-1. **Service Order Creation**:
-   - A service order is initiated to expose a service CAMARA API Exposure with parameter(`ExposeServiceUUID=Profile Enforcer`) using the TMF Service order API.
-   - This triggers the service provisioning process in the Service Inventory Catalogue.
-   - A custom resource is created and request via the CAMARA API controller to create the CAMARA API Exposure for Service Profile Enforcer
-   - The `CAMARA API Exposure` resource is created and populated with configuration values.
-   - The API Exposure is finalized and made available for consumption via the CAMARA API Exposure created service in the cluster.
-
-
-2. **CAMARA API Usage**:
-   - The API request includes QoD (Quality of Delivery) parameters and is accessible via a specified NodePort and endpoint URL e.g. (`portal.osl/{serviceAUUID}/camaraapiFQDN`).
-   -  A client makes a CAMARA QoD Request
-   -  TMF request is used to patch and customize Profile enforcer service configurations in the inventory
-   -  This is passed through OSL orchestrator and CRIDGE down to The `5G Core Controller` 
-   -  The `5G Core Controller` modifies configurations such as:
-     - Slices (5G Network Slice profiles).
-     - User equipment (UE) profiles.
-     - These changes are propagated to the Kubernetes-managed 5G Core components.
-- Resources in the Resource Inventory Catalogue are updated to reflect the service requirements.
-- Updates are made to the `Configmap` resource to align with the latest service configurations.
-- These changes ensure the 5G Core components operate with updated slice, profile, and UE configurations.
+
+There are three workflows depicted for a fully orchestrated end-to-end solution. The first one defines the prerequisites to deliver CAMARAaaS.
+
+The following two workflows explain how the CAMARAaaS is being delivered:
+
+1. **CAMARAaaS - Service Order Creation**:
+   - A Service Order is initiated to expose a CAMARA API Exposure service with parameter(`ExposeServiceUUID=Profile Enforcer`) using the TMF Service order API
+   - This triggers the service provisioning process in the Service Inventory
+   - A custom resource is created and requests via the CAMARA API controller to create the CAMARA API Exposure for the Service Profile Enforcer
+   - The `CAMARA API Exposure` resource is created and populated with configuration values
+   - The API Exposure resource is finalized in the cluster and made available for consumption via the ordered CAMARA API Exposure service.
+
+
+2. **CAMARA API Usage - Service Operation**:
+   - The API request includes QoD (Quality on Demand) parameters and is accessible via a specified NodePort and/or endpoint URL (e.g. `portal.osl/{serviceAUUID}/camaraapiFQDN`).
+   - A client performs a CAMARA QoD Request.
+   - An event is created and circulated within OSL message bus to notify about the request.
+   - The event results into a TMF request that is used to patch and customize the Network Operator's Profile enforcer service in the Service Inventory.
+   - The configuration is passed through OSL Orchestrator and CRIDGE down to the `5G Core Controller`.
+   - The 5G Core Controller modifies the respective network configurations such as:
+     - Slices (5G Network Slice profiles)
+     - User equipment (UE) profiles
+   - These changes are propagated to the Kubernetes-managed 5G Core components.
+   - Resources in the Resource Inventory are updated to reflect the enforced requirements.
+   - Updates are made to the `Configmap` Resource to align with the latest configurations.
+   - These changes ensure that the 5G Core components operate with updated slice, profile, and UE configurations.
+   - A similar event as in previous steps is generated that enables the CAMARA API to get notified by the enforced changes and update the client. 
 ---
 
-This architecture emphasizes automation, modularity, and interoperability between CAMARA APIs and 5G Core infrastructure, leveraging Kubernetes for seamless management and deployment.
+This architecture emphasizes automation, modularity, and interoperability between CAMARA APIs and 5G Core Infrastructure, leveraging Kubernetes for seamless management and deployment.
 
-The first image below, displays how normally one can use OSL to deploy and change a running service deployed in a Kubernetes cluster, using Kubernetes CRDs. First the service is requested through a Service Order. For example the service is a Service Specification bundle consisting of:
-- a 5GCore Service Specification that will deploy a 5G core through HELM charts
-- a 5GController Service Specification (deployed via HELM) that can chage configuration of slices for UEs. This Controller might register further Kubernetes operators for reconfiguring the core, slices, etc. This 5GController is developed by the service provider able to  reconfigure via e.g. NEF, scripting, API commands or other means.
+The first image below, displays a normal scenario of using OSL to deploy and change a running service deployed in a Kubernetes cluster, using Kubernetes CRDs. First the service is requested through a Service Order. For example, the requested service can be a Service Specification bundle consisting of:
+- a 5G Core Service Specification that will deploy a 5G Core through HELM chart(s).
+- a 5G Controller Service Specification (deployed via HELM) that can change configuration of slices for UEs. This 5G Controller might register further Kubernetes operators for reconfiguring the core, slices, etc. It is developed by the Network Operator and is able to reconfigure several components via e.g. NEF, scripting, API commands or other means.
 
-OSL via a service order deploys the services. Then while the service is in operation (ACTIVE), the user that ordered it can reconfigure it (see loop in figure) by changing characteristics of the sevice. These characteristics are then propagated from OSL orchestrator, through CRIDGE, down to the 5GController Kubernetes resource to handle it.
+OSL deploys the services via a Service Order request. Then while the service is in operation (ACTIVE), the user that ordered it can submit reconfigurations (see loop in figure) by changing characteristics of the service. These characteristics are then propagated from OSL orchestrator, through CRIDGE, down to the 5G Controller Kubernetes resource to handle it.
 
 ![CAMARAaaS-Workflow-OSLToday](Documentation/CAMARAaaS-Workflow-OSLToday.png)
 
-Since we have the service running in previous step, we request to expose it via a certain CAMARA API. We order the CAMARA controller to expose this service via CAMARA API, we just need to pass during the Service Order the UUID identifier of the service in TMF Service Inventory.
+Since the 5G Controller Service is running since the previous step, the user requests to expose it via a certain CAMARA API. The user orders the respective CAMARA Controller to expose this service via CAMARA API. User just needs to pass the UUID identifier of the 5G Controller Service (facilitator of CAMARA Controller), as seen in TMF Service Inventory, during the Service Order request.
 
 ![CAMARAaaS-Workflow-ServiceOrdering](Documentation/CAMARAaaS-Workflow-ServiceOrdering.png)
 
-Since we have now a new CAMRAS API service, clients can use this new API to reconfigure the service. This request is passed through the service bus to the TMF API and then down to the 5GController service.
-As already mentioned, the step “PATCH Characteristics” is achieved by send a message to OSL’s message bus.
+Since the new CAMARA API service is active, clients can use this new API to reconfigure the service. This request is passed through the message bus to the TMF API and then down to the 5G Controller Service.
+
+As already mentioned, the steps that require to “Update Service Characteristics” are achieved by sending a message to OSL’s message bus.
 
 
 ![CAMARAaaS-Workflow-ServiceOperation](Documentation/CAMARAaaS-Workflow-ServiceOperation.png)
@@ -110,12 +120,11 @@ As already mentioned, the step “PATCH Characteristics” is achieved by send a
 
 ## Important Considerations
 
-The CAMARAaaS Add-on depends on 2 Services:
+The CAMARAaaS add-on depends on 2 Services:
 
 - The OSL CAMARA API Service
-    - Is a generic CAMARA API wrapper service implemented by the OSL team
-    - This implementation will be publicly offered as an Addon (Helm chart)
-- A custom 5G-related Service (that shall be controlled/referenced by the CAMARA API Service):
+    - Is a generic CAMARA API wrapper Service implemented by the OSL team
+    - This implementation is publicly offered as an OpenSlice add-on (Helm Chart)
+- A custom 5G-related Service (that shall be controlled/referenced by the CAMARA API Service)
     - An OSL user must implement and provide its own 5G-related Controlling Service (following OSL design patterns)
-    - Implementation is custom
-
+    - Implementation is custom
\ No newline at end of file