diff --git a/docs/docs/architecture/components.md b/docs/docs/architecture/components.md
index 798e17ea7..45389ef2d 100644
--- a/docs/docs/architecture/components.md
+++ b/docs/docs/architecture/components.md
@@ -1,6 +1,8 @@
 # Components
 
-(**FS: Overall, good**)
+
+
+(**FS: Overall, good. Should be renamed to something like "Kubernetes Components"**)
 
 Constellation takes care of bootstrapping and initializing a Confidential Kubernetes cluster. (**FS: weird**)
 During the lifetime of the cluster, it handles day 2 operations such as key management, remote attestation, and updates. (**FS: features**)
@@ -11,15 +13,15 @@ These features are provided by several components:
 * The [VerificationService](components.md#verificationservice) provides remote attestation functionality
 * The [Key Management Service (KMS)](components.md#kms) manages Constellation-internal keys
 
-The relations between components are shown in the following diagram: (**FS: this doesn't look quite right. Talk to Moritz. Maybe remove.**)
+The relations between components are shown in the following diagram: (**FS: this is only the first node**)
 
 ```mermaid
 flowchart LR
     subgraph admin [Admin's machine]
         A[Constellation CLI]
     end
-    subgraph img [Constellation OS image]
-        B[Constellation OS]
+    subgraph img [Node / Confidential VM]
+        B[Constellation OS image]
         C[Bootstrapper]
     end
     subgraph Kubernetes
@@ -27,7 +29,7 @@ flowchart LR
         E[KMS]
         F[VerificationService]
     end
-    A -- deploys -->
+    A -- boots -->
     B -- starts --> C
     C -- deploys --> D
     C -- deploys --> E
@@ -39,8 +41,8 @@ flowchart LR
 **FS: some context missing**
 The *Bootstrapper* is the first component launched after booting a Constellation node image.
 It sets up that machine as a Kubernetes node and integrates that node into the Kubernetes cluster.
-To this end, the *Bootstrapper* first downloads and [verifies](https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73) the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) at the configured versions. (**FS: where are they configured?**)
-The *Bootstrapper* tries to find an existing cluster and if successful, communicates with the [JoinService](components.md#joinservice) to join the node.
+To this end, the *Bootstrapper* first downloads and [verifies](https://blog.sigstore.dev/kubernetes-signals-massive-adoption-of-sigstore-for-protecting-open-source-ecosystem-73a6757da73) (**FS: this is not a good link**) the [Kubernetes components](https://kubernetes.io/docs/concepts/overview/components/) at the configured versions. (**FS: where are they configured?**)
+The *Bootstrapper* tries to find an existing cluster (**FS: how?**) and if successful, communicates with the [JoinService](components.md#joinservice) to join the node.
 Otherwise, it waits for an initialization request to create a new Kubernetes cluster.
 
 ## JoinService
@@ -73,4 +75,4 @@ Read more about the hardware-based [attestation feature](attestation.md) of Cons
 
 The *KMS* runs as DaemonSet on each control-plane node.
 It implements the key management for the [storage encryption keys](keys.md#storage-encryption) in Constellation. These keys are used for the [state disk](images.md#state-disk) of each node and the [transparently encrypted storage](encrypted-storage.md) for Kubernetes.
-Depending on wether the [constellation-managed](keys.md#constellation-managed-key-management) or [user-managed](keys.md#user-managed-key-management) mode is used, the *KMS* holds the key encryption key (KEK) directly or calls an external service for key derivation respectively.
+Depending on wether the [constellation-managed](keys.md#constellation-managed-key-management) (**FS: this is an odd name.**)or [user-managed](keys.md#user-managed-key-management) mode is used, the *KMS* holds the key encryption key (KEK) directly or calls an external service for key derivation respectively.