Experiment V · protocol
The Retrograde Audit
Mercury retrograde gets blamed for delayed flights, dropped calls and broken deployments. The windows are real and computable to the hour. Whether anything actually clusters inside them is a separate question, and an answerable one.
What retrograde actually is
Mercury does not reverse. It appears to because Earth, on a faster inner-track orbit, overtakes it — the same effect as a train sliding backwards when another passes it. The apparent reversal is viewing geometry, and it is as predictable as a timetable.
That makes the windows genuinely real. They are not a belief, they are a projection effect you can compute. Which is exactly why the question of whether anything clusters inside them can be settled by counting rather than by argument.
These dates are computed, not copied
Retrograde dates are easy to find and impossible to check by looking at them. So they are derived here from JPL orbital elements — Mercury's and Earth's positions, converted to the longitude you would measure from the ground — and the derivation is tested against facts known independently of it: successive windows must be one synodic period apart (115.88 days), three to four must fall in a year, each must run about three weeks, and Mercury must never appear more than about 28° from the Sun. If the arithmetic were wrong, those checks would fail.
src/lib/retrograde.ts ↗ · the checks ↗
Windows
| Station · retrograde begins | Station · direct again | Days |
|---|---|---|
| 15 Mar 2025 | 7 Apr 2025 | 23 |
| 18 Jul 2025 | 11 Aug 2025 | 24 |
| 9 Nov 2025 | 29 Nov 2025 | 20 |
| 26 Feb 2026 | 20 Mar 2026 | 23 |
| 29 Jun 2026 | 23 Jul 2026 | 24 |
| 24 Oct 2026 | 13 Nov 2026 | 20 |
| 9 Feb 2027 | 3 Mar 2027 | 22 |
| 10 Jun 2027 | 4 Jul 2027 | 24 |
| 7 Oct 2027 | 28 Oct 2027 | 21 |
| 24 Jan 2028 | 14 Feb 2028 | 21 |
| 21 May 2028 | 14 Jun 2028 | 24 |
| 19 Sept 2028 | 11 Oct 2028 | 22 |
ALL DATES UTC · COMPUTED, NOT COPIED
No dataset is connected
And so there is no result on this page. The protocol is filed first, which is the point: the analysis is fixed before any data is seen, and a rate ratio published later cannot have been chosen to fit what turned up.
Candidate sources are named in the protocol — flight on-time performance, outage archives, edit-revert logs. A dataset qualifies only if it is published independently of this project, defines its event in a way that predates our interest, and covers at least six complete cycles. Any source we examine and reject will be listed here with the reason, so the set of things we looked at cannot be quietly narrowed to the one that worked.
About the shadow periods
Astrological practice often extends the window by one to two weeks either side. Stretching a window until an effect appears is the textbook garden of forking paths, so the primary analysis uses the astronomical window only, and exactly one secondary analysis uses the window plus seven days either side. Both get reported whatever they show.
The filed protocol
SHA-256 585f702d2f0c2b13350548d05611d1ac25de1e803bdd09955cac38595eb8fab8
Known ways this could mislead
- Retrograde windows are not spread evenly across the calendar, and neither are flight delays. A retrograde falling in January would otherwise be credited with January weather, so month and day of week are covariates from the outset.
- Outage counts measure monitoring as much as they measure outages. Only sources whose methodology is stable across the whole period qualify.
- Testing several datasets is several chances at a spurious result, so Holm correction is applied across all of them — and every dataset examined is listed, analysed or not.
- A rate ratio can be statistically distinguishable from 1 and still far too small to matter. The rate ratio is the headline number here, not the p-value.