1. The computer that had to be tested before it could be trusted

David Gerrold’s When HARLIE Was One returns as the recalled work because much of the novel is about testing: a team tries to determine whether HARLIE, a computer designed to think, is actually thinking, and whether its answers can be trusted. The desktop is not an artificial intelligence, but its compute and storage must be tested with the same skepticism. The question is not whether the hardware boots; it is whether the hardware survives the environment and produces correct results when it matters.

This entry asks why the desktop needs a ground test of its compute and storage.

2. Why reading and wondering are not enough

Entries 789 through 792 established what the literature knows about COTS compute, storage reliability, and flight software in orbit. Entries 793 through 796 established that the desktop should manage its own workloads, storage, and policy boundaries autonomously. Both arcs are necessary but not sufficient. A radiation-tolerance paper is a prediction. An SSD datasheet is a promise. A scheduler design is a plan. None of them prove that the desktop will keep working after six months of South Atlantic Anomaly transits.

The test must answer three questions:

  • Does the compute hardware survive the expected radiation environment without silent corruption?
  • Does storage redundancy actually recover data when drives fail or bits flip?
  • Does the autonomy correctly schedule workloads, migrate them under degradation, and protect customer data?

3. What happens without the test

A compute and storage system can fail in ways that look healthy until it is too late:

  • a CPU that passes every bench test but experiences undetected single-event functional interrupts in flight;
  • a DRAM bit flip that corrupts a telemetry value without crashing the program;
  • an SSD controller that silently remaps bad blocks until the mapping table itself is lost;
  • a workload migration that copies state correctly but leaves the old instance running;
  • a thermal throttle that slows compute below the rate needed to clear the downlink queue;
  • a power fault that leaves the filesystem in an inconsistent state.

Each of these is cheaper to find in a test than after launch.

4. What the test protects

The compute and storage test protects:

  • The desktop: from becoming a compute-rich platform that cannot trust its own results.
  • The mission: from losing data products because storage failed or corruption went undetected.
  • The customers: from paying for processing that produced wrong answers or never finished.
  • The operators: from discovering too late that the autonomy cannot handle a degrading cell.

5. What this changes

  • The compute and data phase needs a closing test arc, not just reading and wondering.
  • The test must cover fault injection, storage redundancy, workload migration, and power-fault recovery.
  • The next entry will define the test matrix.