diff --git a/pages/reference/OS/updates/update-process.md b/pages/reference/OS/updates/update-process.md
index 2941958db1..533c90108c 100644
--- a/pages/reference/OS/updates/update-process.md
+++ b/pages/reference/OS/updates/update-process.md
@@ -9,7 +9,7 @@ With OTA updates (Over-the-Air) functionality built-in, {{ $names.os.lower }} en
 
 1. Standard HUP: The main mechanism for updating the hostOS, providing features such as [automatic rollbacks](#automatic-rollbacks) and [delta updates](#delta-updates-and-bandwidth-efficiency).
 
-2. Advanced HUP: Standard HUP can be incompatible for certain upgrade paths. This update mechanism is usually more involved and does not provide features such as automatic rollback and delta updates. Advanced HUP is used for specific scenarios. Subsequent updates to the OS can be done through standard HUP. For example, the partition layout for NVIDIA JetPack 4-based {{ $names.os.lower }} differs from JetPack 5-based {{ $names.os.lower }}. If a device is already running JetPack-4 {{ $names.os.lower }}, you can use advanced HUP to update to a JetPack 5-based {{ $names.os.lower }}. After the advanced HUP, the next updates can be carried out using the standard HUP process.
+2. Advanced HUP: Standard HUP can be incompatible with certain upgrade paths. For these specific scenarios, we have the advanced HUP method to update devices. An example scenario would be updating from NVIDIA JetPack 4-based {{ $names.os.lower }}  to JetPack 5-based {{ $names.os.lower }}. This scenario would need advanced HUP for the update method due to a difference in partition layout. After the advanced HUP, the next updates can be carried out using the standard HUP process.
 
 The method used to perform the host OS update doesn't need to be selected. Rather, {{ $names.company.lower }} determines the method to be used automatically. This is based on the current OS version running on the device and the target OS version selected.
 
@@ -30,7 +30,7 @@ Finally, the boot settings are modified so that on the next reboot the new root
 #### Atomic Updates
 In general, host OS updates are meant to be atomic: if an update is run, it either finishes correctly or it fails and leaves the system in its previous, usable state. If deploying the new root file system is unsuccessful, the boot settings are not switched over to the new partition. This means the device can be rebooted with the previous OS version and no noticeable changes.
 
-__Note:__ Once a host OS update is successful, it is not possible to roll back to a previous OS version (except via [automatic rollbacks](#automatic-rollbacks) as noted below).
+__Note:__ Once a host OS update is successful, it is not possible to roll back to a previous OS version.
 
 #### Automatic Rollbacks
 For failures related to the boot partition, the latest versions of {{ $names.os.lower }} have a rollback feature that will leave the partition in a good state.