ADR-0006 — Payload / IOD Payload Contract Model¶
Status: Accepted
Date: 2026-05-01
Context¶
OrbitFabric is a model-first Mission Data Contract framework for small spacecraft.
The project already models spacecraft-level mission data such as telemetry, commands, events, faults, modes, packets and scenarios.
The demo mission also includes a generic payload subsystem and a scenario where payload activity is part of the operational narrative.
IOD payloads and mission-specific payloads often introduce their own operational contracts:
- telemetry produced by the payload;
- commands accepted by the payload;
- command arguments;
- lifecycle states;
- events generated by payload activity;
- faults or anomalies;
- operational preconditions;
- expected effects;
- scenario-level behavior;
- generated documentation needs.
Without a first-class payload contract model, these concepts remain scattered across generic mission model domains.
Decision¶
OrbitFabric introduces a first-class Payload / IOD Payload Contract Model as part of the Mission Data Contract.
A payload contract describes a declarative mission data and behavior contract.
It does not describe payload firmware, payload drivers, hardware integration or physical payload simulation.
A payload contract may define or reference:
payload identity and profile
linked spacecraft subsystem
payload lifecycle states
payload telemetry references
payload command references
payload event references
payload fault references
command preconditions
expected effects
scenario-level payload behavior
generated payload documentation
Payload contracts must remain part of the Mission Data Contract.
The canonical role of this model is:
Describe payload IOD and mission-specific behavior as a verifiable, simulatable and documentable contract between mission design, onboard software, tests, documentation and ground integration.
Initial Scope¶
The first vertical slice was deliberately narrow.
It includes:
one synthetic IOD payload contract
one payload lifecycle
two payload commands
one payload state telemetry
two payload events
one nominal scenario
generated payload documentation
a small set of payload lint rules
The initial lifecycle remains minimal:
OFF
READY
ACQUIRING
FAULT
Additional states such as STANDBY, WARMUP, PROCESSING and DOWNLINK_PENDING may be added only when a future model slice needs them.
Non-Goals¶
The Payload / IOD Payload Contract Model must not introduce:
payload firmware
payload drivers
payload onboard services
payload runtime execution
payload bus/protocol implementation
payload hardware integration
real payload acquisition data
private mission-specific payload data
physical payload simulation
thermal/optical/scientific instrument simulation
ground segment implementation
These are not delayed implementation tasks.
They are intentionally outside the scope of the core payload contract model.
Consequences¶
This decision strengthens OrbitFabric as a Mission Data Contract framework.
Payloads become explicit model elements without turning OrbitFabric into a payload runtime or spacecraft simulator.
The model can later support:
- Data Product and Storage Contracts;
- Contact Windows and Downlink Flow Contracts;
- future runtime skeletons;
- future ground integration artifacts;
- future payload-specific plugin extension points.
The implementation order remains:
model first
lint before runtime
docs from model
small vertical slice before broad scope