Pith. sign in

REVIEW 2 major objections 5 minor 51 references

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

T0 review · 2 major / 5 minor · reviewed 2026-08-02 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A four-stage open-source compiler validates satellite mission plans with schema and policy-as-code rules, then renders them as Argo and Kueue artifacts for onboard cloud-native runtimes.

desk verdict A solid, unusually honest engineering paper whose central ORCHIDE-interop claim is a reconstruction, not a verified fact; the live DRA/Kueue results are the real contribution and stand on their own. read the letter →

arxiv 2607.14798 v1 pith:2FPOYC4V submitted 2026-07-16 cs.DC

Hsiu-Chi Tsai , Chia-Tung Chung This is my paper · ORCID
classification cs.DC
keywords satellitemissionplanningcloud-nativepolicy-as-codeOPA/RegoArgoWorkflowsKueueDynamicResourceAllocationORCHIDE
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper claims the missing piece for cloud-native satellite operations is ground-side: onboard runtimes execute workflow artifacts, but nothing open-source turns a human-authored mission plan into validated artifacts. The Satellite Mission Compiler fills that gap with four stages: parse against a Pydantic schema, evaluate ten OPA/Rego deny rules, compile to a typed WorkflowIntent IR, and render Argo Workflow DAGs plus Kueue Jobs with Dynamic Resource Allocation. If correct, operators can reject malformed plans before uplink, classify pre-uplink loss events into four severity tiers, and submit artifacts that run on live clusters. Live experiments show a DRA-backed GPU admission cascade on Kueue v0.17.3 and v0.18.3, and a scheduler-level GPU-to-CPU fallback that Kueue itself cannot admission-count. The author-imposed rules are flagged separately from rules traced to ORCHIDE public documents.

What carries the argument

The central mechanism is the four-stage pipeline. Stage 1 parses the mission plan against a Pydantic v2 schema derived from public ORCHIDE materials, enforcing timezone-aware timestamps, instrument presence, and structural integrity. Stage 2 evaluates ten OPA/Rego deny rules covering mission integrity, safety, and ORCHIDE-derived download semantics, with provenance tags distinguishing inherited from author-imposed rules. Stage 3 compiles validated plans into a typed WorkflowIntent IR with resource hints and RFC 1123 workflow names. Stage 4 renders Argo Workflow DAGs and Kueue Jobs with DRA ResourceClaim support, plus six MCP tools for agents.

What would settle it

Release of ORCHIDE's authoritative mission-plan schema or its deployment interface would settle the claim: if the actual event structure, priority direction, or fallback semantics differ from this reconstruction, the emitted Argo and Kueue artifacts would not be consumable by the onboard Workflow Manager. Until then, comparing a compiled artifact against a real ORCHIDE deployment is the decisive experiment.

Watch

Extended reading notes

Core claim

On the paper's own terms, the discovery is that the ground-side compilation gap for onboard cloud-native satellite runtimes is closable by a schema-first, policy-checked, IR-based pipeline. The compiler takes a mission plan, validates it structurally and semantically, compiles validated plans into a typed WorkflowIntent intermediate representation, and renders the artifacts onboard runtimes consume. The paper also claims this design is generalizable: the schema, policy package, and renderers are independent modules, with ORCHIDE as the inaugural case study.

Load-bearing premise

The load-bearing premise is that the mission-plan schema and the ten deny rules reconstructed from public ORCHIDE materials match the real deployment interface, including the undeclared direction of the onboard priority scale.

Editorial extensions

If this is right

  • Operators can reject malformed mission plans on the ground before uplink, with four severity tiers tied to specific schema and policy checks.
  • Validated plans compile to Argo Workflow DAGs and Kueue Job manifests, removing hand-written manifest work and giving onboard runtimes the artifacts they expect.
  • DRA-backed GPU admission with quota counting works on a live Kubernetes cluster with Kueue v0.17.3 and re-validates on v0.18.3, including a unified GPU+CPU device-class quota.
  • A scheduler-level firstAvailable claim gives GPU-to-CPU fallback on plain Pods, but Kueue rejects such claims as Inadmissible, so accelerator fallback and Kueue quota cannot currently be combined in one Job.
  • Six MCP tools let AI agents validate, compile, render, explain policy, diff plans, and check timeline conflicts through a path-traversal-protected interface.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If ORCHIDE's authoritative schema matches this reconstruction, the same pipeline's modularity suggests it could be retargeted to other onboard runtimes by swapping only the renderer; the paper states this design property but does not demonstrate a second renderer.
  • The Kueue firstAvailable rejection points to a concrete upstream feature — quota accounting for prioritized device claims — without which admission-gated accelerator fallback remains impossible inside Kueue.
  • The four-tier loss-event classification is a pre-uplink risk model, not measured flight outcomes; a full STPA hazard analysis would be the natural formal successor, a step the paper leaves future.
  • The MCP tools expose the pipeline to autonomous agents, but the demonstrated loop uses a pre-authored corrected plan; an agent that actually synthesizes repairs is a testable next step.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

2 major / 5 minor

Summary. The paper presents Satellite Mission Compiler, a four-stage open-source pipeline that takes a human-authored satellite mission plan, validates it against a Pydantic schema and an OPA/Rego policy package of ten deny rules, compiles it into a typed WorkflowIntent intermediate representation, and renders Argo Workflow DAGs and Kueue Job manifests with Dynamic Resource Allocation (DRA) support. The stated target is the artifact formats consumed by onboard cloud-native runtimes such as the EU ORCHIDE project. Validation includes golden translation fixtures, argo lint, an in-process baseline that reproduces OPA decisions, and live single-node cluster experiments: a DRA-backed GPU admission cascade on Kueue v0.17.3 and v0.18.3, a unified GPU+CPU device-class quota, and a scheduler-level firstAvailable accelerator fallback. The implementation is released under EUPL-1.2 with committed manifests and captured outputs.

Significance. If the claims hold, the main contribution is a reproducible, open-source reference implementation for ground-side, policy-checked generation of Kubernetes-native workflow artifacts from satellite mission plans. The strongest parts are the live-cluster experiments against real Kueue/DRA/NVIDIA drivers, the committed reproducibility artifacts, the explicit provenance tags distinguishing ORCHIDE-derived rules from author-imposed rules, and the unusually honest limitation statements. The live DRA quota-and-admission cascade is valuable independently of ORCHIDE compatibility. The central 'fills the ORCHIDE ground-side gap' claim is weakened by the unverified reconstruction of ORCHIDE's mission-plan interface, but the engineering substrate and the reported experiments are sound enough that the issue is fixable by validation or by reframing the claims.

major comments (2)
  1. [Abstract, §II-A, §III-F, §VI] The paper's strongest claim — that the compiler produces 'the container-workflow artifacts that cloud-native satellite runtimes consume' and specifically fills the ORCHIDE ground-side gap — rests on an unverified reconstruction of ORCHIDE's mission-plan interface. Section II-A lists D3.2, D4, D5, and D7 as confidential; Section III-F concedes that the orbital/orchide-priority annotation and its 1=highest interpretation are 'this paper's proposal pending disclosure of the deployment interface.' Yet Listing 3 emits this annotation into every rendered Workflow, and Rule 4 enforces a fallback requirement that ORCHIDE's published materials 'do not specify how an Orchestrator ought to act on.' If ORCHIDE's IF_SO_MIS_DP interface uses different field names, value scales, or priority direction, the emitted artifacts will not be consumable by ORCHIDE's Workflow Manager. Section VI further acknowl
  2. [§III-H, Table III, Abstract] The severity-tier classification is presented in the abstract as a contribution ('classify pre-uplink loss events into four severity tiers'), but the paper itself states that the in-orbit consequences are 'derived from ORCHIDE's published Deferred-Phase semantics rather than measured on the onboard runtime' and that the tiers are 'a mechanistically grounded pre-uplink risk model, not empirically measured outcomes.' This is an analytical/consequence-oriented model, not an experimentally validated one. The distinction should be made explicit at every point where the tiers are summarized, including the abstract, so that readers do not mistake the T1–T4 labels for observed failure data. The underlying checks remain useful, but the 'loss event' language should not imply empirically demonstrated in-orbit outcomes.
minor comments (5)
  1. [§V-B] The in-process baseline is correctly called an 'equivalence oracle' because it re-implements the same ten rules. I suggest also describing it as a consistency check in the evaluation summary, so it is not read as independent validation of the policy rules against ORCHIDE semantics.
  2. [§III-C and §III-G] Please reconcile the DRA history. Section II-C says baseline DRA integration with the ResourceClaim Template path shipped as alpha in Kueue v0.14.0, while Section III-G says 'Kueue v0.17.0 introduced alpha-level DRA support.' The intended meaning is presumably 'the extended-resources path,' but the current wording could confuse a reader about which DRA path was introduced when.
  3. [§V-D and §V-E] The experiments use a single-node host kubeadm cluster with consumer GPUs. The paper does not claim an ORCHIDE onboard stack, but it would help to state in Section V-D that all live experiments validate Kubernetes-level artifact consumption only, and that ORCHIDE-specific annotation consumption was not tested.
  4. [§III-F, Listing 3] Consider adding a footnote or annotation marker in Listing 3 next to orbital/orchide-priority indicating that this key and its direction are proposed pending ORCHIDE interface disclosure. This would prevent a reader from treating the rendered manifest as an authoritative ORCHIDE contract.
  5. [§VI] The statement that modularity across renderers is 'a design property, not an evaluated result' is appreciated and should also appear in the conclusion or abstract, since the abstract's 'such as ORCHIDE' phrasing might be read as a demonstrated multi-runtime claim.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity found: the paper's rules, schema, and validation are transparently sourced, with author-imposed rules and unverified ORCHIDE-schema assumptions explicitly labeled as such; live-cluster benchmarks against independent runtimes anchor the central claims.

full rationale

The paper is a systems/engineering contribution whose derivation chain is self-contained and honestly labeled at every step where circularity could have crept in. (1) There is no self-citation chain at all: none of the 51 references is authored by Tsai or Chung, so patterns 3-5 (self-citation load-bearing, uniqueness imported from authors, ansatz smuggled via citation) do not apply. (2) The ten Rego rules are not fitted to any outcome; they are design constraints explicitly partitioned by provenance, with author-imposed rules tagged 'A' and ORCHIDE-traceable rules tagged 'D' (Table II), and the paper states that the fallback rule 'is an author-imposed rule, not an ORCHIDE-inherited requirement.' (3) The one place where the paper makes an assumption about ORCHIDE's interface — the priority-direction translation ('taking 1 as the highest priority... since ORCHIDE's public materials document the 1-4 scale but not its direction') — is explicitly disclaimed: 'this paper's proposal pending disclosure of the deployment interface.' That is an honest external-validity caveat, not an ansatz presented as derived. (4) The severity tiers are framed as a 'mechanistically grounded pre-uplink risk model that motivates the admission gate, not empirically measured outcomes,' so no consequence is presented as a prediction that could reduce to its own rule. (5) The in-process baseline 're-implements the ten rules and reproduces OPA's decision' and is candidly described as 'a performance reference and equivalence oracle, not a rejected design' — the paper never treats it as independent evidence. (6) The load-bearing validation is genuinely external: rendered artifacts are submitted to real Kueue v0.17.3/v0.18.3 clusters with Kubernetes v1.36.1, the NVIDIA DRA driver, and dra-driver-cpu, and static validity is checked by argo lint; these are independent runtimes, so the claim that the compiler emits consumable artifacts is benchmarked outside the paper's own fixtures. (7) The residual concern — that the Pydantic schema may not faithfully match ORCHIDE's confidential IF_SO_MIS_DP interface — is the inverse of circularity: the paper identifies it as an unresolved external-fidelity question (D3.2/D4/D5/D7 'remain confidential') and designs the schema as a 'pluggable boundary.' It is a correctness/external-validity risk, explicitly acknowledged, not a reduction of the derivation to its inputs. No step of the paper's argument is forced by definition, by fitted parameter, or by a sel

Assumptions & free parameters 3 free parameters · 4 assumptions · 2 invented entities

This is an engineering-systems paper; there are no fitted physical constants. The hand-chosen items are design parameters (priority bucket mapping, author-imposed policy rules, severity tiers). The load-bearing assumptions are about the unreleased ORCHIDE interface and the paper's own consequence model, both explicitly disclosed. The only invented artifacts are internal software structures and a proposed annotation whose acceptance by ORCHIDE is unverified.

free parameters (3)
  • Priority bucket boundaries (0–100 → ORCHIDE 1–4) = 76–100→1, 51–75→2, 26–50→3, 1–25→4
    Chosen by the authors; ORCHIDE documents the 1–4 scale but not its direction, so 1=highest is an assumption (Section III-F).
  • Ten deny rules in policy package = Rules 4,5,6,9 marked 'A' (author-imposed)
    Six of ten rules are author-imposed safety practice, not derived from ORCHIDE docs (Table II); they define what the compiler enforces, so the validation results are relative to these hand-chosen rules.
  • Severity-tier thresholds (T1–T4) = four tiers
    Operational classification chosen by the authors, not measured outcomes; Section III-H states the in-orbit consequences are not empirically measured.
assumptions (4)
  • domain assumption The Pydantic schema accurately represents ORCHIDE's mission-plan format from public materials; confidential deliverables D3.2/D4/D5/D7 could invalidate field names and constraints.
    Section II-A: schema derived from publicly available deliverables; confidential deliverables remain; paper states replacement is 'mechanical' if an authoritative spec arrives.
  • ad hoc to paper ORCHIDE's Workflow Manager will interpret 1 as highest priority and consume the orbital/orchide-priority annotation.
    Section III-F: 'this too is an assumption pending interface disclosure'; 'interoperation with the unreleased onboard scheduler is not verified here.'
  • domain assumption The in-orbit consequences assigned to severity tiers T1–T4 (stall, contact-window loss, AI-service drop) reflect ORCHIDE Deferred-Phase semantics.
    Section III-H: 'derived from ORCHIDE's published Deferred-Phase semantics rather than measured on the onboard runtime.'
  • domain assumption No existing open-source toolchain provides the same mission-plan→Argo+Kueue compilation path, so the gap is real.
    Section II-D/Table I compares adjacent systems; absence of a specific tool is asserted from literature review, not a formal proof of absence.
invented entities (2)
  • orbital/orchide-priority annotation
    purpose: Carry mission-plan priority from the compiler to the ORCHIDE Workflow Manager
    Proposed by this paper; no ORCHIDE public interface confirms the annotation exists; Section III-F says it is 'this paper's proposal pending disclosure of the deployment interface.'
  • WorkflowIntent IR
    purpose: Typed intermediate representation between validation and rendering stages
    Internal data structure (Section III-E); no external consumer; not a falsifiable handle outside the tool.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Ground-Side Mission Plan Compilation with Policy-as-Code Guardrails for Cloud-Native Satellite Platforms." pith.science (2026). https://pith.science/paper/2FPOYC4V

@misc{pith2026260714798,
  author       = {Pith},
  title        = {Pith review of: Ground-Side Mission Plan Compilation with Policy-as-Code Guardrails for Cloud-Native Satellite Platforms},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/2FPOYC4V}},
  note         = {Machine review of arXiv:2607.14798}
}
read the original abstract

Onboard cloud-native runtimes for satellites are emerging on multiple tracks (ORCHIDE, Axiom Space's AxDCU-1, Kepler's Jetson 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 Satellite Mission Compiler, a four-stage pipeline that addresses this gap: it takes a human-authored mission plan, checks it against machine-checkable structural and policy rules, and compiles it into the container-workflow artifacts that cloud-native satellite runtimes consume. 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 documented provenance, compiles it into a typed WorkflowIntent intermediate representation, and renders it as Argo Workflow 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) rather than the security reading (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. The compiler is released under EUPL-1.2 (DOI 10.5281/zenodo.21228150).

Figures

Figures reproduced from arXiv: 2607.14798 by the authors.

Figure 1
Figure 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: … view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

51 extracted references · 1 canonical work pages

  1. [1]

    Bringing cloud-native PaaS to space: Onboard edge computing for satellites,

    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

    2026

  2. [2]

    Overall ORCHIDE solution architecture and design,

    ORCHIDE Consortium, “Overall ORCHIDE solution architecture and design,” Horizon Europe Project #101135595 deliverable D3.1, issue 003, Jul. 2024

    2024

  3. [3]

    State of the art of edge computing orchestration and unikernels technologies,

    ORCHIDE Consortium, “State of the art of edge computing orchestration and unikernels technologies,” Horizon Europe Project #101135595 deliverable D2.2, May 2024

    2024

  4. [4]

    On- board data processing orchestrator,

    A. K. Hankache, A. Castanie, L. R. Medina, V . Robles, and S. Weisz, “On- board 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/

    2025

  5. [5]

    Open Policy Agent,

    T. Hinrichs, T. Sandall, and T. Koponen, “Open Policy Agent,” CNCF Graduated Project. [Online]. Available: https://www.openpolicyagent.org/

  6. [6]

    Kueue: Kubernetes-native job queue- ing,

    A. Gharaibeh and A. Culquicondor, “Kueue: Kubernetes-native job queue- ing,” Kubernetes SIGs. [Online]. Available: https://kueue.sigs.k8s.io/

  7. [7]

    Release v0.17.3,

    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

    2026

  8. [8]

    Release v0.18.3,

    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

    2026

Show all 51 references
  1. [9]

    dra-driver-cpu: a Dynamic Resource Allocation driver for CPUs,

    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

  2. [10]

    KEP-4816: DRA: Prioritized Alternatives in Device Re- quests,

    Kubernetes, “KEP-4816: DRA: Prioritized Alternatives in Device Re- quests,” Kubernetes Enhancements (Stable in Kubernetes v1.36). [Online]. Available: https://github.com/kubernetes/enhancements/tree/master/keps/ sig-scheduling/4816-dra-prioritized-list

  3. [11]

    Dynamic Resource Allocation (DRA) with Ex- tendedResources,

    Kubernetes SIGs, “Dynamic Resource Allocation (DRA) with Ex- tendedResources,” Kueue documentation. [Online]. Available: https: //kueue.sigs.k8s.io/docs/concepts/dynamic_resource_allocation/

  4. [12]

    DRA driver for NVIDIA GPUs,

    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

    2026

  5. [13]

    V olcano: A cloud native batch system for high- performance workloads,

    V olcano Community, “V olcano: A cloud native batch system for high- performance workloads,” CNCF Incubating Project. [Online]. Available: https://volcano.sh/

  6. [14]

    Extend cloud to edge with KubeEdge,

    Y . Xiong, Y . Sun, L. Xing, and Y . Huang, “Extend cloud to edge with KubeEdge,” inProc. IEEE/ACM Symp. Edge Computing (SEC), 2018

    2018

  7. [15]

    KubeSpace: A low- latency and stable control plane for LEO satellite container orchestration,

    Z. Zhao, J. Wu, S. Su, W. Zhu, and Y . Gao, “KubeSpace: A low- latency and stable control plane for LEO satellite container orchestration,” arXiv:2601.21383, Jan. 2026

    2026

  8. [16]

    Krios: Scheduling abstractions and mechanisms for enabling a LEO compute cloud,

    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

    2024

  9. [17]

    Komet: A serverless platform for low-Earth orbit edge services,

    T. Pfandzelter and D. Bermbach, “Komet: A serverless platform for low-Earth orbit edge services,” inProc. ACM Symp. Cloud Computing (SoCC), 2024. arXiv:2410.05973

    2024 arXiv

  10. [18]

    urunc: A lightweight OCI-compatible unikernel runtime,

    Nubificus, “urunc: A lightweight OCI-compatible unikernel runtime,” CNCF Sandbox Project. [Online]. Available: https://github.com/urunc- dev/urunc

  11. [19]

    Pydantic: Data validation using Python type annotations

    S. Colvin, “Pydantic: Data validation using Python type annotations.” [Online]. Available: https://docs.pydantic.dev/

  12. [20]

    Model Context Protocol specification

    Anthropic, “Model Context Protocol specification.” [Online]. Available: https://modelcontextprotocol.io/

  13. [21]

    FastMCP: A Python framework for MCP servers

    J. Lowin, “FastMCP: A Python framework for MCP servers.” [Online]. Available: https://gofastmcp.com/

  14. [22]

    Argo Workflows: Container-native workflow engine for Kubernetes,

    Argo Project, “Argo Workflows: Container-native workflow engine for Kubernetes,” CNCF Graduated Project. [Online]. Available: https://argo proj.github.io/

  15. [23]

    K3s: Lightweight Kubernetes

    Rancher Labs, “K3s: Lightweight Kubernetes.” [Online]. Available: https: //k3s.io/

  16. [24]

    Gatekeeper: Policy controller for Kubernetes

    Open Policy Agent, “Gatekeeper: Policy controller for Kubernetes.” [Online]. Available: https://open-policy-agent.github.io/gatekeeper/

  17. [25]

    Security and privacy controls for information systems and organizations,

    NIST, “Security and privacy controls for information systems and organizations,” NIST SP 800-53 Rev. 5, Sep. 2020

    2020

  18. [26]

    Requirements for Internet hosts,

    R. Braden, “Requirements for Internet hosts,” RFC 1123, IETF, Oct. 1989

    1989

  19. [27]

    EOEPCA+: Earth Observation Exploitation Platform Common Architecture

    ESA, “EOEPCA+: Earth Observation Exploitation Platform Common Architecture.” [Online]. Available: https://eoepca.org/

  20. [28]

    OpenSpace platform for multi-mission ground systems

    Kratos Defense, “OpenSpace platform for multi-mission ground systems.” [Online]. Available: https://www.kratosdefense.com/

  21. [29]

    Mission planning and scheduling,

    CCSDS, “Mission planning and scheduling,” Green Book, CCSDS 529.0- G-1, Jun. 2018. [Online]. Available: https://ccsds.org/Pubs/529x0g1.pdf

    2018

  22. [30]

    The EnMAP mission planning system,

    T. Fruth, C. Lenzen, E. Gross, and F. Mrowka, “The EnMAP mission planning system,” inSpace Operations: Inspiring Humankind’s Future, Springer, 2019

    2019

  23. [31]

    Red Hat teams up with Axiom Space to launch, optimize the space company’s Data Center Unit-1 on orbit,

    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/red- hat-teams-axiom-space-launch-optimize-axiom-spaces-data-cente...

    2025

  24. [32]

    Kepler deploys first space-based, scalable cloud infrastructure powered by NVIDIA,

    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-based- scalable-cloud-infrastructure-powered-by-nvidia/

    2026

  25. [33]

    Off-the-shelf mission planning is possible: FlexPlan does it,

    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,” inProc. 2005 IEEE Aerospace Conference, Big Sky, MT, USA, Mar. 2005. DOI: 10.1109/AERO.2005.1559706

    2005

  26. [34]

    RP- check: an architecture for spaceflight command sequence validation,

    M. Maimone, S. Maxwell, J. Biesiadecki, and S. Algermissen, “RP- check: 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/

    2018

  27. [35]

    COSMOS open-source mission-operations framework,

    OpenC3, “COSMOS open-source mission-operations framework,” Enter- prise edition documentation (Helm/K8s deployment). [Online]. Available: https://openc3.com/enterprise/

  28. [36]

    Software assurance and software safety standard,

    NASA Office of Safety and Mission Assurance, “Software assurance and software safety standard,” NASA Technical Standard NASA-STD- 8739.8B, Sep. 2022. [Online]. Available: https://standards.nasa.gov/stand ard/NASA/NASA-STD-87398

    2022

  29. [37]

    N. G. Leveson,Engineering a Safer World: Systems Thinking Applied to Safety. Cambridge, MA, USA: MIT Press, 2011

    2011

  30. [38]

    Communication plan (D6.1),

    ORCHIDE Consortium, “Communication plan (D6.1),” Horizon Europe Project #101135595 deliverable, May 2024. [Online]. Available: https: //orchide-project.eu/deliverables/orchide-d6.1.pdf

    2024

  31. [39]

    Website and dissemination tools (D6.2),

    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

    2024

  32. [40]

    ORCHIDE: using EOS for space edge computing,

    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/

    2026

  33. [41]

    ORCHIDE: Bringing Unikernels to an Orchestra- tor near You,

    S. Weiszet al., “ORCHIDE: Bringing Unikernels to an Orchestra- tor near You,”Future Internet, vol. 18, no. 6, p. 299, Jun. 2026. DOI: 10.3390/fi18060299

    2026 doi

  34. [42]

    Advancing Open Source AI, NVIDIA Donates Dynamic Resource Allocation Driver for GPUs to Kubernetes Community,

    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/

    2026

  35. [43]

    Creating unikernel data processing workflows,

    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)

    2026

  36. [44]

    YUHENG-OS: A cloud- native space cluster operating system,

    J. Zhang, J. Sun, K. Liu, L. Kuang, and J. Lu, “YUHENG-OS: A cloud- native space cluster operating system,” arXiv:2603.27946, Mar. 2026

    2026

  37. [45]

    Equinox: Decentralized scheduling for hardware-aware orbital intelligence,

    A. K. Erol and D. Mahajan, “Equinox: Decentralized scheduling for hardware-aware orbital intelligence,” arXiv:2604.19958, Apr. 2026

    2026 arXiv

  38. [46]

    Orches- trating serverless applications in the edge cloud space continuum: What breaks and what is next?,

    H. Tabatabaee Malazi, R. Farahani, N. Mohan, and S. Dustdar, “Orches- trating serverless applications in the edge cloud space continuum: What breaks and what is next?,” arXiv:2605.04316, May 2026

    2026 arXiv

  39. [47]

    Kubernetes-orchestrated hybrid quantum-classical workflows,

    M. Tejedor, M. Grossi, C. Tüysüz, R. Rocha, and S. Val- lecorsa, “Kubernetes-orchestrated hybrid quantum-classical workflows,” arXiv:2603.24206, Mar. 2026

    2026

  40. [48]

    ClusterLess: Deadline-aware serverless workflow orchestration on federated edge clusters,

    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

    2026 arXiv

  41. [49]

    BIDENT: Heterogeneous operator-level mapping for efficient edge inference,

    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

    2026 arXiv

  42. [50]

    Edge intelligence for satellite-based Earth observation: Scheduling image acquisition and processing,

    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

    2026 arXiv

  43. [51]

    An empirical study of policy-as-code adoption in open-source software projects,

    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

    2026

Pith tools

Reviewed August 2, 2026 · model on record in the stance chip above.