Evidence, Attestation, and Requirements Traceability with Python and Flexo MMS
Reproducibility tells you a computation can be re-run. It does not tell you the result justifies the claim you are making with it. Between the two sits a layer our tooling rarely captures: the assumptions a model rests on, the provenance chain from source to artifact, and the judgment that this evidence is sufficient. Today those live in notebook text, docstrings, and chat threads. They are unversioned, non-queryable, and first to rot.
Engineering disciplines that carry legal accountability have a structure for this, and it generalizes cleanly to scientific software. Three linked layers: requirements are the claims you commit to, evidence is what your code produces, and attestation is a named person judging the model adequate and the evidence sufficient. The value here is not the paperwork; it is that all three become queryable data.
The implementation is a knowledge graph. RDF lets the vocabulary come from standards that already exist: PROV for provenance, EARL for outcomes, SHACL for the rules that must be satisfied. This approach makes correct construction suitable for CI/CD work flows and turns review into a query. What assumptions does this result depend on? What conclusions break if this analysis changes? Who signed off, and against which version?
Graphs like this need version control, which is where OpenMBEE Flexo MMS comes in: a branchable RDF store that gives engineering artifacts the commit, branch, and diff semantics Git gives code.
The talk works end to end in Python on a satellite attitude-control system: SymPy proofs, SciPy simulations, digest-pinned containers, hashed evidence, attestations bound into named graphs, provenance pushed live to Flexo. It closes on the boundary that makes the rest trustworthy — automation verifies claims within a model; only a person can attest that the model was adequate. While the example comes from aerospace, the same discipline can be applied to Machine Learning models and AI workflows; or any other system sensitive modeling assumptions that are used to inform or make decisions.
About the Speaker
Michael Zargham is CEO and Chief Engineer of Dynamical Systems Group, a systems engineering firm that helps high-reliability organizations put emerging technology to dependable use across civil and commercial aerospace, public-sector R&D, and the open infrastructure that science and engineering depend on.
Within OpenMBEE, he helps set technical roadmap and ecosystem direction, with contributions centered on knowledge enforcing traceability discipline across the lifecycle of model-based systems engineering artifacts.
The through-line in his work is one design discipline: simple local algorithms with provable relationships to desirable global properties, under the weakest possible assumptions about agent behavior. The mathematics is the same whether the agents are robots, markets, or institutions.
He holds a Ph.D. in Electrical and Systems Engineering from the University of Pennsylvania in optimization and control of distributed systems, has taught at Penn and Carnegie Mellon, and serves on the NumFOCUS Advisory Council.
About the Open Source Architect Community
The Open Source Architect (OSA) Community is an invitation-only group for seasoned software architects who are passionate about open source technology. Request to join the OSA Community: https://forms.gle/7efbynVzYhhH2LCQ7
We review each application carefully. If it’s a fit, you’ll get an invite to join the space where it all happens.
For the latest updates on all things open source, follow our public feed on LinkedIn.