The fault presented as a drift.
Line-to-line tie-line errors were running 1.2 nT across the block. That's not sensor noise; that's a real offset. Our reflex was to suspect the cesium vapour sensor or the heading compensation. Both checked out. We re-ran diurnal correction with a denser base station lattice. Still 1.2 nT.
The IGRF was the error.
Our levelling workflow had an IGRF model computed for the block centre, cached from a previous India campaign. Transplanting that workflow to the East African equator left a 1.2 nT residual from the geomagnetic gradient across a 20km block at 4° latitude — something that is negligible at 28° latitude in India and catastrophic at 4° in Uganda.
Fix, in one paragraph.
We re-ran IGRF per-line, not per-block, using the current CHAOS-7 model. Drift collapsed to 0.18 nT. We also added a mandatory latitude check to the preflight script — if the survey block is less than 500km from the equator, IGRF is per-line, not per-block, always. A 30-line change in our pipeline. Three days of grief to find it.
What this cost, and what it saved.
The client's deliverable slipped by 36 hours. We took the hit. But the fix is now baked into every subsequent Flybi aeromagnetic campaign — we haven't seen a latitude-related tie-line error since. And the next African campaign went green on day one.
The general lesson.
A workflow that works at one latitude is not guaranteed to work at another. When a geophysicist tells you "the correction is negligible at our scale," always ask at whose scale. Industrial intelligence is mostly a game of boundary conditions — get them wrong once per campaign and the deliverable slips. Get them right and the drill target is defensible.