diff --git a/.vitepress/config.js b/.vitepress/config.js
index 2bff0cd425..b8c81650e0 100644
--- a/.vitepress/config.js
+++ b/.vitepress/config.js
@@ -106,8 +106,8 @@ config.rewrites = rewrites
 // Add custom capire info to the theme config
 config.themeConfig.capire = {
   versions: {
-    java_services: '3.10.1',
-    java_cds4j: '3.10.1'
+    java_services: '4.0.2',
+    java_cds4j: '4.0.2'
   },
   gotoLinks: [],
   maven_host_base: 'https://repo1.maven.org/maven2'
diff --git a/advanced/odata.md b/advanced/odata.md
index 69960f00af..df8e8bffd3 100644
--- a/advanced/odata.md
+++ b/advanced/odata.md
@@ -1138,71 +1138,6 @@ GET SalesOrganizations?$apply=
    /ancestors(..., ID, filter(contains(Name, 'New York')), keep start)
 ```
 
-#### Modeling Recursive Hierarchies
-
-Recursive hierarchies are parent-child hierarchies, where each entity references its parent and through that defines the hierarchical structure. A common example is a company organization structure or HR reporting, where each employee entity references another employee a as direct report or manager.
-
-##### Domain Model
-
-The simplest domain model looks as follows:
-
-```cds
-entity Employee : Hierarchy {
-  key ID       : UUID;
-      parent   : Association to Employee;
-      fullName : String;
-}
-
-aspect Hierarchy {
-  virtual LimitedDescendantCount : Integer64;
-  virtual DistanceFromRoot       : Integer64;
-  virtual DrillState             : String;
-  virtual LimitedRank            : Integer64;
-}
-```
-
-The entity `Employee` has the element `ID`, which identifies the hierarchy node. The `parent` association references the same entity, which establishes the parent-child relationship.
-
-##### Virtual Elements of a Hierarchy
-
-The `Hierarchy` aspect defines a set of virtual elements, automatically calculated by the backend at runtime, to describe the state of the hierarchy. This information is requested by the UI to correctly render the hierarchy in a *TreeTable* during user interaction.
-
-##### Service Model
-
-The following service defines the projection on the domain model.
-
-```cds
-service HRService {
-    entity HREmployee as projection on Employee;
-}
-```
-
-
-##### OData v4 Annotations for Fiori
-
-To link the backend and Fiori UI, the projected service entity must be enriched with the following annotations.
-
-```cds
-annotate HRService.HREmployee with @Aggregation.RecursiveHierarchy #EmployeeHierarchy: {
-    $Type: 'Aggregation.RecursiveHierarchyType',
-    NodeProperty: ID,
-    ParentNavigationProperty: parent
-};
-```
-
-Here the `EmployeeHierarchy` specifies a hierarchy qualifier, `NodeProperty` (identifying the hierarchy node) is linked to `ID` of the entity `HREmployee`, and the `ParentNavigationProperty` is linked to a corresponding `parent` association.
-
-```cds
-annotate HRService.HREmployee with @Hierarchy.RecursiveHierarchy #EmployeeHierarchy: {
-  $Type: 'Hierarchy.RecursiveHierarchyType',
-  LimitedDescendantCount: LimitedDescendantCount,
-  DistanceFromRoot: DistanceFromRoot,
-  DrillState: DrillState,
-  LimitedRank: LimitedRank
-};
-```
-
-Here the same qualifier `EmployeeHierarchy` is referenced to list the names of the [virtual elements of the hierarchy](#virtual-elements-of-a-hierarchy).
 
 ### Aggregation Methods
 
diff --git a/guides/deployment/microservices.md b/guides/deployment/microservices.md
index 12e87c5c80..be8accb6a7 100644
--- a/guides/deployment/microservices.md
+++ b/guides/deployment/microservices.md
@@ -466,18 +466,6 @@ resources:
 ```
 :::
 
-Add the *processed-after* property, so that the xsuaa instance is created after the messaging:
-
-::: code-group
-```yaml [mta.yaml]
-resources:
-  ...
-  - name: samples-auth
-    processed-after: #[!code ++]
-      - samples-messaging #[!code ++]
-```
-:::
-
 ::: details Configure each app for cloud readiness
 Enable messaging for the modules that use it:
 
@@ -593,7 +581,7 @@ mv app/router .deploy/app-router
 ```
 
 ::: code-group
-```yaml
+```yaml [mta.yaml]
 modules:
   ...
   - name: samples
diff --git a/node.js/events.md b/node.js/events.md
index 9158d2e9cf..c4a05c9e37 100644
--- a/node.js/events.md
+++ b/node.js/events.md
@@ -588,3 +588,5 @@ Content-Type: application/json
 
 > [!warning] Error Sanitization
 > In production, error responses should never disclose internal information that could be exploited by attackers. To ensure that, all errors with a `5xx` status code are returned to the client with only the respective generic message (example: `500 Internal Server Error`).
+>
+> In very rare cases, you might want to return 5xx errors with a meaningful message to the client. This can be achieved with `err.$sanitize = false`. Use that option with care!
diff --git a/package-lock.json b/package-lock.json
index fb04dd423a..0688e220dd 100644
--- a/package-lock.json
+++ b/package-lock.json
@@ -286,9 +286,9 @@
       }
     },
     "node_modules/@cap-js/cds-types": {
-      "version": "0.10.0",
-      "resolved": "https://registry.npmjs.org/@cap-js/cds-types/-/cds-types-0.10.0.tgz",
-      "integrity": "sha512-E0uVAXmYz8X7O4Pf/ZveECi+qPUl2X/o4BQRlGNstxhvUfrNHmADZR1N3RJvKxO5wOGfaZuJtY+fg7diU9tnAw==",
+      "version": "0.11.0",
+      "resolved": "https://registry.npmjs.org/@cap-js/cds-types/-/cds-types-0.11.0.tgz",
+      "integrity": "sha512-NPy98LJ35q+78kaz2R5xsBfiUUC8Tk/OZAgwuhPhxbkOnNSwAW5yDO6Kl63XEnAJK2/LytVx6Lc2A1S1LNIIjQ==",
       "dev": true,
       "hasInstallScript": true,
       "license": "Apache-2.0",