Flight-Ready Mission Autonomy

A Physics-Informed Architecture for Spacecraft Health Monitoring and Evidence-Based Anomaly Response

Orbelis PBC — White Paper, Volume I
Brandon M. Lopez, Founder & CEO
August 2026 · orbelis.ai

Abstract

Spacecraft operations are approaching a capacity limit that hardware cannot relieve. The number of objects in low Earth orbit, the rate of launch, and the frequency of collision-avoidance maneuvers are all rising faster than the number of trained operators. The binding constraint is no longer observation — the orbital environment is better characterized than at any point in the space age — but decision throughput: the interval between a signal arriving and a defensible action being approved.

This paper describes an architecture that addresses decision throughput without asking an operator to trust an opaque model. Four commitments define it. The system is read-only by architecture, not by policy: it has no command path to the spacecraft. Its inference is physics-informed, constrained by a declared engineering envelope that no recommendation may cross. Its reasoning is reconstructible, so that every recommendation carries the telemetry, limit, and dependency that produced it. And its claims are validated by historical replay against ground truth the system was never given.

We describe the Mission Graph, the structure that carries engineering context into inference; a detection method combining orbital-phase conditioning with secular detrending; a decision layer that filters approved actions against current spacecraft state; and a validation protocol that scores the system honestly, including its failures. We report results from a reference implementation and state its limitations plainly.

We also present two defects found in that implementation by the validation protocol itself, because they illustrate the paper's central argument: a detector that cannot be scored against ground truth cannot be trusted, and the failures such scoring exposes are the ones that matter operationally.

1. The operational gap

1.1 Congestion is outpacing operator capacity

The European Space Agency tracks 46,180 objects in orbit, of which roughly 16,000 are functioning satellites. Its statistical models estimate 54,000 objects larger than 10 cm, approximately 1.2 million between 1 and 10 cm, and around 140 million between 1 mm and 1 cm. More than 660 fragmentation events have occurred since the beginning of the space age.^[esa]

The distribution matters more than the totals. The objects most likely to end a mission sit in the 1–10 cm band: individually catastrophic at orbital velocity, too numerous and too small to track individually. An operator cannot maneuver around what cannot be catalogued. What an operator can do is understand their own spacecraft well enough to distinguish a survivable anomaly from a mission-ending one, and to act while options remain open.

Launch cadence compounds this. The U.S. Federal Aviation Administration licensed 148 commercial launch and reentry operations in FY2024 and projects between 259 and 566 annual operations by FY2034.^[faa] A single large constellation operator reported 144,404 collision-avoidance maneuvers in a six-month period.^[starlink] Maneuver volume at that scale is already beyond per-event human deliberation.

1.2 The constraint is decision throughput

Three capabilities are well served by the existing market. Conjunction screening and space-domain awareness providers determine where objects are and what they may strike. Mission-operations infrastructure vendors supply the rails on which a control center runs. Ground-segment and telemetry systems deliver data reliably.

What remains manual is the step between them: taking an external orbital threat, combining it with the internal state of a specific spacecraft — its subsystem health, command history, engineering limits, and approved procedures — and producing an action an operator can defend in a review board.

That step is performed today by experienced engineers reading plots. It produces good decisions, and it does not scale. It is bounded by the number of people who hold a given spacecraft's behavior in their heads, and it degrades under exactly the conditions where it matters most: many spacecraft, many concurrent alerts, and a short time to closest approach.

1.3 Why more automation is not automatically the answer

The obvious response — automate the decision — fails on trust rather than on technology. Spacecraft operations are a domain where an incorrect action can be unrecoverable. A latch valve closed cannot be reopened. Propellant spent cannot be recovered. An operator who cannot reconstruct why a system recommended an action will not approve it, and should not.

This produces a requirement that shapes the entire architecture: the system must be more auditable than it is autonomous. Capability that cannot be inspected will not be used, regardless of its accuracy. The design below therefore treats explanation not as a reporting feature layered on top of inference, but as a constraint on which inference methods are admissible at all.

2. Architecture

2.1 The OODA decomposition

Orbelis structures spacecraft operations as an observe–orient–decide–act loop, a decomposition originating in military decision theory and well suited to domains where the cost of a slow decision is comparable to the cost of a wrong one.^[ooda]

Observe. Ingest telemetry, command history, trajectory and ephemeris data, conjunction screening messages, space-weather indices, and written operational procedures. All ingestion is read-only.

Orient. Place observations in the Mission Graph, which links spacecraft health to orbital context, subsystem dependencies, and declared engineering limits. Orientation is where a number becomes a fact about a mission.

Decide. Apply deterministic rules, anomaly models, and physics constraints to rank probable cause, assess urgency, and enumerate the actions that remain safe given current state.

Act. Present ranked recommendations, each with its evidence, for operator approval. Approved actions are executed by the operator through their existing mission operations center. Orbelis does not execute.

Learn. Approved outcomes and their consequences are recorded, improving the customer-specific mission model over time.

2.2 Read-only by architecture

The system has no command path. This is a structural property, not a configuration setting, and it is the precondition for everything else.

The distinction matters because the two are often conflated. A system that can command but is configured not to has a failure mode in which misconfiguration, compromise, or a software defect produces an unintended command. A system with no command interface does not have that failure mode. It can be wrong — it can rank the wrong cause, or miss an anomaly entirely — but the blast radius of being wrong is bounded at "an operator was shown a bad recommendation," which is a category of failure that mission operations already knows how to absorb.

This has a commercial consequence worth stating directly. Read-only deployment substantially shortens the security review that gates a first customer, because the question "what happens if this system is compromised" has a short answer.

2.3 Deployment posture

The architecture assumes sovereign deployment as the default rather than the exception. Telemetry is among the most sensitive data an operator holds: it reveals capability, tasking, and vulnerability. Orbelis is designed to run inside the customer's environment, including air-gapped configurations, with no requirement that telemetry leave the operator's control.

The reference implementation is written against the Python standard library with no third-party dependencies and no network calls, which makes review of the deployed artifact tractable for a customer's security team and eliminates supply-chain surface as a review topic.

3. The Mission Graph

3.1 Why context is the product

Consider a conjunction screening message reporting a 400 m miss distance. On its own it is a number requiring triage. Now consider the same message against a spacecraft whose reaction wheel current has risen 40% over nine days, whose thruster duty-cycle limit constrains burn magnitude, and whose next ground contact is 40 minutes away. That is no longer a triage item. It is a decision with a deadline, a constrained option set, and a clear cost of delay.

The difference between the two is not more data. It is structure. The Mission Graph is that structure.

3.2 Contents

The graph holds four classes of knowledge.

Channels. Each telemetry stream, what it physically measures, and the subsystem it belongs to. This is the mapping from raw stream to engineering meaning.

Limits. The declared engineering envelope. Each limit carries a caution threshold, a redline, a direction (whether high or low values are threatening), and — critically — a written rationale. A limit without a rationale is a number an operator cannot evaluate. A limit with one is an engineering judgment they can accept or dispute. For example:

prop_tank_pressure — caution 20.4 bar, redline 19.0 bar, direction low. Below 19.0 bar the thruster cannot guarantee a full collision-avoidance burn.

Dependencies. What degrades downstream when a subsystem is impaired. Attitude control degradation does not merely affect attitude control; it affects payload pointing, solar array sun tracking, and the ability to perform a collision-avoidance slew. The third of these converts an ADCS problem into a collision-response problem, which is a different conversation with a different urgency.

Actions. The approved response procedures available for each subsystem, each annotated with reversibility, resource consumption, operational cost, and the preconditions under which it is safe.

3.3 Reversibility as a first-class property

Every action in the graph declares whether it can be undone on orbit. This single annotation carries more operational weight than any other field.

Closing a latch valve to isolate a leaking thruster branch is irreversible and halves thruster authority. Reducing a wheel's duty cycle is reversible and costs two imaging passes per day. When both are viable responses, the ordering is not a matter of taste — a system that presents them as equivalent options has failed to encode the thing an operator cares about most.

Orbelis therefore orders reversible actions above irreversible ones in every presentation, and marks irreversibility explicitly. Where an action consumes an unrecoverable resource, that is stated in the option itself rather than left for the operator to recall.

4. Physics-informed detection

4.1 The requirement

An anomaly detector for spacecraft telemetry must satisfy three conditions simultaneously. It must be sensitive enough to catch degradation while options remain open. It must be specific enough that operators do not learn to ignore it. And its output must be reconstructible from inspectable quantities.

The third condition is the binding one, and it rules out a large class of otherwise capable methods. A detector whose alert cannot be traced to specific samples, a specific expectation, and a specific limit cannot be signed off on by an operator, and will therefore not be used when it matters.

4.2 What "anomalous" must mean

Naive formulations fail on spacecraft data for a specific reason: much of what a spacecraft does is supposed to vary, and vary a great deal.

Battery state of charge on a low Earth orbit spacecraft swings by twenty percentage points or more every orbit, charging in sunlight and discharging in eclipse. Wheel temperature rises and falls with thermal input. Array current drops to zero in eclipse by design. Against a pooled global average, these channels have enormous variance — and real degradation hides comfortably inside it.

Some channels also drift legitimately over long horizons. Propellant tank pressure declines through normal blowdown across a mission. A detector that flags this expected decline generates alerts on healthy behavior.

The operative definition is therefore narrower:

An observation is anomalous when it departs from what this spacecraft normally does at this point in its orbit, at this point in its life.

Two mechanisms implement that definition.

4.3 Orbital-phase conditioning

Each channel's orbit is divided into phase bins. For sample index i with sampling interval Δ t and orbital period T:

with B bins. Each bin maintains its own baseline, so eclipse is compared to eclipse and the discharge trough is compared to the discharge trough. The orbital cycle — the dominant source of variance — is removed by construction rather than by filtering.

4.4 Secular detrending

Within each bin, healthy behavior is modelled as a line fitted over a learning window assumed nominal:

where β_b is the expected secular drift. Residuals are taken against this extrapolated expectation rather than a static mean:

A channel declining exactly as fast as it should produces residuals near zero and no alert. A channel declining faster than it should produces a growing residual, which is the signal of interest.

4.5 Robust scale and the firing rule

Scale is estimated per bin using the median absolute deviation, scaled for comparability with a standard deviation:

MAD is used rather than sample standard deviation because telemetry archives contain transients, dropouts, and recovery artifacts. A few extreme samples must not inflate the scale to the point where genuine degradation falls inside the noise band.

Over an evaluation window W, each bin is scored independently and the largest excursion is retained:

A finding is raised when |z| ≥ z_crit or when the current sample breaches a declared limit. Direction is enforced against the limit: a battery reading above expectation is not a fault, and is suppressed.

Per-bin scoring, rather than averaging residuals across the orbit, is load-bearing. Section 7.2 documents what happens without it.

4.6 Projection to limit

Where a limit exists, the current trend is projected to estimate time to threshold:

for limit L and current slope ẋ estimated over a longer window. This converts a statistical excursion into an operational quantity — days until this matters — which is what urgency ranking requires and what an operator actually asks.

5. The decision layer

5.1 From findings to problems

Detection produces per-channel findings. Operators do not act on channels; they act on a problem with a subsystem. Findings are therefore correlated into a single assessment per subsystem.

Correlation across independent channels is also the primary confidence signal. A rising wheel current alone is a finding. A rising wheel current, a correlated temperature rise, and a growing pointing error together are a bearing degradation — the classical signature, corroborated by three physically distinct measurements. Confidence is scored on how completely the observed channel set matches the expected signature, combined with the strength of the strongest excursion.

5.2 Urgency

Urgency is derived, in order of precedence, from: current limit breach; projected time to redline; and operational context, principally whether a conjunction is concurrently active.

The contextual term is what distinguishes this from threshold monitoring. A propulsion anomaly with a 20-day projection is a maintenance item. The same anomaly with a conjunction inside the response window is urgent, because the degrading subsystem is the one required to respond. The Mission Graph makes this inference available: propulsion degradation impairs collision_avoidance_burn, which is on the critical path for the active conjunction.

5.3 Constraint filtering — the safety-critical step

Enumerating actions is straightforward. Withholding them is the part that determines whether the system is safe.

Each approved action declares preconditions evaluated against current spacecraft state. When a precondition fails, the action is removed from the recommended set and shown separately, with the constraint that blocked it stated explicitly.

The load-bearing case in the reference implementation:

Withheld by safety constraint
  ✕ A-PROP-03  Execute collision-avoidance burn early while margin remains
      Tank pressure 18.80 bar is at or below the 19 bar redline —
      a full collision-avoidance burn cannot be guaranteed.

Two properties of this output are deliberate. First, the option is withheld, not merely deprioritized — an operator under time pressure must not be able to select it by reflex. Second, it remains visible, with its reason. A silently filtered option is indistinguishable from an option the system failed to consider, and an operator who suspects the latter will stop trusting the former.

5.4 Evidence trails

Every recommendation carries the complete chain that produced it: the observed value and the phase-matched expectation it departed from; the excursion in robust standard deviations; the current trend against the expected healthy trend; the applicable limit with its written rationale; the projected time to that limit; the mission-graph dependencies affected; and any concurrent orbital context.

The design intent is that an operator can reconstruct the inference without consulting the system that produced it, and disagree with it on specific grounds. A recommendation that can only be accepted or rejected wholesale is not evidence; it is an assertion.

This is also the record that matters after an incident. Reviews ask what was known, when, and on what basis. A system that produces that record as a byproduct of normal operation is materially more valuable than one that requires reconstruction after the fact.

6. The historical-replay validation protocol

6.1 Principle

The claim "our system would have caught this" is unfalsifiable when made after the fact. Replay makes it falsifiable.

The protocol walks a customer's archive forward in time, exposing the engine at each step only to data available at that moment, and records the first time each problem is raised. Alerts are then scored against the archive's known anomaly record — ground truth the engine was never given.

6.2 Rules

Four constraints keep the result honest.

Strict causality. At evaluation index i, only samples \leq i are visible. No detector may consult future data, including for normalization.

Baseline isolation. The learning window is disjoint from every labelled fault, and this is asserted programmatically rather than assumed. A baseline learned over a window containing the fault would be trained to consider the fault normal.

No partial credit. An alert that does not correspond to a known fault is a false positive. Detection before onset is not counted as early detection; it is counted as a false positive, since the system cannot have detected something that had not yet begun.

Deadline scoring. Each fault carries a detect-by deadline — the point at which a competent operations team would reasonably have caught it. Lead time is measured against that deadline, not against the moment of onset. Detection after onset but before the deadline is the target; the metric rewards being useful, not merely being first.

6.3 Reported metrics

• Recall — fraction of injected faults detected after onset.
• Precision — true positives over all alerts raised.
• Mean lead — average days between detection and the detect-by deadline.

Negative values indicate late detection and are reported as such.

• False positive count — reported absolutely, not as a rate, because rates

conceal small absolute numbers that matter operationally.

• Escalation interval — days between first alert and the point at which the

condition reached its peak urgency. This is the operational value of early detection: the warning an operator would have had.

6.4 Why this is the right first commercial engagement

Replay is deliberately the shape of the paid pilot. It requires no integration with live systems, touches no flight hardware, uses data the customer already possesses, and produces a falsifiable result. If the system does not surface what the operator's own engineers found — earlier, with better reasoning — there is nothing to buy, and both parties learn this in weeks rather than quarters.

7. Reference implementation and results

7.1 Configuration

A reference implementation exercises the full architecture against a 90-day synthetic archive: 25,920 samples across 10 channels at 5-minute cadence, modelling a low Earth orbit smallsat with a 94.6-minute period and 36% eclipse fraction. Three faults are injected with known onsets and deadlines, and two conjunction events are scheduled.

The injected faults are a reaction wheel bearing degradation (rising motor current at constant commanded speed with correlated thermal rise), a battery capacity fade (deepening eclipse discharge with correlated bus voltage sag), and a propellant tank leak (pressure decline exceeding nominal blowdown).

7.2 Two defects the protocol exposed

The following are reported because they are the paper's argument in miniature: both are failures the validation protocol surfaced, and neither would have been visible from inspecting detector output alone.

Detecting expected behavior. The initial implementation raised a propulsion alert at day 31.5 for a leak beginning at day 63.0 — a false positive 31.5 days ahead of any fault. The detector was correctly identifying a pressure decline; the decline was normal blowdown. Because the channel is otherwise quiet, its robust scale is small, and an entirely expected drift exceeded the firing threshold.

The fix was not a higher threshold, which would have suppressed the real leak too. It was to learn the expected secular slope per phase bin and score residuals against the extrapolated expectation (Section 4.4). The false positive disappeared and the real leak was detected 1.3 days after onset.

Diluting a real signal. Battery capacity fade was initially detected on day 51.2, against a deadline of day 50.4 — 0.8 days late. The cause was averaging residuals across the full orbit. Capacity fade manifests almost entirely in the eclipse discharge trough and barely moves the sunlit peak, so a whole-orbit mean roughly halved the signal.

The fix was to score each phase bin independently and retain the strongest excursion (Section 4.5). Detection moved to day 47.8 — 4.6 days after onset and 2.6 days ahead of the deadline. That is 3.4 days earlier on identical data, with no change to sensitivity thresholds.

Both defects share a structure worth naming: each produced plausible-looking output. A demonstration would have shown a system finding anomalies and recommending sensible actions. Only scoring against ground truth, with no partial credit, revealed that one alert was 32 days early on a fault that had not started and another was days late on a fault already underway.

7.3 Verification

The implementation carries a test suite asserting the properties a customer would check: that faults begin outside the learning window; that no channel fires before its fault begins; that every fault fires by its deadline; that a collision-avoidance burn is withheld below redline and offered above it; that reversible actions are never ordered below irreversible ones; that every action declares a cost; and that replay is deterministic under a fixed seed, so a result can be reproduced and audited.

Replay returns a non-zero exit status when any fault is missed, allowing it to act as a continuous-integration gate: a change that degrades detection fails the build.

7.4 Limitations

Stated plainly, because a customer will identify them immediately.

The archive is synthetic. Fault signatures are physically motivated but generated. These results establish that the engine finds faults it was not told about in data it had not seen. They do not establish performance on a real fleet, and should not be presented as doing so. Ground truth on customer data is the purpose of the paid pilot.

Coverage is narrow. Three fault modes on a single spacecraft. No cross-fleet correlation, no multi-spacecraft conjunction screening, no constellation-level effects.

Conjunctions are treated as context, not physics. They escalate urgency and gate actions. The implementation contains no orbit propagator and computes no probability of collision; it consumes screening products rather than producing them.

Cause attribution is a deterministic rule table. The customer-specific small language model described in the product roadmap is not present in this build. This ordering is deliberate: the rule table is fully auditable and establishes the baseline any learned component must beat. A learned model introduced before that baseline exists cannot be shown to have improved anything.

8. Path to bounded edge autonomy

Ground-based decision support is the first stage, not the destination. The progression below is defined by what has been earned rather than by schedule, and each stage's entry criterion is evidence produced by the preceding one.

Stage 0 — Observation. Read-only ingestion and monitoring. No recommendations. Establishes data integration and baseline quality.

Stage 1 — Advisory. Ranked assessments with evidence and safe options. Operator decides and executes. This is the stage the reference implementation occupies.

Stage 2 — Validated advisory. Recommendations scored continuously against operator decisions across a deployed fleet. Divergence between recommendation and expert action is the primary training signal, and the primary evidence for whether the system is ready to advance.

Stage 3 — Bounded ground autonomy. For a narrow, explicitly enumerated class of low-consequence, fully reversible actions, with pre-approved envelopes and standing operator authorization. Every action logged and revocable. Entry requires a demonstrated record at Stage 2 on that specific action class.

Stage 4 — Bounded edge autonomy. On-board execution within a pre-approved envelope, for cases where the light-time and ground-contact delay is itself the hazard. Constrained by the same declared limits, with the same evidence trail recorded for downlink and post-hoc review.

Two invariants hold across every stage. The engineering envelope is declared by the operator, not learned by the system, and no autonomy level may cross it. And every action, autonomous or advised, produces the same reconstructible evidence record — autonomy changes who approves, never whether the reasoning can be inspected.

The honest statement of where the technology stands: Stage 1 is implemented and measurable. Stage 2 requires deployed customers. Stages 3 and 4 require a Stage 2 record that does not yet exist. Claiming otherwise would invert the argument this paper makes.

9. Security, sovereignty, and export control

Telemetry reveals capability, tasking, and vulnerability, and for many operators it is subject to export control or government customer restrictions. Three properties follow.

Data residency. The system runs inside the customer's environment. Telemetry is not required to leave operator control, and air-gapped deployment is a supported configuration rather than a special case.

Reviewable artifact. The absence of third-party runtime dependencies makes the deployed artifact tractable for a security team to review directly, and removes supply-chain compromise as a review topic.

Bounded compromise. Because there is no command path, the worst outcome of a compromised deployment is disclosure of telemetry already inside the customer's boundary, and the display of incorrect recommendations to an operator who must approve them. The system cannot be turned into a weapon against the spacecraft it monitors.

Export-control classification is customer- and jurisdiction-specific and is addressed per engagement.

10. Open problems

Stated as open, rather than as roadmap items with implied delivery.

Baseline validity after intervention. A learned baseline assumes healthy operation. When an operator changes a duty cycle or reconfigures a subsystem, the baseline becomes wrong in a way that resembles an anomaly. Distinguishing commanded change from degradation requires ingesting command history as a first-class input, which the architecture provides for but the reference implementation does not yet exploit.

Multi-fault interaction. Faults are currently correlated within a subsystem. Real anomalies cross subsystem boundaries — a thermal problem presenting simultaneously as battery and wheel degradation. Attributing a common cause across subsystems is unsolved here.

Rare-event calibration. The failures that end missions are rare, which is precisely what makes them hard to calibrate against. Replay measures performance on faults that occurred; it says nothing about the fault class absent from the archive.

Confidence under distribution shift. Confidence is currently scored on signature corroboration and excursion magnitude. Neither accounts for a spacecraft operating outside the regime its baseline was learned in — after an orbit change, a seasonal eclipse variation, or an aging-driven regime shift.

11. Conclusion

The constraint on spacecraft operations is decision throughput, and it is tightening faster than operator headcount can be grown. The response cannot be to remove the operator, because the actions that matter are frequently irreversible and the cost of an unexplained wrong action is unbounded.

The architecture described here takes the opposite approach. It is read-only by construction, so that being wrong is survivable. It is physics-informed, so that recommendations are bounded by an envelope the operator declares. It is reconstructible, so that an operator can disagree on specific grounds. And it is validated by replay against ground truth it was never given, so that its claims are falsifiable — including, as Section 7.2 documents, when they turn out to be false.

The commercial and the technical arguments are the same argument. A system that cannot be inspected will not be approved, a system that cannot be scored cannot be improved, and a system that cannot be trusted with a small decision will never be trusted with an important one.

Notes on sources