Ground-Side Mission Plan Compilation with Policy-as-Code Guardrails for Cloud-Native Satellite Platforms

arXiv:2607.14798v1 [cs.DC] 16 Jul 2026

Ground-Side Mission Plan Compilation with Policy-as-Code Guardrails for Cloud-Native Satellite Platforms Hsiu-Chi Tsai

Chia-Tung Chung

National Yang Ming Chiao Tung University Hsinchu, Taiwan [email protected]

National Yang Ming Chiao Tung University Hsinchu, Taiwan [email protected]

Abstract—Onboard cloud-native runtimes for satellites are emerging on multiple tracks (ORCHIDE’s K3s and Argo Workflows stack, Axiom Space’s AxDCU-1 with Red Hat MicroShift, and Kepler Communications’ NVIDIA Jetson Orin edge nodes), but each assumes that the workflow artifacts it executes arrive from the ground. ORCHIDE’s architecture document D3.1 states explicitly that “only the Deferred Phase is part of the ORCHIDE scope,” and no open-source ground-side toolchain has been released by the consortium. We present S ATELLITE M ISSION C OMPILER, a four-stage pipeline that addresses this gap: it takes a human-authored mission plan, checks it against machinecheckable structural and policy rules, and compiles it into the container-workflow artifacts that cloud-native satellite runtimes consume. Concretely, the pipeline parses the plan against a Pydantic schema derived from public ORCHIDE materials, evaluates it against an OPA/Rego policy package of ten deny rules with explicit ORCHIDE-inherited versus author-imposed provenance, compiles it into a typed WorkflowIntent intermediate representation (IR), and renders it as Argo Workflow directed acyclic graphs (DAGs) and Kueue Job manifests with Dynamic Resource Allocation (DRA) support. We classify pre-uplink loss events into four severity tiers tied to specific schema and policy checks, and anchor the layered-validation design in the safety reading of defense-in-depth (NASA-STD-8739.8B), distinguished from the security reading of NIST SP 800-53. The implementation is validated by golden translation evaluations, argo lint, an in-process baseline that reproduces OPA’s decisions, and live single-node cluster submission—including a DRA-backed GPU admission cascade on Kueue v0.17.3 (re-validated on v0.18.3) and, on v0.18.3, a unified GPU+CPU device-class quota with a scheduler-level accelerator fallback. Six Model Context Protocol (MCP) tools expose the pipeline to AI agents through a pathtraversal-protected interface (CWE-22). The compiler is released under EUPL-1.2 (DOI 10.5281/zenodo.21228150). Index Terms—satellite mission planning, cloud-native, Argo Workflows, OPA/Rego, Kueue, policy-as-code, ORCHIDE

© 2026 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works. Accepted for publication in the IEEE Space Mission Challenges for Information Technology / Space Computing Conference (SMC-IT/SCC), 2026. This arXiv version is an extended version of that paper, adding a unified GPU+CPU DRA quota and a scheduler-level accelerator fallback re-validated on Kueue v0.18.3 (Section V-F).

I. I NTRODUCTION Onboard cloud-native runtimes for satellites have moved from concept to deployment along several parallel tracks. The ORCHIDE EU project (Horizon grant #101135595) has publicly specified an onboard stack of K3s, Argo Workflows, containerd, urunc [18]-hosted unikernels, EOS storage, and vAccel-mediated accelerators running on heterogeneous onboard hardware (NVIDIA Jetson Orin GPUs, Xilinx Versal FPGAs, NXP LX2160 ARM64 CPUs, and Kalray MPPA accelerators), presented at KubeCon EU 2026 [1], [2], [4]. Red Hat and Axiom Space’s AxDCU-1, an orbital data-center prototype powered by Red Hat Device Edge (which includes the MicroShift lightweight Kubernetes distribution) was announced in March 2025 [31] and delivered to the International Space Station aboard SpaceX CRS-33 in August 2025 for an onorbit data-processing demonstration. Kepler Communications reported in March 2026 the commissioning of distributed on-orbit compute across its ten Tranche 1 satellites, using forty NVIDIA Jetson Orin modules as edge-compute nodes interconnected by optical inter-satellite links to support AI and accelerated workloads [32]. The technology stacks differ in important ways, and KubeSpace [15] has argued that the standard Kubernetes control plane is ill-suited to low-Earth-orbit (LEO) satellite networks characterized by geographic dispersion and frequent handovers. What the deployed tracks share, however, is the assumption that the workflow artifacts they execute— directed acyclic graphs (DAGs), container manifests, resource claims—arrive from the ground. The artifacts arrive, but the ground-side tooling that should produce them is uneven. ORCHIDE’s architecture document D3.1 states explicitly that “only the Deferred Phase is part of the ORCHIDE scope” (Section II-A): the onboard Orchestrator executes mission plans but does not itself generate, validate, or compile them. The consortium’s ground segment does include a Software Development Kit (SDK), a Simulation Framework, and a Management Framework, but none of those tools, nor any mission-plan schema or policy-enforcement layer, has been released as open source (Section II-A). The other onboard tracks similarly assume but do not provide a way to take

a structured mission plan, prove it is well-formed under a • Six Model Context Protocol (MCP) [20] tools that expose published schema, and emit the Argo artifacts the onboard the pipeline to AI agents through a path-traversal-protected runtime executes together with the Kueue artifacts that gate interface (Common Weakness Enumeration CWE-22). ground-side admission. The consequence of operating without The implementation is validated by golden translation that layer is concrete rather than hypothetical: a plan whose evaluations, static Argo linting against argo v4.0.1, an inacquisition step has no fallback resource class declared can process baseline that reproduces the OPA policy decisions, and reach the satellite and stall the Deferred Phase when the live-cluster submission on host kubeadm Kubernetes clusters requested accelerator is unavailable; a download event missing (v1.35–v1.36 across experiments) running Argo, Kueue, and a ground-visibility window can be admitted and then never the NVIDIA DRA driver. Source code is released under executed, queuing the next plan behind it; a structural error the European Union Public Licence v1.2 (EUPL-1.2) at in the YAML payload can require a corrective uplink that https://github.com/thc1006/satellite- mission- compiler consumes the next contact window. Section III-H classifies (DOI 10.5281/zenodo.21228150). these consequences by severity tier. Validation of mission plans against configurable rules is not II. BACKGROUND AND R ELATED W ORK a new problem. Commercial mission-planning systems such as A. Background: The ORCHIDE Onboard Cloud-Native PlatGMV FlexPlan [33] have for decades supported reusable conform straint and rule definitions, and command-sequence checking ORCHIDE (Orchestration of Reliable Computing on Hetagainst flight rules is a mature practice at NASA’s Jet Propulsion Laboratory (JPL), exemplified by the RP-check architecture erogeneous Infrastructures Deployed at the Edge) is an EU used in Mars-rover operations [34]. Open-source frameworks Horizon Europe project running from December 2023 to exist on the ground-control side (OpenC3 COSMOS [35] runs May 2026, led by Thales Alenia Space with Tarides, KP Labs, on Kubernetes via Helm, scaling to constellation-sized fleets) Thales Romania, and POLITEHNICA Bucharest as partners [2]. and the EOEPCA platform [27] already compiles Common Its objective is an onboard Edge Platform-as-a-Service for Workflow Language specifications for Earth-observation data- Earth-observation satellites: a runtime stack that lets operators processing applications into Argo workflows. Each of these deploy, update, and revise containerized AI workflows while systems addresses part of the problem the ORCHIDE-class the spacecraft is in orbit. The publicly described ORCHIDE onboard runtimes raise; none of them, however, provides as an solution consists of three components targeted at the ground open-source toolchain the specific combination of (i) policy- segment—a Software Development Kit, a Simulation Frameas-code over (ii) satellite mission plans, distinct from generic work, and a Management Framework—together with the command sequences or data-processing apps, (iii) compiled onboard runtime they target, the Orchestrator [2], [3]. The into Argo Workflow and Kueue Job artifacts that (iv) target the compiler presented in this paper provides three functions absent artifact formats consumed by onboard cloud-native runtimes from the published ORCHIDE artifacts: schema validation, policy-as-code enforcement, and compilation into the artifacts such as ORCHIDE. This paper contributes that synthesis. We present S ATELLITE the Orchestrator consumes. M ISSION C OMPILER, an open-source four-stage pipeline that Onboard technology stack.: ORCHIDE’s onboard Orchestakes a structured mission plan and produces validated Argo trator runs K3s [23] as its lightweight Kubernetes distribution and Kueue artifacts. Concretely: and Argo Workflows [22] as the directed-acyclic-graph execu• A Pydantic [19] schema derived from the public OR- tion engine, with containerd and the urunc [18] OCI (Open CHIDE materials enumerated in Section II-A, with Container Initiative) runtime hosting Unikraft and MirageOS parse-time enforcement of timezone-aware timestamps, unikernels under hypervisor isolation. The platform uses EOS, instrument presence for acquisition events, and structural the distributed-storage system originally developed at CERN, as its data backbone; Zot as the OCI registry; and vAccel as integrity of AI services and steps. a hardware-agnostic abstraction over graphics-processing-unit • An OPA (Open Policy Agent)/Rego policy package of ten deny rules, separated explicitly into rules derived from (GPU) and field-programmable-gate-array (FPGA) acceleraORCHIDE materials and rules imposed by the authors as tors [4], [40]. The choice is constrained by the size, weight, and power (SWaP) envelope typical of an Earth-observation safety practice, with provenance indicated in Table II. payload; the use of Argo Workflows specifically allows a • Argo Workflow and Kueue Job renderers supporting sequential and parallel execution modes, soft-preference mission plan to be represented as a graph of containerized GPU affinity, and Dynamic Resource Allocation (DRA) steps with explicit data and resource dependencies. for accelerators. DRA-backed GPU admission with singleStructure of an ORCHIDE mission plan.: A mission plan device quota was demonstrated against Kueue v0.17.3 is a time-ordered sequence of events distributed over one or on a kubeadm cluster (Section V-E), and extended on more orbits. Each event has a type, either an acquisition, Kueue v0.18.3 to a unified GPU+CPU device-class quota which is bound to an instrument identifier (e.g., optical and and an opt-in scheduler-level firstAvailable accelerator hyperspectral cameras, radars, or multi-detector arrays) and a fallback, with the empirical boundary that Kueue quota- region descriptor distinguishing ocean (O) from land (L) [1], [4], counts only exactly device requests (Section V-F). or a download, characterized by a ground-visibility window and

a transmission duration. Acquisition events carry one or more AI services; each service is annotated with a priority on the 1–4 scale used by the onboard scheduler [1] and is decomposed into an ordered sequence of steps. Steps declare a phase (preprocessing, AI inference, or postprocessing) and a resource class (CPU, GPU, or FPGA) [1]. Plans may also declare an optional fallback resource class per step. The public ORCHIDE materials note this field but do not specify how an Orchestrator ought to act on it; this paper treats fallback declaration as a recommended safety practice and enforces it through a policy rule for any accelerator-requesting step (Section III-D, Rule 4)—an author-imposed rule, not an ORCHIDE-inherited requirement. The Deferred Phase scope and the ground-side gap.: D3.1 states explicitly that “only the Deferred Phase is part of the ORCHIDE scope” and that the Acquisition and Transmission phases are outside that scope [2, §2.2]. The mission plan itself reaches the Orchestrator through D3.1’s mission-plan deployment interface, identified as IF_SO_MIS_DP in the project’s interface catalogue [2, §3.3.1, Table], and is consumed by the onboard Mission Manager and dispatched to its Workflow Manager subcomponent for execution [2, §3.2.1.1]. The Orchestrator does not generate, validate, or compile that plan; although the consortium has demonstrated graphical SDK tools on its YouTube channel [43], no open-source ground-side toolchain, mission-plan schema, or policy-enforcement layer has been released as of June 2026. A malformed plan that bypasses ground-side checks consumes scarce in-orbit compute and downlink budget before the next plan can be uploaded, with consequences ranging from missed observation windows to Deferred-Phase stalls. Section III-H returns to this consequence model. Section III-A presents the compiler that addresses this gap. What public materials cover and what they do not.: Our schema and compilation pipeline are derived from the union of publicly available ORCHIDE artifacts to date: deliverables D2.2 (state-of-the-art review of edge orchestration and unikernel technologies), D3.1 (overall solution architecture and design), and the dissemination deliverables D6.1 and D6.2 [2], [3], [38], [39]; Karam Hankache’s EDHPC 2025 talk on the onboard data-processing orchestrator [4]; the KubeCon EU 2026 talk by Karam Hankache and Weisz [1]; the CERN-hosted workshop presentation by Weisz on ORCHIDE’s use of EOS for space edge computing [40]; and the consortium’s June 2026 archival paper [41], published after our initial submission, which documents the onboard architecture but does not release a groundside schema or policy package. The technical deliverables D3.2, D4, D5, and D7 remain confidential at the time of writing. The Pydantic schema we present in Section III-C is designed as a pluggable boundary: when an authoritative ORCHIDE specification or an open-source schema is released, replacement is intended to be mechanical because the schema does not propagate into the policy package or into the renderers. Section VI returns to this point.

B. Policy-as-Code, Safety, and the Security–Safety Distinction OPA [5] is a general-purpose policy engine that evaluates rules written in the Rego declarative language. OPA is a Cloud Native Computing Foundation (CNCF) Graduated project and is widely deployed as a Kubernetes admission controller through Gatekeeper [24]. We use OPA because the policy is a separate artifact that a reviewer can execute and audit standalone: an external auditor can run opa eval against arbitrary inputs without invoking the compiler. Version control and independent review OPA shares with any in-repo validator; what OPA adds over a hand-written Python validator is compiler-independent executable evaluation delivered by a standard, off-the-shelf external tool. Layered defensive validation.: The compiler enforces four independent checks on every mission plan before any artifact is admitted to a cluster: (i) structural validation against a Pydantic v2 schema, (ii) semantic policy evaluation against ten Rego deny rules, (iii) static lint of the rendered Argo Workflow YAML via argo lint, and (iv) runtime admission by the Kubernetes API server, optionally fronted by Kueue. We call this, by analogy with NASA-STD-8739.8B’s layered Independent Verification and Validation (IV&V), layered defensive validation by partially redundant checkers: each stage has a distinct primary failure mode—the schema catches type, cardinality, and required-field errors at parse time; the policy catches cross-field semantic errors that span multiple fields; the static lint catches manifest-level errors introduced by the renderer; and admission catches violations of the target cluster’s own constraints—and the stages overlap by design so that a defect in an overlapping check does not silently propagate. The schema and policy layers overlap on five of the ten rules (1, 2, 7, 8, and 9), documented in Section III-D; the resulting pre-uplink loss-event classification is given in Section III-H. Security defense-in-depth versus safety defense-in-depth.: The term defense-in-depth is used in two distinct technical communities and carries different operational interpretations in each. In the security community, defense-in-depth refers to overlapping controls (network, host, application, and data) that together mitigate adversarial threats to confidentiality, integrity, and availability, as catalogued in NIST SP 80053 [25]. In the safety community, defense-in-depth refers to layered, mutually redundant verification of safety-relevant artifacts so that no single analytical or implementation error can propagate undetected to the operational system. The safety reading is articulated by NASA’s Software Assurance and Software Safety Standard [36] and is consistent with the constraint-enforcement perspective of Leveson’s SystemsTheoretic Accident Model and Processes (STAMP) [37], whose associated hazard-analysis technique is Systems-Theoretic Process Analysis (STPA). The two readings are complementary but not interchangeable, and the layered validation pipeline of this paper instantiates the safety reading through partially redundant layers. The ORCHIDE consortium’s own archival paper [41] describes its onboard Security Manager as offering

a “layered defense-in-depth posture” against an “adversarial August 2025 for on-orbit data-processing experiments. Kepler satellite environment”—verbatim the security reading—which Communications reported in March 2026 the deployment of the ground-side validation pipeline of this paper does not forty NVIDIA Jetson Orin modules across its ten Tranche 1 duplicate. The compiler does not implement the security satellites; as of that announcement the orchestration layer above reading—it does not authenticate uplink operators, encrypt the Jetson modules is not publicly specified [32]. KubeSpace’s transmitted artifacts, or defend the cluster against an adversarial orbit-aware critique [15] targets onboard control-plane stability mission-plan author—and that scope boundary is recorded in and is orthogonal to the ground-side compilation layer the Section VI. present work occupies. Commercial mission planning and command-sequence Scope disclaimer.: NASA-STD-8739.8B [36] prescribes a full software-assurance program including hazard analysis, validation.: Validation of mission plans against configurable assurance records, and IV&V by an organization independent rules is a mature practice. GMV’s FlexPlan is a commercial of the developer; this paper does not produce those deliverables. mission-planning product that has supported reusable constraint STPA-style hazard analysis would be the natural successor to and rule definitions for ground-segment scheduling across the consequence-tier classification we adopt in Section III-H multiple operators [33]. On the spaceflight-operations side, but is outside the scope of a ground-side compiler. We invoke JPL’s RP-check is an architecture for command-sequence both standards as the source of the safety-defense-in-depth validation against flight rules, developed and deployed in Marspractice that motivates the layered design, not as compliance rover surface operations [34]. Both reflect the practitioner expectation that automated rule checking is essential before claims. On novelty.: OPA satisfies the version-control, decoupling, commands or plans leave the ground. Ground-control and EO data-processing frameworks.: and external-audit requirements that motivate our choice of policy engine. The contribution of this paper is the synthesis On the open-source side, OpenC3 COSMOS is an open-source of OPA-style policy-as-code with a typed mission-plan schema mission-operations framework, with a separate commercial and an Argo/Kueue renderer targeting the artifact formats of Enterprise edition that adds Kubernetes/Helm deployment an onboard cloud-native runtime; the precise scope of that for constellation-scale fleets; its focus across both tiers is synthesis claim, and the adjacent systems it does and does not telemetry, command, and the operator-facing console rather than mission-plan compilation [35]. The European Space overlap with, are deferred to Section II-D. Agency (ESA) EOEPCA platform compiles Common Workflow C. Kubernetes Batch Admission Language (CWL) specifications for Earth-observation dataKueue [6] is a Kubernetes-native job queuing system provid- processing applications into Argo workflows via Calrissian [27], ing fair-share scheduling, resource quotas, and preemption for but the inputs are processing-application descriptors, not batch workloads. Baseline DRA integration (the ResourceClaim satellite mission plans, and policy enforcement is not part of the Template path with deviceClassMappings) shipped as alpha in compilation contract. Adjacent systems address different layers: Kueue v0.14.0 (September 2025); v0.17.0 (March 2026) added Krios [16] and Komet [17] contribute LEO scheduling and an alpha extended-resources path enabled by the DRAExtended serverless abstractions, KubeEdge [14] provides edge orchestraResources feature gate. The v0.17.3 release [7] (May 2026) tion with reported satellite deployments, Kratos OpenSpace [28] that we exercise in Section V-E retains the same gate [11]. Vol- deploys Rancher Kubernetes Engine 2 (RKE2)/K3s for groundcano [13] provides a richer abstraction (scheduler, PodGroup, station signal processing, and the Consultative Committee queue), but its API surface exceeds the requirements of single- for Space Data Systems’ mission-planning standard (CCSDSJob-per-service workloads. We treat Kueue as the admission MPS) [29] together with operator systems such as the Gertarget because its ClusterQueue + LocalQueue abstraction maps man Aerospace Center (DLR) EnMAP Mission Planning cleanly to the per-mission quota model the renderer needs; the System [30] formalise constraint-based mission planning at a application to satellite workload scheduling is the contribution layer above the workflow runtime. Recent developments (2026).: The literature published Section II-D positions among adjacent ground-side toolchains. while this system matured advances the layers around the D. Related Work compiler without closing the ground-side gap. On the space Onboard cloud-native runtimes for satellites.: Several cloud-native side, YUHENG-OS proposes a cloud-native opertracks are converging on container-based orchestration in orbit, ating system for distributed satellite clusters and benchmarks it each naming a specific Kubernetes-derived or Kubernetes- against vanilla Kubernetes [44], while Equinox turns onboard adjacent runtime rather than vanilla Kubernetes. The ORCHIDE battery, thermal, and queue state into a marginal cost of consortium specifies an onboard K3s+Argo stack (detailed in execution for decentralized scheduling on Earth-observation Section II-A) with a project-end demonstration that was targeted constellations [45]; both sit at the onboard-runtime and for May 2026 [1], [2], [4]. Red Hat and Axiom Space’s AxDCU- scheduling layer that consumes workflow artifacts rather than 1, an orbital data-center prototype running Red Hat Device Edge the ground-side layer that produces and validates them. A (which includes the MicroShift lightweight Kubernetes distri- position paper on the edge-cloud-space continuum enumerates bution) was announced in March 2025 [31] and delivered the assumptions that break when serverless and orchestration to the International Space Station aboard SpaceX CRS-33 in models move to low-Earth orbit and names constraint-aware

placement of workflow graphs as an open problem [46]— the placement our compiler front-loads with schema and policy checks. On the heterogeneous-scheduling side, an independent Kubernetes+Argo+Kueue framework for hybrid quantum-classical pipelines corroborates the toolchain we chose for accelerator admission [47], ClusterLess demonstrates deadline-aware serverless workflow orchestration across federated edge clusters [48], and BIDENT maps neuralnetwork operators across heterogeneous CPU/GPU/NPU units on edge hardware [49]—an operator-level analogue of the GPU→CPU device fallback of Section V-F. On the workload side, edge intelligence for satellite Earth observation schedules image acquisition and on-board-versus-ground processing under energy constraints [50], the acquisition-and-download task model our mission plans encode. Finally, an empirical study of policy-as-code adoption across open-source projects frames OPA/Rego governance as an established engineering practice rather than an ad hoc choice [51]; space-specific policy-as-code nonetheless remains scarce, a gap this paper’s policy package addresses. These systems collectively cover the onboardruntime, edge-orchestration, heterogeneous-scheduling, and policy-as-code layers that surround the compiler, yet none takes a satellite mission plan through schema and policy validation into onboard-runtime artifacts. The ground-side compilation gap.: None of the four threads above offers a typed, policy-checked compilation path from a satellite mission plan to onboard-runtime workflow artifacts. The onboard-runtime thread stops at the runtime itself; the commercial-planning and command-sequence threads define rules but not container-workflow output; the ground-control and EO threads either focus on telemetry-and-command (COSMOS) or compile from processing-application descriptors rather than mission plans (EOEPCA); and the adjacent constraintbased planning systems (KubeSpace/Krios/Komet/CCSDSMPS/EnMAP) operate at a layer above the workflow runtime without emitting validated Argo or Kueue artifacts. Section III-A presents the compiler that addresses this gap; Table I quantifies the gap across the dimensions of mission-plan input, policy-as-code, and Kubernetes-artifact output. III. S YSTEM A RCHITECTURE A. Pipeline Overview The compiler implements a four-stage pipeline (Fig. 1): Stage 1 validates the mission plan schema using Pydantic, Stage 2 evaluates OPA/Rego policy rules, Stage 3 compiles validated plans into a typed WorkflowIntent intermediate representation (IR), and Stage 4 renders the IR into Argo Workflow and Kueue Job artifacts. B. Mission Plan Input Format Listing 1 shows an excerpt from a maritime surveillance mission plan. The plan declares two events on one orbit: an acquisition event at 10:30 running a three-step ship detection pipeline (preprocess, detect-ships, postprocess), and a download event at 10:42 transmitting results during a 268-second

Mission Plan YAML

Stage 1: Schema Validation (Pydantic v2)

Stage 2: Policy Evaluation (OPA/Rego)

Stage 3: WorkflowIntent IR

Argo Workflow YAML

Kueue Job YAML

Fig. 1. Four-Stage Compilation Pipeline mission_id: mission-alpha events: - timestamp: "2026-04-15T10:30:00Z" event_type: acquisition instrument: optical-camera services: - service_id: maritime-surveillance priority: 90 steps: - name: preprocess image: ghcr.io/example/preprocess:0.1.0 resource_class: cpu - name: detect-ships image: ghcr.io/example/ship-detector:0.1.0 resource_class: gpu fallback_resource_class: cpu - name: postprocess resource_class: cpu - timestamp: "2026-04-15T10:42:00Z" event_type: download duration_seconds: 268 ground_visibility: true

Listing 1. Mission plan input (abbreviated)

ground-visibility window. The detect-ships step requests GPU acceleration with CPU fallback. C. Schema Validation (Stage 1) The mission plan schema is implemented as Pydantic v2 [19] BaseModel classes derived from publicly available ORCHIDE materials, with the structural elements summarized inline in Section II-A. Key constraints enforced at parse time: • Acquisition events must specify an instrument. • Download events must specify duration, must not declare AI services, and must require ground visibility. • mission_id must not be empty; events must contain at least one entry; each service must have at least one step. Error messages include source references back to the ORCHIDE materials enumerated in Section II-A, enabling downstream auditing of rule provenance. Service priority uses a 0–100 scale internally (0 is a misconfiguration, since ORCHIDE’s target scale starts at 1, and is rejected by policy Rule 5); ORCHIDE’s onboard scheduler uses 1–4 (Section II-A). We preserve priority intent as-is in the domain model; translation to ORCHIDE’s scale belongs in the rendering layer, which is a deployment-specific concern.

TABLE I C OMPARISON WITH A DJACENT S YSTEMS

System This work ORCHIDE [1] AxDCU-1 / MicroShift [31] Kepler / Jetson [32] KubeSpace [15] Krios [16] Komet [17] GMV FlexPlan [33] JPL RP-check [34] OpenC3 COSMOS [35] EOEPCA+ [27] Kratos OpenSpace [28] OPA Gatekeeper [24]

Mission plan input

Policy-as-code (PaC)

K8s artifact output

Domain

✓ Receives plan – – – – – ✓(commercial) ✓(cmd. seq.) – – – –

✓(OPA/Rego) – – – – – – proprietary rules flight rules (non-PaC) – – – ✓(OPA/Rego)

✓(Argo + Kueue) Argo (embedded) – – – – FaaS (custom) – – K8s/Helm (Enterprise) CWL → Argo (Calrissian) RKE2/K3s (ops) –

Satellite ground-side Satellite onboard Orbital data-center prototype On-orbit Jetson edge compute LEO control plane LEO scheduling LEO serverless Ground-segment planning Command-sequence validation Ground-control ops EO data pipelines Ground station infra K8s admission (general)

D. Policy Evaluation (Stage 2) Ten OPA/Rego deny rules enforce semantic constraints, several requiring cross-field reasoning, as summarized in Table II. TABLE II OPA/R EGO P OLICY RULES

#

Constraint

Origin

Prov.

1 2 3 4 5 6 7 8 9 10

mission_id not empty At least one event ACQ must declare services GPU/FPGA must have fallback Priority must not be zero CPU must not claim accel. DL must not carry services DL requires visibility Services must have ≥1 step Landscape type recognized

Integrity Integrity ORCHIDE doc Safety Range Logic ORCHIDE doc ORCHIDE doc Validity ORCHIDE doc

A A D A A A D D A D

D = directly traceable to ORCHIDE docs; A = author-imposed safety policy

accel_bound(s) if s.resource_class == "gpu" accel_bound(s) if s.resource_class == "fpga" missing_fallback(s) if not s.fallback_resource_class missing_fallback(s) if s.fallback_resource_class == null deny contains msg if { some i, j, k step := input.events[i].services[j].steps[k] accel_bound(step) missing_fallback(step) msg := sprintf("accelerator step %q " "(resource_class %q) must declare " "fallback_resource_class", [step.name, step.resource_class]) } deny contains msg if { some i, j, k step := input.events[i].services[j].steps[k] step.resource_class == "cpu" step.needs_acceleration == true msg := sprintf("step %q claims needs_acceleration" " but uses cpu resource class", [step.name]) }

Listing 2. OPA/Rego policy rules (abbreviated)

Schema validation and policy evaluation intentionally overlap Workflow names are normalized to RFC 1123 [26] DNS on Rules 1, 2, 7, 8, and 9 in the safety defense-in-depth sense labels at IR creation time to ensure consistent resource of Section II-B: schema catches structural errors at parse time, identification across heterogeneous renderers. while policy catches data bypassing schema validation (e.g., raw JSON submitted directly to OPA). F. Argo Workflow Rendering (Stage 4a) Listing 2 shows two representative Rego rules. Rule 4 The renderer produces Argo v1alpha1 Workflow manifests requires any GPU or FPGA step (independent of the optional with DAG-based execution. Sequential mode builds a linear needs_acceleration flag) to declare a fallback resource class. dependency chain; parallel mode omits dependencies. Unknown Rule 6 flags the contradictory combination of CPU resource execution modes default to sequential to prevent accidental class with needs_acceleration. parallelism. OPA is invoked as a subprocess with a 30-second timeout Each step template includes phase annotations (preprocessing, (CWE-400 mitigation). Standard output and standard error are AI inference, postprocessing) as defined in Section II-A, and captured separately to prevent error message leakage into policy GPU steps use soft-preference node affinity with fallback results. via an environment variable. Both the raw 0–100 priority E. Compilation to IR (Stage 3) and its deterministic translation to ORCHIDE’s 1–4 scale The compiler filters acquisition events and generates a Work- are emitted as workflow annotations (orbital/priority and flowIntent for each AI service. The IR carries ten resource orbital/orchide-priority). The translation buckets 0–100 hints including event timestamp, ground visibility, region type, onto 1–4 (76–100→1 through 1–25→4; priority 0 is rejected by orbit, duration, landscape type, execution mode, and three Rule 5), taking 1 as the highest priority—the common schedulBoolean flags for GPU/FPGA requirements and fallback. ing convention, since ORCHIDE’s public materials document

apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: name: mission-alpha-maritime-...-00z annotations: orbital/priority: '90' orbital/orchide-priority: '1' orbital/execution-mode: sequential orbital/requires-gpu: 'true' spec: entrypoint: main templates: - name: main dag: tasks: - name: preprocess template: step-0-preprocess - name: detect-ships template: step-1-detect-ships depends: preprocess - name: postprocess template: step-2-postprocess depends: detect-ships

apiVersion: batch/v1 kind: Job metadata: generateName: mission-alpha-maritime-...labels: kueue.x-k8s.io/queue-name: orbital-demo-local mission-id: mission-alpha spec: template: spec: containers: - name: detect-ships resources: requests: cpu: '1' memory: 256Mi claims: - name: gpu resourceClaims: - name: gpu resourceClaimTemplateName: ...-gpu-claim

Listing 4. Rendered Kueue Job with DRA (abbreviated)

Listing 3. Rendered Argo Workflow DAG (abbreviated)

the 1–4 scale but not its direction, so this too is an assumption pending interface disclosure. The orbital/orchide-priority key, and the assumption that an ORCHIDE Workflow Manager consumes it, are this paper’s proposal pending disclosure of the deployment interface (Section II-A); interoperation with the unreleased onboard scheduler is not verified here. Listing 3 shows a rendered DAG. G. Kueue Job Rendering (Stage 4b) The renderer produces batch/v1 Job manifests with Kueue [6] admission labels. Unlike the Argo renderer, which preserves the full multi-step DAG, the Kueue renderer generates an admission-oriented Job for the primary compute step (GPU step if present, else first step); full pipeline execution is delegated to the Argo path. Listing 4 shows a rendered Job. We chose Kueue over Volcano [13] for admission control. Kueue’s ClusterQueue + LocalQueue abstraction handles fair queuing and GPU quotas without an additional scheduler. Kueue v0.17.0 introduced alpha-level DRA support for extended resources. Our renderer generates DRA ResourceClaims for GPU workloads and standard resource requests for CPUonly workloads. H. Loss Events and Severity Tiers A ground-side admission-gate compiler is only useful insofar as the checks it enforces correspond to real in-orbit consequences. We therefore classify the loss events that a malformed or under-constrained mission plan can produce into four severity tiers, each tied to the schema or policy check that catches it. The classification is consequence-oriented, in the spirit of hazard-tier practice in software-safety engineering— the severity classification of NASA-STD-8739.8B [36] and the constraint-enforcement perspective of STAMP [37], whose associated hazard-analysis technique is STPA—but the tiers below are an operational classification for the compiler’s admission gate, not a flight safety case. Provenance tags in Table III reproduce the convention of Table II: D denotes a check derived from ORCHIDE’s published Deferred-Phase

scope, and A denotes a check that the authors impose as safety practice. Tier interpretation and provenance.: T1 captures structural violations: missing required fields, malformed timestamps, or type errors caught by the Pydantic schema, plus the OPA backstops for an empty mission_id (Rule 1) and a plan with no events (Rule 2). Such plans are rejected on the ground before any uplink is attempted; the in-orbit consequence is therefore null. T1 is author-imposed (A); Rules 1–2 narrow the residual risk on a schema-bypass path, but if both Pydantic and the policy package are bypassed entirely no pre-uplink guarantee applies. T2 covers semantic violations that would not crash the onboard Orchestrator but could cause the Deferred Phase to stall: a GPU step with no fallback_resource_class (Rule 4) cannot be rescheduled if the accelerator is unavailable, and a CPU step asserting needs_acceleration (Rule 6) is internally contradictory. Both are author-imposed (A); ORCHIDE documents the field but does not prescribe how the Orchestrator should act on it (Section II-A). “Deferred-Phase stall” is one plausible behavior under that unspecified policy; the rule prevents the ambiguous configuration from reaching orbit regardless of the Orchestrator’s eventual behavior. T3 covers checks tied to the download-event contract that ORCHIDE’s published materials specify directly (D): a download event carrying AI services (Rule 7) violates the published ORCHIDE invariant that DOWNLOAD events carry no WORKFLOW field (Section II-A), and a download event with missing or false ground_visibility (Rule 8) cannot transmit during its scheduled window. T4 captures checks whose violation can drop AI processing of a primary observation. Rule 3 is per-event: an acquisition event with no services attached (D) is still acquired at the sensor but produces no processed output. Rules 5, 9, and 10 are per-service (Rego some i, j): priority zero on the compiler’s 0–100 scale, a range check informed by ORCHIDE’s documented 1–4 scale (Rule 5, A), a service with no executable steps (Rule 9, A), or a service with an unrecognized landscape_type preventing model selection (Rule 10, D; the field is optional, so the rule flags a present

TABLE III P RE -U PLINK L OSS -E VENT S EVERITY T IERS AND T HEIR S CHEMA /OPA C HECKS

Tier

Loss event

Detected by

Rules

T1 T2 T3 T4

Plan malformed Accelerator stall, deferrable Contact-window loss Mission-objective loss

Pydantic + OPA OPA Pydantic + OPA OPA

1, 2 4, 6 7, 8 3, 5, 9, 10

In-orbit consequence none (ground reject) Deferred-Phase stall missed/malformed downlink AI service drop

Provenance per row: T1 A (Rules 1 A, 2 A); T2 A (Rules 4 A, 6 A); T3 D (Rules 7 D, 8 D); T4 mixed (Rule 3 D, Rule 5 A, Rule 9 A, Rule 10 D). Rule 5’s A tag reflects that its priority ̸= 0 check operates on the compiler’s 0–100 scale rather than ORCHIDE’s documented 1–4 scale; its Tier T4 placement is interpretive. The Detected by column lists the layer(s) that catch every rule in the tier; in T4, Rule 9 is also schema-enforced (the Section II-B overlap set), but Rules 3, 5, and 10 are policy-only, so the tier as a whole is caught only by OPA.

unrecognized value but permits a null or omitted one) each drop download with services (Rule 7)—demonstrating the layered the affected service. None of these consequence modes involves schema–policy coverage of Section II-B; only acquisition spacecraft hardware damage—the failure modes are scheduling without instrument is schema-exclusive. stalls, missed contact windows, or null AI-service execution. Semantic errors: Three categories of semantic violations These in-orbit consequences are derived from ORCHIDE’s passed schema validation but were flagged by OPA policy published Deferred-Phase semantics rather than measured on (Rules 4, 6, 10). A Pydantic model_validator could express the onboard runtime, which is not publicly available; the these checks (the schema already uses one for the downloadtiers are a mechanistically grounded pre-uplink risk model event constraints, Table IV), so we place them in the Rego that motivates the admission gate, not empirically measured policy not for expressiveness but for governance: the policy outcomes. can be executed and audited standalone by a reviewer who never runs the compiler (Section II-B). IV. MCP AGENT I NTERFACE Six Model Context Protocol [20] tools expose the pipeline to AI agents via FastMCP [21]: validate_plan (schema check), compile_plan (IR generation), render_argo (workflow rendering), explain_policy (OPA evaluation), diff_plans (structural comparison), and check_timeline_conflicts. The last tool detects interval overlaps using max(astart , bstart ) < min(aend , bend ). A scripted client exercises the tools end-to-end through the real MCP server in scripts/mcp_agent_demo.py: it validates a plan, surfaces a missing-fallback violation via explain_policy (Rule 4), then re-checks a corrected plan and compiles and renders it. The fix is applied from a preauthored corrected plan rather than synthesized by an LLM; the demonstration shows the tool surface is composable and agent-consumable, and closing the diagnose–repair–verify loop with an autonomous agent is future work. File path validation uses Path.relative_to() containment checks rather than prefix matching to prevent path traversal (CWE-22). Plan files accept only bare filenames within a whitelisted directory. V. E VALUATION A. Case Study: Error Detection We evaluated the compiler on three categories of mission plans. Table IV summarizes the results. Valid plans: The ORCHIDE-format sample plan (3 events, 3 AI services across 2 orbits) passes both schema and policy validation and compiles to 3 Argo Workflows and 3 Kueue Jobs. Structural errors: Four categories of structurally invalid plans were rejected at schema validation (Stage 1). Three of the four are independently caught by policy as well—empty mission_id (Rule 1), download without visibility (Rule 8), and

B. Compilation Performance and Scaling Table V shows phase-wise compilation times for synthetic mission plans with 10 to 1000 acquisition events (3 steps each), measured on an Intel Core i5-7400 @ 3.00 GHz (single core, Ubuntu 24.04, Python 3.12.3, OPA 1.15.1), mean of 30 iterations. Parse and total time scale near-linearly; parse (YAML + Pydantic) dominates at large sizes (its share grows from 41.8% at 10 events to 86.9% at 1000) while the OPA subprocess scales sub-linearly (18.8 ms → 115 ms), its per-call cost being a large fixed component (process spawn and policy load) plus a smaller input-proportional term. The sub-100 ms compile and render phases carry large relative variance because this host also runs a single-node kubeadm cluster; background control-plane load on this shared host, rather than the compiler, likely drives that jitter, so we read them as order-of-magnitude costs. A 1000-event plan with 3000 steps compiles in about 1.5 seconds, dominated by the pure-Python YAML load. Benchmarking OPA against an in-process Python validator (baseline_validator.py) that re-implements the ten rules and reproduces OPA’s decision on the entire ablation corpus (fourteen cases spanning valid, schema-only, policy-only, and both-layer inputs), the latter runs in 0.02–1.0 ms versus 17–120 ms in the same paired run. This run is separate from Table V, so its OPA figures differ from that table’s 18.8–115 ms through ordinary run-torun variance on the shared host. The gap over the in-process baseline (870× at 10 events, 120× at 1000) is largest where that fixed per-call overhead dominates; a long-lived OPA server or embedded engine would remove the fixed component while preserving standalone auditability. We keep the subprocess model because ∼120 ms is negligible beside parse; the baseline

TABLE IV C ASE S TUDY: E RROR D ETECTION ACROSS P LAN C ATEGORIES

Category

Example Error

Sch.

Pol.

Notes

Valid (ORCHIDE, 3 events)

None

✓

✓

3 Argo WFs + 3 Kueue Jobs

Struct: DL w/o visibility Struct: ACQ w/o instrument Struct: empty mission_id Struct: DL with services

visibility=false Missing instrument mission_id="" Services on DL event

✓ ✓ ✓ ✓

✓ – ✓ ✓

Both (Rule 8) Schema-only Both (Rule 1) Both layers catch

Semantic: invalid landscape_type Semantic: GPU no fallback Semantic: CPU+accel

landscape_type=desert No fallback_class cpu+accel

– – –

✓ ✓ ✓

Rule 10: unknown value Rule 4: safety Rule 6: within-step

explicit DRA Template Path on the same host after a platform upgrade, is presented in Section V-E. Argo sequential DAG: A three-step CPU-only mission plan Events Parse OPA Compile Render Total was compiled and submitted. All steps executed in correct 10 14.1±3.9 18.8±3.2 0.2±0.0 0.5±0.3 33.7±6.4 DAG order, completing with Succeeded 3/3. 50 64.6±10.8 21.5±3.9 0.9±0.1 2.4±1.3 89.4±13.7 100 127±7 27.7±4.0 1.8±0.4 5.2±2.0 162±8 Real GPU allocation: A mission plan with a CUDA con500 641±16 68.4±6.1 11.2±6.5 28.4±7.7 749±19 tainer (nvidia/cuda:13.0.0-base-ubuntu22.04) was compiled 1000 1323±36 115±5 20.9±9.2 62.7±14.5 1522±44 and submitted using DRA via the gpu.nvidia.com DeviceClass. The GPU step executed nvidia-smi, confirming RTX 5080 alis a performance reference and equivalence oracle, not a location (16,303 MiB, CUDA 13.0, Driver 580.126). Workflow rejected design. completed Succeeded 3/3. GPU path comparison: The same CUDA container was C. Defense-in-Depth Analysis submitted twice: once with a DRA ResourceClaim (output: Whereas Table IV in Section V-A shows specific example PATH=GPU, RTX 5080 detected) and once without (output: errors for each constraint category, Table VI below summarizes, PATH=CPU-FALLBACK, no GPU device). This shows that DRA for eight representative constraint categories, which layer claims control GPU device visibility and that the runtime catches each independently of the example workload. Three fallback path works end-to-end. of the eight are enforced by both layers; the structural Rules 1 Kueue quota contention: Two CPU Jobs (priority 90 and 50) and 2 (mission_id, event count) are two further schema–policy were submitted simultaneously to a ClusterQueue with CPU overlaps not tabulated in this event/service/step-level subset. quota 4. Each requested 3 CPUs (combined 6>4), so Kueue If the schema layer were removed, seven of eight constraint admitted the first and suspended the second. Upon completion, categories would still be caught by policy. If the policy layer the second was automatically admitted within 1 second. Both were removed, four semantic constraints (GPU fallback, CPU completed successfully. acceleration contradiction, priority validation, and landscape type) would go unchecked. E. DRA-Backed GPU Admission on a Live Cluster To demonstrate that Kueue-rendered Job artifacts compose TABLE VI correctly with the DRA path on a recent stable Kueue release, D EFENSE - IN -D EPTH : S CHEMA VS . P OLICY OVERLAP we ran a quota-and-admission experiment that exercises both Constraint Sch. Pol. Both layers (DRA device binding by the scheduler and ClusterQueue quota accounting by Kueue) on a single-device GPU queue. ACQ needs instrument ✓ – – DL no services ✓ ✓ ✓ Setup: The experiment ran on a single-node host kubeadm DL needs visibility ✓ ✓ ✓ Kubernetes v1.36.1 cluster with one NVIDIA GeForce GT 1030 ✓ ✓ ✓ Service ≥1 step device, Cilium CNI, Multus secondary CNI, and the NVIDIA GPU/FPGA needs fallback – ✓ – DRA driver [12], which NVIDIA donated to the Cloud CPU contradicts accel – ✓ – Native Computing Foundation at KubeCon EU 2026 [42]; the Priority ̸= 0 – ✓ – Landscape recognized – ✓ – GT 1030 is used purely as a DRA-allocatable device whose role is to exercise Kueue’s quota-and-binding cycle (no GPUcompute workload is run against it). The same physical host D. Live Cluster Validation previously ran the experiments in Section V-D at Kubernetes We validated rendered artifacts on a live single-node v1.35.1 with an RTX 5080; reproducing the experiment in K8s v1.35.1 cluster (8 CPU, 32 GiB, NVIDIA RTX 5080 GPU) this subsection requires only Kubernetes v1.36.1 and a single running Argo v4.0.1 and Kueue v0.17.0. Four experiments are DRA-allocatable GPU. Kueue v0.17.3 [6], [7] ran with the reported in this subsection; a fifth experiment, exercising the DRAExtendedResources and DynamicResourceAllocation feature TABLE V P HASE -W ISE C OMPILATION T IME ( MS , MEAN ± STD )

gates enabled on the controller-manager and a Configuration ConfigMap whose deviceClassMappings entry bound the DRA DeviceClass gpu.nvidia.com to a logical resource name dra. gpu.nvidia.com [11]. A ClusterQueue was provisioned covering cpu, memory, and dra.gpu.nvidia.com, with nominalQuota of one GPU. Methodology: Two Kubernetes Jobs were submitted simultaneously to the LocalQueue backing the ClusterQueue. Each Pod declared a resourceClaims entry pointing to a singleGPU ResourceClaimTemplate and a container that referenced the claim via resources.claims; the template requested one device from deviceClassName:gpu.nvidia.com. We checked four properties: (i) at most one non-Finished Workload is in Admitted=True at any time (the Admitted status is monotone and persists after Finished=True; quota release is bound to Finished, not to clearing Admitted); (ii) the second Workload remains pending until quota is released; (iii) Kueue accounts the allocation against the deviceClassMappings logical resource so flavorsUsage[dra.gpu.nvidia.com]=1; (iv) upon completion of the first Job, the queued Workload transitions to Admitted=True without operator intervention, the DRA driver instantiates a fresh ResourceClaim (state=allocated, reserved), and the second Job runs to completion. Results: Both Jobs were accepted by the API server. At submission both Workloads were Suspended (pending=2,admitted=0); within ∼10 seconds Kueue admitted one (pending=1, admitted=1,flavorsUsage[dra.gpu.nvidia.com]=1). The first Job logged job-1 starting at 18:04:15 and job-1 done at 18:04:45; the queued Workload then transitioned to Admitted=True after a ∼5-second cascade gap (wall-clock between job-1 container exit and job-2 container start; not decomposed by stage), with a freshly created ResourceClaim bound to the GT 1030. The second Job logged job-2 starting at 18:04:50 and job-2 done at 18:05:20. Final state: both Workloads Admitted=True,Finished=True; both Jobs Complete 1/1. All four properties held without manual reconciliation. Scope of this result: What was validated is the explicit DRA Template Path: a per-Pod ResourceClaim created from a ResourceClaimTemplate, its quota accounted via deviceClass Mappings, and the admission cascade triggered on first-Job completion. The experiment does not measure scheduling fairness beyond two contestants and does not exercise multiclass device flavors (e.g., mixed FPGA+GPU). The setup is for Kueue v0.17.3; in v0.18 the corresponding gates were renamed to KueueDRAIntegration (Beta, default-on) and Kueue DRAIntegrationExtendedResource (Alpha, default-off), with the legacy DynamicResourceAllocation/DRAExtendedResources names deprecated and locked-to-default in v0.18 and scheduled for removal in v0.19 [11]. Section V-F re-validates the renderer against the renamed KueueDRAIntegration gate on v0.18.3 and extends this single-class result to a unified GPU+CPU quota with a scheduler-level accelerator fallback. Reproducibility: The Configuration patch, ClusterQueue+ LocalQueue+ResourceFlavor, ResourceClaimTemplate, and the two-Job manifest are committed at manifests/k8s/kueue/ dra-paper-test/ as files 00 through 03, with the captured ex-

perimental output in docs/experiments/2026-06-09-dra-quotacascade-output.md. The deterministic CPU pipeline checks (schema, policy, render, Argo submit and completion, Kueue Job render and admission, Kueue Job completion) are exercised by scripts/validate_live_cluster.sh on the CPU mission plan configs/mission_plans/validation_live_cluster.yaml, returning PASS: 13 FAIL: 0. F. Unified GPU+CPU DRA and Scheduler-Level Fallback The Section V-E experiment counted a single GPU device class under one ClusterQueue. This subsection extends that result in three directions on the same host after upgrading Kueue to v0.18.3 [8] (Kubernetes v1.36.1, one NVIDIA Quadro K2200 in the single-DRA-allocatable-GPU role of Section V-E, and kubernetes-sigs/dra-driver-cpu [9] publishing a dra.cpu DeviceClass): (i) a unified quota that counts a CPU device class alongside the GPU class; (ii) a scheduler-level accelerator fallback that replaces the runtime environmentvariable switch of Section V-D; and (iii) the empirical boundary between them. On v0.18.3 the DRA integration is governed by the KueueDRAIntegration gate (Beta, default-on), so no explicit feature-gate flag is required; this re-validates the renderer against the renamed gates that Section V-E left open. Unified quota (both classes counted). We extended the Configuration deviceClassMappings to bind gpu.nvidia.com to dra.gpu.nvidia.com and dra.cpu to a second logical resource dra.cpu, and provisioned a ClusterQueue covering both plus cpu and memory. Two Jobs each claiming one dra.cpu device through an exactly request reproduced the Section V-E cascade for the CPU class: Kueue admitted the first (flavorsUsage[ dra.cpu]=1) and gated the second with the explicit reason “insufficient unused quota for dra.cpu . . . 1 more needed,” then cascade-admitted it on completion. The GPU cascade of Section V-E reproduced identically on v0.18.3 (flavorsUsage[ dra.gpu.nvidia.com]=1). Each accelerator class thus carries its own logical quota under a single ClusterQueue, subject to the boundary below. Scheduler-level fallback (firstAvailable). Kubernetes DRA expresses “prefer GPU, else CPU” declaratively through a firstAvailable ResourceClaim request—a prioritized subrequest list that graduated to stable in Kubernetes v1.36 (KEP4816 [10]). This is a scheduler-level decision, in contrast to the Section V-D runtime switch in which the container inspects an environment variable at start-up. Two identical plain Pods, each referencing one firstAvailable[gpu.nvidia. com,dra.cpu] claim, demonstrated the fallback: the first bound the K2200 (device=gpu-0, driver gpu.nvidia.com) and the second, finding the GPU taken, fell back to a CPU device (device=cpudevnuma000, driver dra.cpu)—same specification, the scheduler choosing. The compiler emits this claim under an opt-in --dra-fallback flag for a step whose primary and fallback resource classes are both driver-backed; FPGA is deliberately excluded, as no FPGA DRA driver exists. Upstream KEP-4816 examples prioritize tiers within one GPU driver; we did not find an upstream example demonstrating this cross-

driver GPU→CPU form, so it is an application the specification permits rather than one it illustrates. The boundary (firstAvailable is not admissible under Kueue). Kueue quota counting supports only exactly device requests [11]. Submitting the same firstAvailable claim as a Kueue Job makes the boundary concrete: Kueue rejects the Workload as Inadmissible (QuotaReserved=False, reason= Inadmissible) with the message “ResourceClaimTemplate . . . : FirstAvailable device selection is not supported”; the Job stays Suspended and nothing is quota-counted. We observed the identical rejection on both Kueue v0.17.3 and v0.18.3, so it is a property of the integration rather than of one release. The two mechanisms are therefore disjoint under current Kueue: the scheduler-level firstAvailable fallback lives off the admission path (a plain Pod or the Argo route), while a Kueue-admitted Job uses an exactly claim. The renderer reflects this boundary: for a Kueue Job it emits an exactly gpu.nvidia.com claim (which Kueue quota-counts) and never a firstAvailable claim; applying the renderer’s --dra-fallback output to the live queue yielded an admitted, quota-counted Workload (Admitted=True), confirming the path end-to-end. Reproducibility. The Configuration patch, ClusterQueue, both ResourceClaimTemplates, and the three demonstrations (unified CPU cascade, firstAvailable fallback Pods, and firstAvailable-under-Kueue rejection) are committed at manifests/k8s/kueue/dra-unified/, with captured output under results-v0.18.3-20260716/. The dra-driver-cpu install carries a documented kubelet-root-dir path fix—a local workaround for a Helm-chart limitation that remains open upstream. G. Test Suite and Static Validation The test suite spans every stage of the pipeline (schema validation, policy evaluation, compilation, rendering both sequential and parallel, the command-line interface, MCP tools and security, interface contracts, continuous integration, and Docker) and exercises all ten policy rules directly: the in-process baseline reproduces OPA’s accept/reject decision across the entire ablation corpus, so every rule is checked at the decision level rather than only by line execution. In a fresh environment lacking OPA or a live cluster, the OPA- and cluster-dependent cases skip and the remainder pass; the full suite passes with the local OPA binary and a live single-node kubeadm cluster. Continuous integration runs the suite as a merge gate. Golden evaluation fixtures verify end-to-end compilation correctness by comparing actual WorkflowIntent output against expected JSON. Rendered Argo Workflow YAML is validated by argo lint [22] locally; CI runs Python-based manifest structure checks when the Argo CLI is unavailable. H. Security MCP path traversal protection is tested with six attack vectors including absolute paths, .. traversal, directory components, and prefix bypass. OPA subprocess timeout is tested for CWE400 mitigation.

VI. L IMITATIONS AND F UTURE W ORK FPGA, mixed-accelerator, and multi-class DRA policies remain future work; DRA-backed GPU admission with singledevice quota is documented in Section V-E. All test mission plans were author-constructed; validation against real satellite operator mission plans would strengthen external validity. The system does not implement radiation hardening, full high availability (HA), or over-the-air (OTA) update guarantees, and does not implement security controls in the NIST SP 800-53 sense (Section II-B); it complements onboard platforms rather than replacing them. Because landscape_type is optional (Section III-H, Rule 10), a service that omits it while nonetheless depending on landscape context is admitted by both layers— the omission is indistinguishable at compile time from “not applicable,” and catching it would require runtime context the ground-side compiler lacks. ORCHIDE’s archival paper [41] identifies its own ground-side SDK as ongoing work. Accelerator fallback and Kueue admission.: The schedulerlevel firstAvailable fallback and Kueue quota accounting are disjoint under current Kueue (Section V-F): Kueue rejects a firstAvailable claim as Inadmissible and quota-counts only exactly requests, so expressing accelerator fallback and Kueue quota within a single claim awaits upstream Kueue support. The CPU DRA path depends on kubernetes-sigs/ dra-driver-cpu [9], which is pre-beta, and on a local kubeletroot-dir workaround for a Helm-chart limitation still open upstream; these are integration constraints of the current driver ecosystem rather than properties of the compiler. The crossdriver GPU→CPU firstAvailable form, while permitted by KEP-4816, is not illustrated by upstream examples, so its portability across DRA drivers remains to be established. Generalization beyond ORCHIDE.: The framework treats ORCHIDE as the inaugural case study, not as a hard coupling. The Pydantic schema, the Rego policy package, and the Argo/Kueue renderer are independent modules; another operator’s plan format can replace the schema, that operator’s flight rules can replace or augment the policy package, and an alternative onboard runtime (for example, MicroShift [31] Jobs on AxDCU-1-class hardware, or raw CWL via Calrissian [27] for an EOEPCA-aligned deployment) can replace the renderer without disturbing the compilation pipeline. The author-imposed safety rules (rows marked ‘A’ in Table II) are designed to carry over directly (priority bounds, fallbackclass requirements, and CPU/accelerator-coherence checks are not ORCHIDE-specific), though no second renderer is yet demonstrated, so this modularity is a design property, not an evaluated result. Unlike admission-time validators (OPA Gatekeeper [24], or Kubernetes-native CEL admission policies) that check rendered Kubernetes objects at API-server admission, this compiler checks mission-plan domain semantics before any Kubernetes object exists; the two are complementary. VII. C ONCLUSION We presented an open-source ground-side compiler that addresses the mission plan validation and compilation gap identified in onboard satellite platforms like ORCHIDE.

The system applies OPA/Rego policy-as-code and Kueuecompatible rendering to satellite mission plans, producing Argo Workflow and Kueue Job artifacts verified through static lint checks and live cluster submission. A case study demonstrated that the layered validation approach catches both structural errors (at schema parse time) and semantic violations (via OPA policy), with end-to-end compilation scaling nearlinearly (parse-dominated at scale) from 34 ms (10 events) to 1.5 s (1000 events). The tool is available under EUPL-1.2 at https://github.com/thc1006/satellite-mission-compiler (tag v0.4.2, DOI 10.5281/zenodo.21228150). ACKNOWLEDGMENT This work was supported in part by the Center for Intelligent Team Robotics and Human-Robot Collaboration under the “Top Research Centers in Taiwan Key Fields Program” of the Ministry of Education (MOE), Taiwan, and in part by the National Science and Technology Council, Taiwan, under grants 115-2221-E-A49-004 and 115-2640-E-011-003. R EFERENCES [1] A. K. Hankache and S. Weisz, “Bringing cloud-native PaaS to space: Onboard edge computing for satellites,” presented at KubeCon + CloudNativeCon Europe, Amsterdam, Mar. 2026. [2] ORCHIDE Consortium, “Overall ORCHIDE solution architecture and design,” Horizon Europe Project #101135595 deliverable D3.1, issue 003, Jul. 2024. [3] ORCHIDE Consortium, “State of the art of edge computing orchestration and unikernels technologies,” Horizon Europe Project #101135595 deliverable D2.2, May 2024. [4] A. K. Hankache, A. Castanie, L. R. Medina, V. Robles, and S. Weisz, “Onboard data processing orchestrator,” presented at the 2nd European Data Handling & Data Processing Conference (EDHPC 2025), ESA/ESTEC, Elche, Spain, Oct. 13–17, 2025. [Online]. Available: https://indico.esa.i nt/event/552/contributions/11150/ [5] T. Hinrichs, T. Sandall, and T. Koponen, “Open Policy Agent,” CNCF Graduated Project. [Online]. Available: https://www.openpolicyagent.org/ [6] A. Gharaibeh and A. Culquicondor, “Kueue: Kubernetes-native job queueing,” Kubernetes SIGs. [Online]. Available: https://kueue.sigs.k8s.io/ [7] Kubernetes SIGs, “Release v0.17.3,” Kueue GitHub release, May 2026. [Online]. Available: https://github.com/kubernetes-sigs/kueue/releases/ta g/v0.17.3 [8] Kubernetes SIGs, “Release v0.18.3,” Kueue GitHub release, July 2026. [Online]. Available: https://github.com/kubernetes-sigs/kueue/releases/ta g/v0.18.3 [9] Kubernetes SIGs, “dra-driver-cpu: a Dynamic Resource Allocation driver for CPUs,” GitHub repository. [Online]. Available: https://github.com/k ubernetes-sigs/dra-driver-cpu [10] Kubernetes, “KEP-4816: DRA: Prioritized Alternatives in Device Requests,” Kubernetes Enhancements (Stable in Kubernetes v1.36). [Online]. Available: https://github.com/kubernetes/enhancements/tree/master/keps/ sig-scheduling/4816-dra-prioritized-list [11] Kubernetes SIGs, “Dynamic Resource Allocation (DRA) with ExtendedResources,” Kueue documentation. [Online]. Available: https: //kueue.sigs.k8s.io/docs/concepts/dynamic_resource_allocation/ [12] Kubernetes SIGs, “DRA driver for NVIDIA GPUs,” open-source project (previously at https://github.com/NVIDIA/k8s-dra-driver-gpu, relocated to the kubernetes-sigs organization in 2026). [Online]. Available: https: //github.com/kubernetes-sigs/dra-driver-nvidia-gpu [13] Volcano Community, “Volcano: A cloud native batch system for highperformance workloads,” CNCF Incubating Project. [Online]. Available: https://volcano.sh/ [14] Y. Xiong, Y. Sun, L. Xing, and Y. Huang, “Extend cloud to edge with KubeEdge,” in Proc. IEEE/ACM Symp. Edge Computing (SEC), 2018. [15] Z. Zhao, J. Wu, S. Su, W. Zhu, and Y. Gao, “KubeSpace: A lowlatency and stable control plane for LEO satellite container orchestration,” arXiv:2601.21383, Jan. 2026.

[16] V. Bhosale, A. Gavrilovska, and K. Bhardwaj, “Krios: Scheduling abstractions and mechanisms for enabling a LEO compute cloud,” in Proc. ACM Symp. Cloud Computing (SoCC), 2024. [17] T. Pfandzelter and D. Bermbach, “Komet: A serverless platform for low-Earth orbit edge services,” in Proc. ACM Symp. Cloud Computing (SoCC), 2024. arXiv:2410.05973. [18] Nubificus, “urunc: A lightweight OCI-compatible unikernel runtime,” CNCF Sandbox Project. [Online]. Available: https://github.com/uruncdev/urunc [19] S. Colvin, “Pydantic: Data validation using Python type annotations.” [Online]. Available: https://docs.pydantic.dev/ [20] Anthropic, “Model Context Protocol specification.” [Online]. Available: https://modelcontextprotocol.io/ [21] J. Lowin, “FastMCP: A Python framework for MCP servers.” [Online]. Available: https://gofastmcp.com/ [22] Argo Project, “Argo Workflows: Container-native workflow engine for Kubernetes,” CNCF Graduated Project. [Online]. Available: https://argo proj.github.io/ [23] Rancher Labs, “K3s: Lightweight Kubernetes.” [Online]. Available: https: //k3s.io/ [24] Open Policy Agent, “Gatekeeper: Policy controller for Kubernetes.” [Online]. Available: https://open-policy-agent.github.io/gatekeeper/ [25] NIST, “Security and privacy controls for information systems and organizations,” NIST SP 800-53 Rev. 5, Sep. 2020. [26] R. Braden, “Requirements for Internet hosts,” RFC 1123, IETF, Oct. 1989. [27] ESA, “EOEPCA+: Earth Observation Exploitation Platform Common Architecture.” [Online]. Available: https://eoepca.org/ [28] Kratos Defense, “OpenSpace platform for multi-mission ground systems.” [Online]. Available: https://www.kratosdefense.com/ [29] CCSDS, “Mission planning and scheduling,” Green Book, CCSDS 529.0G-1, Jun. 2018. [Online]. Available: https://ccsds.org/Pubs/529x0g1.pdf [30] T. Fruth, C. Lenzen, E. Gross, and F. Mrowka, “The EnMAP mission planning system,” in Space Operations: Inspiring Humankind’s Future, Springer, 2019. [31] Red Hat, “Red Hat teams up with Axiom Space to launch, optimize the space company’s Data Center Unit-1 on orbit,” press release, Mar. 6, 2025. [Online]. Available: https://www.redhat.com/en/about/press-releases/redhat-teams-axiom-space-launch-optimize-axiom-spaces-data-centerunit-1-orbit [32] Kepler Communications, “Kepler deploys first space-based, scalable cloud infrastructure powered by NVIDIA,” press release, Mar. 16, 2026. [Online]. Available: https://kepler.space/kepler-deploys-first-space-basedscalable-cloud-infrastructure-powered-by-nvidia/ [33] L. G. Gutierrez, J. A. Tejo, A. Cendrero, M. Pereda, J. Saiz, C. Hernandez, D. de Miguel, and T. W. Beech, “Off-the-shelf mission planning is possible: FlexPlan does it,” in Proc. 2005 IEEE Aerospace Conference, Big Sky, MT, USA, Mar. 2005. DOI: 10.1109/AERO.2005.1559706. [34] M. Maimone, S. Maxwell, J. Biesiadecki, and S. Algermissen, “RPcheck: an architecture for spaceflight command sequence validation,” in Proc. IEEE Aerospace Conference, Big Sky, MT, USA, 2018. [Online]. Available: https://ieeexplore.ieee.org/document/8396785/ [35] OpenC3, “COSMOS open-source mission-operations framework,” Enterprise edition documentation (Helm/K8s deployment). [Online]. Available: https://openc3.com/enterprise/ [36] NASA Office of Safety and Mission Assurance, “Software assurance and software safety standard,” NASA Technical Standard NASA-STD8739.8B, Sep. 2022. [Online]. Available: https://standards.nasa.gov/stand ard/NASA/NASA-STD-87398 [37] N. G. Leveson, Engineering a Safer World: Systems Thinking Applied to Safety. Cambridge, MA, USA: MIT Press, 2011. [38] ORCHIDE Consortium, “Communication plan (D6.1),” Horizon Europe Project #101135595 deliverable, May 2024. [Online]. Available: https: //orchide-project.eu/deliverables/orchide-d6.1.pdf [39] ORCHIDE Consortium, “Website and dissemination tools (D6.2),” Horizon Europe Project #101135595 deliverable, May 2024. [Online]. Available: https://orchide-project.eu/deliverables/orchide-d6.2.pdf [40] S. Weisz, “ORCHIDE: using EOS for space edge computing,” CERN Indico EOS 2026 Workshop, Mar. 11, 2026. [Online]. Available: https: //indico.cern.ch/event/1622471/contributions/6910807/ [41] S. Weisz et al., “ORCHIDE: Bringing Unikernels to an Orchestrator near You,” Future Internet, vol. 18, no. 6, p. 299, Jun. 2026. DOI: 10.3390/fi18060299.

[42] J. Boitano, “Advancing Open Source AI, NVIDIA Donates Dynamic Resource Allocation Driver for GPUs to Kubernetes Community,” NVIDIA Blog, Mar. 24, 2026. [Online]. Available: https://blogs.nv idia.com/blog/nvidia-at-kubecon-2026/ [43] ORCHIDE Consortium, “Creating unikernel data processing workflows,” ORCHIDE YouTube channel (@ORCHIDE-EU), Jun. 18, 2026. [Online]. Available: https://www.youtube.com/watch?v=JFOWgbJRvXQ (accessed Jun. 2026) [44] J. Zhang, J. Sun, K. Liu, L. Kuang, and J. Lu, “YUHENG-OS: A cloudnative space cluster operating system,” arXiv:2603.27946, Mar. 2026. [45] A. K. Erol and D. Mahajan, “Equinox: Decentralized scheduling for hardware-aware orbital intelligence,” arXiv:2604.19958, Apr. 2026. [46] H. Tabatabaee Malazi, R. Farahani, N. Mohan, and S. Dustdar, “Orchestrating serverless applications in the edge cloud space continuum: What breaks and what is next?,” arXiv:2605.04316, May 2026. [47] M. Tejedor, M. Grossi, C. Tüysüz, R. Rocha, and S. Vallecorsa, “Kubernetes-orchestrated hybrid quantum-classical workflows,” arXiv:2603.24206, Mar. 2026. [48] R. Farahani, M. Colosi, I. Murturi, S. Nastic, M. Villari, S. Dustdar, and R. Prodan, “ClusterLess: Deadline-aware serverless workflow orchestration on federated edge clusters,” arXiv:2605.04310, May 2026. [49] H. Kim, A. Das, S. Ghosh, A. Raha, and V. Raghunathan, “BIDENT: Heterogeneous operator-level mapping for efficient edge inference,” arXiv:2606.05271, Jun. 2026. [50] B. Soret, A. M. Mercado-Martínez, A. Jurado-Navas, N. D. Lyholm, M. Moretti, P. Popovski, and I. Leyva-Mayorga, “Edge intelligence for satellite-based Earth observation: Scheduling image acquisition and processing,” arXiv:2604.05937, Apr. 2026. [51] P. L. Foalem, F. Khomh, L. Da Silva, and E. Merlo, “An empirical study of policy-as-code adoption in open-source software projects,” arXiv:2601.05555, Jan. 2026.