Why space missions need a trust boundary, not a smarter model

Read NASA's Space Technology Mission Directorate shortfalls in order and a pattern appears. The high-ranked entries are not requests for better models. They are requests for the missing pieces of a system: assurance for autonomy, verifiable trust across components, mission-level reasoning under uncertainty, coordination across heterogeneous vehicles, and a way to certify a plan an accident board can replay.

The shortfalls that survive review the longest are the ones that describe the layer above the model, not the model itself. That layer does not have a common name inside the agency. It does inside JPL, quietly, in the form of the systems people have been building around specific missions for thirty years. But there is no widely used term for it, no reference implementation to point to, and no ecosystem of components that share its semantics. Every mission rebuilds it from parts.

The industry response has been to point at machine learning. That would be right if the bottleneck were the quality of a single decision. It is not. The bottleneck is that many good decisions arrive from many components, each with its own uncertainty, its own operating domain, its own idea of what is safe, and no single mechanism decides which of them may execute at this moment.

The claim, precisely

A space mission is a system of autonomous components under human authority. When it works, it works because the humans set intent and constraints, the components propose actions inside their competence, and a small independent mechanism decides what runs. When it fails, it fails because that mechanism was implicit, hand-coded per mission, or absent.

The missing piece is a trust boundary. Not a smarter component; not a bigger model. A named, engineered mechanism that says: given the mission's current intent, its current belief about the world, and the constraints of the vehicle, this action is permitted; that action is not. If the mechanism is small enough to verify, and independent enough that a bug in a proposer cannot bypass it, the entire system inherits properties that no individual component can provide.

Why this is not a model problem

Consider a rover with an on-board science-targeting model that has become extremely good at finding interesting rocks. Better data, better training, more compute at the edge. The model is worth flying. It is also completely silent about power budgets, communication windows, thermal state, the safety of the traverse to the rock, whether the target lies inside a keep-out zone the operator declared last uplink, and whether the observation would consume the exposure that the primary science team needs for a different target this sol.

Improving the model does not help. Improving the model is not the axis of the problem. The axis of the problem is: which of the components' proposals may execute right now, given everything else? That is a systems question, and it is answered by a systems mechanism.

What "trust boundary" actually means

The term is borrowed deliberately from security engineering. In a secured system, a trust boundary is a line drawn in the architecture: on one side are inputs whose provenance is known and whose behavior is constrained; on the other side are components that may propose, compute, and learn. Nothing crosses the line without a check.

Translating that into mission autonomy: the components that observe, plan, learn, and adapt are on one side. The mechanism that grants execution permits is on the other. It is not a large model. It does not learn. It is a small piece of software that takes intent, belief, constraints, and a proposed action, and returns a permit or a refusal with a reason. Every mission we care about builds one implicitly. The argument of this essay is that it should be an explicit product, verified once, reused across missions.

Three implications the industry usually skips

First, the boundary is architectural, not statistical. You cannot get it from more training data. It is not a filter learned from examples of bad plans. It is a mechanism that verifies claims against a specification, and its correctness is a matter of proofs and reviews, not accuracy numbers.

Second, the boundary implies contracts for everything it touches. A learned perception model does not simply produce classifications; it produces classifications tagged with the operating domain it is qualified for. A planner does not simply produce plans; it produces plans tagged with the constraints it evaluated. A boundary can only make sense of these things if the components speak a common contract language.

Third, the boundary implies evidence. If a permit was granted, the exact state that justified it can be reconstructed later. If a permit was refused, the reason is captured. This is what an accident board, commercial or agency, actually needs, and it is what none of today's ad-hoc autonomy stacks provide by default.

Where this leaves ML

Machine learning has a real role in flight software, and it is going to get a bigger one. Perception, model-based prediction, anomaly detection, and adaptation are all improved by learned components. The right question is not whether they belong on the vehicle. They do. The question is where they sit relative to the trust boundary.

They sit inside it. They are bounded services: their inputs are contracted, their outputs are contracted, their operating domain is monitored, and their trust decays automatically when they drift outside it. They propose. They do not decide. The mechanism that decides is small, verified, and separate.

This is not a compromise. It is how every mature safety-critical system has worked, from commercial aviation to nuclear reactor control. The industry that put learned pilots inside flight envelopes did not do it by trusting the learned pilot's judgment; it did it by keeping the envelope separate.

What would falsify this

If a general-purpose model, at the scale we can host on a radiation-hardened processor, could take intent and belief and produce plans that meet mission constraints with the failure rate a flight review demands, and could produce, from the same weights, a reviewable proof that any given plan meets those constraints, the argument would weaken. That is not the direction the evidence points. It might one day. It is not the direction to build against now.

What we are building is the mechanism that inherits properties from being small, being separate, and being auditable. It is the runtime part of the sentence "an autonomous mission." It is what the agency shortfalls have been asking for, plainly, if you read them as a system engineer instead of a product manager.

Barycenter Systems is building a mission autonomy runtime. If this problem is yours too, write to us.