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

This is a significant step, but the boundary is important.

Generated Runtime Skeletons are not flight software.

They are not an onboard runtime, not a scheduler, not a HAL, not a command dispatcher and not a command queue.

They are contract-facing software artifacts derived from the validated Mission Model.

Why this release matters

Previous OrbitFabric releases focused on making the mission data chain explicit.

The project could already describe telemetry, commands, events, faults, payload contracts, data products, storage intent, downlink intent, contact windows, commandability assumptions and end-to-end data-flow evidence.

v0.7.0 is the first release where that contract becomes directly visible to implementation code.

The chain now becomes:

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

This is the key shift.

OrbitFabric is no longer only producing documentation, reports and deterministic scenario evidence.

It can now generate a software-facing boundary that implementation code may include, compile and implement against.

RuntimeContract

v0.7.0 introduces RuntimeContract.

RuntimeContract is an intermediate model representing the software-facing subset of the validated Mission Model.

It is the bridge between the declarative mission contract and generated runtime-facing files.

The generation flow is:

Mission Model
        -> structural and semantic validation
        -> engineering linting
        -> RuntimeContract construction
        -> profile-specific generator
        -> generated runtime-facing artifacts

The current generation profile is:

cpp17

This is deliberately narrow.

The goal is not to generate onboard behavior.

The goal is to expose the validated contract surface in a deterministic software-facing form.

The new generator command

The new command is:

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

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

The default generated output is:

generated/runtime/cpp17/ 

The generated C++17 profile currently emits:

generated/runtime/cpp17/runtime_contract_manifest.json
generated/runtime/cpp17/CMakeLists.txt
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/src/orbitfabric_runtime_contract_smoke.cpp

These are generated artifacts.

They are reproducible and disposable.

User implementation code must live outside generated/.

What the generated bindings expose

The generated runtime-facing contract bindings expose several kinds of information.

Identifier headers provide deterministic strongly typed identifiers for model elements such as:

ModeId
TelemetryId
CommandId
EventId
FaultId
PacketId
PayloadId
DataProductId
StoragePolicyId
DownlinkPolicyId 

Static registries expose contract metadata such as model IDs, symbol names, value types, units, command targets, event severities, fault metadata and data product attributes.

Command argument structs expose the declared shape of command arguments.

For example:

struct PayloadStartAcquisitionArgs {
    std::uint16_t duration_s;
};

This struct defines the contract-facing command argument shape.

It does not parse packets.

It does not validate permissions.

It does not enqueue commands.

It does not execute the command.

Adapter interfaces

v0.7.0 also generates abstract adapter interfaces.

Examples include:

ICommandHandler
ITelemetrySink
IEventReporter
IFaultReporter

These interfaces are integration boundaries only.

They are not concrete services.

They do not implement command dispatch.

They do not poll telemetry.

They do not route events.

They do not manage faults.

They define where user implementation code can attach to the generated contract surface.

That distinction is important.

OrbitFabric generates the contract-facing boundary.

The user still owns the implementation.

Host-build smoke validation

The generated C++17 surface can be validated on the host with CMake:

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

This checks that the generated headers and smoke source are syntactically valid and buildable as C++17.

It does not validate flight behavior.

It does not prove onboard readiness.

It only validates the generated contract-binding surface.

What this release intentionally does not do

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

Those are not missing pieces of v0.7.0.

They are outside the generated runtime skeleton boundary.

Security boundary

A final architectural review was performed before publishing v0.7.0.

The decision was not to add security hooks to this release.

OrbitFabric already exposes command risk as contract metadata, but it does not yet model security assumptions, command criticality contracts, data classification, trust boundary metadata, audit requirements or replay/integrity/confidentiality assumptions.

Those should be explored separately.

Adding vague security placeholders now would make the contract weaker, not stronger.

Why this matters before v0.8

v0.7.0 is the correct step before Ground Integration Artifacts.

Ground-facing exports should not be generated from isolated YAML fragments.

They should be generated from a validated Mission Data Contract that already has:

declared mission data,
validated references,
scenario evidence,
data-flow evidence,
runtime-facing identifiers,
typed command argument shapes,
metadata registries,
and implementation-facing adapter boundaries.

That is what v0.7.0 adds.

It does not turn OrbitFabric into flight software.

It makes the Mission Model consumable by software without pretending to own the runtime.

The architectural rule remains:

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

Feedback is welcome from people who have worked with generated headers, telemetry dictionaries, command interfaces, flight software integration boundaries, ground interface control documents or model-to-code workflows and have seen contract drift appear between documentation, tests and implementation code.