# EXP-005 — Infrastructure failures against Mercury retrograde windows **Status:** reporting, first dataset connected **Protocol version:** v1.1 **Filed:** 2026-07-24 **Dataset registered:** 2026-08-21 **Experiment slug:** `retrograde-audit` This document is the preregistration. Its SHA-256 is displayed on the audit page. --- ## 1. Question Mercury retrograde is popularly blamed for communication breakdowns, technology failures and travel disruption. Do measurable failures actually cluster inside retrograde windows? ## 2. What retrograde is Mercury does not reverse. It appears to because Earth, on a faster inner-track orbit, overtakes it — the apparent reversal is a projection effect of two bodies moving at different speeds around the same star, and it is as predictable as a train appearing to slide backwards when another passes it. The windows are therefore perfectly real, perfectly computable, and entirely a matter of viewing geometry. Nothing about them reaches a flight schedule. The question is whether the events blamed on them nonetheless cluster there, which is an empirical claim and worth measuring rather than mocking. ## 3. How the windows are determined Computed, not copied. Mercury's and Earth's positions are derived from JPL/Standish approximate orbital elements, converted to geocentric ecliptic longitude, and a window is the interval over which that longitude decreases. Stations are found by bisection to the hour. The computation is checked against facts known independently of it: successive windows must be separated by Mercury's synodic period of 115.88 days, three to four must occur per year, each must last about three weeks, and Mercury's elongation from the Sun must never exceed roughly 28°. Those checks run in the test suite. Published dates that cannot be independently verified by a reader are worth no more than the arithmetic behind them, so the arithmetic is public. Windows that are incomplete at the edge of a scan are discarded rather than reported with a boundary date standing in for a station. ## 4. Hypotheses - **H₀ (null):** the daily rate of the measured failure is the same inside and outside retrograde windows. - **H₁:** the rate differs. Two-sided. A rate that is reliably *lower* during retrograde would be just as interesting and just as reportable. ## 5. Datasets ### Connected: US domestic flight delays - **Publisher:** US Bureau of Transportation Statistics (BTS) - **Table:** Reporting Carrier On-Time Performance (1987-present) - **Connected extract:** 2024-01 through the latest released complete month - **Event:** `ArrDel15 = 1`, a flight arriving at least 15 minutes after its scheduled arrival time - **Exposure:** the sum of `Flights` over every reported scheduled-flight row, including cancelled and diverted rows in the denominator - **Required coverage:** at least six complete computed retrograde windows The definition, table, and reporting program all predate this project. BTS publishes the table monthly and documents the 15-minute threshold. Each monthly official ZIP is retained by URL and SHA-256 in the generated snapshot. The ingestion code reduces individual flight rows to daily counts of scheduled, delayed, cancelled, and diverted flights; no row-level fields capable of supporting an unregistered subgroup search reach the analysis file. `FlightDate` is a local calendar date in the source table. A daily row is classified as retrograde when 12:00 UTC on that date lies inside the computed station-to-station window. Month and weekday covariates are derived from the same date. This midpoint rule fixes the treatment of station dates, where the source has daily rather than hourly resolution. The first registration range begins 2024-01-01. The automated refresh may add newly released months but may not rewrite the event, exposure, date classification, covariates, or model. BTS can revise an archive; if its hash changes, the new hash and resulting daily counts replace that month and the site history records the change. ### Candidate-source register | Source | Event counted | Disposition | |---|---|---| | US BTS, Reporting Carrier On-Time Performance | scheduled flights delayed ≥ 15 minutes | accepted; first connected dataset | | Cloudflare Radar / public status-page archives | recorded service outages | not yet examined | | Wikipedia edit-revert logs | reverted edits per day | not yet examined | A further dataset qualifies only if it is published independently of this project, has a definition of the event that predates our interest in it, and covers at least six complete retrograde cycles. Any source examined and rejected is named here with the reason, so the set of things we looked at cannot be quietly narrowed to the one that worked. ## 6. Analysis Fixed before any dataset is connected: - **Test:** the daily event rate inside windows versus outside, by Poisson regression with an offset for exposure (flights scheduled, services monitored), two-sided, α = .05. - **Effect size:** rate ratio with a 95% confidence interval. The rate ratio is the headline number, not the p-value; an effect too small to matter should read as too small to matter. - **Seasonality:** retrograde windows are not uniformly distributed across the calendar, and neither are flight delays. Month is included as a covariate, so a January retrograde is not credited with January weather. - **Day of week:** included for the same reason. - **Minimum data:** six complete cycles before any test is run. ## 7. The shadow periods Astrological practice often includes a "shadow" period of one to two weeks either side of the window proper. Extending a window until an effect appears is the definition of a garden of forking paths, so the primary analysis uses the astronomical window only, and a single prespecified secondary analysis uses the window plus seven days either side. Both are reported whatever they show. ## 8. Prespecified threats to validity 1. **Seasonality**, addressed in §6. 2. **Multiple datasets.** Testing several sources is several chances at a spurious result; Holm correction is applied across all datasets analysed, and every dataset examined is listed whether or not it was analysed. 3. **Reporting artefacts.** Outage counts reflect monitoring coverage as much as outages. Only sources with stable methodology across the period qualify. 4. **The claim is unfalsifiable in practice for some believers.** A null result will be reported as a null result; nobody's mind is the outcome measure. 5. **Overdispersion and serial dependence.** Weather systems and network disruptions make daily delay counts more variable than an ideal Poisson process. The filed Poisson interval remains the confirmatory result, and its Pearson dispersion diagnostic is published beside it so false precision is visible rather than hidden. A clearly labelled, non-confirmatory quasi-Poisson sensitivity interval scales the standard error by that dispersion. No causal interpretation is made. ## 9. What would change our minds A rate ratio distinguishable from 1 under the preregistered test, surviving the seasonal covariates and the correction, would be a positive result and published as one — followed by an attempt to find the confound, because a genuine association between planetary geometry and flight delays would have a mundane explanation long before it had an astrological one. ## 10. Revision history | Version | Date | Change | |---|---|---| | v1.1 | 2026-08-21 | Registered the BTS Reporting Carrier On-Time Performance dataset and fixed the source fields, exposure, daily station-date rule, provenance hashes, and append-only refresh policy. Hypotheses and analysis in §§4 and 6 are unchanged. | | v1.0 | 2026-07-24 | Filed. No dataset connected. | §§4 and 6 are frozen. The v1.1 dataset amendment records operational details needed to connect the already-named source; it does not change either section.