Rename ADR-011 to device-initiated update checks

docs/03-system-architecture.md

@@ -49,7 +49,7 @@ These are roles, not a shopping list of separate services. One tool may cover se
 
 Imagine a device running version 1. Version 2 is ready. In this example, the device can prepare the new system while keeping the previous one available for recovery.
 
-1. The server offers version 2 to the device.
+1. The device checks with the server, which returns version 2 as an available update for this device.
 2. The OTA manager checks that it fits this device and that an update is allowed now.
 3. The installer downloads, verifies, and prepares version 2. Version 1 is still running.
 4. When the device can restart, boot control selects version 2 and the device reboots.
@@ -62,7 +62,7 @@ If the update itself is interrupted, the device needs enough saved information t
 
 Two ADRs explain the choices behind this example:
 
-- [ADR-011: Device-Controlled Update Execution](../adr/ADR-011-device-controlled-update-execution.md) — why let the device finish the update when the server is unreachable?
-- [ADR-012: Separate Update Management from Installation](../adr/ADR-012-update-management-and-installation.md) — why separate deciding when to update from knowing how to install it?
+- [ADR-011: Device-Initiated Update Checks](../adr/ADR-011-device-initiated-update-checks.md) — how does a device find updates when its connection and settings allow it?
+- [ADR-012: Device-Controlled Update Execution](../adr/ADR-012-device-controlled-update-execution.md) — why let the device finish the update when the server is unreachable?
 
 Next, we will follow the boot process and see what happens before Linux and the OTA manager start.