Mission and Thesis

Mission and Thesis

Mission

flexo-rtm is a verifiable self-certification protocol for bidirectional requirements traceability of SysMLv2 models. It is anchored in open source, self-hostable on Flexo (an open-source Model Management System), and provides explicit lossless I/O paths to OSLC-based proprietary systems such as IBM Doors and Jama Connect. The oracle proves that a model satisfies forward and backward traceability — or pinpoints the structural gaps — and emits a layered, replayable certification artifact: transcript, attestation graph, and audit report.

The differentiator vs. Doors and Jama is certification by construction, not by convention: engineers' natural modeling workflow accumulates traceability data, judgment moments surface as they arise, and attestations are captured atomically alongside model evolution. See Verifiable Self-Certification for the protocol and Design Spec for the normative specification.

Why this exists

Today's incumbent RM tools — Doors, Jama, Polarion, codeBeamer — deliver real value: forward and backward traces, coverage statistics, audit trails, OSLC interop, hosting, support. Their constraint is not the data model but the deployment model. In practice, requirements traceability gets organized as a single canonical database held by one tool, which creates institutional friction: scoped authorities (engineering teams, prime contractors, subsystem suppliers, regulators, qualified auditors) must funnel their authoritative claims through one runtime, and the certification artifacts that emerge are PDFs or proprietary exports rather than directly verifiable evidence.

flexo-rtm is an open standard that delivers certification-by-construction on top of a polycentric institutional topology: multiple organizations hold scoped authorities over different parts of the system, each scope is an Authoritative Source of Truth (ASOT) for its content, scopes compose into higher-order scopes and may overlap, and the certification artifact composes across them. This follows the Modular Open Systems Approach (MOSA) principle of modular, loosely-coupled authorities with well-defined interfaces (10 U.S.C. §4401; DoD MOSA Implementation Guidebook, 2025; OMG MBSE Wiki: ASOT). See ADR-030 Polycentric ASOT Authority Model for the locked decision and Analysis Layer Scope Algebra for the operational mechanics.

The mechanics: open formats (RDF, SHACL, SysMLv2 OWL renderings), reproducible analyses (canonical hashes, replayable transcripts), external content-addressed evidence (git, content hashes, OCI), battle-tested signing primitives, and thin identity projections (per-organization as well as per-person). The same incumbents are first-class citizens of this ecosystem: their data roundtrips losslessly, their products can serve as hosts atop the open standard, and their organizations can serve as credible-counterparty auditors holding their own scoped authorities in the composition — providing reproducibility attestations on top of engineering teams' self-certifications (see Federated Audit and Composition). The goal is not to displace incumbents, and not to relocate the single-database friction from one runtime to another; it is to make institutional requirements traceability open, verifiable, and federable across scoped authorities — properties that benefit incumbents, adopters, and regulators alike.

The two most-immediate extensions of the v0.1 baseline are federated audit and composition (ships in v0.1 as a new analytical primitive — see Federated Audit and Composition) and attestation deprecation cascade detection (v0.2 — the methodology-neutral regression-handling mechanism that detects when upstream changes invalidate downstream attestations and marks them rtm:status/deprecated with prov:wasInvalidatedBy provenance, per ADR-031 Attestation Status Pass Fail Deferred Deprecated). Engineering lifecycle stages become optional organizational-convenience scope metadata (per the revised ADR-029 Engineering Lifecycle Stages as Scope Metadata) — methodology-neutral, with INCOSE / ISO 15288 as one example among many (DO-178C, NASA Phase A–F, ISO 9001, Agile, MIL-STD-498, custom phasing); the framework ships the vocabulary substrate but no privileged lifecycle state machine. These v0.1-and-v0.2 roadmap items are distinct in timeline and substance from the topological framework, which remains in research phase pending registry governance and invariant research (Topological Framework Future Work).

The thesis (eight propositions)

The eight propositions below are the load-bearing claims — each both a design commitment and a falsifiable assertion the implementation must demonstrate.

1. Traditional analysis is the trusted primary. flexo-rtm v0.1 ships traditional bidirectional analysis — forward and backward traces with coverage statistics — as the only required certification surface. Practitioners coming from Doors, Jama, Polarion, or other incumbent RM tools recognize this immediately and adopt without further commitment. Everything else is composable on top of, or deferred from, this primary.

2. Named-approver attestation is structurally enforced for v0.1's three claim types: satisfaction, adequacy, and sufficiency. SHACL shapes with sh:minCount 1 ; sh:nodeKind sh:IRI on rtm:Attestation.rtm:approvedBy reject unaccountable attestations at write time — no unsigned, unattributed claim can enter the graph. Regression-compatible with the ADCS prototype corpus, which already uses adequacy and sufficiency attestations.

3. External URI references (git + content addresses + OCI) are the open-source foundation. Evidence, models, and activities in the RDF graph reference concepts outside the graph via URI — git repositories with commit hashes, content-addressed data (sha256, IPFS), OCI image digests for infrastructure-as-code. These external references — not the RDF metadata in isolation — are the source of true interoperability, portability, auditability, and reproducibility. Adopters can fetch, hash-verify, and re-execute without proprietary dependencies.

4. Cryptography by composition of battle-tested standards, never invention. Where signing matters, flexo-rtm composes git GPG/SSH commit signing, W3C Verifiable Credentials and Data Integrity proofs, DSSE and in-toto attestations, Sigstore (cosign plus the Rekor transparency log), and OCI image signature standards. v0.1 ships vocabulary and composable optional SHACL profiles for each surface — no custom crypto, no custom envelopes, no custom transparency logs. Closes the ADCS prototype's "signed envelopes deferred" gap.

5. Identity by thin projection of external authoritative sources, never ownership. flexo-rtm does not authenticate users or store credentials. The named approvers required by Proposition 2 are IRIs referencing identities owned by institutional SSO (OIDC, SAML), LDAP/Active Directory, GitHub, GitLab, and similar. v0.1 ships vocabulary for thin RDF projections (FOAF + the W3C Org Ontology + a minimal rtm: extension) plus three configurable policy primitives — role-based (RBAC), attribute-based (ABAC), and scope-based — all SPARQL-evaluable and enforced through a single SHACL bottleneck. Reference adapters cover GitHub, OIDC, and GitHub Actions OIDC; adopters extend the thin adapter pattern for SAML, LDAP, Okta, Auth0, or Keycloak. This generalizes the ADCS prototype's hard-coded GitHub-ID approach. See Human-AI Accountability for how the same surface handles AI agents as well as humans.

6. Methodology agnosticism is a foundational axiom. flexo-rtm IS bidirectional requirements traceability reduced to practice plus a record of human signers where judgment is rendered — both halves settled engineering, neither requiring a specific assurance methodology. INCOSE / ISO 15288 stages, DO-178C DAL gates, NASA Phase A–F, ISO 9001 process gates, Agile sprint cycles, MIL-STD-498 phasing, and program-specific milestones participate on equal footing as optional adopter-side metadata. Locked in ADR-032 Methodology Agnosticism as Foundational Axiom.

7. Verifiability requires reproducibility at multiple levels. End-to-end verifiable self-certification requires layered reproducibility: RDF-internal (RDFC-1.0 canonical hashes plus transcript replay); external (fetch git + commit, content-hash, or OCI digest, re-execute, compare); accountability (git GPG/SSH-signed commits matching rtm:approvedBy); signed envelopes (W3C VC-DI, DSSE, cosign, Rekor as composable optional profiles); and identity projection (the projection-as-of-cert-time recorded in the transcript). Each layer is independently inspectable; together they yield end-to-end verifiable self-certification with no proprietary dependencies anywhere in the chain.

8. Reproducibility is structural and local; verification is federated. Each fact in the certification artifact is structurally complete for its own local context — the RDF neighborhood, external URIs, projection-at-cert-time, and signatures sufficient to reproduce that fact in isolation. A verifier with adequate local permissions for a specific fact can re-execute its recorded steps without access to the whole graph. Reproduction therefore federates, both computationally (different parties run different subsets) and organizationally (different permission slices compose to a complete audit). No central coordinator and no universally-privileged verifier is required. This is the property that makes multi-party institutional verification possible under confidentiality, export control, and competing-vendor constraints. Federation is more than a property of the artifact — it is the operational analytical primitive by which reproducibility audits and qualified-role attestations stack on top of the self-certification floor. v0.1 ships this primitive: scope-level certification attestations, composition-coverage attestations (adequacy at composition scale: composed scope coverage of system-of-interest), and composition-sufficiency attestations (sufficiency at composition scale: the number and nature of orgs providing scope-level certifications). See Federated Audit and Composition for the full mechanism, the four levels of certification (self → reproducibility audit → qualified-role audit → composition certification), and the composable SHACL profiles that enforce composition-scale criteria.

Scope-reducing assumption

The modeled system is a SysMLv2 model conformant with OMG specifications. The ontology assumes omg-sysml: IRIs (the openCAESAR OWL rendering) are dereferenceable as the canonical model vocabulary. Requirements, evidence, and attestations are structured around SysMLv2 elements. SysML v1, Rhapsody-native models, MagicDraw pre-v2 dialects, and ad-hoc requirements documents are explicitly out of scope for v0.1; lossless OSLC roundtrip is the integration path for those sources, whether adopters keep using their existing tools or transition over time.

What "openness" means here

Three operational commitments: an open source license on the specification, ontology, oracle, conformance suite, and reference adapters; self-hostable on Flexo, with no mandatory cloud service or telemetry; and an explicit OSLC roundtrip so users of Doors, Jama, Polarion, and other RM tools can interoperate with the open standard — or transition over time — without losing requirement structure, trace links, or attestations. Together these mean a regulator, an external auditor, a service provider hosting RM workloads, or an organization performing federated reproducibility audits can stand up a complete flexo-rtm verification environment from source.

OpenMBEE positioning

flexo-rtm-research and flexo-rtm both start in the user's personal GitHub organization for early-stage iteration speed. The planned transfer is to OpenMBEE at the MVP service milestone — once the design has been reviewed in depth, the reference oracle passes its conformance suite, and the OSLC adapters demonstrate lossless roundtrip on real corpora. OpenMBEE is the natural home for an open-source SysMLv2-aligned standards repo with a Flexo runtime.

What this vault is for

This wiki (flexo-rtm-research) is the reviewable artifact. Its purpose is to make the design — mission, eight propositions, ontology, SHACL discipline, conformance suite, OSLC interop story, and the related topological research line — reviewable in depth before implementation begins. Code follows in flexo-rtm once the design has been audited here. Reading order: Map of Content. Normative spec: Design Spec.