Resilience

When the Signal Fails: Designing for the Technologies We Lose

The systematic decommissioning of ground-based aviation navigation across Europe and the United States rests on an assumption that satellite systems will always be available. Russian electronic warfare in the Baltic has demonstrated, at scale, that they will not.

P J Laszkowicz

The systematic decommissioning of ground-based aviation navigation across Europe and the United States rests on an assumption that satellite systems will always be available. Russian electronic warfare in the Baltic has demonstrated, at scale, that they will not. The same assumption—that the service will always be there—now underpins the digital infrastructure of every organisation building on a small number of American AI providers, and the working lives of every engineer who has substituted a subscription for a skill.

The beacons go quiet

For most of the twentieth century, aviation navigation worked from the ground up. Non-directional beacons—NDBs—transmitted continuous radio signals that pilots could home toward using automatic direction finders. VHF omnidirectional range stations—VORs—provided radial bearings that allowed pilots to fix their position along defined airways. These systems were simple, independently powered, locally maintained, and resilient by design. An NDB is a radio transmitter. It has virtually no moving parts. Its mean time before failure is approximately 28,000 hours, and its mean time to repair is fifteen minutes.1 A pilot with a functioning receiver and a chart could navigate to any airport within range of a beacon without depending on any infrastructure beyond the beacon itself.

These systems are being dismantled.

In the United States, the Federal Aviation Administration's 2018 Navigation Programs Strategy committed to phasing out all NDB approaches from the National Airspace System by 2030 and reducing the VOR network by approximately thirty per cent—from roughly 967 stations to a Minimum Operational Network of 667.2 The remaining VORs would serve a new purpose: not as the primary navigation system, but as a backup—a fallback for pilots in the event of a failure of the Global Navigation Satellite System that was replacing them. The FAA has already discontinued hundreds of NDB and VOR instrument approach procedures and has begun decommissioning the physical stations themselves.3

The pattern is not uniquely American. Sweden's national air traffic control provider announced plans to decommission half of its 22 VOR stations before 2027, retaining 11—contingent on government funding for renovation. Without that funding, the proposal was to decommission all 22.4 Canada's Nav Canada announced a parallel programme to remove hundreds of VOR and NDB aids it determined were no longer required.5 Across Europe, the trajectory is the same: ground-based navigation infrastructure built over decades, tested in every weather condition, independent of any satellite constellation, is being removed on the assumption that GPS and its European counterpart, Galileo, will be continuously available.

The financial rationale is coherent. Maintaining two parallel navigation systems—terrestrial and satellite—is expensive. VOR stations require periodic calibration. NDB facilities require inspection and power supply. The costs are modest for any individual station, but they accumulate across a network of hundreds or thousands of installations. GPS, once the constellation is operational, provides global coverage with no per-station ground cost to the aviation system. The transition from ground-based to satellite-based navigation is, in cost-benefit terms, straightforward.

But cost-benefit analysis is only as sound as its assumptions. The analysis that justified decommissioning assumed that GPS would be continuously available at a level sufficient for all phases of flight. It assumed that interference, if it occurred, would be localised and temporary. It assumed that the constellation itself—built and operated by the United States Air Force, and therefore subject to the strategic priorities of a single foreign government—would remain accessible to all civil aviation indefinitely. Each of these assumptions was reasonable when assessed in isolation. None of them was guaranteed. And the navigation architecture being built on top of them—an architecture with progressively fewer independent terrestrial fallbacks—had diminishing tolerance for any of them proving wrong.

There is a place where that assumption was tested to failure.

Tartu Airport, in eastern Estonia, is a regional airport approximately fifty kilometres from the Russian border. It has a single runway. While it possesses an instrument landing system on one runway direction, its standard approach procedures were primarily GPS-dependent—aircraft could land using GPS-based approaches from either end, but non-GPS precision options were limited to a single direction and a single system.6 When the GPS signal was available, this was efficient. When the GPS signal was not available, the airport's operational flexibility collapsed to a fraction of its normal capacity—and in practice, to zero for Finnair's scheduled services.

The architecture of Tartu's approach procedures was the logical endpoint of the assumption that satellite navigation would always work. It was also the point at which the assumption broke.

The Baltic jammer

The GPS signal over the Baltic Sea has been degraded, intermittently and sometimes continuously, since Russia's full-scale invasion of Ukraine in February 2022. What began as sporadic interference near the Russian exclave of Kaliningrad has escalated into a sustained electronic warfare campaign affecting aviation and maritime navigation across the entire Baltic region—from the airspace above Gdańsk through the shipping lanes of the central Baltic to the skies over Estonia and Finland.7

The scale of the interference is not speculative. It is measured.

In Swedish airspace alone, incidents of GPS interference rose from 55 in 2023 to 733 by mid-2025—a thirteenfold increase in two years. Sweden's Transport Agency conducted detailed analysis over this period and concluded that the interference originated from Russian territory.8 Across the wider Baltic, the escalation was similarly stark: Poland recorded 2,732 cases of GPS jamming and spoofing in January 2025 alone—a figure that had risen from 1,908 cases in October 2024.9 Estonia reported that 85 per cent of its flights were affected by navigation disruptions.10 Latvia's Electronic Communications Office recorded 820 cases of satellite signal interference in 2024, compared to 26 in 2022.11 Between August 2023 and March 2024, over 46,000 instances of potential GPS signal disruption were reported by aircraft flying over the Baltic region.12

The interference takes two forms. Jamming overpowers the weak signals from GPS satellites—which orbit approximately 20,000 kilometres above the Earth's surface and arrive at ground level with extremely low field strength—with stronger radio signals emitted from ground-based or ship-borne transmitters. Spoofing is more insidious: it feeds false positional data into navigation receivers, causing systems to report locations that are plausible but wrong. In 2025, researchers observed that Russia's tactics shifted from primarily jamming to primarily spoofing—the more advanced technique, and the one harder to detect and defend against.13

In October 2024, researchers documented up to seven-hour stretches of GNSS disruption affecting all four major satellite constellations simultaneously—GPS, GLONASS, Galileo, and BeiDou. Position errors exceeded thirty metres, sufficient to compromise safe routing for both ships and aircraft. Analysis of interference patterns matched with vessel movements provided evidence that some sources were mobile—jamming devices operating aboard ships in international waters.14

Tartu was where the consequences became visible to the public. On 25 and 26 April 2024, two consecutive Finnair flights from Helsinki were forced to turn back after GPS interference prevented their approach into the airport. The following week, Finnair—the only international airline serving Tartu—suspended all flights from 29 April to 31 May. The reason was simple and disclosed publicly: the approach procedures at Tartu required a GPS signal, GPS interference in the area was persistent, and the airline could not guarantee safe landings.15 During the suspension, Finnair and Estonian Air Navigation Services worked to implement alternative approach procedures that did not depend on GPS—procedures that, had the ground-based infrastructure not been progressively deprioritised, would already have been in place.16

The response extended beyond Tartu. In May 2025, transport ministers from thirteen EU member states—Lithuania, Latvia, Estonia, Germany, Slovakia, Finland, Slovenia, the Czech Republic, Italy, the Netherlands, Spain, Denmark, and Romania—signed a joint letter demanding coordinated European action.17 The ICAO Assembly condemned both Russia and North Korea for GPS interference affecting civil aviation and demanded an immediate halt.18 Sweden formally accused Russia of being the source.19

And in a development that carried a particular irony, a project that had been running quietly since 2017—dismissed in its early years as a solution to a problem that did not exist—became strategically urgent.

R-Mode Baltic is a terrestrial navigation system developed by the German Aerospace Centre and partners across Finland, Estonia, Poland, Sweden, and Norway. It uses existing maritime radio beacons—infrastructure already installed along the Baltic coast—to provide positioning information independent of any satellite constellation. Ships and, in early trials, aircraft equipped with ranging-mode receivers can calculate their position by measuring distances to multiple land-based stations. The system requires no satellites, no new major infrastructure, and no dependency on any technology controlled by a foreign power.20

The project is funded through the EU's Interreg Baltic Sea Area programme under the name ORMOBASS. Germany's DLR leads the development. Stations are being set up in Finland and Estonia—the countries experiencing the most severe interference. The goal is a pre-operational service by the end of 2026.21 At the 39th Chaos Communication Congress in Hamburg in December 2025, the DLR team presented R-Mode's current status. Their opening framing was direct: the Baltic's dangerous dependence on satellite navigation was the problem, and a terrestrial backup was the solution. The system they described used existing medium-wave and VHF infrastructure with a range of approximately 300 kilometres—enough to cover the entire Baltic Sea.22

The researchers presented their journey as a progression from academic curiosity to critical infrastructure—a system that "nobody needed" becoming a system that countries were urgently requesting. The trajectory is instructive. R-Mode was not built in response to the Baltic jamming campaign. It was built because a small number of engineers recognised, years before the jamming began, that a navigation system dependent on a single technology—however sophisticated—was structurally fragile, and that the sensible response was to maintain an independent fallback that could activate when the primary system failed.

The countries now deploying R-Mode are, in many cases, the same countries that were decommissioning VORs.

The same pattern, different frequency

The structural parallel between aviation navigation and digital infrastructure is not metaphorical. It is architectural.

In aviation, the transition followed a clear path: a distributed system of independent, locally maintained, ground-based beacons was replaced by a centralised satellite-dependent system. The old infrastructure was decommissioned to reduce costs. The new system worked well under normal conditions. When the signal was deliberately disrupted, the absence of fallback infrastructure converted a degraded service into an inoperable one.

In digital infrastructure, the transition follows the same path. Organisations that once maintained their own servers, their own software, their own engineering capacity, have progressively centralised their operations on a small number of cloud providers and, more recently, on an even smaller number of AI model providers. The old capacity—in-house expertise, self-hosted systems, teams that understood their own codebases from the ground up—has been reduced or eliminated to lower costs and increase efficiency. The new systems work well under normal conditions. When the signal is disrupted, the consequences are immediate and systemic.

The reduction in internal capability was, like the decommissioning of VORs, driven by sound financial logic. Maintaining an in-house machine learning team was expensive. Operating self-hosted infrastructure required capital and expertise. Building bespoke systems took time that commercial pressures did not allow. The cloud providers and AI model providers offered better performance at lower marginal cost, with the friction of integration decreasing every year. The rational decision, evaluated quarter by quarter, was to outsource more and maintain less. The accumulated effect of a decade of rational decisions was a landscape in which most organisations could not function without a small number of external dependencies they did not control.

On 20 October 2025, a major outage at Amazon Web Services brought down AI coding tools, customer service chatbots, supply chain decision systems, and automated analytics platforms across thousands of organisations simultaneously.23 The outage lasted several hours. For companies whose AI-integrated systems had no fallback path—no rules-based degradation mode, no locally hosted alternative, no human process that could substitute—those hours were a full operational stop. Engineers who relied on cloud-hosted AI coding assistants could not write code. Customer service teams whose workflows depended on AI triage could not process requests. Decision systems that fed automated recommendations into logistics chains went silent.24

The financial impact was significant, but the structural lesson was more important: the outage revealed how many organisations had built mission-critical workflows on a single external dependency without planning for its absence. The parallel with Tartu is precise. Tartu Airport had only GPS-dependent approach procedures. When GPS was unavailable, flights could not land. Thousands of organisations had only cloud-dependent AI workflows. When the cloud was unavailable, work could not continue.

The measured uptime of major LLM providers underscores the fragility. Traditional cloud infrastructure operates to service-level agreements of 99.9 per cent—a maximum of approximately 43 minutes of downtime per month. Measured uptime for LLM APIs has been consistently lower, with some providers recording effective availability of 99.3 per cent or less—over five hours of potential downtime per month.25 In December 2025 alone, monitoring services recorded 47 incidents across major AI providers, with some individual providers reporting 20 or more distinct service disruptions.26 This is not anomalous. It is the operational reality of a technology that is scaling faster than the infrastructure supporting it can stabilise.

The concentration risk compounds the availability risk. Most organisations' AI integrations rely on a single provider. The API key points to one company, in one jurisdiction, subject to one set of commercial terms and one set of political pressures. When that provider experiences a technical failure, the customer has no alternative. When the provider changes its terms, pricing, or model behaviour, the customer adapts or migrates—a process that is rarely simple and never instant. When the provider's relationship with its government changes, the customer absorbs the consequences.

This is not a theoretical concern. The Anthropic-Pentagon crisis of February 2026 demonstrated that access to American AI infrastructure can be revoked overnight—not through a technical failure, but through an administrative designation. A single executive action by the United States Defence Secretary removed one of the world's leading AI companies from the entire federal technology stack within hours. Defence contractors began stripping Anthropic's technology from their systems immediately.27 Any organisation—American or allied—that had built on Anthropic's models witnessed a live demonstration of how quickly a dependency can be severed, and how little the customer's investment in integration counts when the decision is made upstream.

Georgetown University's Centre for Security and Emerging Technology analysed what it termed the "sovereignty gap" in American AI statecraft: the structural distance between the deployment-layer control that customers exercise and the upstream dependencies—chips, cloud infrastructure, foundational models—that they do not control and cannot replicate quickly.28 The CLOUD Act compounds this exposure for non-American organisations: United States law permits the compulsion of data disclosure from US-headquartered companies regardless of where the data is physically stored.29 For European organisations subject to GDPR, this creates a jurisdictional tension that no technical architecture can fully resolve as long as the underlying AI provider is American.

The Tartu problem, transposed to software: when your only approach procedure depends on a signal you do not control, and that signal is interrupted—whether by electronic warfare, by a data centre failure, or by a political decision made in a distant capital—you cannot land.

The pen-and-paper engineer

The pattern operates at one further level: the individual.

AI-assisted software development has become, in the space of approximately three years, a standard feature of professional engineering practice. Subscriptions to AI coding assistants range from roughly €20 to €200 per month. The tools are effective. An engineer working with a capable AI assistant can generate, review, and iterate on code at a pace that would have been impractical a few years ago. Codebases that might have taken weeks to scaffold can be produced in days. Patterns that would have required extensive research can be surfaced instantly. The productivity gains are real, measurable, and—for teams under delivery pressure—difficult to refuse.

But productivity and capability are not the same thing.

What AI-assisted development produces is volume: more code, more quickly, across more domains than any individual engineer could cover independently. What it does not necessarily produce is understanding. The engineer who prompts a model to generate a database migration, a networking layer, an authentication flow, and a deployment pipeline has, at the end of the process, a working system. Whether that engineer understands the system—can reason about its failure modes, debug it without AI assistance, modify it when the underlying assumptions change—is a separate question, and one that the productivity metrics do not capture.

The accumulation is significant. Organisations using AI-assisted development are building technical assets at an unprecedented rate. Every generated module, every scaffolded service, every AI-suggested architectural decision becomes part of a codebase that must be maintained, extended, debugged, and eventually replaced. The volume of code an organisation must support grows in proportion to the speed at which it is produced. But the human capacity to understand that code does not scale at the same rate—particularly when the understanding was never fully developed in the first place, because the AI tool handled the complexity that would otherwise have forced the engineer to learn.

This is not an argument against AI-assisted development. The tools are good, and they will improve. It is an observation about what happens when the signal fails. If the AI provider suffers an outage, changes its model's behaviour, alters its pricing, or—as the Anthropic precedent demonstrated—loses access to its market through a political decision, the engineer is left with a codebase they may not fully comprehend and no tool to mediate their relationship with it. The team has not shrunk. But the concentration of its productivity on a single external dependency means that the removal of that dependency—whether for an hour or permanently—is not a minor inconvenience. It is an operational crisis.

The deeper shift is in the nature of engineering knowledge itself. A generation of engineers is developing professional skills calibrated to a specific workflow: formulate a prompt, evaluate the output, iterate, ship. This is a valid and increasingly necessary skill. But it is a skill that presupposes the continuous availability of the tool. An engineer who can design a system architecture on a whiteboard, reason about data flow on paper, sketch a state machine in a notebook, and debug a failure by reading code line by line possesses capabilities that are independent of any external service. An engineer whose practice is organised entirely around AI-mediated development possesses capabilities that are contingent on that mediation continuing.

I think about this through a memory from the beginning of my career. In 2000, at the age of nineteen, I was working at my first real engineering job. One morning, we arrived at the office to discover that the building had no electricity. The backup power system had been severed—cut through by a telecommunications company doing work nearby. No power meant no desktop computers, which in 2000 meant no development environment of any kind. There were no laptops to speak of. No cloud to fail over to. No mobile devices capable of running an IDE.

Our line manager arrived, surveyed the darkened office, and asked why we were not working. This confused us, since the answer seemed self-evident: there was no electricity. He would not accept this. He suggested—with what appeared to be complete seriousness—that we write code by hand with pen and paper and type it up when the power returned.

The instruction was absurd as stated. Nobody was going to hand-write compilable code on A4 paper. But something happened that I have thought about many times since. We picked up the pens and paper. Not to write code, but to do the work that did not require a compiler. We sketched system architectures. We outlined data models. We mapped integration points between components. We drew sequence diagrams. We debated design decisions that we had been too busy implementing to think through properly. By the time the power returned several hours later, we had produced some of the most useful design work of the project—not because the pen-and-paper instruction was good management, but because the skills we had were not dependent on a single tool. We could think about software without software.

The question is whether that independence persists. If every AI coding assistant disappeared tomorrow—not permanently, but for a week, or a month—could the engineers who depend on them still reason about the systems they have built? Could they debug a failure by reading the code, rather than by pasting it into a chat interface? Could they design a new component on a whiteboard, from first principles, without a model to suggest the architecture?

For many, the answer is yes. Experience, education, and professional discipline have built a foundation that AI tools augment but do not replace. For a growing number—particularly those who entered the profession after AI-assisted development became the norm—the answer is less certain. The tool has become so integrated into the workflow that the workflow may not function without it. The signal has become the skill.

This is not a failure of individual engineers. It is a systemic outcome of how the tools are adopted. When an organisation measures productivity in lines of code shipped, commits merged, or features delivered per sprint, it is measuring output—not understanding. When promotion decisions reward engineers who deliver faster, they reward the efficient use of tools, not the depth of knowledge that would allow an engineer to work without them. The incentive structure optimises for the signal being present. It does not reward the resilience that would matter if the signal disappeared.

Designing for the signal we might lose

This article is not an argument against satellite navigation, against cloud computing, or against AI-assisted engineering. Each of these technologies delivers genuine value. GPS transformed aviation safety. Cloud infrastructure democratised access to computing resources that were previously available only to the largest organisations. AI coding assistants have made software development faster and more accessible. The question is not whether to use these technologies. It is whether to use them in a way that assumes they will always be available.

The R-Mode project offers a model for what resilient design looks like in practice. The DLR team did not set out to replace GPS. They set out to build a system that would activate when GPS failed—a terrestrial complement, not a terrestrial replacement. The design principle was explicit: any navigation system that depends on a single technology, however reliable, is structurally fragile. The response is not to reject the primary system but to maintain an independent fallback that operates on different principles, uses different infrastructure, and is not vulnerable to the same failure modes.30

This principle—design for the signal you might lose—applies directly to digital infrastructure.

At the organisational level, it means architectural choices that account for provider failure. Multi-provider configurations, where critical AI capabilities can fail over from one provider to another, are the digital equivalent of maintaining both satellite and terrestrial navigation. Graceful degradation paths, where a system drops from AI-augmented operation to simpler but functional rules-based processing when the AI service is unavailable, are the equivalent of a pilot switching from GPS to VOR when the satellite signal is lost. Local capabilities—whether self-hosted models for critical functions, cached decision logic, or manual processes documented and rehearsed—are the equivalent of keeping the ground-based beacons operational even after the satellite constellation is in place.

At the governance level, it means treating dependency as a risk category. Organisations routinely audit their financial risks, their security risks, their compliance risks. Few conduct rigorous audits of their AI dependency chains—mapping which business processes depend on which external AI services, identifying single points of failure, and testing what happens when those services become unavailable. Fewer still audit the human dependency: which skills within the organisation exist only in mediated form, accessible through a tool but not embedded in the people who use it? What institutional knowledge has been externalised to a provider that could change its terms, its pricing, or its availability at any time?

The parallel with aviation is instructive: the Minimum Operational Network concept—the FAA's plan to retain enough VOR stations to allow navigation during a GPS failure—is a dependency audit applied to physical infrastructure. The same discipline, applied to digital infrastructure, would ask: if this provider fails, what still works? If this API is revoked, what do we fall back to? If this model changes its behaviour, how do we detect it and adapt?

At the level of individual capability, it means preserving the skills that precede the tools. An engineer who understands algorithms, data structures, system design, and software architecture possesses knowledge that is independent of any particular AI model. An engineer who can reason about a problem on paper—who can diagram a system, trace a data flow, identify a failure mode without assistance—possesses a resilience that no subscription can provide. This does not mean refusing to use AI tools. It means ensuring that the use of AI tools does not erode the foundation on which effective use of those tools depends.

The Norwegian approach to aviation navigation illustrates both the principle and its difficulty. Norway's air navigation service provider, Avinor, has historically maintained non-GPS alternatives across its network—a backbone of VOR/DME, NDB installations, and ILS systems alongside satellite-based procedures. But the transition to GNSS-dependent navigation is under way there too. In late 2025, plans to remove ground-based navigation systems from 19 of Norway's smaller airports drew sharp criticism from pilots and airlines, with the Norwegian Pilot Union warning that the transition had moved too quickly given record levels of GPS interference. The regional airline Widerøe considered imposing weight restrictions on flights from affected airports. Political leaders called for reassessment, citing the British government's decision to abandon its own full phase-out of legacy navigation aids in favour of a dual-system strategy where old and new operate side by side.31 The debate in Norway centres on a question that applies well beyond aviation: should critical infrastructure rely on a single advanced technology, or must it be built on technological diversity for resilience?

I have some personal experience of what this principle looks like in practice. I trained as a pilot two decades ago, in aircraft equipped with analogue instruments—what pilots call steam gauges. Six round dials arranged in the standard panel: airspeed indicator, attitude indicator, altimeter, turn coordinator, heading indicator, vertical speed indicator. Navigation was a VOR receiver and an ADF needle. You flew by scanning the instruments, building a mental model of the aircraft's state from six independent readings, and cross-referencing your position against ground-based beacons. It was demanding, manual, and entirely independent of any satellite.

When I first flew in aircraft with glass cockpits—where those six individual instruments are replaced by integrated digital displays, a primary flight display and a multi-function display rendering the same information as computed graphics on LCD screens—it made me nervous. The information was better presented, more precise, and easier to interpret. But it was also mediated. The system between me and the aircraft's state had gained a layer of abstraction, and with it a new category of failure mode. A steam gauge fails visibly—the needle stops moving, the gyro topples, the reading diverges from the others. A digital display fails in ways that can be harder to detect, because the presentation remains clean and confident even when the underlying data is degraded.

Eventually I became comfortable with glass cockpits, and I would not willingly go back. The situational awareness they provide—moving maps, terrain overlays, traffic information, coupled approaches—is a genuine safety improvement. But I maintain simulation time on a variety of aircraft types, including those with conventional panels, specifically to keep the older skills sharp. I fly ILS Category II approaches and RNAV procedures when they are available, and I benefit from them. But I also ensure I can fly a VOR approach, hold a heading on a directional gyro, and navigate without GPS if the situation demands it. Regardless of which cockpit I am sitting in, I am safe—not because I have chosen one generation of technology over another, but because I remain adaptive, able to use the newest capabilities when they are available without depending on them exclusively, and grounded in the fundamentals that make a competent pilot regardless of what is fitted to the panel.

This is not nostalgia. It is operational discipline. And it is the same discipline that the R-Mode engineers applied to Baltic navigation, that Norway applies to its airspace infrastructure, and that any responsible approach to technology—whether in aviation or in software—requires.

The countries now investing most urgently in GPS alternatives are the ones closest to the source of interference. Finland, Estonia, Poland, Germany—the nations that experience Baltic jamming daily—are the ones deploying R-Mode stations, demanding ICAO action, and reinforcing their ground-based navigation infrastructure. They did not invest in resilience because they anticipated the specific threat. They invested because the threat arrived, and they discovered that the infrastructure they had allowed to atrophy was the infrastructure they now needed most.

The parallel holds for organisations and for individuals. The companies that will navigate an AI provider outage most effectively are those that invested in multi-provider architectures and maintained human processes before the outage occurred—not because they predicted a specific failure, but because they designed for the possibility of failure in general. The engineers who will remain productive when their AI tools are unavailable are those who never allowed their tools to become a substitute for their skills—who used AI to augment their capability rather than to replace it.

The distinction between augmentation and replacement is not always visible in the moment. An engineer who uses an AI tool to generate boilerplate while focusing their own attention on architecture and design is being augmented. An engineer who uses an AI tool to generate architecture and design while focusing their own attention on prompting is being replaced—gradually, and perhaps without noticing, because the output looks the same. The difference only becomes apparent when the tool is removed. The augmented engineer continues to work, less efficiently but competently. The replaced engineer discovers that the competence was in the tool, not in them.

There is a sentence from the DLR team's presentation at the Chaos Communication Congress that captures the design philosophy precisely. Describing R-Mode, they said they had built a navigation system that "simply doesn't care about the jammer."32 The system works whether the satellite signal is present or not. It does not depend on the absence of interference. It does not require the threat to be resolved. It operates on its own terms, from its own infrastructure, with its own physics.

That is what resilient design means—in aviation, in digital infrastructure, and in the capabilities of the people who build and operate both. Not a rejection of the sophisticated, the efficient, or the new. But an insistence that when the signal fails—and it will fail—the ability to navigate does not fail with it.

The beacons are going quiet. Some of them should be kept on. Not all of them—the transition to satellite navigation is real and valuable, and maintaining every legacy installation would be wasteful. But enough of them, in the right places, so that when the signal is lost, people can still find their way. The same principle applies to the digital systems we are building and the skills of the people who build them. Keep the beacons on. Not because the new technology is bad, but because the people who depend on it deserve a system that was designed for the day it stops working.

Footnotes

  1. Southern Avionics Company, "Why Is the FAA Decommissioning NDBs?" ↩

  2. Federal Aviation Administration, Navigation Programs Strategy, 2018. See also: AOPA, "NAVAID Decommissioning," September 2018. The FAA's original target was 500 VORs by 2020; this was revised to 867 by 2020 and 667 by 2025 following industry feedback on coverage requirements. ↩

  3. AOPA, "FAA Releases List of Instrument Approaches to Be Eliminated," April 2015. The FAA proposed eliminating 736 VOR and NDB approach procedures in the initial round. ↩

  4. LFV (Luftfartsverket), Sweden's air navigation service provider, presented the decommissioning plan publicly; reported via EuroGA aviation forum. The plan proposed decommissioning 11 of 22 VOR stations by 2027, contingent on government funding to renovate the remaining 11. Without funding, all 22 would be decommissioned. Thirty-four DME stations would be retained for DME/DME performance-based navigation. ↩

  5. Aviation International News, "Canada to Decommission Hundreds of VORs, NDBs," March 2019. ↩

  6. Estonian Air Navigation Services, via ERR News, April 2024. EANS confirmed that Tartu Airport's approach procedures were primarily GPS-based, with visual approach capabilities available in good weather. ERR additionally reported that Tartu has a one-way ILS installation. FlightGlobal confirmed the ILS serves one runway direction only. ↩

  7. Defense News, "Researchers Home In on Origins of Russia's Baltic GPS Jamming," July 2025. Polish researchers at Gdynia Maritime University and the German Aerospace Centre traced interference to the Kaliningrad region, specifically the Okunevo antenna complex and Baltiysk area. ↩

  8. The Moscow Times, "Sweden Accuses Russia of Widespread GPS Jamming Over Baltic Sea," September 2025, citing Swedish Transport Agency data. ↩

  9. GPS World, "13 EU Member States Demand Action on GNSS Interference," June 2025. ↩

  10. DISA, "NSDC Reports Intensified Russian GPS Jamming in the Baltic Sea," September 2025. ↩

  11. PBS News, "What to Know About Russia's GPS Jamming of a European Official's Plane," September 2025. Latvia's figures were reported alongside coverage of the GPS jamming of European Commission President Ursula von der Leyen's aircraft en route to Bulgaria on 1 September 2025. ↩

  12. ComplexDiscovery, "Cyber Warfare: GPS Disruptions in the Baltic Challenge Global Security," May 2024. ↩

  13. Defense News, July 2025, citing Jarosław Cydejko, adjunct assistant professor at Gdynia Maritime University. ↩

  14. Spire Global, "GNSS Interference Report: Russia 2024/2025—Part 1 of 4: Kaliningrad & the Baltic Sea," September 2025. ↩

  15. Finnair press statement, 29 April 2024. See also: Helsinki Times, "Finnair Suspends Tartu Flights for a Month, Citing GPS Jamming," April 2024; ERR News, "Finnair Plane Aborts Landing at Tartu Airport Due to GPS Interference," April 2024. ↩

  16. FlightGlobal, "Estonian Authority Seeks Alternative to GPS Navigation as Finnair Suspends Tartu Flights," April 2024. Estonia's EANS installed supplementary DME equipment in five locations to support aircraft navigation above 3,000 metres, while acknowledging that lower-altitude support remained a concern. ↩

  17. GPS World, "13 EU Member States Demand Action on GNSS Interference," June 2025. The joint letter was signed by transport ministers from Lithuania, Latvia, Estonia, Germany, Slovakia, Finland, Slovenia, the Czech Republic, Italy, the Netherlands, Spain, Denmark, and Romania. ↩

  18. AeroTime, "ICAO Condemns Russia and North Korea Over GPS Signal Jamming," October 2025. ↩

  19. The Moscow Times, September 2025. Andreas Holmgren, head of aviation at Sweden's Transport Agency, stated: "We have done analyses over a longer period and collected data. We can conclude that the interference is originating from Russian territory." ↩

  20. IALA, "GNSS Jamming and Spoofing: Navigating Challenges in the Baltic Sea," December 2024. See also: Deutschland.de, "GPS Interference: EU Project R-Mode Baltic," November 2024. ↩

  21. Defense News, July 2025. Ralf Ziebold, head of the German Aerospace Centre's nautical systems department, confirmed the expansion of R-Mode stations to Finland and Estonia, targeting pre-operational status by 2026. ↩

  22. Heise Online, "39C3: Navigation System 'R-Mode' Against the Baltic Jammer," December 2025. Presentation by Niklas Hehenkamp, Markus, and Lars from DLR Neustrelitz and Oberpfaffenhofen. The team described successful testing on Bavaria's Ammersee with water rescue services, achieving accuracy of approximately 10 metres, and initial aviation trials over Hamburg with a DLR research motor glider showing deviation of approximately 200 metres. ↩

  23. CloudFactory, "Strengthening AI Resilience: 3 Lessons from the 2025 AWS Outage," October 2025. See also: Medium, Valdez Ladd, "Cloud 'Infallible' Requires Resilient AI Systems After the October AWS and Azure Outages," November 2025. ↩

  24. InfoWorld, "Cloud-Based LLMs Risk Enterprise Stability," March 2026. The article documented the cascading impact of LLM provider outages on legal AI tools, customer service systems, and supply chain decision engines, noting billions in revenue losses and emergency remediation costs. ↩

  25. Universal.cloud, "AI Uptime: The Forgotten Risk in Your Application Landscape," April 2026. The analysis noted that measured LLM API uptime of 99.3 per cent equates to over five hours of downtime per month—a factor of seven worse than the 99.9 per cent SLA typical of traditional cloud infrastructure. ↩

  26. IsDown, "LLM Providers Status Report—December 2025," January 2026. ↩

  27. P J Laszkowicz, "The Sovereignty Trap: AI Power, Military Demand, and the Governance Gap," Responsible Engineering, February 2026. ↩

  28. Centre for Security and Emerging Technology, Georgetown University, "The Sovereignty Gap in U.S. AI Statecraft," 2026. ↩

  29. The CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) permits United States law enforcement to compel disclosure of data stored by US-headquartered companies regardless of where the data is physically located. ↩

  30. Media CCC, "Who Cares About the Baltic Jammer? Terrestrial Navigation in the Baltic Sea Region," 39th Chaos Communication Congress, December 2025. ↩

  31. Nordics Today, "Norwegian Airports Face Navigation Crisis as GPS Jamming Exposes Backup Gaps," December 2025. The article reported plans to remove ground-based systems from 19 smaller airports, opposition from the Norwegian Pilot Union and regional airline Widerøe, and the British precedent of retaining dual navigation systems. ↩

  32. Media CCC, December 2025. The full description: "What happens when a group of engineers decides to build a navigation system that simply doesn't care about the jammer?" ↩