Skip to content

OrbitFabric v0.7.0 — Generated Runtime Skeletons

Status: Released
Scope: Generated Runtime-Facing Contract Bindings

Summary

OrbitFabric v0.7.0 introduces the first generated runtime-facing contract binding slice.

This release turns the validated Mission Model into deterministic C++17 artifacts that implementation code can include, compile and implement against.

The feature remains deliberately narrow.

It does not generate onboard behavior, runtime loops, schedulers, command queues, HAL code, drivers, RTOS abstractions or flight-ready software.

It generates the contract-aligned software boundary that onboard or host-side implementation code may implement outside generated/.

Architectural meaning

v0.7.0 is the first OrbitFabric release where the Mission Model produces a software-facing boundary.

The intended chain is:

Mission Model
        -> validation and linting
        -> RuntimeContract
        -> C++17 runtime-facing contract bindings
        -> host-build smoke validation
        -> user implementation outside generated/

The important rule is:

generated code is disposable;
user code lives outside generated/;
integration happens through interfaces.

Added

v0.7.0 adds:

RuntimeContract intermediate model
orbitfabric gen runtime command
runtime_contract_manifest.json
C++17 mission identifier headers
C++17 runtime value enums
C++17 static metadata registries
C++17 command argument structs
C++17 abstract adapter interfaces
C++17 host-build smoke CMake target
host-build smoke source including all generated headers

Runtime generator command

Runtime bindings are generated with:

orbitfabric gen runtime examples/demo-3u/mission/

The default output is:

generated/runtime/cpp17/

The current supported profile is:

cpp17

Generated artifacts

The C++17 profile generates:

generated/runtime/cpp17/runtime_contract_manifest.json
generated/runtime/cpp17/include/orbitfabric/generated/mission_ids.hpp
generated/runtime/cpp17/include/orbitfabric/generated/mission_enums.hpp
generated/runtime/cpp17/include/orbitfabric/generated/mission_registries.hpp
generated/runtime/cpp17/include/orbitfabric/generated/command_args.hpp
generated/runtime/cpp17/include/orbitfabric/generated/adapter_interfaces.hpp
generated/runtime/cpp17/CMakeLists.txt
generated/runtime/cpp17/src/orbitfabric_runtime_contract_smoke.cpp

These files are generated artifacts.

They are reproducible and disposable.

They are not committed as source files.

RuntimeContract manifest

The manifest records the software-facing contract surface produced from the Mission Model.

It includes mission identity, generation profile, contract counts and the generated contract domains.

It also records:

contains_flight_runtime = false
generated_artifacts_are_disposable = true

C++17 identifiers and registries

The generated C++17 headers expose deterministic identifiers and metadata registries for:

modes
telemetry
commands
events
faults
packets
payloads
data products
storage policies
downlink policies

The registries make the contract surface inspectable from C++17 without implementing any runtime behavior.

Command argument structs

Commands receive generated typed argument structs.

For example:

struct PayloadStartAcquisitionArgs {
    std::uint16_t duration_s;
};

These structs define the command argument shape.

They do not parse packets, validate permissions, enqueue commands or execute command behavior.

Adapter interfaces

v0.7.0 generates abstract interfaces such as:

ICommandHandler
ITelemetrySink
IEventReporter
IFaultReporter

These interfaces are contract-facing integration boundaries only.

User implementations must live outside generated/.

Host-build smoke validation

The generated C++17 surface can be validated with:

cmake -S generated/runtime/cpp17 -B generated/runtime/cpp17/build
cmake --build generated/runtime/cpp17/build

This validates that the generated headers are buildable as C++17 on the host.

It does not validate flight behavior.

Validation baseline

The release baseline is:

ruff check .
pytest
mkdocs build --strict

orbitfabric lint examples/demo-3u/mission/ \
  --json generated/reports/lint_report.json

orbitfabric gen docs examples/demo-3u/mission/

orbitfabric gen data-flow examples/demo-3u/mission/ \
  --output-file generated/docs/data_flow.md

orbitfabric sim examples/demo-3u/scenarios/battery_low_during_payload.yaml \
  --json generated/reports/battery_low_during_payload_report.json \
  --log generated/logs/battery_low_during_payload.log

orbitfabric sim examples/demo-3u/scenarios/payload_data_flow_evidence.yaml \
  --json generated/reports/payload_data_flow_evidence_report.json \
  --log generated/logs/payload_data_flow_evidence.log

orbitfabric gen runtime examples/demo-3u/mission/

cmake -S generated/runtime/cpp17 -B generated/runtime/cpp17/build
cmake --build generated/runtime/cpp17/build

Expected result:

all checks passing
lint result: PASSED
docs generation: PASSED
scenario result: PASSED
runtime generation: PASSED
C++17 host-build smoke: PASSED

Non-goals

v0.7.0 intentionally does not introduce:

flight runtime
onboard application framework
runtime loop
command dispatch runtime
command queue
command validation runtime
telemetry polling runtime
event routing runtime
fault manager runtime
scheduler
HAL
drivers
RTOS abstraction
Linux daemon
binary serialization
CCSDS/PUS/CFDP mapping
storage runtime
downlink runtime
user-code merge
protected regions
flight-ready software

These are not missing pieces of v0.7.0.

They remain intentionally outside the generated runtime skeleton boundary.

Final position

OrbitFabric v0.7.0 remains a Mission Data Contract framework.

Generated Runtime Skeletons are runtime-facing contract bindings.

They are not flight software.

They provide a reproducible, host-buildable software boundary derived from the Mission Model.