Building MissionOS: AI Mission Control, Tested from the Physics Up

The simulator that makes the mission continuous

At its core is a six-degree-of-freedom model that integrates translation and rotation together. It carries position, velocity, a quaternion describing body orientation, and angular velocity. Forces and moments determine how those states evolve through a fourth-order Runge–Kutta integrator.

A gimballed engine changes both the thrust direction and the moment about the center of mass. Burning propellant changes the vehicle's mass, center of mass, and inertia. The attitude controller requests an orientation; the dynamics determine how closely the vehicle can follow it. This coupling gives a control decision consequences throughout the trajectory.

Individual engines have configured thrust, specific impulse, mounting positions, and gimbal limits. Throttle, gimbal, and flap commands pass through actuator lag and rate limits before producing forces. RCS consists of finite thrusters at declared positions and directions, consuming propellant. Requested and achieved actuation are recorded separately.

The environment includes a WGS84 Earth, Earth rotation, gravity with J2, and a standard-atmosphere model. Local airflow produces forces on generic hull panels, flaps, and grid fins. Aerodynamics use a plate approximation; the atmosphere above 86 km uses an exponential surrogate. Thermal protection, structural flexibility, and propellant slosh remain outside this model's coverage.

A continuous mission proceeds from launch through stage separation, Ship insertion, payload release, deorbit, entry, flip, and hull contact. Booster return inherits the actual separation state and engine failures. Released payloads have finite mass and inertia: separation applies a reaction to the parent, then each body propagates its own motion. A deployment choice therefore changes the mass that comes home.

The physics runs in a separate process. MissionOS receives observations and candidate assessments; a checked AI proposal becomes an objective for the Executor. Later observations establish what changed. Model API credentials stay with the host, outside the physics worker.

Figure · Select to enlarge

↗

The CG replay reads saved states. Recorded quaternions determine the vehicle's orientation, while actuator states, mission time, and the model's external decision summary provide context. Ocean, clouds, lighting, and camera movement make that record easier to follow. The physical calculation and the presentation remain separate artifacts.

Numerical checks include analytic solutions, conservation properties, and timestep comparisons. The project also provides validation paths against declared NASA check cases and an independent dynamics implementation, Basilisk. Each comparison records the equations and conditions it covers.

First, give the controller something meaningful to compare

The first milestone, M1, centered on a recovery area becoming unavailable.

MissionOS had to notice the update, assess return opportunities, choose a plan, and confirm the eventual contact. An event-driven monitor detected one advisory update within 0.2 simulated seconds and started a new assessment.

We then made candidate preparation a responsibility of the tool layer. MissionOS reuses an applicable forecast and calculates the missing alternative. Each candidate includes waiting time, fuel loss allowance, battery energy, temperature, recovery timing, and uncertainty. Preparation has a budget calculated backward from the existing return deadline.

That gives the model a concrete comparison. In one recorded decision, DeepSeek weighed overlapping recovery-time estimates against the additional resource cost of waiting for another orbit, then retained the original plan.

We also gave numerical evidence stable IDs. A model can point to the candidate fields supporting its decision, and a checker can resolve those IDs against the snapshot supplied at judgment time. This makes the cited numerical basis traceable. The model's prose remains a separately recorded explanation.

Carry the consequences into the next stage

M2 joined deployment supervision to return planning. The returning vehicle inherits its actual retained payload inventory and corresponding mass.

M3 added inflight scope amendment. A proposed return can be physically feasible while requiring a broader approval grant. MissionOS binds approval to the particular candidate, its digest, and its expiry, then records one-time consumption and checks the resulting reservation in a later observation.

An authenticated test-operator script supplied the approval in these experiments. The exchange crossed the real HTTP boundary, connecting the approval request, candidate identity, authorized update, and subsequent observation.

Figure · Select to enlarge

↗

YouTube video · 1:52

The division of work stays consistent:

AI judges. A human approves the scope. Rules constrain. Executor acts. Verifier checks.

Jev handles monitoring and bounded choices. DeepSeek handles selected deeper assessments. Numerical tools estimate and predict. Fast flight-control loops execute the permitted objective.

Build fault diagnosis on measured sensitivity

The trouble engine brought reproducible disturbances into the physical simulation. A source-linked incident catalog informed six test families: Booster ascent engine loss, Ship engine loss, Booster restart failure, directional RCS loss, a deployment-mechanism fault, and tower unavailability. Their seeded probabilities are engineering test settings.

For symptom-based recovery, we concentrated on Ship propulsion capability. Before introducing AI, we separated the capability assumed by the controller from the capability used by the physical plant.

A 3×3 matrix crossed assumed and actual thrust at 100%, 80%, and 60%. The three matched cells satisfied the contact gates. All six mismatched cells exceeded the contact-speed limit, exposing the return procedure's sensitivity to the capability estimate. Every outer control/physics step carried an audit of which vehicle model supplied each value.

Figure · Select to enlarge

↗

Next came the estimator. With synthetic sensor noise, bias, and latency fixed in advance, it detected the 80% and 60% capability conditions in 20 of 20 seeds each. The healthy condition produced zero alarms in 20 seeds. The true factor lay inside the reported band in every case.

We then tested post-burn adoption at five assumed values—76%, 78%, 80%, 82%, and 84%—against actual 80% thrust. All five met the registered gates at that saved starting state. The 76% point contacted at about 4.96 m/s, close to the 5 m/s limit. These discrete measurements gave the later AI requests a physically grounded treatment of uncertainty.

Finally, we introduced an alternative explanation for the same symptom: an accelerometer gain error. Independent tracking supplied another view of the vehicle's motion. The AI could request that observation, use the evidence to choose a response, and send its proposal through the independent check.

The work of diagnosis now had a complete sequence: symptom, information request, numerical estimate, choice, check, execution, and observed result.

Check a successful flight against the world outside the model

Alongside the mission architecture, we audited the simulator against public Flight 14 material.

The reference work separated official schedules, values read from the broadcast display, and quantities inferred from those readings. We compared altitude and speed as time series, checked selected frames by eye, and corrected several transcription errors while retaining the original data.

This changed the questions we asked of the physics. Ascent, stage separation, Booster apogee, return timing, entry attitude, and terminal descent all became measurable parts of the comparison. Calibration targets and held-out checks were registered separately, with a limited set of adjustable parameters.

The most consequential analysis concerned Ship's entry attitude.

A static trim study examined the old panel-aerodynamics model with roughly 103 tonnes of propellant. In the intended belly-oriented condition, the remaining pitch moment at 5 kPa dynamic pressure was about 1.0 MN·m. The modeled RCS pitch authority was about 0.08 MN·m. Center of mass, aerodynamic center, and flap geometry therefore became concrete design constraints.

Saved successful flights supplied another clue: their body-frame airflow had substantial components on two axes, corresponding to an approximately 45-degree oblique flow orientation. The panel model could obtain a balancing solution in that orientation. The analysis showed that those earlier successful flights relied on a balancing solution produced by oblique airflow in that particular model. Its attitude and flap behavior differed from the intended belly-oriented entry. We made checking trim in the intended belly orientation an explicit task in redesigning the return.

The static result became a diagnosis to investigate through subsequent design and flight checks. We examined mass distribution and flap trim, revised attitude and terminal guidance, and carried the states produced by the revised ascent into both vehicles' return calculations. The research profile also incorporated the declared Flight-14-style engine shutdowns.

The result was a broader recovery effort: ascent, entry preparation, Booster return, landing-burn timing, numerical integration, and the interfaces between them were reviewed together. Each new controller had to work with the state produced by the preceding phase.

Agreement with public flight data remains limited after this reconstruction; these tests do not validate a real SpaceX vehicle. Booster recovery is assessed within a broad 10 km development acceptance envelope.

That process gave the project a stronger foundation: successful trajectories came with an account of the assumptions and physical balances that supported them.

Turn recovery research into decision material

Booster recovery developed along its own path. We built models for the tower, support pins, moving arms, contact loads, and support settling, alongside return-guidance experiments.

A tower capture requires position, velocity, attitude, angular rate, fuel, and arm timing to align at the same encounter. Keeping those stages explicit helped turn a visually attractive objective into a set of engineering questions. A launch-derived return ending in supported tower capture has yet to succeed in these experiments. The integrated demonstrations use ocean recovery as their executed objective.

The research history itself became an input to mission judgment. In the recorded October 14 recovery experiment, DeepSeek received the current Booster observation and a reviewed report of catch-development evidence. It selected splashdown; an independent execution check accepted the choice, and a later observation confirmed the selected objective.

The 120-second replay shows that earlier decision alongside telemetry, ocean scenery, and an illustrative tower cutaway.

Figure · Select to enlarge

↗

YouTube video · 2:00

Make the experiment as traceable as the mission

We registered each bounded experiment before execution: source, starting state, assumptions, allowed changes, contact gates, time and storage budgets, and the interpretation of possible outcomes.

Each attempt kept its own record and verdict. A later repair received a new identity. Saved-record verification let us investigate discrepancies while preserving the original numerical trajectory. Control-side assumptions and physical capability remained distinguishable throughout the audit.

Credential-free checker processes examined the permitted action separately from the model. Earlier nominal return qualification covered 39 finite cases. Later exact-point work bound the current state, vehicle, inventory, plan, environment, and complete actuator history, with bounded chunks allowing every history row to be checked.

Those identities also define where a result applies. Each qualification belongs to its stated source and environment; each changed implementation has its own verification work.

Figure · Select to enlarge

↗

Operating the models added another layer of engineering. We recorded variation in Jev's choices for an identical input, model-name and response-format compatibility, and long periods before a usable DeepSeek answer. Timing diagnostics separated HTTP arrival, stream activity, and answer events. These observations informed the Jev-first structure, explicit deeper review, deadlines, and preapproved fallback behavior.

Bring the layers together in one mission

On October 23, a registered integrated experiment connected launch monitoring, Booster recovery review, image-assisted deployment control, return replanning, scripted HTTP approval, injected propulsion reduction, independent tracking, and checked capability adoption.

The mission released thirteen payloads and retained thirteen under Jev’s checked decisions; that mass continued into return planning. It requested tracking after the propulsion symptoms and selected the numerical estimate. The independent guard preceded one-time application, and the verifier followed the return to contact.

The flight recorded 10 valid Jev responses in 10 calls, one valid DeepSeek response in one call, Ship model contact at 3.459 m/s, and 51.209 tonnes of remaining propellant.

The October 22 attempt remains recorded as exceeding its registered time budget, with host sleep included in that interval. We then made a fresh registration with explicit timing boundaries and clock evidence, prevented host sleep, and executed a separate flight on October 23.

Before that flight, the registration defined the mission-supervisor interval for the 1,800-second runtime gate. That interval measured 1,304.871 seconds. The complete CLI, including separate pre-mission and post-mission checks, measured 2,140.761 seconds. Both measurements stay attached to their original boundaries.

These figures describe one registered flight in a research simulator, together with its declared physical assumptions and test-operator approval. They sit alongside the earlier candidate comparisons, fault studies, static analyses, and recovery experiments.

The maintained integration is now public in MissionOS PR #133, merged as 56013c8b, with successful Python 3.11 and 3.13 CI. The integrated report keeps execution, qualification, and public-release versions visible.

What I value most is the connection between judgment and investigation. The AI asks for evidence during a mission. As developers, we ask what supports a successful simulation, inspect the physical assumptions, and rebuild the pieces that need a stronger basis.

MissionOS is growing through that same cycle at both levels: observe, investigate, decide, check, execute, and carry the evidence forward.

Explore the project

• Event-driven monitoring and automatic candidate preparation.
• Trouble-engine families and incident sources.
• Capability-matrix protocol and estimator/tolerance protocol.
• Public-data observation ledger and entry attitude and trim preparation implementation.

• Six-degree-of-freedom model overview and state, force, and verification contract