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
2

Quick update on this original thread.

When I first posted OrbitFabric here, it was still an early public project and I was mainly looking for critical feedback on whether a model-first mission data contract layer could make sense for small spacecraft workflows.

The project has now reached v1.0.0: Stable Mission Data Contract.

I want to be precise about what that means.

It does not mean OrbitFabric is complete, flight-ready, or a replacement for flight software, a ground segment, mission control, a spacecraft simulator, CCSDS/PUS/CFDP tooling, or SatNOGS-like infrastructure.

The v1.0.0 milestone stabilizes a deliberately narrow Core boundary around the Mission Model, validation/linting, scenario evidence, generated review artifacts, ground-facing outputs, runtime-facing bindings, and Core-owned structured surfaces.

The most important stable structured outputs are now:

  • model_summary.json
  • entity_index.json
  • relationship_manifest.json

The idea is that downstream tools should consume these Core-owned surfaces instead of reinterpreting the Mission Model directly.

The demo evidence chain now connects, from one validated mission model:

  • payload acquisition command
  • payload event
  • data product evidence
  • storage intent
  • downlink intent
  • contact window
  • scenario JSON evidence
  • runtime-facing bindings
  • ground-facing dictionaries
  • Core structured surfaces

So the project is still intentionally narrow, but the contract boundary is now explicit and protected.

Repository: OrbitFabric
Docs: OrbitFabric documentation

I’m sharing this update here because the v1.0.0 boundary makes the original feedback request more concrete and easier to evaluate.

At this point, the feedback I would value most from this community is more specific:

  • does this kind of stable mission-data contract boundary look useful upstream of ground/decoder/dashboard/test tooling?
  • are the current structured surfaces the right kind of boundary for downstream tools?
  • from a SatNOGS / open-source space perspective, what would be the most useful integration artifact to focus on next?
1 Like