AfterLight

Simulated connectivity loss of Fire Station 2
Hospital A and Fire Station 1 offline rerouting

Inspiration

Afterlight started from our interest in off-grid communication and mesh networks, especially the question of what happens when the infrastructure a community depends on suddenly stops working. Mesh networks are built around resilience: if one node disappears, information can often find another route rather than depending on a single central system.

That made us wonder: what if a city could respond to failure the same way?

During a disaster, cyberattack, blackout, or communications failure, a hospital, fire station, shelter, or other critical service could suddenly become unavailable. Emergency plans may identify backups ahead of time, but real disasters rarely fail according to plan. Multiple facilities can fail at once, capacity can change, and the designated backup may itself be unreachable or overwhelmed.

Afterlight treats a community as a network of capabilities rather than a collection of isolated buildings. When part of that network goes dark, the system asks a different question: what capabilities were lost, what resources remain, and how can the surviving infrastructure reorganize around the failure?

How we built it

We model community infrastructure as a graph, with facilities represented as nodes and their relationships represented as edges. Each facility, such as a hospital, fire station, school, or emergency shelter, is defined not only by what type of building it is, but by the capabilities it can actually provide, including first aid, firefighting, rescue, shelter, medical care, and hazardous-material response.

Nodes also contain operational information such as capacity and availability. When a facility goes offline, Afterlight identifies every capability lost with it and searches the surviving network for facilities capable of assuming each responsibility.

Instead of automatically selecting the nearest facility, Afterlight ranks candidates using a deterministic suitability score. The score considers factors such as available capacity, network distance, and the candidate's ability to provide the lost service. This means the best backup does not necessarily have to be the same type of facility.

For example, if a fire station goes offline, another fire station may inherit its firefighting responsibility, while a hospital, shelter, school, or other capable facility could help absorb first-aid responsibilities. If a specialized capability such as hazmat response has no surviving provider, Afterlight flags it as a critical coverage gap rather than pretending that a viable backup exists.

We then connect this resilience logic to an interactive frontend that makes the network visible. Users can simulate facility failures and see how the state of the network changes, which capabilities are affected, and where responsibilities could be rerouted.

The result is a system where the underlying response is determined by explicit infrastructure data and graph logic rather than generated by an AI model.

Challenges we ran into

Our biggest challenge was deciding how to represent resilience realistically. A naive system could simply say, "Fire Station 2 failed, so send everything to Fire Station 1." Real infrastructure does not work that cleanly.

Facilities have limited capacity, different capabilities, and dependencies of their own. Some responsibilities can be distributed across several types of facilities, while highly specialized capabilities may have only one provider in the entire network. The problem becomes even more complicated when multiple facilities fail. A backup selected after the first failure may become unavailable, unsuitable, or overloaded after another failure.

That forced us to think beyond shortest-path routing. Afterlight became a resource-allocation and capability-routing problem: given what has failed, what can the remaining network actually support?

Another challenge was translating graph analysis into something understandable at a glance. A resilience algorithm can produce rankings and scores, but those numbers are much more useful when a user can actually see the affected facility, the surviving network, and how responsibilities shift as conditions change. Connecting the analysis to an interactive visualization became an important part of making Afterlight useful rather than simply mathematically interesting.

What we learned

One of the biggest things we learned while building Afterlight is that infrastructure resilience is not the same thing as redundancy. Having another hospital or fire station on the map does not necessarily mean a community has a viable backup. What matters is whether the remaining network still has the specific capabilities and capacity required after something fails.

We also discovered that failure recovery quickly becomes a resource-allocation problem. A facility may technically be capable of assuming a responsibility but may not have enough remaining capacity to do so effectively. This pushed us beyond simply finding the nearest backup and toward evaluating the suitability of multiple surviving nodes.

Another important realization came from modeling capabilities individually. A failed facility's responsibilities do not necessarily have to move together. If a fire station goes offline, firefighting might transfer to another fire station while first aid could be supported by a hospital, shelter, school, or another capable facility. At the same time, a specialized capability such as hazmat response may have no backup at all.

That distinction changed the central question behind the project. Instead of asking: "What facility replaces this one?" Afterlight asks: "What capabilities did we lose, and where can each of them go?" That makes the network capable of exposing not only potential recovery paths, but also the places where recovery is impossible with the resources currently available.

Next Steps

Our next step is to make Afterlight's resilience model increasingly dynamic. Right now, the system can evaluate failures and identify suitable surviving facilities. A more advanced version could model capacity consumption as responsibilities are reassigned, allowing one failure to influence the network's ability to survive the next. This would let Afterlight simulate cascading failures, overloaded facilities, and situations where a network gradually loses resilience even though individual facilities remain online.

We also want to expand the model beyond individual facilities by incorporating additional infrastructure dependencies, such as roads, communications, electricity, water, and transportation. A hospital may technically remain operational, for example, while becoming effectively unreachable because the infrastructure supporting it has failed.

A longer-term direction is integrating LightGuide's augmented-reality capabilities. Instead of viewing the resilience network only through a traditional screen, the infrastructure model could be projected into a physical environment, allowing users to interact spatially with facilities, failures, coverage gaps, and changing response paths.

Ultimately, we want Afterlight to move from demonstrating where responsibility could go after a failure toward answering a harder question: How long can a community continue functioning as the systems around it begin to fail?