GPS corrects for relativity twice, in two different places. Satellite clocks are built to run slow before launch: the onboard fundamental is set to 10.2299999954326 MHz rather than 10.23 MHz, a fractional offset of −4.4647×10⁻¹⁰. Then every receiver applies a second, periodic correction for orbital eccentricity, using a formula and a constant printed in the governing interface specification. Both corrections are specified in advance. Neither is discovered by monitoring.
Ross Jones — Founder, The Hopium Lab. Last modified 22 July 2026.
Twenty-four shipped products across fifteen sectors. The survivors specified their known errors up front, rather than waiting to observe them. Engineering commentary; not navigation or legal advice.
What are the two relativistic effects on a GPS satellite clock?
Gravity speeds the satellite clock up, orbital velocity slows it down, and gravity wins by about six to one.
A GPS satellite sits on a semi-major axis of 26,559.6 km — some 20,181 km of altitude — moving at 3,874 m/s. Weaker gravity at that height — a higher gravitational potential — runs the onboard clock fast by roughly 45.65 microseconds per day. Orbital speed runs it slow by roughly 7.21 microseconds per day. Net gain to the satellite.
Ashby's 2003 review in Living Reviews in Relativity gives the exchange rate: one nanosecond of timing error is about 30 cm of position. Tens of microseconds a day sits four orders of magnitude outside that budget.
Where does GPS apply the correction?
In the satellite's clock hardware before launch, and in your receiver at every epoch. Both formulas are fixed in a published specification before anything flies; only one of them runs before launch. Call the pattern a specified correction: a correction whose formula and constants are fixed in a published specification before the system ships, so every implementation computes the same value from the same inputs.
Correction one lives in hardware. IS-GPS-200N §3.3.1.1 — US Space Force, current revision, 01-AUG-2022 — puts the satellite's frequency source at a nominal 10.23 MHz as it appears to an observer on the ground, then states that clock rates "are offset by Δf/f = -4.4647E-10 ... This is equal to 10.2299999954326 MHz." Five significant figures of offset, restated as a fifteen-digit frequency, applied on a bench before launch.
Correction two lives in your receiver, and the specification is blunt about whose job it is: "the user's equipment must determine the requisite relativistic correction" (§20.3.3.3.3.1). Every epoch, a receiver computes Δt_r = F·e·√A·sin(E_k), where F = −2√μ/c² = −4.442807633×10⁻¹⁰ s·m^−½.
| Correction | Computed where | Fixed by | Cost of omitting it |
|---|---|---|---|
| Secular rate offset, Δf/f = −4.4647×10⁻¹⁰ | Satellite clock hardware, pre-launch | IS-GPS-200N §3.3.1.1 | 38,575 ns/day of clock rate — largely absorbed by the receiver clock unknown |
| Periodic eccentricity term, Δt_r = F·e·√A·sin(E_k) | Receiver, every epoch, from broadcast ephemeris | IS-GPS-200N §20.3.3.3.3.1 | 22.9 ns (6.9 m of range) at e = 0.01; spec bounds it under 25 m when justifying its omission from almanac time (§20.3.3.5.2.3) |
| Earth-rotation (Sagnac) handling | Receiver, when transforming ECEF geometry to an inertial frame | Not a spec constant — a frame transformation the receiver must get right | Geometry-dependent, so it lands per satellite; Ashby measures 207.4 ns of lag around one eastward equatorial synchronisation path |
The constant every GPS receiver uses for the relativistic eccentricity correction is printed in a US Space Force interface specification to ten significant figures. Not inferred at runtime. Not learned from data. Printed.
Would GPS really drift kilometres a day without relativity?
No, and the most-copied sentence in this topic is misleading. Multiply 38,575 ns/day by the speed of light: 11,564 metres. Almost every page reports that product as accumulated position error, rounded to "about 10 kilometers each day" after Richard Pogge's Ohio State course notes.
Eleven and a half kilometres is a light-travel distance. A receiver does not measure ranges; it measures pseudoranges, because putting a caesium standard in a phone is not a product. It solves four unknowns — three position components plus its own clock bias — which is precisely why four satellites are needed, per Ashby's review. A rate offset identical across every satellite in view is indistinguishable from receiver clock offset, so the solver eats it. The argument is standard receiver theory, not a contrarian reading — it falls straight out of solving for clock bias as a fourth unknown.
Thirty-eight microseconds a day converts to eleven and a half kilometres of light travel — a distance light covers, not a distance a receiver is wrong by. A bias common to every satellite is indistinguishable from receiver clock offset, and every receiver already solves for receiver clock offset.
Relativity is not optional here. The bite relocates.
Which relativistic corrections genuinely degrade your position?
The ones that are not common-mode. Marc Weiss of NIST and Neil Ashby fixed the count at the 1997 PTTI meeting: for the ordinary user of broadcast ephemerides there are "two and only two relativistic effects that must be considered" — the eccentricity term Δt_r, and the geometric path delay: signals propagate at a finite, universally constant c, and the path must be evaluated relative to an inertial frame.
Eccentricity varies per satellite and per orbital position, so nothing absorbs it. At e = 0.01 the amplitude is 22.9 ns — 6.9 metres of range error landing differently on each satellite, and therefore landing in your position. Earth-rotation handling is likewise geometry-dependent, not a common bias.
Skip the secular offset and a receiver mostly copes. Skip the eccentricity term and the answer is wrong in a way no clock unknown can hide.
Why does 45.65 minus 7.21 not equal the constant in the specification?
Because the ground clock sits on a rotating Earth, and the textbook decomposition quietly forgets the rotation. Naive subtraction gives 38.437 µs/day, a fractional offset of 4.4487×10⁻¹⁰. The specification says 4.4647×10⁻¹⁰, or 38.575 µs/day. A 0.36 % gap — well outside rounding, and a physicist will spot it.
Reference the ground clock properly, to the geoid's effective equipotential using the conventional W₀ = 62,636,856 m²/s², and the answer is 4.46453×10⁻¹⁰: agreement with the printed constant to 0.004 %. Ashby calls the geoid "a surface of constant effective gravitational equipotential", and effective is the load-bearing word: rotation is inside it. The 45.65/7.21 split is pedagogy. The operational number is defined against a rotating reference surface.
What did the NTS-2 team do in 1977 that most AI teams skip?
They built the correction mechanism before launch, then deliberately refused to switch it on until they had measured the effect against the prediction.
Ashby tells it in his contribution to Matters of Gravity no. 9 (arXiv gr-qc/9702010, ed. Jorge Pullin, 1997). NTS-2 launched in June 1977 carrying the first caesium clock placed in orbit, at a moment when "there were some who doubted that relativistic effects were real". A frequency synthesiser was built into the clock system so the correction could be switched on after launch, once the on-orbit rate had been measured against theory. The clock ran uncorrected for about twenty days. Measured rate: +442.5 parts in 10¹² fast, which uncorrected would produce "timing errors of about 38,000 nanoseconds per day". Predicted minus measured: 3.97 parts in 10¹².
Predict. Build the mechanism and ship it switched off. Measure. Only then commit. That sequence is the whole discipline, and it is not what "we'll watch the dashboards after launch" means.
What does GPS relativity have to do with AI systems?
Everything, on one narrow axis: a systematic error you can characterise belongs in the architecture, not in the alerting.
The wrong lesson is design-time versus runtime. Half the GPS correction executes at runtime, in the chip in your pocket, every epoch, by design — Ashby notes the eccentricity term was pushed to receivers because 1970s onboard computers were too weak. The axis that holds is specified and deterministic versus observed and patched: a closed-form formula with fixed constants that every implementation on Earth computes identically. Nothing in a specified correction is discovered by watching a dashboard go red.
Most AI teams invert the order. Ship, instrument, wait for drift, patch empirically. That order produces a fudge factor nobody can derive, at a layer nobody documented, tuned against an incident nobody can reproduce. My own auditor runs seventeen categories against a launch date precisely because post-hoc discovery is the expensive path.
The honest concession, because the analogy is attackable: relativistic clock drift is closed-form and exactly computable, with a constant printable to ten significant figures. Most model bias is empirical, data-dependent, drifting, and not characterisable in closed form. The analogy does not transfer wholesale; claiming otherwise smuggles in a determinism machine learning does not have. What transfers is narrower: when an error is characterisable, structure beats monitoring, and the NTS-2 sequence is the discipline worth importing. Tokenisation effects, retrieval recall floors, position bias in a judge rubric, floating-point arithmetic — all characterisable today, all better handled structurally. Which parts should never be an LLM and reproducible LLM systems are the same argument in other clothes.
Can you rebuild the answer without calling the model? If not, you don't have a system. You have a demo with a try/except around it.
How does the specified-correction discipline fail in practice?
Five named ways, all observed rather than theorised.
- Monitoring-as-design. No characterisation of a known error, a dashboard instead, and an alert threshold set by whoever configured it last. Detection is not correction.
- Common-mode blindness. Assuming every bias surfaces in aggregate metrics. The secular offset hides inside a solved-for unknown; the eccentricity term does not. Aggregate accuracy conceals the errors that cancel on average and bite per case.
- Constant confusion. −4.4647×10⁻¹⁰ (dimensionless rate offset) and −4.442807633×10⁻¹⁰ s·m^−½ (eccentricity coefficient) look nearly identical and are unrelated quantities. A correction written without units is a correction copied without understanding.
- Unversioned correction. A formula living in application code rather than a specification, so two implementations silently disagree and neither is wrong on paper. The GPS analogue is citing ICD-GPS-200 or Revision H as current when Revision N of 01-AUG-2022 governs.
- The uncharacterised residual. GPS still runs continuous ground-segment clock estimation; the factory offset only removes the bulk. Structure shrinks a residual and never abolishes it. Anyone selling the abolition is selling something.
Can you check every number here yourself?
Yes. Nothing is fitted: μ, c and Δf/f come from IS-GPS-200N, the equatorial radius from WGS-84, the geoid potential W₀ from the IERS conventions, and √A is a nominal orbit value. Fork it, run it, argue with it.
"""GPS relativity from published constants. Nothing fitted."""
from math import sqrt
mu = 3.986005e14 # IS-GPS-200N 20.3.3.3.3.1
c = 2.99792458e8 # IS-GPS-200N 20.3.3.3.3.1
sqrtA = 5153.6 # sqrt(semi-major axis), m^(1/2), nominal orbit
R_e = 6378137.0 # WGS-84 equatorial radius
W0 = 62636856.0 # IERS conventional geoid potential
DAY = 86400.0
a, spec = sqrtA**2, 4.4647e-10 # spec: IS-GPS-200N 3.3.1.1
v = sqrt(mu / a) # orbital speed
sr = v*v / (2*c*c) # SR: satellite clock slowed
gr = (mu/(c*c)) * (1/R_e - 1/a) # GR: satellite clock sped up
naive = gr - sr # textbook decomposition
geoid = W0/(c*c) - mu/(a*c*c) - sr # ground clock on ROTATING geoid
F = -2*sqrt(mu) / (c*c) # eccentricity coeff, s/m^(1/2)
print(f"orbit a={a/1e3:.1f}km alt={(a-R_e)/1e3:.1f}km v={v:.1f}m/s")
print(f"GR +{gr*DAY*1e6:.2f} SR -{sr*DAY*1e6:.2f} us/d")
print(f"naive {naive*DAY*1e6:.3f} geoid {geoid*DAY*1e6:.3f} "
f"spec {spec*DAY*1e6:.3f} us/d")
print(f"err geoid {abs(spec-geoid)/spec*100:.3f}% "
f"naive {abs(spec-naive)/spec*100:.2f}%")
print(f"pre-launch {10.23e6*(1-spec)/1e6:.13f} MHz df {10.23e6*spec:.7f} Hz")
print(f"light travel {spec*DAY*c:.0f} m/day <-- NOT position error")
for e in (0.01, 0.02): # peak eccentricity term
amp = abs(F) * e * sqrtA
print(f"ecc e={e:<5} {amp*1e9:.2f} ns = {amp*c:.2f} m range")
Output reproduces the specification exactly: 10.2299999954326 MHz, and df 0.0045674 Hz against the printed Δf of −4.5674E-3 Hz. A correction you can regenerate is one you can defend in a review. A correction copied off a course page is a number you are hoping about.
Ross Jones, Founder, The Hopium Lab. Last modified 22 July 2026. Engineering commentary; not navigation or legal advice.