1. The moment the tester decides if HARLIE is real
David Gerrold’s When HARLIE Was One returns as the recalled work because the testers must eventually decide whether the computer’s behavior is good enough to continue the program. The desktop’s compute and storage test has the same moment. A test is not useful unless the pass/fail line is drawn before the data comes in.
This entry defines success and failure for the compute and storage test matrix.
2. Success criteria
A successful test run means the platform can be trusted to operate in orbit:
- Fault detection: single-bit errors are detected and corrected; multi-bit errors are detected and recovered without silent data corruption.
- Recovery: SEFI, latch-up, and power-fault scenarios result in controlled restart, with platform safety tasks resuming within a bounded time.
- Storage redundancy: loss of one drive from a redundant set is fully recoverable without customer data loss.
- Scrubbing: scheduled or triggered scrubbing finds and repairs injected silent errors.
- Migration: a workload moved between cells completes correctly and produces the same result as an unmigrated workload.
- Scheduling: safety-critical and platform tasks meet their deadlines even when customer workloads are saturating compute.
- Policy: forbidden actions are refused and logged.
- Data survival: data queued for downlink survives compute restart and is delivered without corruption.
3. Failure criteria
A failure is any result that would be unacceptable on orbit:
- silent data corruption that is not detected by checksums, ECC, or application verification;
- a workload that crashes, hangs, or produces wrong results after a single-bit flip;
- storage redundancy that cannot reconstruct data when one copy fails;
- a filesystem that requires manual repair after power loss;
- a migration that loses state or leaves two inconsistent instances running;
- a safety task that misses a deadline during contention;
- a policy violation that succeeds without refusal or log entry;
- customer data that disappears after a subsystem restart.
4. Marginal results
Some results are not clean passes or failures:
- a fault that is detected but causes a long recovery that exceeds the mission’s availability requirement;
- a storage rebuild that succeeds but takes so long that it crowds out customer work;
- a thermal throttle that protects hardware but makes the platform unable to meet its compute commitments.
These are redesign triggers. They do not fail the test, but they fail the mission unless addressed.
5. What this changes
- Each test in the matrix now has a clear pass/fail/marginal definition.
- The next entry will close the compute test arc and decide what to carry forward.