dotbion

Satellites carry fault-protection software whose job is to keep them safe when hardware breaks. It's usually tested one failure at a time, but in the real world failures stack up, and the fix for one problem can make the next one much worse. FaultForge goes looking for those cases before launch. Meta's Muse Spark proposes multi-fault scenarios for a simulated CubeSat in Basilisk, an open-source spacecraft simulator, and learns from each near-miss where the safety logic is weakest. Every failure it finds is shrunk to the smallest version that still breaks and saved as a one-command replay. Our headline case: a reaction wheel picks up mild friction, the policy isolates it, and that uses up its only isolation. When a second wheel then dies, the spacecraft can't recover. Turn off just that one isolation decision and the failure goes away in 24 of 24 nearby scenarios. Across 276 policy-caused failures we found three defect patterns, plus a real bug in the policy code where it breaks ties by wheel number instead of by how badly the wheel is misbehaving. Muse also proposes fixes, but it doesn't get the final say. Every patch is re-run against a 3,508-run regression suite. The strict gate rejected all 12 proposals. A looser budget gate accepted one, which fixed 26 runs, broke 1 that was previously clean (flagged and documented), and fixed 4 held-out cases without breaking any. At equal compute, Muse found failures about 46x more often than random search and about 9x as many distinct fault combinations as CMA-ES. Our ablations suggest the gain comes from Muse's feedback loop finding where failures live, not just from picking the right fault types.