In many cases there is some opportunity to validate information before it goes out. In others ... not so much.
Even a missile-launch alarm would typically have some opportunity to be assessed based on alert values (e.g., increasing or decreasing hostilities), and perhaps multiple sensor systems (boost-phase IR tracks plus radar signatures, known planned non-military launches, etc.).
In the case of earthquakes, their very unpredictability, the brief period of time avialable in which to make an alert (often only a few seconds, in cases a few minutes) means that manual cross-validation is all but impossible. Still, checks across multiple seismic detectors, preferably isolated from one another to the maximum extent possible, would be one potential check, though you'd still need to have multiple sensors relatively close together, as the time of propagation of seismic waves is both what provides the early alert and causes the damage. (Relative speeds of P (primary) and S (secondary) waves helps --- the p waves tend to cause less damage, but provide an earlier alert, the s waves arrive more slowly but do most of the damage.
At the surface, speed differential is about 3 km/s, meaning there's roughly 1 second of arrival differential for each 3km the observer is from the epicentre. (Subsurface waves travel faster.) Each 3km of separation of seismic stations costs 1 second of advanced warning time, plus whatever system logic and response times exist.
But given that major earthquakes can occur suddenly and without warning or pre-shocks, you really do pretty much have to be ready for anything at any time. And alerting systems need to take this into account. One option might be to have the logic on the phone itself --- it would trigger an alert, but only if some number of independent alarms were detected. One would be unlikely to trigger a false alarm, but two or three near-simultaneous alerts would indicate a major quake.
Penalising false alarms is probably the wrong approach. An engineering philosophy, of determining paths to either false positives or false negatives (each of which have high impact), and eliminating those.
> In the case of earthquakes, their very unpredictability, the brief period of time avialable in which to make an alert (often only a few seconds, in cases a few minutes) means that manual cross-validation is all but impossible.
For the earthquake alarm there is absolutely no manual intervention. These are automatic alarms exploiting the fact that the speed of light in air is faster than the speed of sound in rock. Earthquakes move approximately 1km/s, so if you are 3km away from the epicenter, you get a maximum of 3 seconds warning. Throw a human in the loop and there's no way they'd respond fast enough.
Often these false alarm incidents occur due to issues with the "last mile" of the system in the US, which might be substantially alleviated if there was a federal effort to get automation in place. In a nuclear strike, for example, NORAD would issue the alarm ("attack warning") via FEMA NAWAS and EAS after several documented and proceduralised validation steps.
The problem is that after FEMA NAWAS delivers the alert (audibly) to state and local EOCs, the next step is a ???. In those areas that do have some type of state or locally operated warning system, it's usually just some staff member pushing a button... and the button pushing is where mistakes can and do get made. In theory IPAWS and CAP will introduce automation at this step, but there's a lot of issues that have made CAP implementation slow, mainly the budgetary limitations of local governments and the fact that the major IPAWS/CAP software vendors expect very high prices.
Obviously in the case of earthquake warnings the options for manual validation are very limited due to the time constraints... but in general false-positive incidents have come from fat fingering, not misidentification by technical systems. There are good opportunities to put safeguards in place for automated systems to reduce false positives. For example (although I believe this is partly manual), as I understand it the Pacific Tsunami Warning Center will not issue a full warning until multiple data buoys have indicated a tsunami wave. That doesn't guarantee that it will be of damaging proportions once it reaches our coasts due to the vagaries of ocean modeling (i.e. in the case of the major Japanese earthquake in which a tsunami did occur but was quite small by the time it reached Hawaii, so the warnings felt a bit silly), but it does ensure that it's not an outright false positive.
My point is that more broadly false alarms a failures to alarm must be individually reviewed and cause for failure identified. Assuming that all more most failures are last-mile will work ... until it doesn't. Reviewing and demonstrating that the failure was or was not "last-mile" is what's required.
False signal, improper sensor detection, bad comms (generating or inhibiting signal), bad processing, confusing training or testing events for actual, having an actual alert during a test or drill, and errors in broadcasting alerts to the general public and/or the response to those alerts, might all be components to assess. "Last mile" concerns that last stage.
Since it's one that's often outside the core of an alerting system, and may involve many independent entities (people and/or organisations), it is likely to malfunction. Streamlining procedures and drilling frequently will help identify any such issues and iron them out.
Note that though tsunamis move quickly (> 800 kph / 500 mph in open ocean), the fact that they are often travelling immense distances (100s or 1,000s of miles or km) means that there are almost always many minutes, and quite often many hours for alerts to be sent and responded to. Earthquakes afford seconds to minutes, the timeframes are nearly two orders of magnitude less.
Even a missile-launch alarm would typically have some opportunity to be assessed based on alert values (e.g., increasing or decreasing hostilities), and perhaps multiple sensor systems (boost-phase IR tracks plus radar signatures, known planned non-military launches, etc.).
In the case of earthquakes, their very unpredictability, the brief period of time avialable in which to make an alert (often only a few seconds, in cases a few minutes) means that manual cross-validation is all but impossible. Still, checks across multiple seismic detectors, preferably isolated from one another to the maximum extent possible, would be one potential check, though you'd still need to have multiple sensors relatively close together, as the time of propagation of seismic waves is both what provides the early alert and causes the damage. (Relative speeds of P (primary) and S (secondary) waves helps --- the p waves tend to cause less damage, but provide an earlier alert, the s waves arrive more slowly but do most of the damage.
At the surface, speed differential is about 3 km/s, meaning there's roughly 1 second of arrival differential for each 3km the observer is from the epicentre. (Subsurface waves travel faster.) Each 3km of separation of seismic stations costs 1 second of advanced warning time, plus whatever system logic and response times exist.
But given that major earthquakes can occur suddenly and without warning or pre-shocks, you really do pretty much have to be ready for anything at any time. And alerting systems need to take this into account. One option might be to have the logic on the phone itself --- it would trigger an alert, but only if some number of independent alarms were detected. One would be unlikely to trigger a false alarm, but two or three near-simultaneous alerts would indicate a major quake.
Penalising false alarms is probably the wrong approach. An engineering philosophy, of determining paths to either false positives or false negatives (each of which have high impact), and eliminating those.