OrbitFabric

OrbitFabric is an open source, model first Mission Data Contract framework for small spacecraft.

Its purpose is to keep mission semantics explicit, consistent, reviewable and reusable across engineering activities that would otherwise maintain their own partially overlapping representation of the mission.

Typical examples include flight software structures, ground dictionaries, validation fixtures, simulation inputs, documentation, payload integration definitions, fault handling logic, storage assumptions, downlink configuration and external engineering tools.

The problem OrbitFabric addresses is not that these representations exist.

The problem is that each of them can gradually become its own interpretation of the mission.

OrbitFabric introduces one explicit Mission Data Contract and makes other artifacts derive from, or consume, that contract through controlled interfaces.

The architectural rule

The central rule of the project is deliberately strict:

The Mission Model is the semantic source of truth.

OrbitFabric Core owns Mission Data Contract interpretation.

Derived artifacts remain derived.

Downstream tools consume explicit Core owned facts.

This distinction has become increasingly important as the project has grown.

A consumer should not independently parse the Mission Model and reconstruct OrbitFabric semantics for itself.

A visualization tool should not invent relationships because two identifiers look related.

An integration adapter should not silently reinterpret the source YAML when a required Core surface is incompatible.

The goal is to preserve one semantic authority while allowing many different consumers.

Mission Data Contract

The Mission Data Contract is expressed as a structured YAML Mission Model.

The current stable model covers:

• spacecraft identity and mission metadata
• subsystems
• operational modes and transitions
• telemetry
• commands
• events
• faults
• packets
• policies
• payload contracts
• data products
• storage and retention intent
• contact and downlink assumptions
• commandability
• autonomy and recovery intent

Operational scenarios are defined separately and exercise the contract as deterministic engineering evidence.

A typical mission workspace contains:

mission/
    spacecraft.yaml
    subsystems.yaml
    modes.yaml
    telemetry.yaml
    commands.yaml
    events.yaml
    faults.yaml
    packets.yaml
    policies.yaml
    payloads.yaml
    data_products.yaml
    contacts.yaml
    commandability.yaml

scenarios/
    *.yaml

The YAML files are the authored representation, but the important concept is not YAML itself.

The important concept is the semantic contract represented by those files and interpreted by Core.

OrbitFabric Core

OrbitFabric Core is the semantic authority of the ecosystem.

The current baseline is OrbitFabric Core v1.2.0.

The stable Mission Data Contract compatibility commitment started with v1.0.0.

Core performs several distinct engineering functions.

Structural validation and semantic linting

Core first determines whether a Mission Model is structurally valid and then checks semantic consistency across the declared domains.

Examples include identifier validity, references between entities, command and telemetry consistency, operational relationships, payload lifecycle declarations, data product continuity and recovery intent.

Diagnostics are available both for humans and as structured machine readable output.

Deterministic scenario evidence

OrbitFabric scenarios exercise declared mission behavior in a deterministic host side environment.

They can drive telemetry values, dispatch commands, observe events, follow mode transitions and evaluate explicit expectations.

This is intentionally not spacecraft dynamics simulation and not flight execution.

The objective is to provide reproducible evidence about the declared Mission Data Contract.

Generated documentation

Core can generate reviewable documentation directly from the validated Mission Model.

Generated documents are useful engineering artifacts, but they are never treated as the source of truth.

They can always be regenerated from the contract.

Runtime facing contract artifacts

Core can generate deterministic runtime facing bindings.

The current C++17 profile produces identifiers, metadata registries, command argument structures, abstract adapter interfaces and a host build smoke target.

These artifacts describe the contract boundary.

They do not implement scheduling, device drivers, command dispatch, telemetry polling, RTOS behavior or spacecraft application logic.

Ground facing contract artifacts

Core also generates generic ground facing dictionaries and review artifacts.

These outputs can help connect the Mission Data Contract to downstream tooling, but OrbitFabric does not implement a telemetry archive, mission control system, command uplink service or operator console.

Core owned machine readable surfaces

As OrbitFabric evolved, it became clear that downstream tools needed something better than terminal output, generated Markdown or independent parsing of source YAML.

Core therefore exposes structured machine readable surfaces with explicit ownership.

Current stable surfaces include:

• lint JSON report
• simulation JSON report
• model_summary.json
• entity_index.json
• relationship_manifest.json
• mission_snapshot.json
• Core Integration Input Set

These surfaces answer different questions.

model_summary.json
What contract domains are present?

entity_index.json
What entities exist?

relationship_manifest.json
Which explicit admitted relationships connect them?

mission_snapshot.json
What complete Mission Model did Core actually load?

This separation is intentional.

For example, an Entity Index is useful for navigation but is not a complete semantic snapshot.

A Relationship Manifest exposes explicit admitted relationships but does not authorize a consumer to infer additional ones.

The Mission Snapshot provides a complete read only serialization of the Mission Model that Core actually interpreted.

Explicit relationships and FDIR

OrbitFabric v1.2.0 extends the stable Relationship Manifest with explicit FDIR related relationship families derived deterministically from Mission Model fields.

These include relationships between faults, observed telemetry, autonomous actions, recovery commands and recovery target modes.

The important design choice is that these relationships are explicit.

If Core has not admitted a relationship type, downstream consumers must not guess its meaning.

This rule is especially important for visualization and integration tools, where inferred semantics can easily become indistinguishable from authoritative semantics.

Coherent Core Integration Input Set

One of the main architectural additions in v1.2.0 is the stable Core Integration Input boundary.

External integrations should not independently collect a set of unrelated reports and assume they represent one coherent semantic state.

Core can instead produce one coherent Integration Input Set from one logical load and lint operation.

The set contains:

• integration_input_manifest.json
• mission_snapshot.json
• entity_index.json
• relationship_manifest.json
• lint_report.json
• model_summary.json

The manifest records information such as:

• surface role
• surface kind and version
• availability
• load state
• lint state
• SHA 256 digest
• coherent input set fingerprint

The complete set is fingerprinted deterministically.

The manifest is published last.

This allows an integration consumer to reason about one coherent Core produced input rather than a collection of potentially unrelated files.

An incompatible required surface must cause the integration to stop.

Raw YAML semantic fallback is deliberately forbidden.

Generic Integration Framework

OrbitFabric now defines a generic external integration architecture.

Mission Model
    |
    v
OrbitFabric Core
    |
    v
Core Integration Input Set
    |
    v
Projection Profile
    |
    v
Integration Package and Adapter
    |
    v
Integration Result
    |
    v
downstream ecosystem

Each layer has explicit ownership.

OrbitFabric Core

owns Mission Data Contract semantics
and coherent integration inputs


Projection Profile

owns authored target specific
projection intent


Integration Adapter

owns target validation,
projection and artifact generation


Integration Result

owns explicit mappings,
artifacts,
diagnostics,
coverage and provenance


Downstream tools

navigate, present or orchestrate
those explicit records

This separation prevents target specific semantics from leaking back into Core.

Core does not need to understand a particular flight software framework, validation environment, ground system or external engineering tool.

The adapter understands the target.

Core remains responsible only for OrbitFabric semantics.

Several contracts on the external side of this boundary remain intentionally classified as candidate rather than stable Core interfaces.

That distinction is important.

OrbitFabric does not pretend that every part of the ecosystem has reached the same maturity level.

OrbitFabric Studio

OrbitFabric Studio is the visual engineering workbench of the ecosystem.

Its purpose is not to replace the Mission Model with a graphical representation.

Its purpose is to make Core owned mission facts easier for an engineer to understand.

The first public developer preview provides a mission understanding workflow built around several complementary views:

• Open Mission
• Mission Atlas
• Entity Explorer
• Entity X Ray
• Relationship Explorer
• Context Path
• Context Map
• Validation Findings
• Operational State Map
• Mode Focus

Studio consumes structured surfaces produced by Core.

It does not become another Mission Model interpreter.

The architectural rule is:

Core owns the fact.

Studio makes the fact understandable.

This means Studio may organize, search, filter, group, lay out and visualize mission information.

It may not create mission meaning that Core did not expose.

For example, Studio does not infer relationships from identifier names, file proximity or textual similarity.

It does not reinterpret telemetry limits as fault semantics.

It does not construct a private mission ontology.

It does not calculate its own hidden mission health or readiness model.

The current preview is read only with respect to Mission Model source.

Studio architecture

Studio deliberately separates semantic ownership from desktop and presentation responsibilities.

OrbitFabric Core
Python

owns semantics,
validation and structured mission facts


Tauri and Rust

own desktop integration,
filesystem boundaries
and Core process lifecycle


React and TypeScript

own interaction,
presentation
and non authoritative Studio state

Relationship and operational graphs use React Flow for rendering and ELK for graph layout.

Presentation geometry remains separate from semantic graph content.

A layout engine may decide where a node appears on screen.

It must never decide whether that semantic relationship exists.

OrbitFabric Reference Mission

A model architecture cannot be evaluated indefinitely using only small isolated examples.

OrbitFabric therefore includes a separate Reference Mission repository containing a realistic synthetic small spacecraft engineering workspace.

It is not flight software.

It is not a spacecraft simulator.

It is not a real mission configuration.

Its role is to provide a coherent engineering context that exercises the Mission Data Contract across multiple domains.

The current Reference Mission includes:

• spacecraft topology
• operational modes
• EPS
• ADCS
• communications
• payload behavior
• telemetry and commands
• events and faults
• data products
• storage intent
• contact windows
• downlink intent
• commandability
• autonomy and recovery

It also includes deterministic scenarios.

Current scenarios exercise cases such as:

• nominal payload acquisition
• low power payload suspension
• degraded pointing payload inhibition
• pending downlink backlog

The Reference Mission provides a common workspace for validating both Core and Studio.

The same declared mission facts can therefore be inspected as model entities, exercised through scenarios, exported as structured Core surfaces and explored visually in Studio.

Stability is part of the architecture

OrbitFabric explicitly distinguishes between stable and candidate surfaces.

The current stable v1.x boundary includes the documented Mission Model semantics and the Core owned surfaces required for deterministic consumption.

Other capabilities remain candidate where the architecture is implemented but not yet committed as a long term compatibility boundary.

This distinction is deliberate.

A project that exposes machine readable contracts needs to communicate not only what exists, but also what consumers may safely depend on.

Compatibility is therefore treated as an engineering concern rather than only as a release version number.

What OrbitFabric owns

• Mission Data Contract semantics
• validation
• semantic linting
• deterministic scenario evidence
• Core owned structured surfaces
• generic contract artifact generation
• stable Core integration input boundary
• integration architecture contracts

What OrbitFabric does not own

• flight software
• RTOS or operating system
• spacecraft dynamics simulator
• ground segment
• mission control
• telemetry archive
• command uplink system
• hardware abstraction layer
• device drivers
• target specific protocol implementation

Those systems remain independent engineering domains.

OrbitFabric provides a semantic contract that they can consume where useful.

Engineering principles

• Keep the Mission Model as the semantic source of truth.
• Keep Core as the single semantic authority.
• Prefer explicit relationships over inferred relationships.
• Treat generated artifacts as reproducible outputs.
• Make compatibility boundaries explicit.
• Keep target specific integration semantics outside Core.
• Preserve provenance across generated and integrated artifacts.
• Allow downstream tools to present facts without silently redefining them.
• Use realistic engineering examples to pressure test the architecture.
• Keep public examples synthetic and clean room.

Current ecosystem

The project is currently split across three primary repositories:

OrbitFabric Core
https://github.com/FAROTECH/orbitfabric

OrbitFabric Studio
https://github.com/FAROTECH/orbitfabric-studio

OrbitFabric Reference Mission
https://github.com/FAROTECH/orbitfabric-reference-mission

Core is currently at v1.2.0.

Studio has its first public developer preview.

The Reference Mission provides the primary engineering workspace used to exercise the ecosystem.

External integration work is now being developed against the generic Integration Framework rather than by embedding target specific semantics into Core.

Future project logs will go deeper into each of these architectural layers and into the real software integrations being used to test them.