A runtime constitution for orbital AI power decisions

What the work claims

The authors argue that autonomous AI in orbit - from individual CubeSats to future orbital data centers - needs a runtime constitutional layer between the AI policy and the spacecraft actuators. They propose Glass Box, a verifier that evaluates every candidate action against six closed-form constraints and seven Linear Temporal Logic (LTL) safety invariants before any command is executed. They claim the verification overhead is linear in the number of constraints, independent of model size or spacecraft state dimension, and that their worked example shows the framework correctly deferring an unsafe inference request at eclipse entry while preserving mission utility.¹

How it works

Glass Box sits inside a five-layer simulated architecture called Project October. The bottom layer is an orbital digital twin that feeds real-time physics state into a shared dictionary. The twin includes an orbit propagator, a solar-array and battery power model, a thermal model, and a radiation model derived from CREME96. The second layer is a TinyML inference engine that produces candidate actions. Glass Box is the third layer; the fourth and fifth layers handle fault tolerance and constellation coordination.¹

The verifier has three outcomes. APPROVE logs the decision with a weighted explainability score and issues the command. FLAG logs a violation, queues a priority downlink, and substitutes a safe default action. BLOCK cancels the command and triggers safe mode if warranted. The decision is based on a battery of six constraints, each evaluated in constant time:¹

• Power Safety Margin (C1): the action is feasible only if generated power minus the action's load stays at least 0.5 W above housekeeping loads.
• Thermal Operating Envelope (C2): inference is permitted only while spacecraft temperature is inside -20 to +70 degrees Celsius.
• Collision Avoidance (C3): no maneuver is approved if it raises conjunction probability above 1e-4.
• Battery State Floor (C4): all non-essential operations are suspended when battery state of charge falls below 20 percent.
• Radiation Fault Gate (C5): when the modeled single-event-upset rate exceeds a threshold, triple modular redundancy is mandated and unprotected inference is blocked.
• Bayesian Confidence Gate (C6): high-entropy predictions are blocked; entropy is estimated with 20 Monte Carlo dropout passes.

The seven LTL invariants extend these instantaneous checks to behavioral sequences. They require, for example, that any flagged anomaly be downlinked within two orbital periods, that safe mode persist until recovery is explicitly confirmed, and that a watchdog heartbeat occur within every watchdog period. The authors report that Z3 and NuSMV verify the invariants against the constraint grammar in simulation.¹

The worked example places a CubeSat at 47 minutes into a 96-minute orbit, three minutes before eclipse entry. Solar generation is 4.20 W, base load is 3.70 W, battery state of charge is 0.31, temperature is 42.1 degrees Celsius, modeled SEU rate is 8.3e-6 upsets per bit per day, and conjunction risk is 2.1e-6. The AI policy proposes running wildfire inference, which would add 0.52 W. C1 evaluates to false because 4.20 - (3.70 + 0.52) = -0.02 W, below the 0.5 W safety margin. The verifier flags the action and defers it six minutes to the post-eclipse solar window. The explainability score for the decision is 0.70.¹

The strongest case for it

The paper identifies a real gap. Existing spacecraft fault detection, isolation, and recovery is reactive: it responds after a fault has occurred. Pre-deployment formal verification cannot cover learned AI behavior under operational conditions it never saw during training. Glass Box proposes a middle layer that intercepts AI-generated actions before they reach actuators, using constraints derived from live physics rather than static rules. For power systems, the most important idea is that the battery floor, the thermal envelope, and the solar generation forecast become hard guards on what the AI is allowed to do.

The framework is also designed to fit resource-constrained platforms. The authors prove that verification complexity is O(N_c), linear in the number of constraints, and they target sub-10-millisecond latency on ARM Cortex-M4-class processors. The audit log gives ground operators an explainable record of every autonomous decision, which is critical when contact windows are short.

Where a skeptic should push

The biggest limitation is that every result is from simulation. The authors state this explicitly: "Every result in this paper is architecture and analysis. Measured hardware results on Coral TPU silicon and ARM Cortex-M4 are the subject of subsequent papers." No constraint has been exercised against real flight software, a real battery, or a real radiator.

The constraint values, while plausible, are chosen rather than derived from a specific mission requirements document. The 0.5 W power margin, the 20 percent battery floor, the 1e-4 collision threshold, and the 0.55 entropy gate are engineering judgments. They may be right for the CubeSat example, but they are not universal. The 10-minute ground-contact window and 86 autonomous minutes per 96-minute orbit are also scenario-specific; a different orbit or communications architecture changes the contact-free time.

The LTL proofs apply to the formal specification, not to the actual neural network. An AI policy can pass Glass Box and still be wrong in ways the six constraints do not capture. The constraints also assume the digital twin is accurate; if the power model, thermal model, or radiation model drifts, the verifier becomes a false assurance.

Finally, several claims about the orbital-computing market are the authors' own assertions. The paper lists Microsoft, AWS, D-Orbit, Starcloud, and Lumen Space as actors moving cloud processing into orbit, and it states that none currently ship a runtime constitutional verification layer. Those are industry observations made by the authors, not independently verified facts.

The bottom line

Glass Box is a well-specified concept for runtime AI governance, not a flight system. Its value for power in space is the framing: power, thermal, and battery constraints should be enforced at the decision layer, not only by traditional power-management electronics or after-the-fact fault recovery. The simulation results support feasibility, but the framework needs hardware-in-the-loop testing, orbit-specific calibration of the constraint thresholds, and a demonstration that it can keep up with real inference workloads. If those tests hold, it could become a standard component of autonomous spacecraft power management. If the digital twin is wrong or the constraints are mis-calibrated, it could create a dangerous sense of safety.

What it means for autonomous spacecraft power governance

The non-obvious implication is that the spacecraft power system may need to expose a real-time API to the AI. Battery state of charge, solar generation forecast, thermal headroom, and predicted eclipse state become inputs to a command gate, not just telemetry for ground review. This shifts power management from a subsystem discipline to a cross-cutting safety layer that every autonomous workload must call.

The genuine threat is complacency. If mission designers install Glass Box and treat it as a substitute for conservative power margins, hardware protection circuits, and ground oversight, a bad digital-twin model or an overconfident entropy threshold could allow an unsafe action. The verifier is only as good as the physics models and thresholds it evaluates.

The opportunity is a new interface between power engineering and autonomy. A power-system engineer could encode the spacecraft's actual power and thermal budgets as constitutional constraints, then let the AI scheduler optimize within those bounds. Instead of manually preventing every eclipse-entry overload, the team defines the envelope and the AI operates inside it. That could make future orbital data centers both more autonomous and more power-safe.