diff --git a/src/docs/asciidoc/50-moments.adoc b/src/docs/asciidoc/50-moments.adoc
index 19c0f409..7c1a09fb 100644
--- a/src/docs/asciidoc/50-moments.adoc
+++ b/src/docs/asciidoc/50-moments.adoc
@@ -10,7 +10,7 @@ To use the abstraction, include the following dependency in your project:
 ----
 <dependency>
   <groupId>org.springframework.modulith</groupId>
-  <artifactId>modulith-moments</artifactId>
+  <artifactId>spring-modulith-moments</artifactId>
 </dependency>
 ----
 
diff --git a/src/docs/asciidoc/70-runtime.adoc b/src/docs/asciidoc/70-runtime.adoc
new file mode 100644
index 00000000..2745a613
--- /dev/null
+++ b/src/docs/asciidoc/70-runtime.adoc
@@ -0,0 +1,76 @@
+[[runtime]]
+= Spring Modulith Runtime Support
+
+The functionality described in previous chapters have all used the application module arrangement in either testing scenarios for verification and documentation purposes or were general support functionality that help to loosely couple modules but did not work with the application module structure directly.
+In this section we are going to describe Spring Modulith's support for
+
+[[runtime.setup]]
+== Setting up Runtime Support for Application Modules
+
+To enable the runtime support for Spring Modulith, make sure you include the `spring-modulith-runtime` JAR in your project.
+
+[source, xml]
+----
+<dependency>
+  <groupId>org.springframework.modulith</groupId>
+  <artifactId>spring-modulith-runtime</artifactId>
+  <scope>runtime</scope>
+</dependency>
+----
+
+IMPORTANT: It's worth noting that using the runtime support of Spring Modulith will mean that you include both https://www.archunit.org/[ArchUnit] and the https://jgrapht.org/[JGraphT] (required to topologically sort application modules) library in your application.
+
+Adding this JAR will cause Spring Boot auto-configuration to run that registers the following components in your application:
+
+* An `ApplicationModulesRuntime` that allows to access the `ApplicationModules`.
+* A `SpringBootApplicationRuntime` to back the former bean to detect the main application class.
+* An event listener for https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#features.spring-application.application-events-and-listeners[`ApplicationStartedEvent`]s that will invoke <<runtime.application-module-initializer, `ApplicationModuleInitializer`>> beans defined in the application context.
+
+[[runtime.application-module-initializer]]
+== Application Module Initializers
+
+When working with application modules, it is pretty common to need to execute some code specific to an individual module on application startup.
+This means that the execution order of that code needs to follow the dependency structure of the application modules.
+If a module B depends on module A, the initialization code of A has to run before the one for B, even if the initializers do not directly depend on another.
+
+[plantuml, format='svg']
+....
+hide empty members
+
+package org.springframework.modulith {
+interface ApplicationModuleInitializer
+}
+
+package com.acme.moduleA {
+  class InitializerA implements ApplicationModuleInitializer
+
+  class ComponentA
+}
+
+package com.acme.moduleB {
+
+  class ComponentB
+
+  class InitializerB implements ApplicationModuleInitializer
+}
+
+ComponentB --> ComponentA
+
+....
+
+While developers could of course define the execution order via Spring's standard `@Order` annotation or `Ordered` interface, Spring Modulith provides an `ApplicationModuleInitializer` interface for beans to be run on application startup.
+The execution order of those beans will automatically follow the application module dependency structure.
+
+[source, java]
+----
+@Component
+class MyInitializer implements ApplicationModuleInitializer {
+
+  @Override
+  void initialize() {
+    // Initialization code goes here
+  }
+}
+----
+
+Note, that the `ApplicationModuleInitializer` beans will only be invoked if the `spring-modulith-runtime` JAR is on the classpath (see <<runtime.setup>>) as that pulls in the dependencies that are needed to topologically sort the initializers according to the application module structure.
diff --git a/src/docs/asciidoc/70-observability.adoc b/src/docs/asciidoc/80-observability.adoc
similarity index 99%
rename from src/docs/asciidoc/70-observability.adoc
rename to src/docs/asciidoc/80-observability.adoc
index f213fedb..77c0bd4d 100644
--- a/src/docs/asciidoc/70-observability.adoc
+++ b/src/docs/asciidoc/80-observability.adoc
@@ -24,6 +24,7 @@ image::observability.png[]
 In this particular case, triggering the payment changes the state of the order which then causes an order completion event being triggered.
 This gets picked up asynchronously by the engine that triggers another state change on the order, works for a couple of seconds and triggers the final state change on the order in turn.
 
+[[observability.actuator]]
 == Application Module Actuator
 
 The application module structure can be exposed as Spring Boot actuator.
diff --git a/src/docs/asciidoc/index.adoc b/src/docs/asciidoc/index.adoc
index 74e7b1d5..fb891a4d 100644
--- a/src/docs/asciidoc/index.adoc
+++ b/src/docs/asciidoc/index.adoc
@@ -28,7 +28,9 @@ include::50-moments.adoc[]
 
 include::60-documentation.adoc[]
 
-include::70-observability.adoc[]
+include::70-runtime.adoc[]
+
+include::80-observability.adoc[]
 
 include::90-appendix.adoc[]