No one inside SpaceX, except for Elon Musk himself? https://arstechnica.com/space/2025/05/spacex-pushed-sniper-t...

Dealing with liquid oxygen is hard, but we've been dealing with it in rocket engines since the 1940s at least. It's not a mystery, but like anything in aerospace, as the saying goes, it is terribly unforgiving of any carelessness, incapacity or neglect.

You're assuming "before" when it's probably "investigate 100 possible causes in parallel".

Relevant WKUK sketch: https://www.youtube.com/watch?v=mpC_hO15IoA

We hear about how dealing with liquid oxygen is hard. I don't know that we hear about industrial sabotage.

It reminds me of my younger self when I encountered inexplicable behavior in my own software, “I think I found a bug in Firefox!” … “Oh, nope. I forgot to add an event handler.”

>feels very Elon

why

[dead]

[flagged]

The real concern was Russia, given SpaceX has always been a MIC project, now publicly manifest as "Golden Dome" .. a program which undermines M.A.D. and obviously greatly incentives sabotage. There just happened to be a ULA building nearby that was in range and investigated as a possible vector of attack.

> if you take that approach when testing all the thousands of components together, which is simply just too complex to exhaustively model[1], you'll never get anywhere.

This is exactly why ideas like test-driven development don't work well as a general approach.

Most realistic systems exhibit non-linear interactions where correctness is not compositional. Local correctness does not compose upward in any meaningful sense. Top-down design (working backward from the customer) allows for you to perform what is effectively one big global search. Bottom-up design (TDD) requires many local searches that all have to fit together perfectly at the very end. With units & composition, the consequences of component A's interactions with component B may not be considered until nearly the end of the project. If you are testing an integrated vertical, you will discover these interactions much earlier.

No, this would be crushing regardless. Even if Blue Origin had dozens of rockets ready to go, they can't fly without without the pad, which will take around a year to repair (based on previous examples).

Risk aversion is very risky.

Failure is not only an option, but is required. The more smaller failures you have, the more big successes you can have.

> Crushing only because their cadence is so slow compared to SpaceX. Their process seems much closer to the highly risk averse methodology of traditional incumbents than to SpaceX's style. Failure becomes a self-fulfilling prophecy.

This is a silly perspective. Some reports suggest SpaceX's 1-year budget is around 20 times the yearly budget of Blue Origin. Of course SpaceX can afford to blow up rocket after rocket. The radical difference is not methodologies, but how much cash is being thrown at the project.

For perspective, apparently the whole lunar lander program ran on a 1-year budget much similar to SpaceX's, and thus 20 times larger than Blue Origin's. Where they also highly risk- averse?

BO was founded in 2000 and has about 2 orbital launches with a partly reusable system. They build rockets.

SpaceX was founded in 2002 and has around 660 orbital launches with a fully reusable system. They build rocket factories.

BO is absolutely the underdog, in every way, unless you want to count 38 suborbital joyrides, then they're ahead at 38 to 0.

Always hope for the stupid mistake. It’s embarrassing but so much better than having the same problem caused by a complex and difficult-to-root-cause issue.

After a long day of working on a car I would much rather have it fail to start because I forgot to connect the battery than fail to start because the starter I replaced had been returned to the store by a previous purchaser, with the wrong part in the box, which was mechanically compatible with the mount but not with the flywheel. (Hypothetically speaking…)

Sort of - if it's determined that somebody bypassed a safety control they can just make the control firmer and fire that person and move onto other things. If it's some fundamental flaw in the engine design that could set them back months/years.

Calling Blue Origin a vanity project is so ridiculous.

I'd bet lots of telemetry, comprehensive design and change documentation, along with engineers tacit knowledge.

Something like:

telemetry shows dramatic drop of temperature on this, that given the location of the sensor could only be caused by a specific LOX line leak, and vibration sensors show data compatible with friction as the ignition event and not a short circuit because the relevant telemetry doesn't show any electrical abnormality, so, by exclusion, given no other anomalies, give that computer simulations show it is a feasible scenario, followed by lab work with a physical model, this must be the cause of the accident.

Are there enough open source aero engineering projects to give the current ai approaches a remotely plausible amount of training data?

Imagine is a good word to use. Before offering a solution, understand the problem first - is "debugging speed" a problem that needs solving, in this case?

Much more likely is that it would hallucinate a plausible sounding but incorrect answer and send intermediate and junior engineers on a wild goose chase