Why we open our software foundation

In May 2025, Exercise Hedgehog brought more than 16,000 personnel to Estonia for one of the country’s largest military exercises. The official purpose was to test readiness and allied integration. One episode reported afterwards made a different lesson unusually clear.

Around ten Ukrainian drone operators, acting as the opposing force, were credited in press accounts with the simulated destruction of 17 armoured vehicles and roughly 30 other strikes in about half a day. The wider opposing force was reported to have rendered two battalions combat ineffective within the exercise scenario [1][2].

This was an exercise, not combat. Simulated losses are not battlefield losses, and the episode should not be stretched into a verdict on every allied unit involved. Its value is architectural. It showed the gap between owning capable equipment and organising that equipment for a battlefield shaped by persistent sensors, distributed operators and compressed decision cycles.

Europe does not lack mission applications, sensors or platforms. It lacks a common tactical system layer that lets them operate together, survive disruption and change without rebuilding the foundations for every programme. Penrose Tactical is opening that layer. This article explains why, what will be published, what remains closed, and what a customer actually buys.

The lesson was not simply about drones

Drones made the result visible. The deeper issue sits underneath the applications. A concentrated command post can be found, characterised and struck. A distributed force must therefore move command, sensing and decision support across vehicles, unmanned systems, remote sensors and dismounted teams.

Every node in that force has to remain useful on its own. It must be operable by a non-specialist. It must continue working when the expected network disappears, then rejoin the wider fleet when a link returns.

That requirement changes the meaning of resilience. Resilience is not a server that recovers after an outage. It is a fleet that continues to produce, decide and act while parts of the network are unavailable.

The electromagnetic environment makes this more than a design preference. A 2023 RUSI study estimated Ukrainian unmanned aircraft losses at approximately 10,000 a month at that stage of the war, with electronic warfare contributing heavily to the attrition [3]. In the Baltic region, civil aviation and maritime navigation have also experienced a sustained rise in GNSS jamming and spoofing. European authorities now treat alternative navigation, monitoring and contingency procedures as necessary safeguards [5].

A tactical system must therefore know when not to transmit. It must favour a wired bearer when one exists, store information while radio silence is required, send in controlled bursts when policy allows, and remain fully usable throughout. Emission control cannot depend only on an overloaded operator remembering the correct procedure at the correct moment. It has to be a system property.

Disruption is an operating condition

In July 2025, a global satellite service outage interrupted Ukrainian military communications and some drone operations for roughly two and a half hours. A senior Ukrainian commander publicly called for communication methods to be diversified [4].

The incident did not show that satellite communications are ineffective. They have delivered exceptional operational value. It showed that even a highly valuable bearer can become a single dependency if the system beneath the mission assumes it will always be present.

The same principle applies at boot. Equipment that refuses to start because a licence server cannot be reached, a signature has expired or an update was interrupted may be secure in a narrow administrative sense, yet unavailable for the mission. The right response is not to hide the fault or silently weaken security. The node should start in an explicit degraded posture, record why it is degraded, restrict what policy requires and preserve the capabilities that remain safe to use.

This is one of our core design convictions. Degraded operation is not an exception path added before acceptance. It is the normal condition from which tactical availability must be engineered.

Battlefield and industrial clocks have separated

The second structural break is speed. The measure, countermeasure and counter-countermeasure cycle has compressed. Counter-innovations that took a month in early 2023 now appear in two or three days. Crews describe updating embedded software every four to six weeks simply to remain relevant [6].

Traditional programme cycles were not designed for this rhythm. A modification that is technically small can trigger proprietary integration work, a new hardware dependency and another vertical qualification cycle. The team is then asked to move faster inside an architecture that makes every movement expensive.

This is why we judge an architecture by the cost of changing it, not by the length of its feature list.

The supply chain reinforces the point. Tactical systems often remain in service far longer than the commercial components inside them remain available. If application software is tied to one processor, accelerator or board family, component obsolescence becomes a software rewrite and a programme risk. A hardware abstraction layer changes that equation. Replacing a target becomes a bounded integration exercise instead of a reconstruction of the application stack.

Fast adaptation is not achieved by demanding permanent urgency from engineering teams. It is achieved by removing the architectural reasons that every change spreads.

Europe keeps paying for the same invisible layer

The tactical software market can be read in three layers.

The first is the system foundation beneath the applications. It handles verified boot, software isolation, hardware interfaces, identity, cryptography, resilient transport, exchange formats, updates and fleet management.

The second is the mission layer. It contains the applications that create operational value, including situational awareness, sensor exploitation, autonomy, logistics and decision support.

The third is programme integration. It connects a product to a specific platform, assurance framework, operator and support model.

European industry is rich in the second and third layers. The recurring problem sits at the foundation. The same technical groundwork is rebuilt by vendors and programmes because no shared product is assumed. Interoperability then arrives as a negotiated work package, after the systems already have different data models, security boundaries and update mechanisms.

That layer is nobody’s core business. It is paid for once per vendor, once per programme, then once again at every requalification. The customer ultimately pays for each reimplementation, each gateway and each requalification. Yet this work rarely differentiates the mission application that wins the contract.

Generic open source covers part of the need. Kernels, orchestrators and hypervisors already exist. What the civil ecosystem does not ship as an assembled product is the combination of defence constraints: verified boot end to end, modules that can be signed and revoked offline, emission discipline, useful operation with no remote infrastructure, and a cryptographic posture that can move toward post-quantum protection. Each brick exists somewhere. The foundation assembled, tested and documented for those constraints is what has been missing as a shared European product.

Our conclusion is direct. Interoperability should be a property of the foundation, not a project added after procurement.

AGELAIOS occupies the missing layer

The Ukrainians have Delta. The Americans have Lattice. We offer the European interoperability layer. That sentence is a market position, not a claim of operational equivalence. Between the mission application and the embedded computer sits an operating-system foundation that nobody in Europe currently sells as a shared product. Yet it is what decides whether two pieces of equipment understand one another, whether an update can be pushed safely, and whether the node stays useful when the link drops.

AGELAIOS is not another command application. It is that foundation, designed for open-source release and built to host mission applications.

Its purpose is to provide the shared technical discipline that every tactical product otherwise has to assemble for itself. The complete distribution is designed to remain around 200 MB before mission applications. Its minimal core is written in Rust. Applications and third-party modules execute in declared compartments, with resources and capabilities granted by policy rather than inherited by default.

The operating system is designed around signed, identified images. Where the hardware provides a root of trust, boot can be verified and measured so that what is running is known. Where it does not, the posture is reduced explicitly and logged rather than presented as nominal.

The data bus works across the bearers a node can actually find, including Ethernet, Wi-Fi, serial links, embedded buses and low-bandwidth radio. Nodes continue accumulating information during separation and reconcile their operational pictures after reconnection. There is no mandatory central server whose loss stops the fleet.

Emission posture, hardware abstraction, software isolation and tactical exchange formats belong together because the operational outcome depends on all of them. A secure module that cannot communicate over the surviving bearer is not useful. A resilient network that reveals the unit through uncontrolled transmission is not survivable. An interoperable application that must be rewritten for the available computer is not deployable at the required pace.

The foundation is where these constraints meet. Opening it is how that meeting place becomes usable by more than one programme.

Opening the code is an industrial decision

The question is fair, and practice has already answered part of it. Almost every system in service already carries a significant share of open software: kernel, security layers, drivers, protocols, transcoders, compilers. If the presence of readable source were a blocker, it would have blocked fielded systems long before AGELAIOS.

We will release the AGELAIOS Standard Edition as open source under the Apache 2.0 licence [8]. That choice is not a claim that publishing source code makes a system secure. It creates the conditions for scrutiny, reuse and continuity.

The security of an operational instance must rest on the protection of its secrets, not on the secrecy of its mechanisms. A serious attacker goes after the binary in service, not the published source. Closed code does not deprive a state adversary of durable access. It mainly deprives defenders, auditors and allies of a capacity to verify. Source access allows customers, partners and evaluators to examine the foundation before committing their own applications and fleets to it.

Speed is the second reason. An exposed foundation has to move fast, at a time when generative artificial intelligence makes it possible to find and exploit a vulnerability within hours. Closed development, cut off from ecosystem feedback and from common tooling, is fixed more slowly than it is attacked. Putting the foundations under the standing scrutiny of many parties raises the number of defects found and shortens the time to fix them.

The third reason is commercial continuity. A proven open licence settles intellectual property and patent grants up front, eases audit, and removes the arrangements otherwise needed to protect a customer against a supplier disappearing. If Penrose Tactical were to disappear, access to the foundation would not disappear with it. Publishing the code is the best guarantee of continuity a buyer can obtain.

The source is common. Operational secrets are not. Private keys, fleet data, frequency plans, deployed topologies and mission configurations remain specific to each operator and outside the published foundation.

This distinction matters commercially. We are not asking customers to buy access to a black box. We are asking them to buy accountable industrial delivery around a foundation they can inspect.

Two editions, one foundation

The open foundation is only one part of an operational system. Entry into service creates industrial responsibilities that source code alone cannot carry.

The Standard Edition is the inspectable core. It is designed to include the operating-system recipes and build chain, stable application and binary interfaces, a development kit to create and publish modules, x86-64 and ARM64 emulators, starter kits for widely used computers, the message bus, the mesh, emission postures, node discovery, commercial-grade cryptography, conventional verified boot, hardware abstraction and interoperability protocols. Implementation documentation is written so that a team can port the foundation and produce a first module without waiting for a programme contract.

The Program Edition is built on that same core. It adds what operational service demands: qualified and certified builds, post-quantum cryptography in service with ML-DSA and ML-KEM [7], industrial-grade verified and measured boot with A and B installation, fleet key infrastructure, identity federation and coalition controls, role-based access, a signed software bill of materials, industrial provisioning, long-term support, in-service observability, a store of certified modules, mission replay and inventory management.

The team moves from the Standard Edition to the Program Edition as soon as the programme enters service. Same base, same interfaces, same standards. Customers are not paying us to recreate generic plumbing behind a proprietary boundary. They are paying for the foundation to be adapted, evidenced and supported for their programme, while their own engineers remain focused on the capability that differentiates them.

That model gives partners a low-friction path to begin and a responsible path to enter service. It also gives public buyers a better form of sovereignty. They can retain control of the source, their instance and their secrets while purchasing the assurance and support they actually need.

Evidence has to precede scale

As recorded in the frozen product dossier dated 20 August 2026, the AGELAIOS reference programme reports more than 2,800 automated tests passing on the reference repository, nine continuous integration chains with bit-for-bit reproducible builds, 774 governing specifications and 429 pages of illustrated user documentation maintained against the product baseline to the ASD S1000D standard. The dossier assesses maturity between TRL 6 and 7, demonstrated on emulators and commercial equipment.

Those figures describe the reference baseline at that date. They do not prove that every target platform, bearer or national assurance profile is already qualified. Qualification belongs to a defined configuration and intended use.

What the baseline provides is a disciplined starting point. A reproducible build means a third party rebuilds the binary from source and obtains exactly the same result, hash included. A signed software bill of materials exposes composition. Automated campaigns test defined behaviours such as module isolation, rollback and degraded operation. The standards register distinguishes what is supported, aligned, partial, planned or a declared deviation. We do not turn those different states into one blanket claim of compliance.

That is how we want AGELAIOS to be evaluated. Inspect the requirement. Replay the test. Change the hardware target. Break a module. Interrupt the link. Challenge the cryptographic policy. A tactical foundation should earn confidence through observable behaviour.

Three steps, without a non-disclosure agreement

A standard is worth only as much as the number of players using it. The core is open so that anyone can try it, port it to their own hardware and judge for themselves whether it fits. All of that without prior agreement, without a non-disclosure agreement, without an appointment.

The path we propose is the one written into the product booklet.

1. Take the open distribution and run the demonstration in the emulator, on x86-64 or ARM64. No specific hardware is required. The walkthrough is in the emulator documentation.
2. Port the foundation onto your own target and write your first module from the documentation.
3. Confront the result with your real use case. Only then should we talk about your programme.

A foundation that has to be taken on trust is not a foundation. Verification is the product.

Our reason for being

Penrose Tactical exists because Europe needs to adapt on the timetable set by the operational environment, not on the timetable inherited from closed and vertically integrated software stacks.

We believe Europe can field a common tactical foundation without erasing the value of national programmes or industrial competition. On the contrary, a shared system layer lets that competition move upward, toward better sensors, better autonomy, better interfaces and better operational applications.

Our ambition is to help establish an open, interoperable and coalition-ready European standard across drones, loitering munitions, vehicles, robots, dismounted teams and heavy platforms. We bring experience in ruggedised embedded systems, defence programme delivery, public procurement and the disciplined use of generative AI from specification through validation.

The claim is not that AGELAIOS has already solved every integration problem. The claim is that Europe should stop treating the same foundational problems as proprietary discoveries in every programme.

The battlefield has already shown what the next generation of tactical systems must endure. Our work is to make those requirements available from the first architectural decision, then prove them one build, one target and one fleet at a time. The code is ready. Put it to the test.

Sources

1. Estonian Defence Forces, “The Estonian Defence Forces have concluded their largest exercise of the year, Hedgehog 25”, 23 May 2025, https://mil.ee/en/news/the-estonian-defence-forces-have-concluded-their-largest-exercise-of-the-year-hedgehog-25/
2. Militarnyi, “Ukrainian Drone Operators Defeated NATO Combat Group During Joint Exercises”, 2026, https://militarnyi.com/en/news/ukrainian-drone-operators-defeated-nato-combat-group-during-joint-exercises/
3. Jack Watling and Nick Reynolds, Royal United Services Institute, “Meatgrinder: Russian Tactics in the Second Year of Its Invasion of Ukraine”, 19 May 2023, https://www.rusi.org/explore-our-research/publications/special-resources/meatgrinder-russian-tactics-second-year-its-invasion-ukraine
4. Reuters, “Ukraine says Starlink’s global outage hit its military communications”, 25 July 2025, https://www.reuters.com/business/media-telecom/ukraine-says-starlinks-global-outage-hit-its-military-communications-2025-07-25/
5. Council of the European Union, “Call for common actions in response to Global Satellite Navigation Systems jamming and spoofing threats”, 26 May 2025, https://data.consilium.europa.eu/doc/document/ST-9198-2025-INIT/en/pdf
6. Penrose Tactical, AGELAIOS product booklet, revision 20260820, 20 August 2026, citing published analyses of adaptation cycles in Ukraine, 2025 and 2026.
7. National Institute of Standards and Technology, “FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard” and “FIPS 204 Module-Lattice-Based Digital Signature Standard”, 2024, https://csrc.nist.gov/pubs/fips/203/final and https://csrc.nist.gov/pubs/fips/204/final
8. Apache Software Foundation, “Apache License, Version 2.0”, 2004, https://www.apache.org/licenses/LICENSE-2.0