update docs

docs/index.md

@@ -52,6 +52,11 @@ Overwritting configurations used by clusters (nodes booting with an image linked
 
 ### Configuration vs images
 
-Images are assigned to node but doing this directly is a bad practice, the reason for this is. There is no way to know the content of an image based on its id or name, therefore the configuration-image relationship is mandatory to keep and we should always refer to configurations when assigning images to nodes to boot. For this the sessions must not be deleted. Missing this information means we won't be able to track down the scripts used to build the image.
+Image IDs are typically opaque and do not provide any insight into the content of the image. In other words, you cannot tell what software, configurations, or versions are included in an image just by looking at its ID or name. Due to the obscurity of image IDs, it's crucial to maintain a clear relationship between configurations (the settings and scripts used to create the image) and the images themselves. This means keeping detailed records of which configurations were used to build each image. 
+Due to the obscurity of image IDs, it's crucial to keep the relationship between configurations and the images themselves. This means keeping the sessions used to create the images and/or configure the nodes. The sessions are important because they are the link between the configurations and the images. They contain the information about which configurations were used to create each image, thus ensuring traceability. 
 
-Cluster vs nodes operations: Provide operations on a list no nodes or on all nodes in a cluster
+Instead of using image IDs directly, the best practice is to refer to the configurations when assigning images to nodes for booting. This ensures that you have a clear understanding of what is being deployed and can replicate or troubleshoot it if necessary.
+
+### Cluster vs nodes operations
+
+Provide operations on a list no nodes or on all nodes in a cluster