Epirus and the Leonidas System: Systems Engineering at the Edge of Directed Energy

How a defense startup tackles requirements management, EMC compliance, and DoD acceptance for a weapon class that has no established playbook

Epirus is a Los Angeles-based defense technology company building high-power microwave (HPM) directed energy weapons. Their flagship system, Leonidas, is designed to defeat drone swarms by disrupting the electronics of multiple unmanned aerial systems simultaneously using focused microwave energy. The company has secured contracts with the U.S. Army, demonstrated the system in operational environments, and attracted significant defense investment. On the surface, it is a story about a new weapon working. Underneath, it is a systems engineering story about what happens when you try to build something that no existing standard was written to describe.

This profile does not assess the weapon’s classified performance. It examines the engineering process challenges that any organization — startup or prime — faces when developing a directed energy system, using Epirus and Leonidas as the concrete case.

The Requirements Problem: Defining Effectiveness for Something That Has Never Been Fielded

Every systems engineering program begins with requirements. For a conventional kinetic weapon — a missile, a gun, a warhead — the effectiveness requirement is blunt and testable: does the target stop functioning? The damage mechanism is understood, the test conditions are enumerable, and MIL-STD-882 risk matrices have decades of precedent.

HPM directed energy does not work this way. Leonidas defeats drones by inducing voltage transients in their electronics — disrupting flight controllers, GPS receivers, communication links, or propulsion systems. The effect is probabilistic, target-dependent, geometry-dependent, frequency-dependent, and pulse-duration-dependent. The same power level that neutralizes one commercial DJI-class drone may leave a hardened military UAS unaffected. The “effectiveness” of the weapon is not a single number. It is a family of curves across a target space that is itself moving.

This creates a requirements engineering problem that document-based tools handle poorly. When your System Requirements Specification (SRS) needs to capture a stochastic effectiveness model rather than a binary pass/fail criterion, the traditional “the system shall” statement form becomes a constraint rather than a framework. Writing “the system shall defeat 95% of Class I UAS targets within 400 meters” sounds clean until you try to define “defeat,” agree on what constitutes a “Class I UAS” given the diversity of commercial hardware, and design an acceptance test that is reproducible and not classified.

Epirus, like every directed energy developer before them, had to construct the effectiveness requirement definition as a parallel engineering activity to the hardware development itself. They did not inherit it from a prior program. This is the first distinctive challenge of novel weapon class development: the requirements authority and the design authority are the same team, which creates both agility and governance risk. The program office must simultaneously trust the developer’s effectiveness models and independently verify them — a tension that shapes every systems review from SRR through CDR.

EMC/EMI Requirements Management: When Your Weapon IS the Interference

Electromagnetic compatibility engineering for conventional defense electronics is mature and well-specified. MIL-STD-461 provides emissions and susceptibility limits. MIL-STD-464 addresses system-level electromagnetic environmental effects. The process is rigorous but tractable: characterize what your system emits, ensure it doesn’t exceed limits, ensure it isn’t disrupted by external fields.

A high-power microwave weapon inverts this entirely. Leonidas generates high-intensity microwave radiation as its primary function. The system’s own emissions are the weapon effect. This creates several EMC/EMI management challenges that standard compliance workflows don’t address directly.

Self-compatibility at the system level. The electronics that control the beam — the targeting systems, the power management controllers, the operator interface, the safety interlocks — must function correctly in the presence of the same high-power RF environment the weapon generates. This is not a standard EMC qualification problem. It requires the EMC engineer and the system architect to define operational zones, shielding architectures, and software interlocks that are unique to HPM weapon systems. Every design change to the antenna array, the pulse characteristics, or the beam steering architecture has cascading EMC implications for the platform electronics. Tracking those dependencies with a flat document hierarchy or a manually maintained requirements traceability matrix (RTM) is functionally inadequate at any development tempo.

Platform integration compatibility. When Leonidas is mounted on a vehicle — a Stryker, a JLTV, or a fixed installation — every piece of vehicle electronics becomes a susceptibility concern. The Army’s electromagnetic environmental effects (E3) requirements for vehicle integration are extensive, but they were written for receivers, not for co-located transmitters of this power class. The requirements management challenge is characterizing the interface between the weapon system’s EME and every other electronic system on the platform, then translating that characterization into testable interface requirements that both the weapon developer and the platform integrator can own.

Friendly force susceptibility. HPM weapons have a fratricide dimension that kinetic systems don’t: the weapon’s emissions can affect the electronics of nearby friendly systems — vehicles, aircraft, personnel-worn equipment — if geometry and power levels align. The operational requirements for safe use geometry must trace directly to the physical emission characterization, which traces to the antenna design, which traces to the power system architecture. A break anywhere in that chain means the safety case is unverified.

Managing these interlocking dependencies requires a requirements model that understands relationships between requirements, not just a list of “shall” statements with associated test methods. When the safe employment geometry changes because the beam steering capability improves, every downstream requirement that depended on the prior geometry must be flagged and reverified. In practice, this is where programs that rely on document-based requirements management — where traceability is maintained through manual cross-references in a Word document or a static DOORS module — accumulate technical debt that surfaces painfully at system-level testing.

Power System Integration: Requirements That Cascade

Leonidas is not a small system. Generating microwave pulses of sufficient power to disrupt drone electronics at tactically useful ranges requires significant electrical power — estimates based on public program descriptions suggest continuous power demands in the tens of kilowatts, with peak pulse requirements well above that. On a vehicle platform, this means the weapon system’s power requirements are not an accessory load; they are a primary driver of vehicle integration architecture.

The systems engineering challenge here is the requirement cascade. The effectiveness requirement defines the required field intensity at the target. That traces to a required radiated power level. That traces to a required input power level at the transmitter, accounting for efficiency losses. That traces to a required power generation or storage capacity on the platform. That traces to thermal management requirements for both the weapon system and the vehicle power system. That traces to mechanical envelope and weight constraints that affect vehicle dynamics and payload capacity.

Each link in this chain is a requirements interface. And each interface is a change propagation risk. If the transmitter efficiency improves by 15% because of a solid-state amplifier architecture improvement — a genuine development-phase discovery — the power system requirements change, the thermal requirements change, and potentially the vehicle integration requirements change. Every one of those changes needs to be verified, documented, and accepted by the relevant authority before the next configuration baseline is established.

At a prime contractor operating on a traditional defense program timeline, this is slow but manageable. The configuration control board meets, the changes are reviewed, the affected requirements are updated, and the program moves forward. At a startup operating on a venture-backed cadence with a 12-to-18 month development sprint mentality, the same process becomes a bottleneck unless the requirements management infrastructure is built to handle high-velocity change from the beginning.

This is precisely where startups tend to underinvest. The engineering is fast. The requirements documentation lags. By the time the system reaches CDR or government acceptance testing, the disconnect between what the system actually does and what the approved requirements baseline says it should do is wide enough to create significant re-verification burden.

DoD Acceptance Testing: Where Process Architecture Becomes Visible

Government acceptance testing for a defense system is not a final exam. It is a process audit. The test events — DT&E, OT&E, IOT&E — are designed to verify that the system meets its specified requirements, but the unstated prerequisite is that the requirements specification accurately describes the system, that the test procedures are traceable to specific requirements, and that the configuration of the system being tested matches the configuration that was designed and documented.

For a novel weapon class, the acceptance testing challenge is amplified at every stage. Leonidas’ test events require the program office and Epirus to agree on target surrogates — what represents a “Class I UAS” in a controlled test environment — and on defeat criteria that are observable, measurable, and reproducible without using operationally classified information as the test standard. This is a requirements engineering problem that runs all the way to the test range.

The startup development cadence creates a specific risk here: the system being tested may be genuinely different from the system that was baselined at CDR. Software changes, firmware updates, hardware revisions driven by manufacturing improvements — all of these are normal in an agile defense development environment. But each one requires a configuration change record, a regression analysis, and a determination of whether prior test results remain valid. Programs that lack the discipline to maintain a clean configuration baseline through rapid iteration arrive at acceptance testing with an implicit question hanging over every result: which version of the system is this?

The resolution to this tension is not to slow down development. It is to invest in the process architecture — requirements management infrastructure, configuration control discipline, and test traceability documentation — early enough that it runs in parallel with engineering, not behind it. The programs that manage this successfully treat requirements management as a first-class engineering activity, not an administrative burden.

Managing MIL-STD Compliance at Startup Velocity

Epirus occupies a specific position in the defense technology ecosystem: well-funded enough to build and demonstrate a real system, but structured around the development speed that differentiates them from legacy primes. The MIL-STD compliance burden — 461, 464, 810, 882, 1553 if applicable, and whatever directed energy-specific standards the program office adds — is real and non-negotiable for a program heading toward fielding.

The approach that works, based on what is publicly observable in Epirus’ program structure and similar defense startup programs, has three components.

First, hire compliance expertise early and integrate it with the engineering team, not adjacent to it. EMC engineers who know MIL-STD-461 well enough to shape design decisions, not just test against them after the fact, are worth their cost many times over in rework avoidance.

Second, build requirements traceability infrastructure that can handle the change velocity of a startup. This means a tool environment where requirements have defined relationships to each other and to test procedures, where a design change automatically surfaces the downstream requirements that need re-evaluation, and where the state of the traceability model is always current rather than catching up to the engineering. The cost of not doing this is not visible until acceptance testing, at which point it is extremely expensive.

Third, establish a configuration baseline rhythm that is faster than a traditional prime but rigorous enough to support DoD oversight. Monthly or sprint-aligned configuration snapshots with clear change records are achievable and accepted by sophisticated program offices working with defense startups. What is not accepted is a fuzzy configuration state at a major test event.

Honest Assessment

Epirus has demonstrated that a defense startup can build a credible high-power microwave weapon system and bring it to operational demonstration. That is not a trivial achievement. The systems engineering challenges of directed energy — requirements definition for a novel weapon class, EMC management where the weapon IS the emission, power system requirement cascades, and acceptance testing of a probabilistic effect — are genuine and not fully solved by any program in this space.

The broader lesson for the defense technology ecosystem is that the disciplines that differentiate successful novel weapon programs from expensive failures are not primarily the physics or the electronics. Those are hard problems with engineering solutions. The differentiating disciplines are requirements management, configuration control, and test traceability — the infrastructure that makes it possible to know, at any point in the program, exactly what you’ve built, exactly what it’s supposed to do, and exactly how you’ll prove it.

For defense startups competing in directed energy and other novel weapon classes, the investment in that infrastructure is not overhead. It is the mechanism by which fast engineering becomes fielded capability.