When Safe Mode Is Not Enough For Autonomous Spacecraft – Analysis

Key Takeaways:

• Katalyst Space’s LINK launched in July to capture and boost NASA’s Swift observatory. Attitude-control trouble cut the job to rendezvous only; by early September it was 12–15 km from Swift and NASA said it would come no closer. Author’s point: when a mission premise fails, authority to keep the original plan should fail with it—and that rule should live in the spacecraft, not only on the ground.
• NASA’s 2005 DART hit MUBLCOM while closing at 1.5 m/s; its nav thought it was 130 m away and backing off at 0.3 m/s. Avoidance used the same bad nav as guidance. The piece names a missing state: LOSS OF GUARANTEE—best-effort protection after the evidence for the safety claim has gone. A mode called SAFE only means software entered that label. A toy approach model: flagged nav bias plus “inhibit commands” still crosses if closing speed remains; bounded braking does not—unless bias is unseen, thrust is short, or delay is tens of seconds.
• Two parallel states: control (nominal, protective, halt) and assurance (is the claim still evidenced?). GUARANTEE LOST should shrink mission authority, keep only preauthorized physical actions, name the broken premise (nav, thrust, timing, margin), and block auto-resume on a timer. Independence is shared evidence, not extra boxes—NASA already asked for collision-avoidance sensors apart from primary nav. Gateway contracts and R2U2 point that way; the ask is to surface “acting, but the guarantee no longer holds.”

NASA’s scaled-back Swift servicing mission is a reminder that protective action is only as trustworthy as the evidence behind it. Future spacecraft need a way to say when a safety guarantee no longer holds.

A spacecraft does not have to fail completely for the assumptions behind its mission to change. NASA received a timely reminder this summer. Katalyst Space’s LINK robotic servicing spacecraft launched in July to rendezvous with, capture, and boost NASA’s Neil Gehrels Swift Observatory. After LINK developed attitude-control problems, NASA and Katalyst scaled the mission back: LINK would no longer capture or boost Swift, but would continue rendezvous and proximity operations as a technology demonstration.

By early September, LINK had approached to within roughly 12 to 15 kilometers of Swift, but NASA said it would go no closer. The episode is not evidence of a failure in autonomous safety logic. It illustrates something more basic: when a premise supporting the original mission changes, the authority to continue the original mission can change with it.

That distinction should exist inside autonomous spacecraft, not only in the ground teams supervising them.

A spacecraft can execute the right command for the wrong world. NASA learned a more violent version of that lesson in 2005, when its Demonstration of Autonomous Rendezvous Technology spacecraft, DART, collided with the MUBLCOM satellite during an autonomous rendezvous demonstration. According to NASA’s public mishap overview, DART was actually closing on the target at 1.5 meters per second while its navigation system believed it was 130 meters away and retreating at 0.3 meters per second. The spacecraft had collision-avoidance logic. The deeper problem was that the collision-avoidance function depended on the same navigation source as the guidance system. When that source became badly wrong, both layers inherited the same fiction.

That distinction matters more now than it did two decades ago. Autonomous spacecraft are moving from scripted sequences toward systems that can monitor themselves, replan, manage faults, and continue operating with less immediate human supervision. NASA’s Gateway Vehicle System Manager is being developed with design-time and runtime assume-guarantee contracts. NASA research on runtime assurance for autonomous systems uses the familiar idea of a monitor that detects a problem and hands control to a trusted recovery mechanism. In spacecraft docking research, runtime-assurance architectures have already been compared in three-dimensional docking problems, while control-barrier-function methods have been used to keep docking trajectories inside defined safe sets.

But there is a state that our autonomy vocabulary still handles poorly: the system is doing the best protective thing it knows how to do, but the guarantee behind that action is no longer supported. That is not the same as nominal operation, and it is not the same as an ordinary fault. It deserves an explicit name: LOSS OF GUARANTEE.

The point is easy to miss because several different questions are often compressed into a single word such as “safe,” “authorized,” or “fallback.” They are not the same question. Is the mission controller permitted to continue? Is the navigation estimate still inside its declared error bounds? Can the spacecraft still deliver the braking or thrust that the protective maneuver assumes? Will the resulting physical trajectory actually preserve the boundary that matters? A software state transition can answer the first question correctly while the answers to the others have already changed.

A mode named SAFE therefore does not prove that the spacecraft is safe. It proves only that the software entered a state given that name. The physical guarantee still depends on evidence: state estimation, actuator capability, timing, geometry, resources, and whatever model connects them. If any load-bearing premise becomes unsupported, the system should not continue displaying an undifferentiated green light.

The distinction can be tested in a deliberately simple spacecraft-approach model. The point is to make every assumption visible enough to challenge rather than to simulate orbital rendezvous faithfully. Consider a set of sampled approach cases run under several fault conditions. In a scenario where navigation develops an optimistic position bias and the fault is flagged perfectly, a nominal controller crosses the protected boundary every time. A policy that responds by inhibiting further commands crosses just as often, because zero command does nothing to remove the closing velocity already present. A bounded active fallback that applies braking does not cross.

That favorable result should not be allowed to stand alone. When the same navigation bias goes undetected, all three policies cross every time. When the actuator delivers far less braking than the fallback assumes, the fallback fails in a large share of cases. A response delay of tens of seconds produces failures of its own. And when the system was told to use a much wider navigation-error bound, the reserve check intervenes early enough to prevent crossings, but only by sacrificing the original close-approach objective. These are qualitative stress tests of a toy model, not flight statistics. Their value is that they expose the structure of the guarantee: it lasts only as long as the premises underneath it.

That suggests a simple architectural change. Spacecraft autonomy should carry two states in parallel. One is the control state: nominal, filtered, protective, halted, or whatever the mission architecture requires. The second is the assurance state: whether the evidence supporting the current safety claim is still valid. A spacecraft can therefore be in PROTECTIVE control while simultaneously declaring GUARANTEE LOST.

LOSS OF GUARANTEE is therefore not another control mode. It is a statement about whether the evidence supporting the current control mode still justifies its safety claim.

GUARANTEE LOST should not mean “stop computing” or “give up.” The best available action may still be to brake, hold attitude, retreat, or execute another preauthorized contingency. It means something narrower and more useful: the spacecraft is continuing a best-effort protective action outside the conditions under which its original guarantee was justified. That distinction should be visible to onboard decision logic, to operators, and to the post-event record.

In practice, entering LOSS OF GUARANTEE should do four things. It should contract mission authority rather than allowing the nominal planner to continue as if nothing happened. It should preserve only those protective actions that remain physically available and preauthorized. It should identify which premise failed, navigation validity, delivered thrust, timing, resource margin, or another condition, instead of reporting a generic fault. And it should block automatic return to the mission on the strength of an expired timer alone. Resumption should require new evidence that the relevant assumptions have been re-established.

This is also why independence has to mean more than separate software. DART’s collision-avoidance logic existed, but it shared the navigation evidence that had already gone wrong. NASA’s investigation recommended that future autonomous rendezvous and proximity-operations spacecraft have collision-avoidance sensing that is completely independent of the primary navigation sensors. That lesson generalizes. Two processors are not independent if they share the same bad sensor, clock, power rail, command bus, or actuator assumption. Independence is an evidentiary property, not a box-counting exercise.

NASA’s current direction already points toward richer onboard reasoning. The agency’s R2U2 runtime-verification work was designed to monitor sensors, software, and hardware in real time, while Gateway work uses runtime contracts whose verdicts are fed back into autonomous management. And NASA’s rendezvous, proximity-operations, and docking capability treats collision avoidance, separation maneuvers, guidance, navigation, control, and operations as an integrated engineering problem. The missing step is to make the validity of the safety argument itself something the autonomy stack can represent and act on.

That is a governance question as much as a control question. Autonomy is a delegation of authority under conditions. A spacecraft may be allowed to continue an approach because its estimate is current, its uncertainty is bounded, its braking capability is known, and its response latency remains inside a tested envelope. If those conditions disappear, the authority justified by them should contract. The machine should do more than change what it does; it should change what it claims to know about why that action is safe.

This becomes more important as spacecraft operate farther from immediate ground intervention, as servicing and logistics missions proliferate, and as autonomous rendezvous becomes routine rather than exceptional. Human supervisors cannot be expected to reconstruct, in seconds, whether a fallback action still satisfies every hidden assumption inside a safety case. The system should surface that information directly.

The most dangerous autonomy failure is not always a machine that refuses to enter safe mode. Sometimes it is a machine that enters safe mode exactly as designed while the evidence that made that mode safe has already expired.

Future spacecraft should be able to say more than “I am in protective mode.” They should also be able to say: “I am still acting, but the guarantee that justified calling this action safe no longer holds.” That sentence admits no failure. It is a more honest, and more useful, form of autonomy.