Fixed TMR is one baseline, not the default
Two more policies went into the simulation. Against cold standby with spares that barely age, the shrinking quorum does less work, and the page now says so.
dusk compared the shrinking quorum against fixed triple redundancy and a standby simplex, and the paper’s first version had treated fixed TMR as what spacecraft fly. Stepping down from three to two to one is in JPL’s STAR computer from 1971 and in the Shuttle’s redundancy management, so fixed TMR is one baseline among several, and the errata now say that version 1.0 did not say so clearly enough.
Two baselines went in. TMR with an unchecked fallback is the shrinking quorum without the self-check: it steps down the same way, and its last processor runs at full rate and never tests itself. It does 25% more useful work and a hundred times the wrong results, and 87% of its missions deliver at least one. Cold standby is the nearest model of dual string with autonomous switchover: one processor powered, the rest off, switched on in order. How fast an unpowered spare ages is not known, so it is a parameter, swept from 0.1 to 1.0 of the powered rate, and the report prints both ends so that no single guess reads as the result. At 1.0 it is the standby simplex. At 0.1 the shrinking quorum does 0.92 of its work, and the crossover is about 0.20. Cold standby has more missions with a wrong result at every rate, 61% at 0.1 against 20%.
Risk is now a number of its own, the share of missions with at least one wrong day, with a bootstrap interval. Every term has a definition where the README used to describe it in prose: a day of service is exactly one of correct, lost, wrong or idle. A script fails CI if the README misses any number the page shows.
Neither baseline adds a random draw, so every number that existed is unchanged. 1.34x stands, and now says it assumes no ground support after launch. What changed is what it is compared to.