Feedback wanted on OrbitFabric: model-first mission data contracts for small spacecraft

,
1

Hi all,

I recently made public an early open-source project called OrbitFabric.

The idea is to explore a model-first mission data contract layer for small spacecraft.

It is not intended to be a flight software framework, a mission control system, a ground segment, a dynamic simulator, or a replacement for existing tools.

The problem I’m trying to address is the drift that often appears between mission design, onboard software, test scenarios, generated documentation, payload assumptions, storage/downlink expectations and ground-facing data definitions.

In practice, the same mission concepts often get duplicated in different places:

  • telemetry

  • commands

  • events

  • faults

  • modes

  • payload behavior

  • data products

  • storage expectations

  • scenario/test assumptions

  • documentation

  • ground integration assumptions

OrbitFabric tries to define these concepts once, validate them, run lightweight scenarios, generate documentation, and keep them version-controlled and CI-friendly.

The project is still early, but the current direction is already focused on mission model validation, semantic linting, scenario execution, generated docs, payload contracts, data product contracts and storage contracts.

The next area I’m working toward is contact windows and downlink flow contracts.

I’m posting here because this community is much closer to the kind of open-source space ecosystem where this idea either makes sense or should be challenged early.

I’d be very interested in feedback from people working with CubeSats, ground stations, mission operations, SatNOGS-like workflows, educational missions or open-source space tooling.

Some questions I’m trying to answer:

  • Does a lightweight mission-data contract layer solve a real problem for small spacecraft teams?

  • Would this be useful upstream of tools such as ground systems, telemetry dashboards, simulators or test pipelines?

  • Is this kind of contract layer missing in smallsat workflows, or is it usually handled well enough by existing documents and tooling?

  • What would be the most useful integration direction from an open-source space perspective?

  • What concepts are missing before this becomes genuinely useful to a CubeSat / smallsat team?

For transparency: I’m the author of the project. I’m not presenting it as a mature flight-ready system, but as an open-source framework in early public development and I’m looking for critical technical feedback.

Repository:
https://github.com/FAROTECH/orbitfabric

1 Like