Reliability Without MIL-SPEC: How New Space Companies Are Rewriting the Rules

In 1961, a NASA reliability engineer named Jerome Lederer gave a speech at the American Rocket Society in which he described the challenge of building systems that had to work perfectly the first time, in an environment that would destroy them if they did not. Sixty-five years later, that physical reality has not changed. What has changed is who builds the systems, how quickly they have to do it, and whether they can afford to spend three years on a standards compliance matrix before they launch anything.

The commercial space sector—SpaceX, Rocket Lab, Astroscale, True Anomaly, and roughly 200 smaller companies operating at varying stages of maturity—is not operating under MIL-SPEC. Most are not following GEIA-STD-0009 reliability program standards. Many are not following AS9100 in any rigorous way. They are launching anyway. Some are failing. More are succeeding. The engineering question worth examining is: what are they actually doing instead, and does it work?

What MIL-SPEC Was Actually Solving

Before dismissing legacy standards as bureaucratic overhead, it is worth being precise about what they were designed to accomplish.

MIL-SPEC and its civilian derivatives—MIL-STD-1629 for FMECA, MIL-HDBK-217 for parts reliability prediction, GEIA-STD-0009 for reliability program management—emerged from a specific context: large programs, multiple prime contractors, long development cycles, and systems that could not be tested at operational scale before deployment. The standards created a common language across organizations, enforced documentation discipline, and ensured that reliability analysis was performed at defined intervals regardless of schedule pressure.

The problem was not the intent. The problem was that compliance became the goal. Programs met documentation requirements without those documents meaningfully informing design decisions. Failure Mode and Effects Analysis worksheets were completed after design freeze. Parts screening requirements were applied to components that were never the dominant failure modes. The standards calcified into audit checklists rather than engineering tools.

New space companies looked at this and made a judgment call: the overhead was real, the benefit was often theatrical, and they could not afford either.

The Risk-Informed Alternative

The phrase “risk-informed design” appears frequently in commercial space engineering discussions, but it is used loosely enough that it requires unpacking.

In practice, risk-informed design at a new space company typically means: identify the failure modes that actually kill the mission, quantify their probability and consequence where you can, and focus engineering resources—testing, margin, redundancy, inspection—on those failure modes specifically. Everything else gets proportionally less attention.

This sounds obvious. It is not how traditional defense programs work. Traditional defense reliability programs apply systematic analysis to every subsystem at a defined level of decomposition, regardless of whether that subsystem is on the critical path to mission success. The rigor is consistent. The allocation of engineering attention is not risk-informed—it is compliance-informed.

The commercial approach concentrates effort differently. A propulsion startup building a monopropellant thruster for a small satellite will run its combustion chamber to failure repeatedly before flight, accept commercial-grade components in non-critical electrical subassemblies, and spend almost no time on a formal reliability prediction model. That is not recklessness. It is a deliberate choice about where empirical validation matters more than analytical paperwork.

The genuine risk in this approach is organizational memory. Risk-informed design depends on engineers accurately knowing which failure modes matter. That knowledge is often tribal, residing in specific engineers who have seen previous failures. When those engineers leave—and in a sector with significant talent competition, they do leave—the rationale for design decisions can disappear.

Anomaly-Driven Requirements Evolution

One of the more interesting engineering practices emerging in commercial space is what some teams are calling anomaly-driven requirements evolution: the systematic process of using flight anomalies, test failures, and near-misses to update system requirements in real time.

In a traditional program, requirements are baselined early and changed through formal change control processes that can take weeks or months. This is appropriate when multiple contractors are building to those requirements simultaneously. It is counterproductive when a 40-person team builds, launches, and operates its own satellite constellation.

What anomaly-driven evolution looks like in practice: a flight anomaly occurs, a root cause investigation identifies a gap between the operating environment and the assumptions baked into requirements, and that gap gets closed through a requirement change that is immediately propagated to the affected design documents, test procedures, and verification plans. The change is traceable, but the cycle time is days rather than months.

The engineering value of this approach is real. Requirements that survive contact with operational data are better requirements. The risk is that it requires robust traceability infrastructure to work safely. If you cannot determine, quickly, which downstream artifacts are affected by an upstream requirement change, you will close one gap while opening others. This is where manual documentation processes genuinely cannot keep pace with iteration cadence.

Internal Standards: The Hidden Engineering Work

What receives insufficient attention in coverage of the new space sector is the engineering standards development work happening inside commercial companies.

SpaceX’s internal engineering standards are not public, but they are extensive. Rocket Lab has developed internal material specifications, qualification approaches, and process controls that represent genuine engineering rigor, even if they do not reference a MIL-SPEC document number. Smaller companies are at varying stages of this work, but the better-managed ones understand that “we don’t use MIL-SPEC” cannot mean “we have no standards”—it has to mean “we have our own.”

Building internal standards is slow, expensive, and technically demanding work. It requires capturing the engineering rationale behind decisions, not just the decisions themselves. It requires maintaining those standards as products evolve. It requires onboarding new engineers to standards they cannot look up in a defense handbook.

The companies doing this well are treating internal standards development as a first-class engineering function. The companies doing it poorly are operating on tribal knowledge that will eventually produce a failure they could not explain or predict because they never wrote down what they knew.

There is also a supply chain problem. When a commercial space company builds internal standards that diverge from MIL-SPEC, their suppliers may not understand the requirements. A vendor who has spent 20 years building to MIL-STD-810 testing requirements will struggle with a customer specification that describes a different environmental test philosophy using different metrics. The lack of a common language creates integration risk that MIL-SPEC, for all its faults, was designed to prevent.

Acceptance Testing: Statistical Rigor Without Full-Rate Production

Classical acceptance testing at scale—the kind that generates statistically meaningful reliability data—requires production volumes that most new space hardware programs do not have. You cannot demonstrate a 99.5% reliability at 90% confidence with a sample size of twelve.

Commercial space companies are addressing this through several approaches that are worth examining separately.

Environmental stress screening over traditional acceptance testing. Rather than pass/fail testing to fixed acceptance criteria, some teams are using ESS to identify latent defects in individual units by exposing them to stress levels above nominal operating conditions. This is not new—it has roots in reliability physics work from the 1970s—but commercial space teams are applying it with more flexibility in test profile design than traditional programs allow.

Accelerated life testing with physics-of-failure models. Rather than running units to failure at operational conditions, teams use elevated stress levels combined with Arrhenius or other acceleration models to predict operational life. This is analytically sophisticated but depends heavily on the quality of the underlying physics model. When the physics are well understood—capacitor degradation, bearing wear—this works. When they are not, you are projecting from a model that may not capture the relevant failure mechanism.

Flight data as acceptance feedback. For constellations deploying dozens or hundreds of units, early constellation performance data becomes a reliability database in near-real-time. Anomaly patterns across early units can inform acceptance criteria for later production units. This is a genuine advantage of constellation architectures that single-spacecraft programs do not have.

None of these are perfect substitutes for statistically robust traditional acceptance programs. They are engineering pragmatics under resource and schedule constraints, and the honest assessment is that they carry residual risk that traditional programs would not accept.

Where AI-Assisted Engineering Tools Actually Fit

The commercial space sector’s rejection of documentation-heavy processes creates a specific problem: the knowledge that documentation was supposed to capture does not disappear just because you stopped writing it down. It has to live somewhere. For most teams, it lives in engineers’ heads, in Confluence pages, in Slack threads, and in Jira tickets that were never intended to be an engineering record.

AI-assisted engineering tools are finding genuine traction in new space precisely because the alternative—maintaining coherent requirements traceability manually at the pace these teams are moving—is not operationally viable.

The most practically useful applications are in requirements management and traceability. Modern tools can parse anomaly reports and flag which existing requirements they implicate. They can identify gaps between system-level requirements and subsystem-level implementations. They can surface latent inconsistencies in requirement sets that would otherwise go undetected until integration testing. These are not exotic capabilities. They are engineering functions that experienced systems engineers perform manually on traditional programs, at a pace that does not match commercial space development cadence.

Flow Engineering, which is built specifically for hardware and systems engineering teams, implements graph-based requirements traceability that supports exactly the anomaly-driven evolution workflow described earlier. When a requirement changes, the affected downstream artifacts—test procedures, design documents, interface specifications—are immediately visible. The traceability graph is the engineering record, not a separate RTM document that gets updated quarterly. For teams that have rejected the overhead of traditional standards compliance but cannot afford the risk of lost traceability, that kind of infrastructure is not a documentation tool—it is a safety function.

The important caveat is that tools do not substitute for engineering judgment. An AI-assisted requirements tool will help you maintain traceability on whatever requirements you have written. It will not tell you whether you have identified the right failure modes, set the right margins, or understood the right failure physics. The engineering decisions are still made by engineers.

The Honest Assessment

New space companies have made a credible case that MIL-SPEC compliance as practiced in legacy defense programs was often more process theater than genuine reliability engineering. That case is well-supported by evidence.

What has not yet been fully demonstrated—because the sector has not been operating long enough to generate the data—is whether the alternative approaches are producing hardware that matches the operational reliability of mature defense space programs over extended mission durations. The five-year-old Falcon 9 record is compelling. The five-year-old record of the broader commercial smallsat sector is more mixed.

The companies most likely to get this right are the ones building genuine internal engineering standards, maintaining rigorous traceability as requirements evolve, investing in failure physics understanding rather than just process compliance, and treating anomaly data as a continuous input to engineering decisions rather than a post-launch report card. That is rigorous engineering. It just looks different from the standards frameworks that codified rigor for the previous generation of programs.

The companies most likely to get it wrong are the ones that have confused moving fast with thinking less carefully—and have mistaken the rejection of documentation overhead for the rejection of systematic engineering thought.

The physical environment in orbit has not relaxed its requirements because the people building hardware for it changed their organizational culture.