ADCS Lifecycle Demo
Evidence, attestation and requirements traceability, one satellite at a time
Michael Zargham · Dynamical Systems Group · OpenMBEE
The example
A geosynchronous communications satellite has an attitude determination and control system (ADCS): a PD controller whose two gains, Kp and Kd, are the design. One system-level requirement, REQ-001, says the pointing error must settle within 0.1° within 120 seconds of a slew. Several kinds of evidence speak to it: a symbolic estimate (SymPy), a torque-limited simulation (SciPy), model checking (z3) and the model's own simulation. They don't always agree. At one design the linear estimate says 105 s, and the simulation misses the limit by half a second. A qualified engineer has to judge whether the requirement is satisfied, and say why, on the record.
The take-away
A tool says pass. A person says satisfied.
The tool produced a formal result about the model. The human attestation is about the system the model represents. Bridging the two is where systems engineering practice meets software engineering agility.
- Requirements declare behavioral envelopes. A system-level requirement states ranges of acceptable behavior, under stated operating assumptions. Without that specification, "working as intended?" has no answer. Every automated system needs a behavioral envelope.
- Every kind of evidence has a blind spot. Model checking, simulation, symbolic analysis and tests each cover something and miss something. None of them is the spacecraft. Contradictory evidence is expected, not a failure of the process.
- Continuous analysis, continuous publication (CA/CP). Every design change re-runs the analyses and republishes the model, as CI/CD does for code. Automation alone is an open loop. A qualified engineer closes it, and their judgment, with rationale, becomes part of the model.
More in Framework: how open source fits into engineering, the DEER framework, and CI/CD next to CA/CP.
This is how engineering delivers trusted and trustworthy systems, despite an incomplete and uncertain world.
How open source fits into engineering
Engineering rests on slow, stable standards, and accountable organizations sit on top. Open-source software is the layer in between: it carries the standards into code anyone can build on. The arrows run up, and the organizations feed back into every layer below them.
In this demo, the standard is SysML v2. OpenSysML and sysml-toolkit implement it as open-source software, and OpenMBEE's Flexo MMS stores models through the standard SysML v2 API.
The DEER framework
Declaration, Execution, Evidence, Realization. Four layers of an engineering record, each implemented and stored in its own way. Together they keep the computational record reproducible, so that the evidence about the engineered system can be trusted.
| Layer | What it holds | Implemented as | Stored in | In this demo |
|---|---|---|---|---|
| Declaration | architecture and requirements | SysML v2 | Flexo MMS | satellite.sysml, authored and evaluated with OpenSysML |
| Execution | scenarios, behavioral modeling and analysis pipelines | software | a Git repo | SymPy, NumPy/SciPy, z3 and the model's own simulation |
| Evidence | data generated from measurements, simulations and analyses executed | datasets | append-only databases | carried in the model commits, each tagged with its Git SHA |
| Realization | cloud infrastructure and Docker images | build artifacts | an artifact registry | a reusable Docker image and a locally hosted Flexo service |
Two realizations are worth keeping apart. One is the realization of the computational materials: the images and services the analysis runs in, which is what this layer covers. The other is the engineered artifact itself, the satellite that gets built and flown. The model is not the system.
For how a compute run is authorized, built and verified, each step pinned to content hashes and recorded so an outside auditor can replay it, see Governed Compute, End to End.
From CI/CD to CA/CP
Engineering at the speed of software. The two loops have the same steps. Automation alone is an open loop, and a person closes it: first for software, then for engineering. In CI/CD a red check blocks the merge. In CA/CP contradictory evidence is expected, and the engineer's judgment, with rationale, becomes part of the model.
| CI/CD, with pull requests | CA/CP: continuous analysis, continuous publication |
|---|---|
| commit and push a change on a branch | revise the design (Kp, Kd) |
| CI builds and tests, automated | re-analysis, automated: several kinds of evidence |
| status checks: a red check blocks the merge | evidence concurring or contradictory: disagreement is expected |
| a reviewer approves, with comments | a qualified engineer judges, with rationale |
| the approval is recorded, then deployed | the attestation is recorded in the model and republished |
Two audiences, one example
This repository is a running workspace: the same satellite and requirement, built anew for each venue, and every version stays runnable. The two big talks are duals of each other.
For systems engineers, about open-source software: how a vendor-neutral, open-source spine (RDF standards, Python, Flexo MMS) keeps evidence and judgment traceable across heterogeneous tools.
For open-source software architects, about systems engineering: requirements as behavioral envelopes, evidence with blind spots, and a person's judgment on the record, made continuous like CI/CD.
OpenMBEE community call
Flexo / SysML v2 dev meeting · May 22, 2026 · for OpenMBEE developers: the first build of the example
-
ADCS lifecycle notebook
marimo · RDF (PROV, EARL, GSN) · SHACL · SymPy · SciPy
The original. It takes the ADCS from structure through symbolic analysis, simulation and engineer attestation. All the traceability lives as named RDF graphs and is checked by a SHACL closure-rule suite. This page is a static export, with code.
Open the notebook →
JAXA MBSE/MCE Workshop
Presentations from Industry · Tsukuba · June 12, 2026 · for systems engineers: open-source software practice
-
Intro slides
PDF · 5 slides
Requirements, Evidence and Attestation Traceability with Python and Flexo MMS: engineering is loopy while institutions are linear, open source as a layered supply chain, and vendor-neutral spines for heterogeneous tool ecosystems.
Open the slides (PDF) → -
Demo notebook
Jupyter · rdflib · Flexo MMS · SymPy · SciPy
The live walkthrough as presented. It covers the integration ontology assembled like packages, evidence and attestation as RDF, and a behavior-model oracle beside the human judgment. This page is static HTML of the recorded outputs.
Open the notebook →
INCOSE International Symposium 2026
June 18, 2026 · for systems engineers: accountable assurance of AI-assisted documents
A related paper, with a different example. This paper doesn't use the satellite. Its example is the paper itself: the framework assured its own documents. The idea is the same one the demos build on, applied to documents. Verification is machine conformance to a specification. Validation is an accountable human judgment against explicit guidance. Assurance closes the triangle between them. Content is organized with knowledgecomplex, a typed simplicial complex over OWL, SHACL and SPARQL, so an audit becomes a check of topological coverage.
-
Paper
INCOSE International Symposium 36(1), pp. 1501–1514 · Wiley
Formalizing Document Assurance: A Topological Framework for Verification, Validation, and Human Accountability. Documents are vertices, verification and validation are edges, and spec-guidance coupling closes assurance triangles. AI assistance is tracked, but it cannot replace a human's judgment or signature.
Read the paper (doi:10.1002/iis2.70203) → -
Talk slides
PDF · 18 slides
When AI assists in creating systems engineering documentation, who bears responsibility for the result? The slides cover the assurance triangle, the recursion to four self-describing boundary documents, and audits as traces of tiled triangles. The underlying topological framework is packaged as knowledgecomplex.
Open the slides (PDF) →
Open Source Architects (OSA) Community
October 15, 2026 · for open-source software architects: systems engineering practice
Same title as the JAXA talk, different talk. The invitation came from the JAXA talk and the OpenMBEE work, so the public abstract kept the JAXA title. The audience changed, and so did the emphasis (see above). So did the tools: OpenMBEE released OpenSysML in August 2026. At JAXA the traceability was RDF named graphs pushed to Flexo's RDF layer. At OSA the requirement, the evidence and the person's judgment live in the SysML v2 model itself: OpenSysML evaluates it, and Flexo stores it through the SysML v2 API.
-
Evidence, Attestation, and Requirements Traceability with Python and Flexo MMS
marimo · SysML v2 (OpenSysML) · Flexo MMS · z3 · SymPy · SciPy · Git
A slide deck with the demo inside it. The model, the evidence and the person's judgment are written in SysML v2. There are three designs, and in one of them the evidence disagrees. Each judgment is published as a Flexo commit tagged with its Git SHA. This page is a static export with every demo step pre-signed. The live version runs locally against Flexo (see the README).
Open the slides → -
Talk recording
YouTube
The full recording of the OSA talk: requirements as behavioral envelopes, evidence with blind spots, and human judgment on the record, with the live SysML v2 demo.
Watch the recording →