1. The machine that upgrades itself, but not yet

Isaac Asimov’s The Bicentennial Man returns one last time for this arc because the desktop’s software is not yet ready to modify its own nature. The conclusion is more modest than the novel. The desktop will be designed so that autonomous self-maintenance is possible, but it will not be turned on until the basic software update process is proven.

Entries 505 through 507 wondered about autonomous firmware patching and self-maintenance. This entry closes the arc.

2. What was decided

The desktop will be designed as self-maintenance-ready, not fully self-maintaining on first launch. This means:

  • Every cell will have a secure, signed update mechanism with rollback storage.
  • Health monitoring and anomaly detection will be built from the start.
  • The first operational mode will use ground-commanded updates with local verification.
  • Autonomous patching will be added as a software upgrade after the basic update and rollback process is proven in orbit.
  • Policy, audit, and federation coordination infrastructure will be built from the start so that autonomy can be enabled safely later.

3. Why this is the right posture

Full autonomous patching on day one would add security and verification burden before the basic software stack is trusted. Ignoring it entirely would force an update architecture redesign later. Designing as self-maintenance-ready preserves optionality: the platform can apply pre-approved patches autonomously when the operators are ready to trust it.

4. What this implies for the software architecture

The software stack must be more than a set of installed programs. It needs:

  • A bootloader and partition layout that supports A/B or fallback images.
  • Cryptographic verification of every patch.
  • A health model that can trigger or block updates.
  • Federation-aware update rules so cells do not drift into incompatible versions.

5. Relationship to the compute migration and storage healing arcs

The self-maintenance arc connects directly to the compute migration arc from Entries 489 through 492 and the federated storage healing arc from Entries 473 through 476. A migrated workload needs the target cell to be running compatible firmware, and a storage healing process must not be interrupted by an ill-timed patch.

6. What comes next

The next arc is the integrated system test. The self-maintenance decisions will feed into that test by setting requirements for update compatibility and rollback behavior across the federation.

7. What this changes

  • The self-maintenance arc is closed.
  • The desktop’s software architecture will support secure updates, health monitoring, and rollback from the start.
  • Full autonomous patching is deferred until the basic update process is proven.
  • The next cycle can proceed to testing with these requirements in mind.