CAN I HELP? 001: FEMA

This began as a fiction problem. I put a character in an earthquake and realized that the information she needed after the event wasn't presented in the form I expected. That sent me into the actual emergency-alert system, and eventually into the FCC public-comment process.

Then we discovered that the FCC was accepting public input on that very question, through PS Docket Nos. 15-94 and 25-224. The question was “Modernization of the Nation’s Alerting Systems.”

So we developed the idea and submitted it through the FCC Electronic Comment Filing System (ECFS) as a public comment.

Submitted September 2026. Reply comments close September 29, 2026.

The letter is as follows:

To the FEMA IPAWS team,

I am writing to share a feature concept for the existing Wireless Emergency Alert system. As a conceptual artist and designer, my work focuses on user experience. I have been considering how citizens interact with design constraints and technology during high-stress, critical moments. While I am not a hardware engineer, I wanted to submit an outside perspective on how we might leverage our existing data pipelines to fundamentally change human outcomes in a disaster.

The current system is very good at answering the first question in a disaster: “Is something happening, and am I in the affected area?”

I would like to see it go one step further:

When an emergency alert is issued, allow the alerting authority to provide a small, location-specific emergency information package that the receiving phone automatically saves locally.

For example, following an earthquake, that package could contain:

• designated evacuation areas and routes

• functioning emergency medical facilities

• shelters and evacuation points

• water and food distribution locations

• road closures or areas to avoid

• coordinates and basic directions

• the time the information was issued and when it should be updated or considered expired

The critical feature is that the information would be saved to the device while connectivity is available. If cellular or Internet service subsequently fails, the person would still have the emergency information.

This could be especially valuable after earthquakes, hurricanes, wildfires, infrastructure failures, or other disasters in which communications become intermittent or disappear entirely.

The phone would not need to determine what is safe or generate emergency instructions. Those decisions would remain with authorized emergency-management agencies. The device would simply receive, store, and present authoritative information supplied through the existing emergency-alert infrastructure. Information would remain clearly associated with its issuing authority and timestamp so that users could distinguish current information from information that has expired or been superseded.

In other words:

Don’t just tell people that there is an emergency. Give their phones the information they will need when the network stops working.

I don’t know what technical, standards, security, or regulatory changes would be required to implement something like this, or whether some portion of the capability already exists. I am suggesting it from the perspective of an end user who sees a potential gap worth investigating.

This seems like a potentially useful extension of infrastructure that already exists, with meaningful consequences for people trying to navigate a disaster after communications have degraded.

Thank you for considering the idea.

I remain,

Abi Post

www.abipost.com

Below please find the confirmation of the comment being sent. It now lives in the FEDERAL RECORD.

These things are not currently available currently:

Local/offline persistence is the clearest thing we proposed that I still cannot find in the current system, but it wasn't the only potentially novel piece. I went back through the current FEMA/FCC material because Reddit Person has earned us an audit, damn them.

There were really four distinct additions in our proposal:

1. Automatic local persistence. While the phone still has connectivity, the incident map/data is cached so it remains usable after cellular/data service fails. I still cannot find this as a standard WEA/FEMA-app behavior.

2. A single incident-specific operational map, rather than merely an alert-area map. The FCC's location-aware WEA map is specifically designed to show the alerted geographic area and the recipient's position relative to it. That's genuinely useful, but considerably narrower than our proposed map.
   We wanted one view combining things such as unsafe/safe areas, evacuation or usable routes, shelters/medical or assistance points, major road conditions, legend and timestamp. FEMA already has some of these data separately, including live shelter GIS layers, so the novelty isn't “FEMA should know where shelters are.” It's assembling the actionable incident picture for the affected person's use.

3. Use the universal alert as the doorway to the richer information. Existing FEMA guidance still commonly tells an alert recipient to follow local directions, call a number, or visit a website/social channel for updates. Our thought was essentially: don't make the frightened person go hunting. The emergency notification initiates access to the useful geographic package while communications still work. That's particularly relevant for people who never installed or configured the FEMA app.

4. Redistribute the same emergency picture across available screens/channels. This part is actually less far-out than we thought. FEMA's IPAWS All-Hazards Feed already exists specifically so approved redistributors can send IPAWS information through apps, websites, digital signage, social media and other systems. So our “as many screens as possible” idea isn't inventing redistribution. The remaining design idea is having a consistent visual emergency map/picture travel across those surfaces.

So I would revise our claim quite substantially.

We didn't invent emergency maps.
We didn't invent geographically targeted alerts.
We didn't invent shelter mapping.
We didn't invent redistribution across multiple kinds of screens.