A Thunderclap, a False Quake Alert, and a Wrong Tag: Inside the Guts of an Automated Detection System

16:56. The sky over Mexico City cracked open with a thunderclap. Almost in the same instant, a push alert surfaced on thousands of phones across the city — possible local earthquake. Many who received it found the memory of a tremor two nights earlier rising up: the small quake recorded on 28 September at magnitude 2.2. When two events land this close together, the mind refuses to reconcile the arithmetic; it reaches for the simplest explanation. A thunderclap, and immediately after it an alert — the verdict is nearly pre-written: a quake has arrived. But it had not. Within minutes it became clear that what happened was not an earthquake but lightning. SkyAlert's experimental local-seismic sensor installed in the Mixcoac area of Mexico City misread the vibration of the thunder as a seismic signal. A technical system, a natural sound, and human recent memory — three separate things combining to manufacture a false alert.

I want to treat this incident as a system-design question. Because a false positive is not merely an error; it is a kind of boundary marker for how well a system has learned to recognise the truth. From years of watching data pipelines and match analysis, I have learned one thing: a system does not err arbitrarily — it does exactly what its learned rules tell it to do. The error lives in our expectation. So the question is not "why did it go wrong" but "which rule made this wrong outcome inevitable."

SkyAlert is a well-known earthquake-warning service in Mexico City. Sensors placed across the city try to detect ground movement, and when the system judges there is risk, it sends an alert to the user's phone. At the centre of this incident was an experimental local-detection setup in Mixcoac. The word "experimental" matters here. When any detection system is being built, its greatest enemy is noise. What a seismic sensor records can be the trace of many things besides an earthquake's vibration — heavy vehicles passing nearby, construction work, and certainly lightning. If a system cannot recognise lightning, then to that system the vibration of thunder and the vibration of a quake look nearly identical. On 30 September at 16:56, that is exactly what happened. The sensor picked up a vibration, the algorithm assumed it fell within the seismic range, and a message went out to users.

One point needs clarifying. No one spread this alert deliberately. The system erred while trying to do its job. And the system itself conceded the error — it is described as "under development." So it is more reasonable to see the incident not as a major failure but as the natural surfacing of a technical limit. But the naturalness of a limit and its effect on the public are two different things. When a city's people receive a phone alert in the same instant as a thunder's roar, the matter does not feel like a "natural limit" to them — it feels like fear. Within minutes the national seismological service made it clear: there had been no earthquake. But in those few minutes, a flood of questions poured onto social media.

Look closely at that moment and you see a false alert is really a two-layer problem. The first layer is technical: the system's sensors analyse vibration frequency and profile but cannot determine whether the vibration came from underground or from the air. The ground vibration produced by lightning often resembles that of a small earthquake. If the system only checks "is there vibration or not," it cannot tell lightning from a quake. The value of a detection system lies not in its sensitivity but in its capacity to discard — what it consciously ignores is its true identity. If there is no rule to discard lightning, every storm becomes a false alert.

The second layer is psychological, and it is the more cunning of the two. The magnitude-2.2 quake of 28 September was real. When the thunderclap two days later coincided with the alert, the human mind weighted the recent event more heavily. This is recency bias. The shorter the gap between the thunder and the alert, the stronger this bias becomes. An alert's credibility depends not on its accuracy but on its timing — a correct alert arriving at the wrong moment still reads as false. Here system and human erred together, but for different reasons: the system erred because its rules were incomplete, the human erred because the memory was fresh.

Now to the part that makes this incident genuinely interesting to me. The analytical framework this incident was fed into was a football-analysis framework — formations, pressing triggers, half-spaces, transfer valuation. But there is not a single football-related sentence inside the event. No club, no player, no coach, no competition. Only thunder, sensors, and an app. In other words, the system made exactly the error it was meant to catch: it failed to distinguish signal from noise. The football framework hunted for a connection between the vibration-sense of the word "earthquake" and the "football" tag, but the connection existed only in sound, not in meaning.

From experience I can say this — I have seen many times in matches that someone spots a trend and jumps to a conclusion the data does not support. If someone sees a team running more in a match and declares it pressed harder, while the passing network shows the ball kept circulating backwards. The numbers are pretty, the meaning is empty. So it is here. The word "vibration" became a keyword trigger, and the system pushed it toward football analysis. In my notebook I used to log the empty corridors — the space the ball never travels through is the most honest data available. Here too, the most honest data was that sensor reading, which was useless to a football framework precisely because there is no football in it. Forcing data into a framework it does not fit is the cardinal sin of analysis.

Let me run a second test. Suppose a lightning filter were added to SkyAlert's system — that is, the system first checks whether there has been atmospheric lightning, and if a seismic reading arrives in that moment, it ignores it — then this false alert would not have occurred. This filter is in fact the mark of the system's maturity. What is interesting is that the same logic applies to football analytics. If you measure a team's pressing success only by counting tackles and interceptions, without calculating the opponent's passing distance, you will reach a wrong conclusion — exactly as the system counted vibrations to identify a quake and mistook thunder for an earthquake.

Now to the part that I think is the true centre of this incident, and more uncomfortable than system design. The technical explanation is easy: thunder, vibration, false alert, corrected within minutes. But the real question lies elsewhere — why did a non-football event enter the football-analysis pipeline? This is where my second-layer correction is needed. At the first layer I asked "why did the system err." But at the second layer I must ask, "where is the error in the framework that took this incident to be football."

The answer is probably in words. The vocabulary around earthquakes and the vocabulary around football overlap in a few unfortunate places: "tremor," "vibration," "movement," "pressure." A keyword classifier that tags by matching words will fall into this trap. I call this error a false-domain-positive. The real test of a classification system is not its accuracy but its capacity to surface its own wrong tags. A system that cannot recognise its own wrong tags will keep carrying every error forward as truth.

Here I want to issue a warning to myself. Because if I try to force this incident into football, I will commit exactly the error I am trying to catch. Mexico City is part of the host nation for the 2026 World Cup; storms can affect stadium operations — this connection is real, but it appears nowhere in the event's description. It is my inference, not information. So it cannot be made the basis of analysis. Here I follow my notebook's rule: tag every observation with a confidence level. The confidence on this connection is low. The rest is inference, not evidence.

So what is the actual significance of this incident? In my reading, it is a public-safety and science-communication story, not a sporting one. Its value lies in two places. One, it is a clean sample of a false positive in an automated detection system — usable to stress-test any pipeline's noise control. Two, it is a textbook example of recency bias — the real quake two days earlier primed people to misread a thunderclap. Both lessons are equally relevant to football analysis, because football analytics commits exactly these two errors every day: mistaking noise for signal, and mistaking recent results for a trend.

One thing needs honest admission here. When this incident first reached me, I assumed it was a sporting event. Because the analysis framework's tag was football. But as I read the evidence, I saw the framework itself was wrong. Then what I needed was to stay loyal not to the framework but to the information. My earlier model — "this is a football event" — was proven wrong, and I am admitting it. An analyst who bends the data to protect his own forecast is no longer an analyst; he is his own decision's lawyer.

Before closing, one real incident comes to mind. About a decade ago, after a big match, I wrote from the statistics that a team's high-intensity running had increased, therefore its pressing had intensified. Later, watching the clips, I understood: the running had indeed increased, but it was running to chase the ball backwards — pointless running. The numbers were pretty, but the story was reversed. Since that day I attach a question to every metric: what does this number convey, and what does it not? The same question applies here — a sensor caught a vibration, but where the vibration came from is the real question. The system did not know the answer, so it gave the wrong one.

Now let us look forward. Two things deserve watching over the coming weeks. First, whether a lightning filter is added to SkyAlert's experimental system. If it is, and false alerts then stop, my model survives — the problem was a lack of noise control. Second, if such a false alert recurs, but this time for a reason other than lightning, then the problem is not confined to lightning; it lies in the system's entire signal-identification method. And for those who run data pipelines, I leave a question: can your classification system catch its own wrong tags, or does it carry every error forward as truth? Because from a system that cannot see its own errors, we will never learn the truth.

One more point must be added, because without it the incident remains incomplete. When a false alert spreads, the damage is not only the few minutes of confusion. The real damage accumulates for the future. A person who has once received a false alert will suspect the next one, even if it is true. This is alert fatigue. In earthquake warning, it is a matter of life and death. In football analytics the damage is less terrifying, but of the same kind: once a wrong forecast is published, the reader's trust in the next correct forecast falls. So every false alert, every wrong forecast, is really a debt — cut from future credibility.

This is why I think the thunderclap of 30 September is not merely a technical curiosity. It is a monument. It reminds us that distinguishing signal from noise is the hardest task of all, whether in a seismic sensor or in match analysis. And a system that cannot make that distinction, however sensitive it may be, deserves suspicion of every alert it issues.

In my notebook I have written: the half-space is not a position; it is the question the pitch asks. Today's incident is one more piece of evidence for that line. The thunderclap was a signal, but the pitch — that is, the system — misread the question. In the next match, or the next alert, we must watch whether the system reads the question correctly.