When I published OrbitFabric v1.0.0, the main goal was to close one important question first:

Can a small spacecraft Mission Data Contract become stable enough that tools, generated artifacts and engineering workflows can depend on it without continuously changing the underlying semantics?

At that point the answer was finally yes.

Version 1.0 established a stable Mission Data Contract covering spacecraft structure, modes, telemetry, commands, events, faults, payload behavior, data products, storage and downlink intent, commandability, autonomy and recovery.

It also established deterministic validation, scenario evidence, generated documentation, runtime facing bindings and ground facing artifacts.

That was a useful milestone, but it exposed a second problem almost immediately.

Once other tools start consuming the Mission Data Contract, how do they consume it without becoming independent Mission Model interpreters?

This question shaped most of the work from v1.0 to v1.2.

The problem after v1.0

A YAML Mission Model is convenient for authorship and review.

It is not automatically the right integration boundary for every downstream tool.

If every consumer directly parses the source YAML, several problems appear.

• Each consumer can implement a slightly different interpretation of the same field.
• Derived relationships may be reconstructed differently.
• Optional domains may be handled inconsistently.
• Validation state can be separated from the exact model that was validated.
• A consumer can silently continue after a partial or incompatible parse.
• Over time, a second semantic authority can emerge outside Core.

That last point is the one I care about most.

The architectural rule is now explicit:

The Mission Model is the semantic source of truth.

OrbitFabric Core owns Mission Data Contract interpretation.

Downstream tools consume explicit Core owned facts.

They do not reconstruct OrbitFabric semantics independently.

This sounds simple, but it has strong consequences for the architecture.

Structured surfaces instead of private interpretation

The first step was to expose more of Core's interpretation through structured machine readable surfaces.

Different consumers need different views of the same Mission Data Contract, so a single generic JSON dump is not enough.

OrbitFabric now exposes several distinct Core owned surfaces.

model_summary.json

What contract domains are present?


entity_index.json

What entities exist and how can they be addressed?


relationship_manifest.json

Which explicit admitted relationships connect those entities?


mission_snapshot.json

What complete Mission Model did Core actually load?

These are deliberately different products.

An entity index is excellent for navigation, but it is not a complete semantic representation.

A relationship manifest is useful for graph based tools, but it must expose only relationships that Core actually owns.

A complete Mission Snapshot is useful when a consumer needs the full interpreted model, but it should not replace the smaller surfaces when a smaller contract is sufficient.

The objective is not to produce as much JSON as possible.

The objective is to make Core ownership explicit.

Why explicit relationships matter

This became particularly important for fault detection, isolation and recovery.

A tool looking at a telemetry limit, a fault definition and a recovery command can often guess that the three are related.

But guessing is exactly what I want downstream tools to avoid.

OrbitFabric v1.2 therefore added explicit FDIR related relationship families to the stable Relationship Manifest.

Examples include relationships such as:

• a fault observing a telemetry item
• a recovery intent dispatching a command
• a recovery intent targeting a mode
• an autonomous action being triggered by a fault

The rule is strict:

If Core does not expose the relationship,
the consumer must not invent it.

This is especially important for visual tools.

A graph can make inferred information look authoritative very quickly.

Once a relationship appears as an edge on screen, it becomes difficult for a user to remember whether that edge came from the Mission Data Contract, from a heuristic, or from a UI convenience.

Keeping that distinction explicit is more important than producing a visually richer graph.

v1.1: candidate inspection surfaces

Version 1.1 introduced another layer of structured outputs.

These surfaces are useful, implemented and machine readable, but they remain candidate rather than stable Core contracts.

They include:

• dashboard_summary.json
• scenario_run_index.json
• coverage_summary.json
• structured scenario expectation accounting

This distinction between stable and candidate surfaces is intentional.

Once another project depends on a machine readable contract, changing that contract is no longer only an internal refactoring decision.

Compatibility becomes an architectural concern.

So OrbitFabric now distinguishes between:

stable Mission Data Contract semantics

stable Core owned machine readable surfaces

candidate Core inspection surfaces

candidate external integration contracts

generated public preview artifacts

I prefer this mixed maturity model to pretending that every part of the project has the same stability simply because it ships in the same repository.

The missing piece: coherence

Even with good structured surfaces, another problem remained.

Suppose an external integration receives:

• a Mission Snapshot
• an Entity Index
• a Relationship Manifest
• a lint report
• a model summary

How does it know that all of those files describe the same logical Core interpretation?

File timestamps are not enough.

Directory proximity is not enough.

Running five export commands independently is not enough.

This led to the main integration change in OrbitFabric v1.2.

The Core Integration Input Set

Core can now produce one coherent Integration Input Set from one logical load and lint operation.

The current set contains:

integration_input_manifest.json
mission_snapshot.json
entity_index.json
relationship_manifest.json
lint_report.json
model_summary.json

The important part is not only the files.

The important part is that Core produces them as one coherent unit.

The manifest records information including:

• required and companion roles
• surface kind and version
• availability
• load state
• lint state
• SHA 256 digests
• a deterministic fingerprint of the complete input set

The complete set is fingerprinted using canonical JSON serialization.

The manifest is written last.

This gives an external integration a simple rule:

Either consume one coherent Core Integration Input Set,
or stop.

If a required surface is incompatible, the integration must reject the input.

It must not fall back to reparsing the Mission Model YAML and continue with its own interpretation.

That fallback would defeat the entire semantic ownership boundary.

Why the manifest is written last

This may sound like a small implementation detail, but it is part of the contract.

If the manifest appeared before all required surfaces were successfully written, another process could observe what looks like a complete Integration Input Set while some artifacts are still missing or incomplete.

Publishing the manifest last turns it into the completion marker for the set.

The manifest therefore represents not only metadata, but also the publication boundary of one coherent Core output.

From files to an integration architecture

Once the Core input boundary became explicit, the next architectural layers became much easier to separate.

OrbitFabric Integration Architecture. Core owns Mission Data Contract semantics and produces one coherent integration input boundary. Target specific projection, adapter execution and Integration Result ownership remain outside Core.

The ownership model is:

OrbitFabric Core

owns Mission Data Contract semantics
and coherent integration inputs


Projection Profile

owns authored target specific
projection intent


Integration Adapter

owns target validation,
projection and artifact generation


Integration Result

owns explicit mappings,
artifacts,
diagnostics,
coverage and provenance


Downstream consumer

presents, navigates or orchestrates
those explicit records

The important consequence is that target specific semantics stay outside Core.

Core does not need to know how a particular flight software framework, validation environment or ground system represents telemetry, commands or events.

The adapter understands the target.

The Projection Profile expresses the authored mapping intent.

The Integration Result records what actually happened.

Core remains responsible for OrbitFabric semantics.

Why this matters for Studio

One of the strongest forcing functions for these boundaries has been OrbitFabric Studio.

A visual workbench makes semantic ambiguity visible very quickly.

If Studio directly parses YAML, derives relationships privately or calculates its own hidden interpretation, then the project has two semantic authorities.

That is exactly what I want to avoid.

Studio therefore consumes Core owned surfaces such as the Mission Snapshot, Entity Index, Relationship Manifest and lint output.

The same architectural rule applies:

Core owns the fact.

Studio makes the fact understandable.

I will describe Studio itself in a separate project log because the visual architecture, relationship exploration and operational views deserve their own discussion.

The role of the Reference Mission

Another forcing function has been the OrbitFabric Reference Mission.

Small isolated examples are useful during implementation, but they are not enough to test whether an architecture remains coherent across multiple domains.

The Reference Mission combines spacecraft topology, operational modes, EPS, ADCS, communications, payload behavior, telemetry, commands, events, faults, data products, storage, contacts, downlink intent, commandability and recovery.

It also provides deterministic scenarios that exercise those relationships together.

This has been useful for identifying where a surface is merely convenient and where it actually needs to become an architectural contract.

I will also dedicate a separate log to that mission and to the way the same declared facts move from Mission Model to Core evidence and then into Studio.

What changed between v1.0 and v1.2?

The biggest change is not the number of YAML fields or CLI commands.

The main change is the boundary around semantic interpretation.

At v1.0 the central question was:

Can the Mission Data Contract itself become stable?

At v1.2 the question has become:

Can other tools depend on OrbitFabric without becoming independent interpreters of the Mission Data Contract?

The current answer is based on four rules.

1. The Mission Model remains the semantic source of truth.
2. Core remains the single semantic authority.
3. Downstream consumers receive explicit Core owned facts through controlled surfaces.
4. External integrations consume one coherent fingerprinted input set rather than reconstructing mission meaning from raw source files.

This architecture is now being exercised against real external software boundaries.

That work is already influencing the Integration Framework, but I do not want to collapse it into this log.

The next logs will cover the pieces individually:

• how OrbitFabric Studio visualizes a mission without becoming another Mission Model interpreter
• why a realistic Reference Mission became necessary
• how the generic Integration Framework separates Core semantics from target specific projection
• and finally, how a real spacecraft flight software and validation ecosystem is being used to pressure test those boundaries

The project has therefore moved beyond the original question of whether a lightweight Mission Data Contract is useful.

The more interesting question now is whether that contract can remain semantically coherent while several independent engineering tools start depending on it.

That is the problem I am trying to solve next.

OrbitFabric Core:
https://github.com/FAROTECH/orbitfabric

OrbitFabric Studio:
https://github.com/FAROTECH/orbitfabric-studio

OrbitFabric Reference Mission:
https://github.com/FAROTECH/orbitfabric-reference-mission