The objection is always the same and it is always delivered as a conclusion.
A civilization capable of crossing interstellar distance does not hit the ground in a desert. Whatever solved propulsion and energy and the problem of getting from one star to another has certainly solved landing. The wreckage is the giveaway. The wreckage is how you know.
I want to take that seriously, and the only way I know to take it seriously is to look closely at a machine that failed and keep looking until the reason stops making sense.
On June 4, 1996, the European Space Agency launched Ariane 5 for the first time. Ten years of development. Roughly seven billion dollars. The most sophisticated launch vehicle Europe had ever built.
Thirty-seven seconds after liftoff, at about 3,700 meters, it veered off its flight path, came apart under aerodynamic load, and was destroyed by its own charges.
The inquiry board found the cause quickly. A component of the inertial reference system converted a 64-bit floating-point value, the horizontal velocity, into a 16-bit signed integer. Ariane 5 accelerated harder than its predecessor. The number outgrew the container. The conversion failed, the processor halted, and the redundant unit halted at the same instant for the same reason, because it was running the same code.
That is the version everyone tells. It is accurate and it is not the interesting part.
The interesting part is that the code had no function.
The routine that destroyed the rocket was an alignment process that continued running for fifty seconds after liftoff. It existed to handle a specific contingency on Ariane 4: a brief hold late in the countdown, after which the launch could resume without a forty-five minute realignment. Ariane 5 could not experience that contingency. The provision did not apply. The software was not doing anything.
It was left running because it had always been left running.
Consider what that means as a physical fact about the vehicle. There was, inside the most advanced machine on the continent, a piece of a previous machine. It was still executing. It was solving a problem that belonged to a different rocket, in terms that rocket had defined, in a body that had never had that problem and could not have it. It was correct. It had been correct for years. It performed its calculation faithfully every time it was asked, on a question nobody was asking, and on the fourth of June it was handed a number from an engine it was not written for, and it stopped, and everything above it stopped, and seven billion dollars came apart in the sky over French Guiana.
Now ask how anyone was supposed to find it.
Testing looks for functions that fail. This function did not fail. It had nothing to do, and it did nothing, correctly, in every test anyone ran. You cannot write a test case for the consequences of a routine whose purpose no longer exists, because to write it you would first have to notice the routine, and there is no reason to notice a component that has never once produced an anomaly.
The board established something else, which the engineers had told them: not every conversion in that system was protected. The specifications called for full integration testing that would very likely have caught it. The program was under budget pressure. Engineers chose the cheaper option, running subsystems independently rather than simulating a complete launch. Nobody in that decision was reckless. Each choice was defensible on the day it was made. The account of the failure notes the resemblance to Challenger, where risky behavior had also become normal by degrees.
Diane Vaughan established the mechanism in her study of that disaster. The shuttle's O-rings eroded on flight after flight, the erosion was documented, and every safe return made the erosion easier to accept, until an alarming anomaly had become an expected variation and then a routine operating condition. The night before the launch, engineers formally recommended against flying in the cold and were overruled. Nobody involved was corrupt or stupid. It was a functioning organization full of careful people, and the boundary of what counted as acceptable drifted outward, one defensible decision at a time, until it crossed the actual boundary, which had not moved.
So there are two things loose inside the machine. There is code nobody reads, and there is an organization gradually redefining what is safe. Both are invisible while everything works. Both are only legible afterward.
Charles Perrow had already argued in 1984 that this is structural rather than accidental. In systems that are interactively complex and tightly coupled, meaning too many components interacting in too many ways to enumerate, with too little slack to intervene when something goes wrong, the failures come from interactions nobody modeled. They cannot be designed out, because the remedy is to add safety systems, and safety systems are components, and components interact.
Notice that this is not a claim about technology level. It is a claim about shape. How many parts, how tightly bound, how fast.
Which is where the objection begins to come apart.
No complex machine is built from scratch. There has never been one. Ariane 5 inherited from Ariane 4, which inherited from what came before it, and the inheritance is not a stylistic choice but an economic necessity, because rewriting a proven subsystem costs money and introduces new errors and nobody can justify it while the old one is working. Every generation of a machine is mostly the previous generation. What is genuinely new is a thin layer at the top.
Apply that honestly to a vehicle capable of crossing light years.
It is not a device. It is an accumulation. It is the current version of something that has been iterated for a very long time by a civilization with budgets and schedules and program offices and turnover, and the overwhelming majority of what is aboard it was written or built by people who are no longer alive, for conditions that may no longer exist, in response to problems that were solved so completely that nobody remembers they were problems.
Somewhere in it there is a subsystem doing something that was necessary four hundred years ago.
Nobody has read it. There is no reason to read it. It has never produced an anomaly. It is correct, and it has been correct on every operation since anyone now living joined the program, and it will be correct until the day it is handed a value from a component that did not exist when it was written.
That is not a failure of their technology. That is what their technology is.
The people aboard do not know what all of it does. They cannot. The quantity of inherited machinery in any system that advanced exceeds what any individual or any team can hold, and this is not a deficiency in them, it is the definition of the thing they are operating. To be advanced is to be carrying more history than you can audit.
And given enough operations, the encounter happens. Some old assumption meets a condition it was never written for. Not because anyone was careless. Because the number of operations kept increasing and the assumption kept being carried forward and eventually the two intersect. That is not a risk. Over a long enough run it is a schedule.
The objection assumes something that is false about every complex machine that has ever existed, ours included. It assumes that a machine is a designed object, understood by the people who operate it, whose behavior is the sum of intentions somebody had. Nothing sufficiently complex is that. A sufficiently complex machine is a sediment, and the operators live on the surface of it, and the layers beneath are still running.
None of this establishes that any reported object is a craft from anywhere. It does not establish that any wreck exists or that any recovery occurred, and those questions have to be settled on their own evidence, which for most cases is not currently sufficient. I am not going to pretend otherwise in order to reach a conclusion I would prefer.
What it establishes is narrower and it is worth having. The claim that an advanced civilization would not crash is not a finding. It is an intuition about what advancement means, and the intuition is contradicted by everything we know about how complex systems behave. Advancement does not mean fewer failure modes. It means more of them, arriving faster, from further back, traced afterward to something small and old and administrative that nobody had any reason to look at.
A phenomenon with a perfect operational record would be the suspicious one. Flawlessness is a property of stories. Machines built by anyone, out of anything, obey laws that do not negotiate, and are operated by organizations that have deadlines, and carry inside them the fossils of every earlier version of themselves.
Something on board is executing right now. It was written for conditions that no longer obtain. It has been correct every time.




"The people aboard do not know what all of it does. They cannot. The quantity of inherited machinery in any system that advanced exceeds what any individual or any team can hold, and this is not a deficiency in them, it is the definition of the thing they are operating. To be advanced is to be carrying more history than you can audit.
And given enough operations, the encounter happens. Some old assumption meets a condition it was never written for. Not because anyone was careless. Because the number of operations kept increasing and the assumption kept being carried forward and eventually the two intersect. That is not a risk. Over a long enough run it is a schedule."
Sounds like a description of every large scale AI application. Will anyone know, in detail, what the app does or how it does it? If not, it's an automatic recipe for human, legal and financial disaster.
Thereās never enough time to do it right, but thereās always enough time to do it over.