1. The upgrade that was never finished

Isaac Asimov’s The Bicentennial Man returns one last time for this arc because Andrew Martin’s transformations are never truly complete; each upgrade opens new possibilities and new risks. The desktop’s software updates will be the same: not a one-time event but a continuous negotiation between capability and safety.

Entries 601 through 603 wondered about autonomous software update in orbit, staged updates and rollback, and what updates need from the desktop. This entry closes the arc.

2. What was learned

The autonomous software update wondering gives the desktop four constraints:

  • Delegation is a spectrum. The desktop can stage and execute updates autonomously, but initiation and final authorization should remain ground-controlled initially.
  • Rollback is mandatory. Every update must be reversible until it has proven itself in operation.
  • Updates are architecture-wide. Storage, boot, compute, operations, and security must all support the update process.
  • Security cannot be an afterthought. Updates must be authenticated, verified, and protected against downgrade attacks.

3. What was decided

The desktop will adopt a ground-initiated, autonomously executed software update process with mandatory rollback. This means:

  • Ground approves and uploads updates.
  • The platform verifies authenticity and integrity, stages the update, and applies it during a planned window.
  • After activation, the platform runs a verification period before committing the update.
  • If verification fails or the platform fails to boot, it rolls back to the previous image.
  • Small parameter and model updates may be staged autonomously, but their application still requires ground authorization or pre-approved policy.
  • All update events are logged and reported to ground.

4. Interaction with earlier arcs

The autonomous software update arc connects to the flight software reading arc, the communications resilience arc, the long-duration autonomy arc, and the software fault injection test arc that comes next.

5. What remains open

The exact bootloader design, image format, and update policy depend on the chosen hardware and RTOS. The wondering arc has set the strategy; detailed update mechanism design comes later.

6. What this changes

  • The autonomous software update wondering arc is closed.
  • The desktop inherits a ground-initiated, autonomously executed update process with rollback.
  • The next arc will design a test for software fault injection and recovery.