diff --git a/doc/addons/camara/qod.md b/doc/addons/camara/qod.md
index f21a4991d7d155eee8794bd90265f3917e698dd2..dd0ab583d9482f14429ad7d173d0dc8907d2d0dd 100644
--- a/doc/addons/camara/qod.md
+++ b/doc/addons/camara/qod.md
@@ -14,7 +14,7 @@ Our solution needs to be deployed in a Kubernetes cluster. A 5G Core is needed f
 
 The PoC is based on [OSL CAMARAaaS Add-on](./intro.md). It is recommended to read this before diving into the implementation of the PoC.
 
-To replicate this PoC you have to close the code found in the [CAMARA Addon project](https://labs.etsi.org/rep/osl/code/addons/org.etsi.osl.controllers.camara/-/tree/main/QoDProvisioning).
+To replicate this PoC you have to clone the code found in the [CAMARA Addon project](https://labs.etsi.org/rep/osl/code/addons/org.etsi.osl.controllers.camara/-/tree/main/QoDProvisioning).
 
 ## General concepts of the OSL CAMARAaaS as a TMF Service Specification
 
diff --git a/doc/addons/images/osl_sylva_integration.png b/doc/addons/images/osl_sylva_integration.png
new file mode 100644
index 0000000000000000000000000000000000000000..504d7336a7238d821b82ce117c9d9b1cb7cec5b0
Binary files /dev/null and b/doc/addons/images/osl_sylva_integration.png differ
diff --git a/doc/addons/sylva.md b/doc/addons/sylva.md
new file mode 100644
index 0000000000000000000000000000000000000000..f4670116919142e8872a81007c31b7261369bad9
--- /dev/null
+++ b/doc/addons/sylva.md
@@ -0,0 +1,46 @@
+
+# LF Sylva Addon
+
+## Introduction
+
+Sylva, a project under the Linux Foundation, is designed to meet the unique demands of the telecom and edge cloud sectors. As telecommunications (telco) networks increasingly transition toward edge computing environments, Sylva provides a tailored cloud software framework for these specialized needs. It does not only address technical challenges in this domain, but also provides a reference implementation of the framework, which can be validated against industry requirements.
+
+The primary goal of Sylva is to ensure that telecom operators have a reliable, flexible, and scalable cloud infrastructure that supports the edge computing needs of modern networks. Additionally, Sylva aims to create a validation program for these implementations, ensuring that they meet the evolving standards and demands of the industry. You can read more about Sylva [here](https://sylvaproject.org/).
+
+## OSL Sylva Addon
+
+The synergy between OSL and Sylva offers a powerful combination that addresses the increasing complexity of managing telco and edge cloud infrastructures. We developed an Addon operator that enables the integration of OSL and Sylva, thus optimizing service orchestration and resource management for telecom operators. This is demonstrated through new resource operators that OSL developed as extensions. 
+
+These operators allow OSL tenants to request and manage Sylva workload clusters directly through OSL’s platform and TMF APIs. This capability means that tenants can now order Kubernetes clusters managed by Sylva in a self-service manner, simplifying resource allocation and management. 
+
+The integration of Sylva with OSL leverages TMF APIs to expose and manage Sylva’s telco-focused cloud software framework. By doing so, OSL provides an efficient means of ordering and orchestrating Sylva’s resources within the broader context of network services.
+The collaboration between OSL and Sylva highlights several key advantages for telecom operators, including:
+
+- **Self-Service Resource Management**: OSL tenants can seamlessly request and manage Sylva workloads, providing greater flexibility and speed in resource provisioning.
+- **Streamlined Orchestration**: By utilizing TMF APIs, OSL simplifies the process of requesting and managing Sylva clusters, reducing the complexity of managing edge cloud infrastructure.
+- **Scalability and Flexibility**: Sylva’s cloud framework is built specifically for the telco industry, offering scalability and flexibility for telecom operators looking to expand their edge computing capabilities.
+- **Efficiency and Automation**: The integration enables automated resource provisioning and lifecycle management, ensuring that telecom operators can focus on innovation rather than manual resource management.
+
+
+We explored the following aspects, which are also represented visually in the following figure:
+
+1. **Identity and Access Management**: This setup uses Keycloak for Identity and Access Management (IAM). Both OSL (installed in an OSL management cluster) and Sylva’s services (Sylva services installed in management cluster) interact with Keycloak to authenticate and authorize users or services, ensuring secure access to resources. This step is crucial for managing user permissions, access rights, and the security of operations.
+2. **Request Workload Clusters**: The **OSL Management Cluster** interfaces with the **Sylva Management Cluster** to request workload clusters. This is a crucial aspect of the integration, as OSL provides a self-service capability for tenants (e.g., telecom operators) to request Sylva’s Kubernetes-based workload clusters easily.
+3. **Awareness of Operators and Management of Workload Cluster Resources**: After the workload cluster is created and managed by Sylva, OSL becomes aware of the workload cluster operators and the resources within the workload clusters. In this process, OSL is managing the workload cluster resources as if they were its own. OSL’s CRIDGE, is utilized to ensure that OSL is fully integrated and aware of the Sylva-managed resources.
+4. **Deploy Resources in Workload Cluster**: Once the workload clusters are set up and managed, Cloud-Native Functions (CNF) are deployed in the clusters. These CNFs represent the telco workloads and applications that the operator needs to manage. The deployment of CNFs takes place in the workload clusters, utilizing Sylva’s capabilities to handle these resources efficiently.
+
+
+![OSL - Sylva integration](./images/osl_sylva_integration.png)
+
+## Probe further
+
+More details of each aspects of the approach can be found in the following three-part news blogposts:
+
+1. [Details in Identity and Access Management](https://osl.etsi.org/news/20241015_osl_sylva_part1/)
+2. [Sylva Workload Cluster as a Service](https://osl.etsi.org/news/20241022_osl_sylva_part2/)
+3. [Awareness of resources in a Sylva Workload Cluster](https://osl.etsi.org/news/20241104_osl_sylva_part3/)
+
+Additional complementary material:
+
+* The Addon’s source code is in the respective [OSL GitLab repository](https://labs.etsi.org/rep/osl/code/addons/org.etsi.osl.controllers.sylva). 
+* You may also check the related [video demonstration](https://www.youtube.com/watch?v=dgrLVD9Sejw).
\ No newline at end of file
diff --git a/doc/service_design/catalogs.md b/doc/service_design/catalogs.md
index b34701caef6638c277f43d3257a2e4f8c509cdd9..9464877f5f50fddffcc336f02c36946aaf16393a 100644
--- a/doc/service_design/catalogs.md
+++ b/doc/service_design/catalogs.md
@@ -1,6 +1,6 @@
 # Catalogs and Templates
 
-The OpenSlice Service Catalogue (accessible through the API or Services portal) contains the representation of Service Specifications, either created from the provider defining service attributes, or by supporting the GSMA Generic Slice Templates (GST) as well as the VINNI Service Blueprint. The following scenarios are supported by the OpenSlice Service Catalogue.
+The OpenSlice Service Catalogue (accessible through the API or Services portal) contains the representation of Service Specifications, either created from the provider defining service attributes, or by supporting the GSMA Generic Slice Template (GST). The following scenarios are supported by the OpenSlice Service Catalogue.
 
 
 ## Create/Design a Service Specification
@@ -91,6 +91,9 @@ See more on [Consuming Services From External Partner Organizations]( ../getting
 
 ## Probe further
 
-[Design Kubernetes-based Service Specifications](./kubernetes/exposing_kubernetes_resources.md/)
+Design and expose services based on:
 
-[Design NFV/OSM-based Service Specifications](./nfv/design_nfv_services.md)
+* [Containerized resources via the Kubernetes Operator pattern](./kubernetes/exposing_kubernetes_resources.md)
+* [NFV artifacts](./nfv/design_nfv_services.md)
+* [Monitoring sources](./monitoring/design_monitoring_services.md)
+* [Generic, developer-owned controllers](./generic/design_generic_services.md)
diff --git a/doc/service_design/generic/design_generic_services.md b/doc/service_design/generic/design_generic_services.md
new file mode 100644
index 0000000000000000000000000000000000000000..c9bc381fb31d4622e15e4ca4c11291af1372fbb0
--- /dev/null
+++ b/doc/service_design/generic/design_generic_services.md
@@ -0,0 +1,45 @@
+# Design Generic Services
+
+**Intended Audience: OpenSlice Service Designers**
+
+This section introduces a way to integrate generic and developer-owned services/controllers within the OpenSlice (OSL) lifecycle. 
+
+## Introduction
+
+Since Release 2024Q2, OSL introduces extensive support for Kubernetes operators exposed as services within OSL catalogs. However, inspired by the operator pattern, developers can now write their own resource controllers and attach them to the OSL service bus. OSL's Service orchestrator (OSOM) has the capability of contacting external controllers, given a specific resource category that this controller can manage.
+
+The intended goal is to write a controller that can handle resources of a specific type, e.g., resource Specifications for managing resources of a specific category. Therefore, a new resource controller can be registered into OSL, in the form of a Resource Specification with a designated name, category and version, and the implementation of the controller shall listen for messages in queues as specified by the name, category and version of the registered Resource Specification. Specifically, it shall listen for CREATE/UPDATE/DELETE actions, with the following scheme:
+
+- CREATE / category_name / version
+- UPDATE / category_name / version
+- DELETE / category_name / version
+
+## Workflow
+
+In a nutshell, the Resource Definition/Specification is registered at startup. During Service Orders of related-to-the-specification services, the controller is invoked (via message queue) and a new service and its underlying resource are created, with messages passing between the service and resource layers. The resource controller processes any updates or status changes. OSOM checks the final status of the deployed resource to confirm it is ready or identify any potential errors. The following diagram describes what the resource controller needs to perform, showcasing how the “Resource Controller” component interacts with various services (TMF API, Message Queue MQa, and OSOM) to register the needed resource types, create new resources (Resource Facing Services - RFSs and underlying resources), process updates, and check the resource’s status.
+
+1.	**Controller Registration (top swimlane)** – This happens when the controller bootstraps
+    * **Register a Resource Specification**: On startup, the Resource Controller posts a ResourceSpec (containing a name, category, and version) to register it in the OSL Resource Specification Catalog.
+    * **QueueRegister**: The controller is registered in these three queues and listens on messages with ResourceCreate or ResourceUpdate payloads. -->
+
+2.	**Create RFS (middle swimlane)** – This happens when there is a Service Order
+    * **ServiceOrderCreate**: When a new RFS needs to be created, a “ServiceOrderCreate” operation via the TMFAPI arrives to OSOM.
+    * **ServiceCreateMSG → ResourceCreateMSG**: Internally, a “ServiceCreateMSG” as well as a “ResourceCreateMSG” are sent to the TMFAPI component to create the related entities in the inventory.
+    * **Resource Deployment**: OSOM sends a message to the queue under the specific queue name to CREATE the resource.
+    * **CreateGenericResourceMSG**: A generic creation message is sent (e.g., CREATE/```{category_name}```/```{version}```), containing metadata such as ServiceID, ResourceID, and OrderID in the message headers.
+        1. *org.etsi.osl.serviceId*: The related service ID that refers to the created resource. 
+        2. *org.etsi.osl.resourceId*: The related resource ID that is the custom controller is expected to update.
+        3. *org.etsi.osl.serviceOrderId*: The related service order id of the deployment request.
+    * **WaitForResourceStatus**: OSOM waits for a status response indicating success or failure in creating the resource.
+3.	**Resource Controller Process (lower-middle swimlane)**
+    * **ProcessRequest**: After the resource is created, the Resource Controller processes any additional instructions or updates related to the resource.
+    * **ResourceUpdate**: The resource is updated accordingly (e.g., changing configurations, state, etc.). The controller needs to update the resource into a valid state, e.g. AVAILABLE, RESERVED, or ALARM. For instance, if it is update in AVAILABLE state, OSOM later will assume that everything is OK, the service is ACTIVE, and the Service Order is COMPLETED, respectively.
+4.	**OSOM Check Deployment (bottom swimlane)**
+    * **GETResource → Check GETResource**: OSOM retrieves the resource information to verify its deployment and status.
+    * **Check Resource Status**: OSOM checks whether the resource has transitioned into a valid operational state (e.g., AVAILABLE, RESERVED, or ALARM).
+
+![Generic Controller Sequence Diagram](./images/generic_controller_seq_diagram.png)
+ 
+## Probe further
+
+A working example of such a generic controller can be found [here](https://labs.etsi.org/rep/osl/code/addons/org.etsi.osl.examples.gcontroller), written in Java, but in general you can implement one in any language.
\ No newline at end of file
diff --git a/doc/service_design/generic/images/generic_controller_seq_diagram.png b/doc/service_design/generic/images/generic_controller_seq_diagram.png
new file mode 100644
index 0000000000000000000000000000000000000000..cd209ad144c736c6b0a3d885e4f8819e33d0f28c
Binary files /dev/null and b/doc/service_design/generic/images/generic_controller_seq_diagram.png differ
diff --git a/doc/service_design/intro.md b/doc/service_design/intro.md
index 140c814639d6ed88eff06dfb17034240f06794b0..8916706ab4486add2b538d3ac28d640daf49f1e8 100644
--- a/doc/service_design/intro.md
+++ b/doc/service_design/intro.md
@@ -3,17 +3,10 @@
 **Intended Audience: OpenSlice Service Designers**
 
 
-This section offers details on how to design Service Specifications and expose them in Service Catalogs
+This section offers details on how to design Service Specifications and expose them in Service Catalogs.
 
-Service Designers create detailed service specifications, which are then managed and exposed in service catalogs. These services are integrated into OpenSlice E2E service orchestration framework to automate and optimize the delivery of network services.
-
-
-OpenSlice can be used to design service specifications for various services, even not networking related services. Here we cover how service designers can expose services related to the NFV world and the containerized world.
-
-## Probe further
-
-* [Design and expose services based on containerized resources via the Kubernetes Operator pattern](./kubernetes/exposing_kubernetes_resources.md)
-* [Design and expose services based on NFV artifacts](./nfv/design_nfv_services.md)
+Service Designers create detailed Service Specifications, which are then managed and exposed in Service Catalogs. These services are integrated into OpenSlice end-to-end service orchestration framework to automate and optimize the delivery of network services.
 
+OpenSlice can be used to design Service Specifications for various services, even not networking related ones. Here we cover how Service Designers can expose services, related to the cloud world (containerized/Kubernetes and NFV), monitoring domain, or even generic developer-owned ones.
 
 
diff --git a/doc/service_design/kubernetes/intro.md b/doc/service_design/kubernetes/intro.md
deleted file mode 100644
index 8fad353e29bd24d4024b51c016caadb056f12b86..0000000000000000000000000000000000000000
--- a/doc/service_design/kubernetes/intro.md
+++ /dev/null
@@ -1,3 +0,0 @@
-# OpenSlice and support for kubernetes
-
-This section contains information on how Service Designers can expose Kubernetes resources as services
\ No newline at end of file
diff --git a/doc/service_ordering/images/service_marketplace.png b/doc/service_ordering/images/service_marketplace.png
new file mode 100644
index 0000000000000000000000000000000000000000..c590119c86f899b157021b666411c3b1aabb3459
Binary files /dev/null and b/doc/service_ordering/images/service_marketplace.png differ
diff --git a/doc/service_ordering/images/service_order_checkout.png b/doc/service_ordering/images/service_order_checkout.png
new file mode 100644
index 0000000000000000000000000000000000000000..744dc9fe561d6b9076ff6eb2c7bc1a5672a86913
Binary files /dev/null and b/doc/service_ordering/images/service_order_checkout.png differ
diff --git a/doc/service_ordering/images/service_order_preview.png b/doc/service_ordering/images/service_order_preview.png
new file mode 100644
index 0000000000000000000000000000000000000000..300c4c224d4296263117cbbb4eed353794a07f1c
Binary files /dev/null and b/doc/service_ordering/images/service_order_preview.png differ
diff --git a/doc/service_ordering/images/service_order_preview_completed.png b/doc/service_ordering/images/service_order_preview_completed.png
new file mode 100644
index 0000000000000000000000000000000000000000..0c94363959f48f50c58f876dc858c4be4fa446b9
Binary files /dev/null and b/doc/service_ordering/images/service_order_preview_completed.png differ
diff --git a/doc/service_ordering/images/service_preview.png b/doc/service_ordering/images/service_preview.png
new file mode 100644
index 0000000000000000000000000000000000000000..5e1fd9426f476517eac8f6a4feef45ecc3f65401
Binary files /dev/null and b/doc/service_ordering/images/service_preview.png differ
diff --git a/doc/service_ordering/ordering_services.md b/doc/service_ordering/ordering_services.md
index c88edca3e4f5f42a7bd560b66722a8bffed78876..57f95211b6ee66091c61dc926c2ec6e0334e1d38 100644
--- a/doc/service_ordering/ordering_services.md
+++ b/doc/service_ordering/ordering_services.md
@@ -2,4 +2,38 @@
 
 **Intended Audience: OpenSlice Users**
 
-_This section is WIP._
\ No newline at end of file
+Having covered how OpenSlice can facilitate the Service Design and exposure, this section introduces the process of ordering the designed Service Specifications and their fulfillment process.
+
+To that extend, we assume that the OpenSlice Service Designers have already created the designated, detailed Service Specifications that are willing to expose to the OpenSlice users, or to potential Communication Service Customers (CSCs). Furthermore, the designed Service Specifications are categorized in the respective Service Categories and Catalogs.
+
+## Service Marketplace
+
+The OpenSlice User can browse the Services Marketplace for available services. There is a designated Service Catalog Explorer that goes through all the available Catalogs and the respective Categories, as seen in the following figure.
+
+![Service Marketplace](./images/service_marketplace.png)
+
+The User can filter offered services within a Category, and when needed, preview a desired service for more information, as well as configurable/non-configurable characteristics.
+
+![Service Preview](./images/service_preview.png)
+
+Once satisfied, the User may place the selected service(s) in the Order List. An icon at the top-right part of the navbar presents the number of services in the Order List. Clicking that icon, the flow is navigated to the Service Order Checkout page.
+
+## Service Order Checkout
+
+Here, the User can see the Order List in detail and configure each Order Item. Specifically, all the configurable characteristics (if any) of a service can be altered and customized, as well as some general preferences, i.e. notes and Service Order duration.
+
+> The ultimate duration may differ from the one requested by the User, as it has to be approved by an Administrator.
+
+![Service Order Checkout](./images/service_order_checkout.png)
+
+## Service Order Preview
+
+When the User clicks the Order Service button from the previous step, a Service Order is created and saved in the respective database. A User can browse its issued Service Order(s) by the "My Service Orders" tab. A freshly issued Service Order acquires the state of *INITIAL*. By selecting a Service Order, the User navigates to the Service Order Overview and Management page. Here, once again, the User may change the requested duration, add notes towards the Administrator, or edit the respective Order Items (change the user-defined characteristics).
+
+![Service Order Overview](./images/service_order_preview.png)
+
+Once the Service Order is reviewed by an Administrator, the state is expected to switch to *ACKNOWLEDGED*, which signals that the order is ready to be processed by the orchestrator. When this happens, the state will switch once more to *IN PROGRESS* and eventually to *COMPLETED*, once the order is successfully fulfilled. At this stage, the User can browse each Order Item and navigate to the created service instances in the Service Inventory. Each service contains relevant information about its execution and deployment and can also be edited.
+
+![Service Order Overview - Completed](./images/service_order_preview_completed.png)
+
+The User can edit the created Services or opt to terminate the Service Order earlier than the requested duration, by selecting the Order Item and click on the termination icon.
\ No newline at end of file
diff --git a/mkdocs.yml b/mkdocs.yml
index a6d24b1b7f1693e92a725a2d785bea8d720e45b3..499edf7dcafb2821ced2dfffe09e4dd21291997f 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -143,17 +143,18 @@ nav:
     - NFV support:
       - Introduction: ./naas/nfv/intro.md
       - NFV Services: ./naas/nfv/nfvservices.md
-  - Service design:
+  - Service Design:
     - Introduction: ./service_design/intro.md
     - Catalogs: ./service_design/catalogs.md
     - Support for Kubernetes:
-      - Introduction: ./service_design/kubernetes/intro.md
       - Exposing Kubernetes Resources: ./service_design/kubernetes/exposing_kubernetes_resources.md
       - Design Helm as a Service: ./service_design/kubernetes/design_helm_aas.md
     - Support for NFV:
       - Design NFV Services: ./service_design/nfv/design_nfv_services.md
     - Support for Monitoring:
-      - Design Monitoring Services: ./service_design/monitoring/design_monitoring_services.md 
+      - Design Monitoring Services: ./service_design/monitoring/design_monitoring_services.md
+    - OSL Generic Controller:
+      - Design Generic Services: ./service_design/generic/design_generic_services.md
     - LCM Rules:
       - Introduction: ./service_design/lcmrules/intro.md
       - Specification: ./service_design/lcmrules/specification.md
@@ -183,6 +184,7 @@ nav:
     - CAMARA:
       - Offering CAMARAaaS: ./addons/camara/intro.md
       - Quality on Demand: ./addons/camara/qod.md
+    - LF Sylva: ./addons/sylva.md
   - Design & Architecture:
       - Architecture: ./architecture/architecture.md
       - Message bus: ./architecture/messagebus.md