OrbitFabric - Roadmap¶
Version: v1.0.0
Status: Stable Mission Data Contract released
Scope: completed path to v1.0.0 and post-v1.0 direction
1. Roadmap Principle¶
OrbitFabric grows through coherent vertical slices, not through feature accumulation.
The project must not try to become, at the same time:
- a flight software framework;
- a ground segment;
- a spacecraft dynamics simulator;
- a packet standard implementation;
- a formal verification tool;
- a hardware abstraction layer;
- a CubeSat tutorial;
- a payload runtime framework;
- a plugin execution platform.
Every milestone must reinforce the core identity:
OrbitFabric is a Mission Data Contract framework.
The v1.0.0 release completes the first stable narrow Mission Data Contract baseline.
2. Roadmap Overview¶
v0.1 Mission Contract MVP completed
v0.2 Model Hardening completed line
v0.2.1 Payload Contract Model completed
v0.2.2 Payload Contract Release Alignment completed
v0.2.3 Mission Data Chain Roadmap Alignment completed
v0.3.0 Data Product and Storage Contracts completed
v0.4.0 Contact Windows and Downlink Flow Contracts completed
v0.5.0 Commandability and Autonomy Contracts completed
v0.6.0 End-to-End Mission Data Flow Evidence completed
v0.7.0 Generated Runtime Skeletons completed
v0.8.0 Ground Integration Artifacts completed
v0.8.1 Contract Introspection Surface completed
v0.8.2 Entity Index Surface completed
v0.9.0 Relationship Manifest Surface and Extensibility Boundary completed
v0.10.0 Stability and Compatibility Contract completed
v0.10.1 Documentation and Published Site Consistency completed
v0.11.0 Extensibility Boundary Contract, no execution completed
v0.12.0 v1.0 Release Candidate Hardening completed
v1.0.0 Stable Mission Data Contract completed
post-v1 Narrow evolution of Core and downstream integrations future
The current completed milestone is:
v1.0.0 - Stable Mission Data Contract
3. Completed Path to v1.0.0¶
The path to v1.0.0 established the following chain:
Mission Model
-> lint
-> scenario simulation
-> generated documentation
-> payload contracts
-> data product and storage contracts
-> contact and downlink contracts
-> commandability and autonomy contracts
-> end-to-end mission data flow evidence
-> runtime-facing contract bindings
-> ground integration artifacts
-> contract introspection surfaces
-> entity index surfaces
-> relationship manifest surfaces
-> stability and compatibility contract
-> documentation and published site consistency
-> extensibility boundary contract
-> release candidate hardening
-> stable surface decision
-> golden signatures for selected Core-owned surfaces
-> demo evidence chain
-> compatibility and migration posture
-> stable Mission Data Contract
The v1.0.0 stable surface is intentionally narrow.
It stabilizes the Mission Data Contract core, not a full space software ecosystem.
4. v1.0.0 Stable Surface¶
The v1.0.0 stable surface includes:
Mission Model documented contract semantics
Core structural validation
Core semantic lint diagnostic policy
scenario YAML evidence inputs
lint JSON report
simulation JSON report
model_summary.json
entity_index.json
relationship_manifest.json for admitted families
CLI command interface for documented workflows
release compatibility policy
extensibility boundary contract
The following remain preview, disposable or out of scope unless explicitly promoted later:
CLI textual output
generated Markdown mission documentation
plain-text simulation logs
generated C++17 runtime-facing bindings
generated ground-facing dictionaries
runtime_contract_manifest.json
ground_contract_manifest.json
plugin execution
relationship graph behavior
schema migration tooling
JSON Schema publication
security enforcement semantics
Studio-specific API
5. Post-v1.0 Direction¶
Post-v1.0 work must preserve the same discipline:
1. protect the Mission Model as source of truth
2. keep Core-owned semantics inside Core
3. keep generated artifacts reproducible and disposable unless explicitly promoted
4. require compatibility or migration notes for stable-surface changes
5. avoid tool-specific claims without implementation and tests
6. avoid plugin execution until a separate design accepts that scope
7. avoid security enforcement semantics until a separate design accepts that scope
Valid future work may include:
additional golden signatures
additional mission examples
additional lint coverage
post-v1 compatibility refinements
JSON Schema publication, if separately designed
schema migration tooling, if separately designed
tool-specific exports, if implemented and tested
extension metadata, if kept descriptive and non-executing
plugin discovery/loading/execution, only after a separate architectural decision
6. Backlog Parking Lot¶
These ideas are valid but are not part of the v1.0.0 stable release boundary:
XTCE export
CCSDS packet generator
PUS service mapping
CFDP metadata
Yamcs integration
OpenC3 integration
Basilisk bridge
Space ROS bridge
F Prime topology generator
cFS table/app generator
web dashboard
visual mission model editor
SARIF lint export
VS Code extension
JSON Schema publication
schema migration tool
simulation time acceleration
fault tree visualization
mode transition graph rendering
requirements traceability
coverage metrics for scenarios
packet budget analyzer
downlink window planner
power budget toy model
ADCS abstract mode examples
thermal abstract mode examples
security policy model
command authorization model
second payload example
payload lifecycle expansion
additional runtime generation profiles
example user implementation outside generated/
plugin metadata manifest
plugin capability manifest
custom lint plugin support
custom generator plugin support
plugin discovery
plugin loading
plugin execution
7. Final Roadmap Statement¶
OrbitFabric v1.0.0 stabilizes OrbitFabric Core as a Mission Data Contract framework.
The stable statement is:
Define the contract once.
Validate it.
Exercise scenario evidence.
Generate review artifacts.
Export Core-owned structured surfaces.
Protect selected stable surface fields with golden signatures.
Keep the Mission Model as the source of truth.
The narrowness of the roadmap is intentional.
That narrowness is a strength, not a limitation.