Skip to content

v0.9.0 - Relationship Manifest Surface and Extensibility Boundary

OrbitFabric v0.9.0 introduces the first Core-owned relationship manifest surface.

The release adds deterministic relationship_manifest.json generation from the loaded Mission Model.

It is a narrow release.

It does not introduce plugin execution, plugin discovery, relationship graphs, dependency graphs, runtime behavior, ground behavior or Studio-specific APIs.


Purpose

The v0.9.0 goal is to let downstream tools ask a third stable question:

How are indexed mission contract entities related?

That answer must come from OrbitFabric Core.

It must not be reconstructed by downstream tools from raw YAML, generated files, human-oriented CLI output, UI state, naming conventions or private assumptions.


Relationship to v0.8.1 and v0.8.2

v0.8.1 introduced model_summary.json.

It answers:

What contract domains are present in this mission?

v0.8.2 introduced entity_index.json.

It answers:

What contract entities are defined in this mission?

v0.9.0 introduces relationship_manifest.json.

It answers:

How are indexed mission contract entities related?

The three surfaces are intentionally separate:

model_summary.json          -> domain-level inspection
entity_index.json           -> entity-level inspection
relationship_manifest.json  -> relationship-level inspection

The relationship manifest references indexed entities.

It does not replace the entity index.

It does not create a graph engine.


Added

v0.9.0 adds:

relationship_manifest_to_dict(model, mission_dir)
write_relationship_manifest(model, mission_dir, output_file)
orbitfabric export relationship-manifest command
relationship_manifest.json output
manifest_version 0.1-candidate
kind orbitfabric.relationship_manifest
relationship records
relationship type records
relationship type counts
explicit relationship derivation policy
explicit boundary flags
relationship manifest export tests
relationship manifest CLI tests
Relationship Manifest Surface reference documentation

CLI

Generate the relationship manifest report with:

orbitfabric export relationship-manifest examples/demo-3u/mission/ \
  --json generated/reports/relationship_manifest.json

Default output:

generated/reports/relationship_manifest.json

Output

The generated report uses:

kind: orbitfabric.relationship_manifest
manifest_version: 0.1-candidate

It contains:

mission identity
source mission directory
boundary flags
relationship type records
relationship type counts
relationship records

For examples/demo-3u/mission, the current manifest contains:

46 relationship records
17 emitted relationship families

The candidate surface admits:

19 relationship families

Admitted relationship families

v0.9.0 admits these deliberately narrow relationship families:

autonomous_action_dispatches_command
command_emits_event
command_targets_subsystem
commandability_rule_constrains_command
data_product_produced_by_payload
data_product_produced_by_subsystem
downlink_flow_includes_data_product
event_sourced_from_subsystem
fault_emits_event
fault_sourced_from_subsystem
packet_includes_telemetry
payload_accepts_command
payload_belongs_to_subsystem
payload_generates_event
payload_may_raise_fault
payload_produces_telemetry
recovery_intent_reacts_to_event
recovery_intent_reacts_to_fault
telemetry_sourced_from_subsystem

Each family is admitted only because Core can derive it from explicit loaded Mission Model fields.

No relationship family is admitted from naming conventions, ID prefixes, generated documentation, CLI text, downstream UI state or private downstream assumptions.


Relationship record shape

Each relationship record has this conceptual shape:

{
  "relationship_id": "<from-domain>:<from-id>-><relationship-type>:<to-domain>:<to-id>",
  "relationship_type": "<relationship-type>",
  "from": {
    "domain": "<from-domain>",
    "id": "<from-id>"
  },
  "to": {
    "domain": "<to-domain>",
    "id": "<to-id>"
  },
  "derived_from": {
    "model_field": "<explicit-loaded-model-field>"
  }
}

Relationship records must refer to entities already represented by the Entity Index Surface.

They must not create independent synthetic nodes.


Boundary

v0.9.0 intentionally does not introduce:

new Mission Model semantics
relationship inference
relationship graph
dependency graph
source line or column tracking
YAML node location tracking
YAML AST export
plugin API
plugin discovery
plugin loader
plugin execution
custom lint plugin support
custom generator plugin support
Studio-specific API
runtime behavior
ground behavior
versioned plugin surface

The relationship manifest is:

Core-owned
read-only
machine-readable
candidate
partial by design
based on explicit loaded Mission Model fields
safe to inspect
not a v1.0 compatibility promise

The relationship manifest is not:

a graph engine
a dependency graph
a visualization format
a Studio API
a runtime routing table
a ground routing table
a scheduler input
a command dispatcher input
a plugin API

Extensibility boundary

v0.9.0 preserves the wider plugin and extensibility roadmap without implementing plugin execution.

Future plugins must extend OrbitFabric without silently redefining Core semantics.

Plugins must not bypass:

Mission Model loading
structural validation
semantic linting
Core-owned structured surfaces
source of truth rules

Plugin execution requires explicit trust, metadata and boundary design before arbitrary or untrusted plugin code is supported.


Why this matters

This release lets downstream tools consume Core-owned relationship semantics without inventing private graph edges.

The important architectural chain becomes:

Core model_summary.json -> domain navigation
Core entity_index.json -> entity navigation
Core relationship_manifest.json -> relationship navigation

Downstream tools may render relationships.

The engineering meaning of every relationship must still come from Core.


Validation

The release validation baseline is:

ruff check .
pytest
mkdocs build --strict

Manual smoke commands:

orbitfabric export model-summary examples/demo-3u/mission/ \
  --json generated/reports/model_summary.json

orbitfabric export entity-index examples/demo-3u/mission/ \
  --json generated/reports/entity_index.json

orbitfabric export relationship-manifest examples/demo-3u/mission/ \
  --json generated/reports/relationship_manifest.json

Expected result:

Result: PASSED