1. When the system must fail without failing

Stanisław Lem’s Solaris returns as the recalled work because the station’s survival depends on maintaining core functions while the ocean produces phenomena it cannot fully explain. The desktop’s flight software must do the same: maintain critical functions while internal faults produce local effects that do not spread.

This entry defines success and failure for the software fault injection test.

2. Minimum success

The test passes if:

  • Critical services continue through every single-task fault case without data loss.
  • Corrupted or malformed messages are rejected or sanitized before they cause crashes.
  • Resource exhaustion in one task does not prevent critical tasks from meeting deadlines.
  • A failed software activation rolls back to the previous image cleanly.
  • The platform detects and contains cascading faults before they reach safe-mode-critical functions.
  • Ground receives a coherent status report and event log after each injected fault.

This minimum says the desktop’s software architecture can absorb common faults.

3. Full success

A stronger result would add:

  • Non-critical services also recover without manual intervention.
  • Recovery is fast enough that external customers do not notice transient faults.
  • The platform predicts resource trends and acts before hard failures.
  • Fault injection results match predictions from architecture analysis.
  • No single software fault requires a platform reboot to recover.

This stronger result supports a claim that the desktop’s software is robust enough for extended autonomous operation.

4. Failure modes

The test fails if any of the following occur:

  • A critical service is lost during a single-task fault case.
  • A corrupted message causes a task crash or system reset.
  • Resource exhaustion in a non-critical task propagates to critical tasks.
  • A failed update cannot be rolled back.
  • A cascading fault reaches safe-mode functions.
  • Recovery actions are not logged or are incomprehensible to ground.
  • The platform does not return to a stable state after the fault is cleared.

Each failure mode points to a fix in task isolation, message validation, resource budgeting, update design, or fault escalation policy.

5. What this changes

  • The software fault injection test has clear pass and fail criteria.
  • The criteria separate containment from graceful recovery.
  • The next entry will close the test arc.