Imagine an alert system that tells you not just where to shelter, but exactly how long you have, what the current status of the threat is, and provides a redundant backup through the very traffic lights you are staring at while driving. Today's prompt from Daniel is about exactly that—a series of concrete, technical proposals for modernizing Israel's Home Front Command civil defense infrastructure. He has put together a massive document of ideas covering everything from app permissions to SCADA systems and public API schemas.
Herman Poppleberry here. This is such a fascinating deep dive because it moves past the general "it should be better" sentiment and into the weeds of systems architecture and user experience. It is essentially a roadmap for turning a reactive emergency system into a proactive, data-driven safety mesh. By the way, today's episode is powered by Google Gemini Three Flash, which is writing our script as we speak.
So, Daniel sent us this one, and I'll read through the core of what he is looking at. He says the current Home Front Command app, Pikud HaOref, has some significant silent failure modes. Specifically, Android's permission auto-reset can kill the app's ability to alert you if you haven't opened it in a while, which is exactly when you need it most. He is proposing better onboarding, traffic light integration via SCADA systems to clear roads during alerts, a "current guidance" field in the data feed so people know when it is actually safe to leave a shelter, and a national Public Shelter Authority to standardize the dilapidated state of many public shelters. He also wants to see a formal JSON schema for the alert payload and multilingual area IDs to stop the translation chaos.
There is so much meat on the bone here. Where do you want to start, Corn? Because the traffic light idea is probably the most "sci-fi" but the app permission stuff is arguably the most critical for immediate life safety.
Let's start with the "silent killers" in the app. I think people underestimate how much "smart" phone features actually get in the way of emergency services. Daniel points out that if you don't have a war every three months—which, thankfully, isn't always the case—Android might just decide, "Hey, you haven't used this Pikud HaOref app lately, let me just revoke its notification permissions to save battery." And then, boom, a siren goes off and your phone stays silent because the OS thought it was doing you a favor.
It is a classic case of standard consumer OS logic clashing with mission-critical requirements. Most apps are ephemeral; an emergency alert app is a permanent piece of safety equipment. Daniel's proposal for the onboarding process to essentially "harden" the app on the device is brilliant. It shouldn't just ask for permissions; it should actively detect if you are on Android Eleven or higher and walk you through disabling that auto-reset. It needs to deep-link directly into those obscure system settings that most users can't find, especially the aggressive power management stuff on OEM skins like Samsung or Xiaomi. Those "battery optimizations" are notorious for killing background processes that wait for a push notification or a cell broadcast.
But wait, how does a regular user even know if the app is actually "alive" in the background? If I’m a non-technical user, I just see the icon on my home screen and assume it's working.
That’s the danger. It’s the "illusion of protection." Daniel suggests the app should maintain a persistent, low-priority notification in the tray. If that icon disappears, you know the OS has killed the process. But more importantly, he wants a "Health Check" heartbeat. The app should occasionally ping the server, and if the server hasn't heard from the app in forty-eight hours, it sends a standard SMS or a system-level push saying, "Hey, your safety app has been put to sleep by your phone. Click here to wake it up." It creates a closed-loop feedback system between the user's device and the Command.
Right, and he mentioned the Wireless Emergency Alerts or WEA. I didn't realize that "Extreme Alerts" could be disabled at the OS level by a user who just doesn't want their phone buzzing for a flash flood, not realizing it also controls the missile alerts.
Well, not exactly, but you've hit on the core problem. The UI treats a weather warning and a kinetic threat similarly in the settings menu. Daniel's idea is to treat the "ability to receive an alert" as a first-class setup outcome. The app should have a dashboard that says, "Green checkmark: Background data is on. Green checkmark: Battery optimization is off. Green checkmark: WEA Extreme is enabled." If any of those are red, you aren't protected. It is about moving from "I downloaded the app" to "I have verified my device is capable of alerting me." He even suggests an in-app "test my alerting" page that summarizes everything. That kind of transparency is missing right now.
It's like checking the batteries in your smoke detector, but for your pocket. Now, let's talk about the one that sounds like it’s straight out of a movie: the SCADA and traffic light integration. Using civil infrastructure as a redundant alert delivery mechanism. Explain the technical side of that, because "hacking the traffic lights" sounds like something a movie protagonist does to escape a car chase.
It is much more grounded than that. Most modern cities, especially a tech-heavy one like Tel Aviv, already use SCADA—Supervisory Control and Data Acquisition—systems to manage their traffic grids. These are centralized controllers that can change light patterns based on time of day or traffic flow. Daniel's proposal is to link the Home Front Command's Red Alert trigger directly to these SCADA systems. When an alert hits a specific polygon—a geographic area—every traffic light in that polygon immediately hits a coordinated red.
So the whole city just... stops?
For about three minutes, yes. Think about the physics of an alert. You have people in cars who might not hear the outdoor siren over their music or AC. You have pedestrians trying to cross busy streets to get to a public shelter. If the lights go red in all directions, the cars stop, the "white noise" of the city drops, and the path to the shelter becomes physically safer. Daniel also suggests a "flashing red" or some distinct visual cue during the early-warning phase. It serves as an in-band signal. Even if your phone is dead and you can't hear the siren, the literal infrastructure around you is telling you that something is wrong.
But what about emergency vehicles? If an ambulance is trying to get through and every light in the city is hard-locked to red, aren't we creating a secondary disaster?
That’s where the "smart" part of SCADA comes in. You’d need an override—an "Emergency Green" corridor—for authenticated first responder vehicles. But during the actual ninety seconds of an incoming rocket barrage, even an ambulance should probably be stationary if it’s in the impact zone. The goal is to minimize the number of people caught in the open. Daniel’s point is that a car is a metal box filled with glass and gasoline; it’s one of the worst places to be during an explosion. By forcing the grid to red, you are nudging people to exit their vehicles and find a structure.
I can see the "aha" moment there. It solves the single-point-of-failure problem of the cellular network. During the October twenty-twenty-three attacks, we saw reports that cellular networks in some areas hit seventy percent congestion. If the tower is swamped, your app-based alert might be delayed by thirty seconds. In some parts of Israel, thirty seconds is the entire window you have to get to safety. But a hardened, wired SCADA system for traffic lights? That's going to trigger in milliseconds.
And it's redundant. It's using light instead of sound or radio waves. But you have to be careful. You’d need a fail-safe where, if the SCADA system loses contact with the central controller, it reverts to normal operation so you don't just paralyze a city indefinitely because of a server glitch. It would need to be a pilot program first—maybe one municipality—to see how drivers react. But the logic is sound: if the goal is to get people to a shelter, the infrastructure should facilitate that movement, not obstruct it with moving vehicles.
It’s interesting how many of these proposals come down to "the feed is stateless." That was a phrase in Daniel's notes that caught my eye. The current data feed tells you what is happening now, but it doesn't give you the context of the event.
This is a huge technical gap. Right now, the API sends a message: "Red Alert in Area X." Ten minutes later, if there's no new message, you assume it's over. But as Daniel points out, there is no "remain in shelter" field. People rely on heuristics, like the "ten-minute rule," which is just a general guideline people have memorized. But what if there's a multi-stage attack? What if there's shrapnel falling for twelve minutes? If the feed had an explicit "current guidance" enum—a structured list of states like early warning, take shelter, remain in shelter, all clear—it would remove the guesswork.
And he wants a "stand-down" state. I like this. It's for those times when an early warning is issued, everyone's heart rate spikes, but then the threat dissipates without a full Red Alert. Currently, they just send an "all-clear," which feels wrong if there was never a "danger" signal. It’s confusing.
It’s semantically incorrect. An "all-clear" implies a threat was present and is now gone. A "stand-down" says "we thought something was coming, it didn't, go back to your coffee." From a data perspective, having a versioned public schema with these states allows third-party developers to build much smarter dashboards. Imagine a TV station's alert ticker. Instead of just a flashing red box, it could have a progress bar or a status indicator: "Threat active," "Monitoring for shrapnel," "Safe to exit." It provides a sense of agency to the public because they are following data, not just reacting to a loud noise.
How does that look in practice for a developer? If I'm building a smart home integration, how does "statelessness" hurt me?
Great question. If the feed is stateless, your smart home hub has to "remember" that an alert happened. If the hub reboots during the alert, it wakes up and sees... nothing. It thinks everything is fine. But if the feed is stateful—meaning the API says "The current status for Tel Aviv is: SHELTER"—then the hub can reboot, check the API, and immediately turn the smart lights red again because it knows the threat is still active. It moves the "memory" of the emergency from the fragile edge device to the robust central server.
Let's shift to the physical side of this: the Public Shelter Authority. Daniel mentions that over thirty percent of Israelis rely on public shelters. I've seen the photos—some of these places are just old basements filled with rusted bikes and spiders. It’s a bit of a "bring your own luck" situation.
It's fragmented. Responsibility is split between the national government and local municipalities, which means the quality of a shelter depends entirely on the budget and competence of your local city council. Daniel wants a national authority to set a "minimum code" that goes beyond just structural integrity. We are talking about water, ventilation, lighting, and, crucially, communications redundancy.
He listed four layers of comms for every shelter. Layer one: cellular. Layer two: wireless internet. Layer three: a hardened, wall-mounted tablet running only the alert app. And layer four: a good old-fashioned AM/FM radio bolted to the wall. That feels like a very "Daniel" list.
It’s the "two is one, one is none" engineering philosophy. If you are in a reinforced concrete room, your cell signal is going to be terrible. If the power goes out, the Wi-Fi dies. But if you have a tablet with its own SIM card and a battery backup, plus a radio that can pick up emergency broadcasts over the air, you are never cut off. The psychological impact of being in a shelter and not knowing if more missiles are coming is a huge part of the trauma of these events. Information is a form of protection.
I wonder about the maintenance of those tablets, though. You put a thousand tablets in a thousand basements, and six months later, half of them will have dead batteries or broken screens.
That’s exactly why he’s calling for an "Authority" and not just a "Guideline." You need a dedicated workforce—like fire inspectors—whose entire job is to rotate through these shelters, test the tablets, check the expiration dates on the water bottles, and ensure the SCADA-linked door locks are functioning. He even suggests these shelters should have a "Maintenance QR Code" on the door. A citizen can scan it to see the last inspection date and report issues directly to the central dashboard. It turns the public into a distributed maintenance crew.
He also had a point about "fewer but better" shelters. The idea being that a family would rather run an extra fifty meters to a shelter that they know has a working AC, a power outlet for a phone, and a clean place to sit, rather than ducking into a dilapidated hole in the ground right next door. It’s about the "UX of survival," essentially. If the shelter is miserable, people will start taking risks and staying in their homes.
And that leads into his "Layer Two" and "Layer Three" proposals regarding how we find these places. Right now, if you're in a new neighborhood and a siren goes off, where do you go? You might find a PDF on a municipal website if you're lucky. A PDF! In twenty-twenty-six! Daniel is calling for a mandatory, standardized shelter-finder app. Not just a list of addresses, but a GeoJSON feed with precise lat-long coordinates, photos of the entrance, and videos showing the walking route.
The video idea is smart because "Entrance is around the back of the community center" is hard to parse when you're panicking. Seeing a five-second clip of someone walking through the gate makes it click instantly. And he's pushing for a machine-readable listing standard. No more PDFs. A defined CSV or JSON feed that any developer can pull into their own maps.
This is where the "Public API" theme ties everything together. Daniel is essentially arguing that the government should provide the "source of truth" and let the developer community build the "last mile" of the experience. He mentions that there are already over a hundred "Red Alert" scrapers in the wild. People are already doing this, but they are doing it by scraping undocumented endpoints, which is incredibly brittle. If the Home Front Command changes a single field name in their private app's API, all those third-party alerts could break at the exact moment a barrage starts.
And the "security through obscurity" argument is pretty weak here, right? I mean, the people launching the rockets already know where they are aiming. They don't need a public API to tell them that an alert is active—they can hear the sirens.
That is Daniel's exact point. Hostile actors are already monitoring the system. Keeping the API undocumented doesn't stop the "bad guys," it only hampers the "good guys"—the developers who want to build accessibility tools, smart home integrations, or research dashboards. He’s proposing a professionally managed, documented API with an OpenAPI spec. He even mentions an MCP server—Model Context Protocol—so AI agents can interact with the data. That is a very forward-looking addition. Imagine asking your smart speaker, "Is it safe to go for a walk?" and it pulls from the official Home Front Command API to give you a real-time risk assessment based on recent alerts.
I want to dig into the "Multilingual Area IDs" proposal because that sounds like a classic "developer's nightmare" that Daniel has lived through.
Oh, it’s a mess. Currently, the alert feed identifies areas using Hebrew strings. So, the data says "Kiryat Shmona" in Hebrew characters. If you want to show that in an English app, you have to maintain a mapping table. But how do you spell it? Is it K-I-R-Y-A-T or Q-I-R-Y-A-T? Does it have an "E" at the end? Every developer makes their own table, and they all drift. When a new area is added or an area is renamed, the apps break.
And that’s a real problem for olim—new immigrants—or tourists, or the Arabic-speaking population. If your app can't translate the area name correctly because of a spelling mismatch, you might not realize the alert is for you.
Daniel's solution is so simple yet so effective: a stable, opaque Area ID. A number or a unique string that never changes. Area five-zero-two is always Area five-zero-two, regardless of whether you call it Kiryat Shmona in Hebrew, English, or Arabic. The feed should carry that ID, and then the government provides an official, versioned dataset that maps that ID to names in at least six languages: Hebrew, Arabic, English, Russian, French, and Amharic. This is such a basic "Data Ten-One" principle, but it would solve so much fragmentation in the ecosystem.
It’s basically moving the "translation layer" from the individual developer to the source of truth. It ensures that everyone, regardless of their native language, is seeing the exact same authoritative information. It’s a matter of equity and safety.
It really is. And it pairs with his "Formal Payload Schema" idea. He actually included an "Observed Payload Schema" in his notes—basically what he’s been able to reverse-engineer from the current live feeds. He pointed out the weaknesses: no timezone, no event ID, no language tag, and no event grouping. If five missiles are fired at one city, you get five separate rows in the data instead of one "event" with five targets. It makes it very hard to do post-event analysis or even just to present a clean UI to the user.
Wait, so right now, if there's a massive barrage, the API is just spamming individual lines? That sounds like a recipe for a buffer overflow or at least a very laggy app.
It’s inefficient. Daniel’s proposed JSON schema includes an event_id and a group_id. This allows an app to say, "Okay, I see twelve incoming alerts, but they all belong to Group ID 8849. I'll just show the user one alert box that says 'Heavy Barrage' instead of vibrating their phone twelve times in ten seconds." It’s about data hygiene. He even suggests adding a threat_type enum—is it a rocket, a drone, a terrorist infiltration, or a hazardous material leak? Currently, these are often lumped together or sent as free-text strings, which are a nightmare to parse programmatically.
So, if we take all of this together—the app hardening, the SCADA traffic lights, the standardized shelters, and the public API—what we’re looking at is a shift toward "Civil Defense as a Platform."
That is a great way to put it. It’s about building a robust, redundant, and transparent foundation. It acknowledges that the government can't solve every single edge-case UX problem, but it can provide the high-quality data and the physical infrastructure that allows the community to protect itself more effectively. I think the biggest takeaway for me is the focus on redundancy. We've become so reliant on the "app on a smartphone" model that we've forgotten that smartphones are actually quite fragile from a systems perspective. They have batteries that die, OS updates that change permissions, and they rely on a cellular network that can be easily overwhelmed.
The traffic light idea really sticks with me for that reason. It’s using something that's already there, that’s already powered, and that people already look at. It’s "passive" alerting. You don't have to do anything to receive that information; it's just part of the environment.
It’s like the "visual siren" concept. In some coastal areas, they use blue lights on poles to warn of tsunamis for the hearing impaired. Daniel is just taking that concept and scaling it to the entire urban grid. It’s brilliant because it doesn't require the citizen to own a device or have a data plan. It’s a return to the idea of the city itself as a protective organism.
And it’s a lesson that applies far beyond Israel. Any country facing natural disasters—earthquakes, hurricanes, wildfires—could look at this framework. How do we make sure the "emergency app" doesn't get put to sleep by the OS? How do we use traffic lights or digital billboards as redundant signal carriers? How do we standardize the data so that when the "big one" hits, the information ecosystem doesn't collapse under the weight of its own fragmentation?
Think about the California earthquake alerts. If the traffic lights on the San Andreas fault line all turned red three seconds before the S-waves hit, how many intersection collisions could be avoided? Or in the Midwest during tornado season—using the SCADA system to trigger sirens and visual cues simultaneously. The technical hurdles Daniel is identifying in Israel are universal hurdles for any modern society trying to keep its citizens safe using digital tools.
It’s also about the "last mile" of the shelter experience. If you get the alert, and you get to the shelter, but then you’re sitting in a dark, hot room with no way to know if it’s safe to leave, the system has failed you at the most critical moment. That’s why those "long-stay amenities" and the "current guidance" field are so important. It’s not just about surviving the impact; it’s about managing the entire duration of the threat.
I love the "current guidance" field because it addresses the "human factor." People are naturally impatient. If you’ve been in a shelter for eight minutes and it’s quiet, you want to leave. But maybe the radar shows another wave incoming. If your phone app has a big yellow bar that says "REMAIN IN SHELTER - NEXT UPDATE IN 3 MINUTES," you’re going to stay put. It’s about reducing the cognitive load on people who are already under extreme stress.
It's the difference between "Go to shelter" and "We have your back until this is over." It’s a subtle but massive psychological shift. Daniel even mentions a "Countdown to Impact" field in the API. That sounds terrifying, but he argues it’s actually grounding. Knowing you have forty-five seconds is better than just knowing "it's coming soon." It allows you to prioritize—do I grab my shoes, or do I grab the dog?
Information is the antidote to panic. When you have a timer, you have a plan. When you have a plan, your heart rate stays lower. It’s the "gamification" of safety, in a weird way—giving the user clear objectives and clear timelines.
So, for our listeners, the practical takeaway here isn't just "Israel should do this." It's a look at how we design mission-critical systems in a world of complex, consumer-grade technology. If you are a developer or a policy maker, think about those "silent failure modes." Think about the difference between "sending a message" and "ensuring it is received and understood."
And look at the power of open data. By proposing a public API and a standardized schema, Daniel is showing how a government can leverage its entire tech-savvy population to solve problems. You don't need a thousand government employees to build a perfect app if you provide a perfect API for a thousand developers to build their own versions. Imagine an app specifically for the elderly with giant buttons and voice-overs, or an app for the blind that uses haptic patterns to indicate the direction of the nearest shelter. All of that becomes possible the moment you open the data.
It’s a fascinating roadmap. I wonder how quickly some of these could be implemented. The API and the schema seem like "low-hanging fruit" technically, even if the bureaucracy might be a challenge. The SCADA integration is obviously a bigger lift, but as a pilot program, it’s definitely doable.
The bureaucracy is always the hardest part of civil defense. There are so many stakeholders—the military, the police, the municipalities, the Ministry of Transport. But when the technical roadmap is this clear, it makes the argument for change much harder to ignore. Daniel’s done a massive service here by laying out the "how" so clearly. He’s essentially handed them the blueprint; now they just need the political will to build it.
Well, that’s a lot to process, but it’s a great example of using a technical lens to solve very human, very high-stakes problems. Before we wrap up, I want to give a quick shout-out to the "fun fact" Daniel tucked into the appendix: apparently, some of the older sirens in Israel are still triggered by analog radio signals that date back decades. Moving from that to a SCADA-integrated, JSON-driven mesh is like jumping from a typewriter to a quantum computer.
It’s a leap worth taking. Thanks as always to our producer Hilbert Flumingtop for keeping the gears turning behind the scenes and making sure our own "alert system" stays functional.
And a big thanks to Modal for providing the GPU credits that power the generation of this show. It’s what allows us to keep exploring these weird and wonderful prompts.
If you're interested in Daniel's full technical document, we'll have a link in the show notes. It's a masterclass in systems thinking.
This has been My Weird Prompts. If you are finding these deep dives useful, leave us a review on your favorite podcast app. It really does help other people find the show and join the conversation. We love hearing from our community of "prompt engineers" and curious minds.
We will be back next time with another prompt from Daniel. Until then, stay curious and stay safe.
Catch you later.
