01 / What it is

The runtime is not a planner, not a fault-management system, and not a perception stack. It is the layer that sits above all of them and decides, mission by mission, moment by moment, what is allowed to execute. It compiles authorized intent into formal goals and prohibitions, maintains a mission belief state, reasons jointly over the physical constraints of the vehicle, and issues an execution permit for every action taken. If a permit cannot be issued, nothing runs.

02 / What it does not replace

The runtime does not replace the software your mission already depends on. It provides common semantics and control contracts across those components. Flight and mission teams keep the tools they trust.

  • Flight controllers and attitude control systems.
  • AutoNav, Terrain-Relative Navigation, and other domain-specific autonomy.
  • Instrument-side algorithms, including learned perception models.
  • Existing mission planning and command sequencing tools.
  • Ground software, deep-space link scheduling, and operations tooling.
03 / The parts

Each mechanism is small enough to explain in a paragraph.

3.1

Intent compiler

Authorized operator intent, expressed as mission objectives, priorities, and prohibitions, is compiled into a formal representation the runtime can reason over. Intent is a first-class artifact with a signature, a version, and a retraction path. It is never an English string parsed at runtime.

3.2

Mission belief state

A probabilistic representation of what the vehicle believes about itself and its environment. Every belief carries provenance: which instrument or algorithm produced it, when, and with what estimated error. Provenance is a safety property, not a debugging aid.

3.3

Joint reasoner

Plans are constructed against science value, safety envelopes, power and thermal budgets, communication windows, and time, as one problem rather than a cascade of independent optimizers. Coupling makes some things harder and other things possible.

3.4

Plan repair

When the world diverges from the plan, the runtime does not restart planning from scratch. It locates the minimum modification that restores feasibility given the current belief state and current intent. Repair beats replan on a radiation-hardened processor.

3.5

Coordination

When more than one vehicle is present, a rover with an aerial scout, a constellation of satellites, the runtime carries the coordination as contracts, not as a single planner running centrally. Contracts survive intermittent communications; centralized planners do not.

3.6

Operating-domain contracts

Learned components are wrapped in explicit contracts: the input domain they are qualified for, the output range they may produce, and the runtime monitors that detect drift outside those bounds. A learned classifier that leaves its qualified domain loses trust automatically.

3.7

Assurance kernel

An independent mechanism, deliberately small and separately verified, that issues execution permits. A permit is granted when goals, constraints, and safety envelopes are simultaneously satisfied. When they are not, nothing runs, and the reason is recorded. The kernel does not plan; it does not interpret. It grants or refuses.

3.8

Evidence & replay

Every decision, every input, and every state transition is recorded such that an accident board can replay the sequence exactly. Assurance is a property of the record, not a promise made in a datasheet.

04 / The doctrine

Learned components are bounded services, never the trust boundary.

Position

Machine learning has a role in flight software: perception, anomaly detection, model-based prediction, adaptation. It does not have a role in deciding what may execute. The mechanism that grants a permit is separate from the mechanism that proposes an action, and it is small enough to verify.

05 / Status

The runtime is in research and design. A reference implementation is in progress against a long-duration planetary surface campaign as the driving mission. We are working with a small number of design partners to shape the runtime against real requirements before general availability.

Status
Research phase · reference implementation in progress
Reference mission
Long-duration planetary surface campaign with rover, aerial scout, and distributed instruments
Design targets
DO-178C DAL A/B for the assurance kernel; NPR 7150.2 Class A software; ECSS-E-ST-40C for European partners
Naming
"The Barycenter runtime" pending trademark clearance of the product name