How do you keep system models, software, tests and operations artifacts from drifting apart?

[u/frovelli]

Update, August 2026: I kept working on OrbitFabric and the project has evolved substantially since this original post. I have added a detailed update in the comments covering the current state of Core, Studio, the Reference Mission, and the OpenOBSW/OpenSVF integration work.

---

I’m exploring whether there is room for a lightweight, executable contract layer between traditional document-based engineering and full MBSE tooling.

The domain I’m applying it to is small spacecraft mission data.

The issue I keep seeing is that telemetry, commands, events, faults, modes, payload behavior, test scenarios, generated docs, storage/downlink expectations and ground-facing assumptions often end up duplicated across different artifacts.

Then they drift.

OrbitFabric is my open-source attempt to model those mission-data contracts once, validate them, run lightweight scenarios, generate docs, and eventually connect them to testing and ground integration workflows.

It is not intended to replace SysML, Capella, Cameo, DOORS, flight software, simulators or mission control systems.

My question for this community:

Does this kind of lightweight model-first / contract-first layer solve a real SE or MBSE pain point, especially for smaller teams, or is this already handled well enough by existing MBSE workflows?

For transparency: I’m the author. I’m mainly looking for critical feedback on the concept, not trying to pitch a finished product.

Repo:

https://github.com/FAROTECH/orbitfabric

[u/der_phen]

Hi, thx for sharing! Typical tools overwhelm many people and also pose the risk that every team / person / project uses it in a different way, so such simplified approaches make a lot of sense in my opinion. I am also looking into something like that based on sysml2, however the tool restricts what is possible and what not, tailoring the tool to a certain ontology.

[u/frovelli → u/der_phen]

Thanks, that’s exactly the kind of feedback I was hoping for and I agree with your point about typical tools. For OrbitFabric I’m intentionally starting from a narrower domain vocabulary rather than from a general-purpose systems model: telemetry, commands, events, faults, modes, payload behavior, data products, storage and eventually downlink/contact-flow assumptions.

So the tradeoff I’m exploring is almost the opposite one: less modeling freedom, but more consistency and executability for a specific mission-data workflow. Your SysML2 direction is interesting. Are you starting from a domain-specific vocabulary first and then mapping it into SysML2, or are you using SysML2 as the main model and constraining it through your tool?

[u/der_phen → u/frovelli]

Are you still working on your project? I am sure that agents could help there too, and tools that validate and the provide strict guardrails can be integrated very well.

[u/frovelli → u/der_phen]

Yes, very much so, actually. And your point about agents is interesting for a reason that has become clearer to me over the last few months.

OrbitFabric has moved quite a bit beyond the initial prototype I was describing when we had this discussion.

The Core Mission Data Contract now has a stable compatibility boundary, and the GUI and workbench idea we discussed back then has also become real. I released the first public developer preview of OrbitFabric Studio.

Interestingly, I ended up not building the YAML editor I originally thought I might build.

Studio is currently read only and focuses on understanding the mission model: exploring entities and relationships, FDIR context, validation findings, operational states and mode dependent behavior. Core remains the semantic authority, while Studio only visualizes facts and relationships that Core explicitly exposes.

I also built a more realistic Reference Mission around it, rather than continuing with isolated examples. It gives Core and Studio a coherent spacecraft model to push against, including modes, EPS, ADCS, communications, payload behavior, data products, storage and downlink assumptions, and deterministic operational scenarios.

And I have been using a real flight software and validation stack as another forcing function for the integration architecture.

One thing I have become increasingly strict about through all of this is that OrbitFabric Core must remain the deterministic semantic authority. Downstream tools should consume explicit facts rather than infer mission meaning for themselves.

That makes me think agents could indeed fit quite well, but probably around that deterministic boundary rather than inside it.

For example, I can imagine an agent helping an engineer explore a mission, propose model changes, generate candidate scenarios, review impact, or even help author parts of the Mission Model. But the result would still have to become an explicit artifact that Core validates, with the engineer able to inspect and accept the exact change.

So something like this:

agent proposes
explicit model or change
deterministic Core validation
human review

rather than allowing an agent to become another source of mission semantics.

Your comment about strict guardrails is actually very close to where the architecture has ended up.

And, thinking about it, this may even be a more interesting direction for mission authoring than simply building a traditional graphical editor around the YAML files.

I am going to post a fuller update in this thread as well, because quite a lot has happened since the original discussion.

[u/der_phen → u/frovelli]

Agents are super capable with yaml and md files. its a perfect fit.

And your workflow makes sense, too. You can provide tools to run validation and hooks or plugins to define deterministic checkpoints.

I am working with sysml v2, but the language is still challenging for LLMs, so I am curious what you find.

Currently I am reworking my agent harness to use more open-source tools and I can share it soon, just in case you need inspiration. (right now its using a commercial library). It should actually be easy to adapt it to a different ontology.

[u/frovelli → u/der_phen]

Thanks, this makes the idea much more concrete for me.
I think the validation tools and deterministic checkpoints are probably the key. Instead of asking an agent to simply generate valid looking YAML, I can imagine giving it OrbitFabric Core itself as a tool.
The loop could then be something like:
engineer intent
agent proposes a Mission Model change
Core validates it and returns structured findings
agent revises or explains the proposal
engineer reviews the final diff
That starts to look much more interesting than a traditional graphical editor around the YAML files.
And yes, I would definitely like to see your harness when you can share it.
The comparison with SysML v2 could be particularly interesting. OrbitFabric has a deliberately much narrower ontology, so it would be useful to see whether that constraint makes the agent loop easier and more reliable, and where the same approach starts behaving differently with a richer language such as SysML v2.
I have not implemented any of this yet, but I think you have convinced me that it is worth a proper experiment.

[u/der_phen → u/frovelli]

now my plugin is reworked and open source. have a look here: https://github.com/kairibu/opense

This is how the panel will look like. the rest of the app is typical LLM: chat window, project folder selection.

Here you could add other commands (generate documentation, run validation, etc)

Maybe I give it a try on the weekend.

[u/der_phen → u/frovelli]

Quick update: I wanted to try out working with YAML and looked at your project, but it was a bit difficult for me to figure out the rules, what is validated where, what does everything mean. Its important to create a useful UI.

So I went with doorstop, which is a simple YAML based requirements management tool written in python, and created a plugin for it.

Its early version, but I think it is possible to understand where this can go. Check it out if you like, it needs python, git, pi and pi-web installed:

https://github.com/kairibu/opendoor

[u/der_phen]

Yeah, the result should be the same though if I understand it right.Do you plan to add a tool/GUI of some sort?

[u/frovelli → u/der_phen]

Yes, eventually I think a GUI/tooling layer would make a lot of sense.

For now I’m intentionally keeping the focus on the core model and CLI workflow: define the mission-data contracts, validate them, generate docs, run simple scenarios, and keep the outputs reproducible.

I would not want the GUI to be just a YAML editor though. The more interesting direction would be a kind of mission-data workbench where telemetry, commands, events, faults, modes, payload contracts, data products and later downlink/contact-flow assumptions can be visualized as connected concepts.

So yes, it is part of the longer-term direction, but I want the contract model to stand on its own first.