Models That Run: The Case for Executable System Architecture

There’s a question that exposes the fault line in every MBSE deployment: “What happens to the model after design review?”

In most organizations, the honest answer is: nothing. The model was built to produce diagrams for a review gate. The review happened. The diagrams were exported to PowerPoint. The PowerPoint was presented. The review board signed off. And the model sits untouched until the next review, slowly drifting from reality as implementation decisions are made in code, in spreadsheets, in hallway conversations - anywhere except the model.

This is the architectural documentation paradox. The model is supposed to be the single source of truth, but it is treated as a snapshot - a point-in-time artifact that captures what was intended, not what was built. By the time the system ships, the model is a historical document. Accurate in spirit, wrong in detail, and useful to no one.

The endgame for MBSE isn’t better documentation. It’s models that run.

What “models as code” actually means

INCOSE’s Vision 2035 describes a future of “pattern-based model composition and continuous virtual exploration.” That language is deliberately forward-looking, but the concept is not abstract. It describes a specific and achievable architectural shift: treating system models the same way software teams treat source code.

Source code is version-controlled. It lives in git. Multiple engineers work on it simultaneously using branches and merge requests. Changes are reviewed through pull requests with visible diffs. Automated pipelines validate every change - linting, type checking, testing, building. The code is the truth, and every other artifact (documentation, releases, deployments) is derived from it.

Now compare that to how system models are managed today. Models live inside proprietary tool databases. Version control - if it exists at all - is tool-specific and opaque. “Diffing” two versions of a model requires specialized comparison tools that show structural changes but not semantic ones. Collaboration means locking model elements to prevent concurrent edits. And nothing about the model is automated - every artifact (diagrams, documents, matrices) requires manual generation.

The “models as code” vision eliminates this gap. It means:

Textual model syntax that can be stored in plain files, committed to git, and diffed with standard tooling
Branch-and-merge workflows where architects propose changes through merge requests, reviewed by peers
Automated validation that runs on every commit - checking model consistency, verifying constraints, enforcing organizational patterns
Derived artifacts generated automatically from the model - diagrams, documents, interface specifications, test scaffolds

SysML v2 makes this architecturally possible in a way its predecessor never did. The SysML v2 specification includes a textual notation (KerML and SysML text) that is human-readable and machine-parseable. A system architecture written in SysML v2 text can live in a .sysml file, committed alongside the source code it describes, versioned with the same tools, reviewed with the same processes.

This isn’t theoretical. The OMG’s SysML v2 specification explicitly defines a standard API with REST endpoints for model queries, diagram services, and evaluation services. The architecture assumes that models are accessed programmatically - not just through a GUI - and that multiple tools can interoperate through a common API layer.

Merge requests on architecture

Consider what it means to put architecture through a pull request workflow.

An engineer proposes a change to the system’s functional decomposition. Instead of modifying a diagram in a proprietary tool and hoping someone reviews it at the next scheduled meeting, they create a branch, edit the textual model, and open a merge request. The diff shows exactly what changed: a new subsystem was added, an interface was modified, a requirement allocation was updated.

Reviewers can comment on specific lines of the model, just as they would on code. Automated checks run: Does the model still parse? Are all interface contracts satisfied? Do all requirements still trace to at least one design element? Is the safety allocation consistent with the hazard analysis?

The review becomes structural, not ceremonial. Instead of presenting diagrams and hoping someone asks the right question, the change is visible, diffable, and auditable. The merge request history becomes the design rationale - not a separate document that nobody maintains, but the actual record of why each decision was made.

This workflow already exists for software. Git, GitHub, GitLab - these tools have spent two decades refining the mechanics of collaborative change management. The insight of “models as code” is that system architecture deserves the same infrastructure.

Continuous assurance: verification moves left

One of the most powerful consequences of executable models is what it does to verification and validation.

In traditional systems engineering, verification is a phase. You design the system, build the system, and then verify the system. If verification finds problems - and it always does - you’re reworking designs that were finalized months ago. The cost of late-discovered defects in complex systems is well documented. NASA’s studies put it at 10-100x more expensive to fix a defect in test than to fix it in design.

Executable models change the economics. If the model can be queried, analyzed, and validated automatically, then verification can happen continuously - on every commit, on every merge, as part of the design process itself.

Continuous assurance means:

Constraint checking runs automatically. Does every safety-critical function have redundancy? Does every external interface have a defined protocol? Does every requirement have a verification method assigned?
Consistency validation catches conflicts early. If two subsystems both claim the same resource, the model catches it at commit time, not during integration testing.
Coverage analysis tracks completeness in real time. What percentage of requirements are allocated? How many have verification evidence? Where are the gaps? These metrics update with every model change.
Risk and compliance assessment moves from periodic review to continuous monitoring. Instead of asking “are we compliant?” at a milestone gate, the model tells you the compliance status at every point in the development lifecycle.

This is not a minor process improvement. This is a fundamental shift in how verification risk is managed. It moves the discovery of design defects from test (expensive, late) to design (cheap, early). It replaces periodic audits with continuous visibility. It transforms compliance from a gate to a trajectory.

The model as database

There’s a deeper architectural point that most MBSE discussions miss. When we talk about “models that run,” we’re not just talking about models that can be queried. We’re talking about a fundamental change in what the model is.

In current MBSE tools, the model is a diagram. The database exists to support the diagram. The data model is optimized for rendering - positions, sizes, layers, visual relationships. When you “query” the model, you’re really navigating the diagram structure and hoping the semantic information you need happens to be attached.

In the executable architecture vision, the model is the database. The diagram is a view - one of many possible views - derived from the underlying semantic data. The data model is optimized for queries, relationships, and constraints. Diagrams are generated, not authored. They’re a rendering of the truth, not the truth itself.

This distinction has enormous practical consequences:

Multiple views, one truth. A safety analyst sees the hazard analysis view. A program manager sees the schedule and resource allocation view. A developer sees the interface specification view. All derived from the same underlying model, always consistent, never out of sync.
Programmatic access. External tools can query the model through APIs. A CI/CD pipeline can ask “what interfaces changed in this release?” A test management system can ask “what requirements need re-verification?” A documentation generator can ask “what’s the current system architecture?” No manual export required.
Downstream generation. Interface control documents, software architecture documents, test plans, FMEA worksheets - these become generated artifacts, always current, never stale. The engineer maintains the model; the artifacts take care of themselves.

Digital twins as runtime expression

The concept of digital twins extends this further. If the model is the authoritative description of the system - its structure, behavior, interfaces, and constraints - then the digital twin is the runtime instantiation of that model, fed with real-world data from the operational system.

INCOSE’s Vision 2035 connects these concepts explicitly: the design model and the digital twin are not separate artifacts but different lifecycle phases of the same information architecture. The model describes what the system should be. The twin describes what the system is. The delta between them is where engineering attention should focus.

This is where “models that run” becomes literal. A SysML v2 model with executable semantics - state machines, constraint blocks, parametric relationships - can be simulated. It can be compared against operational data. It can predict behavior before the physical system exists and validate behavior after it’s deployed.

We’re not there yet. The tooling for full executable SysML v2 is still maturing. But the architectural foundation is in place, and the direction is clear. The model is not a picture. It is not a document. It is operational infrastructure.

The version control revolution

Let’s be concrete about what this means for organizations currently struggling with MBSE.

Today, most organizations treat system models as artifacts produced by a small team of modeling specialists. The models are reviewed periodically. They’re exported to documents for wider consumption. They’re maintained (if at all) by the people who created them.

In the “models as code” paradigm, system models are treated like any other engineering artifact in a modern development workflow:

Every change is tracked. Not just “who modified this element,” but the full context: what branch, what merge request, what review comments, what automated checks passed.
History is meaningful. You can answer “what did the architecture look like six months ago?” and “why did we change the interface between these two subsystems?” by reading the git history, not by asking the one person who remembers.
Collaboration is natural. Engineers work on branches, propose changes, review each other’s work. No element locking. No “I can’t work on that because Maria has it checked out.” Real collaboration, the way software teams have worked for decades.
Automation is the default. Validation, documentation generation, consistency checking, coverage analysis - these happen automatically, continuously, without anyone remembering to click a button.

This is not a distant future. The pieces exist now. SysML v2 provides the textual syntax. Git provides the version control. CI/CD platforms provide the automation. The integration work is non-trivial, but it’s engineering work, not research.

What this demands of tools

The “models that run” vision makes specific demands of MBSE tooling that most current tools fail to meet:

The tool must treat the model as the primary artifact, not the diagram. Tools that store models as serialized diagram state will never support meaningful diffing, merging, or programmatic access.

The tool must support standard version control. Proprietary versioning systems that lock engineers into a single tool’s ecosystem are incompatible with the collaborative workflows that modern engineering demands.

The tool must expose APIs. Not as an afterthought, not as an enterprise add-on, but as a core architectural commitment. If external tools can’t query and contribute to the model, the model remains an island.

The tool must generate artifacts, not just display them. Documentation, diagrams, matrices, reports - these should be derived views, generated on demand, always current. If an engineer has to manually maintain both the model and its downstream artifacts, the model will lose.

The industry has spent two decades building tools that are essentially diagramming applications with a database behind them. The next generation of tools needs to be model management platforms that happen to produce diagrams when you need them.

The model isn’t a picture of your system. It’s the operating system for engineering your system. It’s time to build tools that treat it that way.

This is Part 9 of “The MBSE Reckoning,” a 10-part series from Luvian on the state and future of Model-Based Systems Engineering.

In this series: Part 1: The Breaking Point · Part 8: AI Won’t Save MBSE · Part 9: Models That Run (You are here) · Part 10: A Practitioner’s Manifesto

Subscribe to our newsletter to get each article as it publishes.