From a satellite assignment to a checked computing workflow

Since the previous research note · Earlier expectation not tested

Track continuity

Since the previous research note: How a spacecraft can learn an ordered imaging assignment within its limits

Previous expectation: Spacecraft might eventually learn to carry out ordered imaging assignments while respecting power and reaction-wheel limits, provided that performance and protection transfer to operational vehicles.

What this study adds: The July 16, 2026 preprint supplies a ground-side compiler for checking human-authored plans and producing runtime workflow artifacts, with software evaluations and local cluster execution. It does not test the earlier forecast about learned onboard imaging behavior.

---

What changed in this study

A satellite mission plan may begin as an authored sequence of assignments, but an onboard computing runtime needs something more precise: workflow artifacts that describe what should run and how the steps depend on one another. A July 16, 2026 arXiv preprint presents Satellite Mission Compiler, a ground-side prototype designed to perform that translation before anything is sent toward an onboard environment.

The authors place the compiler between a human-authored plan and the runtime that will consume its instructions. Their motivation is that several emerging onboard cloud-native efforts, including the ORCHIDE, Axiom Space AxDCU-1 and Kepler Jetson-node tracks, assume that suitable workflow artifacts arrive from the ground. In the preprint’s account, ORCHIDE’s architecture document limits its scope to the Deferred Phase, while an open-source ground-side toolchain has not been released by the consortium. The proposed compiler addresses that preparation step rather than making mission decisions onboard.

The missing step is on the ground

Here, “compiler” means software that translates one representation into another executable representation. The input is a mission plan written by a person. The output is a set of workflow descriptions that computing infrastructure can inspect, schedule and submit. The important contribution is therefore not a new onboard learning behavior or an autonomous planning result. It is a controlled route from an assignment description to machine-oriented instructions.

That route matters because a plan can be readable to a human while still being incomplete or internally inconsistent for a runtime. A timestamp without a timezone can be ambiguous. An acquisition event without an instrument can lack a required operational reference. A service definition or step can have structural gaps that are easy to miss when a plan is edited as ordinary text. The compiler makes those expectations explicit before producing downstream artifacts.

The preprint describes the work as filling a gap between several neighboring approaches. The onboard-runtime thread stops at the runtime itself, while other planning or command-sequence systems may define rules without emitting the Argo and Kueue artifacts used by this pipeline. Those comparisons are the authors’ framing of the literature and systems landscape; the concrete result reported here is the compiler and its evaluation.

Four stages turn a plan into a workflow

The pipeline has four stages. First, it parses the plan against a Pydantic schema derived from public ORCHIDE materials. This is the structural layer: fields must have the expected shape, timestamps must be timezone-aware, instruments must be present where required, and AI services and steps must maintain the expected integrity.

Second, the plan is evaluated against an Open Policy Agent package written in Rego. These are executable policy rules rather than informal review notes. The package contains ten deny rules with provenance recorded in the paper. Some rules are derived from the public ORCHIDE materials, while others are explicitly imposed by the authors as safety practice. This distinction gives a reviewer a way to see which constraints are inherited from the referenced architecture and which represent the compiler authors’ own admission policy.

Third, a valid plan is translated into a typed intermediate representation called `WorkflowIntent`. An intermediate representation is a structured form that sits between the original description and the final workflow files. It gives the compiler a stable place to express the plan’s intent before rendering it into particular orchestration formats.

Finally, the compiler renders Argo Workflow directed acyclic graphs and Kueue job manifests, including support for Dynamic Resource Allocation. In practical terms, the result describes dependencies between workflow steps and the resources that queued work may request. A cross-field example shows why the layers are useful: a plan may pass basic schema validation but still violate a policy involving GPU fallback or an incompatible CPU-acceleration setting. Those relationships depend on more than whether each individual field has the right type.

Reviewers can inspect the policy separately

The authors use OPA partly because the policy can be run and audited without running the compiler. A reviewer can evaluate the rule package against an input plan with the external policy tool, inspect the decision and examine the rule’s provenance. That is a governance property, not a claim that Rego can express checks that Python cannot. The preprint acknowledges that a Python model validator could implement the same semantic checks.

The value of the separate policy artifact is that the admission decision can be reviewed as an independently executable object. In the reported ablation study, three categories of semantic violations passed the schema layer and were then caught by policy. The authors also built an in-process Python baseline that reimplemented the ten rules and reproduced OPA’s decisions across fourteen cases spanning valid inputs, schema-only failures, policy-only failures and cases caught by both layers.

The paired timing comparison shows a tradeoff rather than a universal winner. In that run, the in-process baseline took roughly 0.02 to 1.0 milliseconds, while OPA took about 17 to 120 milliseconds. OPA’s extra cost came with an external, standard evaluation surface that reviewers could invoke independently. Agreement on fourteen cases demonstrates consistency across that test corpus; it does not establish equivalence for every possible mission plan or prove that the ten rules are complete.

The workload scaled inside the test setup

The compiler was also measured with synthetic plans containing between 10 and 1,000 acquisition events, with three steps per event. A plan with 1,000 events and 3,000 steps compiled in about 1.5 seconds on the reported desktop setup: an Intel Core i5-7400 running Ubuntu 24.04 with Python 3.12.3 and OPA 1.15.1. The authors identify pure-Python YAML loading as the dominant part of that larger run.

That result answers a narrow engineering question. It indicates that the preparation pipeline handled a sizeable synthetic input within the local test environment, with the main workload cost located in parsing and data loading. It does not measure observation throughput, onboard execution latency or the time needed to complete an end-to-end satellite mission. The benchmark concerns the work of preparing and rendering instructions on the ground.

A local cluster completed one reported execution

A separate test examined whether generated work could reach a local single-node cluster. The reported GPU path used a Dynamic Resource Allocation claim, and the cluster allocated an RTX 5080 with the workflow completing with a `Succeeded 3/3` result. The preprint also reports a GPU admission cascade on Kueue v0.17.3, revalidated on v0.18.3, along with a unified GPU-and-CPU device-class quota and scheduler-level accelerator fallback on v0.18.3.

These observations show a longer handoff than compilation alone: a plan was translated, resources were represented, and a generated workflow was submitted in the tested cluster environment. They still describe local software execution. A successful GPU allocation on that cluster is not evidence that the same workflow has run on an operational spacecraft, nor does it establish that the compiler improved mission outcomes.

The boundary between admission and autonomy

The compiler’s loss-event classification gives its validation layers an operational vocabulary. Four severity tiers connect pre-uplink failures to specific schema or policy checks. The modeled consequences include scheduling stalls, missed contact windows and ineffective AI-service execution. Those consequences are derived from published runtime semantics, according to the evidence supplied with the preprint; they were not measured as outcomes during satellite operations.

The source is explicit that this classification is an admission-gate model, not a flight safety case. That distinction matters because a ground check can prevent a known class of malformed or contradictory input from entering the tested workflow path without demonstrating that every relevant mission constraint has been captured. The checks make review more concrete, but their protection remains bounded by the rules, representations and runtime integration that have actually been tested.

The agent interface illustrates a similar boundary. Six Model Context Protocol tools expose the pipeline to AI agents. The demonstrated sequence surfaced a missing-fallback violation through an explanation tool, then processed a corrected plan that had already been authored. The example shows that the tool surface can support a diagnose-and-verify interaction. It does not show an agent independently inventing a correct repair. An autonomous diagnose, repair and verification loop remained future work in the preprint.

What this could change for satellite mission teams

Satellite mission teams could gain a reusable route from authored assignments to onboard computing workflows, with acceptance rules that reviewers can evaluate as a separate policy artifact. If generated workflows integrate reliably with operational runtimes and the checks capture the constraints that matter for a particular mission, changing processing assignments could become more dependable and less exposed to the modeled disruptions caused by invalid plans.

The potential benefit is therefore practical and conditional. It lies in making the ground preparation of satellite computing work more inspectable and repeatable, not in promising autonomous mission learning or measured reductions in missed observations. The July 2026 preprint supplies a software prototype, local performance measurements and a cluster execution example; broader mission value would depend on validation beyond that tested environment.

Key Sources

• Primary source: Ground-Side Mission Plan Compilation with Policy-as-Code Guardrails for Cloud-Native Satellite Platforms
  arXiv · Preprint · 2026-07-16