What Comes Next: A Practitioner's Manifesto for MBSE 2.0

Over the past nine weeks, we’ve laid out the case. MBSE has won the argument but lost the practitioners. The tools are hostile. The models are disconnected. Maturity is unmeasured. Systems engineers and developers speak different languages. Stakeholders are locked out. Intent doesn’t survive the pipeline. AI promises more than it delivers. And the models themselves remain static artifacts when they should be living infrastructure.

None of this is fatal. MBSE is not dying. It is stuck - caught between the vision it promised and the reality it delivered. The question is whether the industry has the honesty to acknowledge what’s broken and the will to fix it.

We believe it does. But it won’t happen through another standard, another metamodel revision, or another vendor keynote. It will happen through a change in principles - a shared understanding of what MBSE 2.0 must prioritize to succeed where MBSE 1.0 stalled.

This is our attempt at those principles. Eight commitments that we believe the industry - tool vendors, adopting organizations, standards bodies, and practitioners - must embrace to move past the current crisis. We wrote them for ourselves first. We publish them for accountability.

The Eight Principles of MBSE 2.0

1. Accessibility over completeness

If 90% of stakeholders can’t use the tool, the ontological completeness of the metamodel doesn’t matter.

MBSE tools have historically been built for the modeler - the person who understands SysML stereotypes, multiplicity constraints, and behavioral state machines. These users matter. But they represent a small fraction of the people who need to interact with system data. Program managers need schedule and risk views. Safety analysts need hazard-to-requirement traceability. Developers need interface specifications. Executives need progress dashboards. Test engineers need verification matrices.

When tools require specialized training to access any of this information, the model becomes a gated artifact - authoritative in theory, inaccessible in practice. The first duty of any MBSE tool is to be usable by the people who need the data, not just the people who create it. A model that only modelers can read has failed its primary mission, no matter how formally correct it is. Accessibility is not a feature request. It is a prerequisite for relevance.

2. Connection over containment

The model must be a node in the digital thread, not a standalone artifact.

The containment instinct is strong in MBSE tooling. Vendors want the model to be the center of the universe - the place where all engineering data lives, managed by their platform, governed by their licensing. The result is informational silos. The model knows about requirements and architecture but is blind to the issue tracker tickets, Git commits, test results, and deployment states that represent the actual progress of engineering.

MBSE 2.0 treats the model as one participant in a connected ecosystem. It exposes APIs. It consumes data from adjacent tools. It publishes model changes to downstream consumers. The value of a model is proportional to the number of things it connects to. A beautifully detailed SysML model that can’t answer “which requirements changed since the last build?” is less useful than a rough block diagram linked to the CI/CD pipeline, the test management system, and the issue tracker. Connection creates value. Containment destroys it.

3. Progressive maturity over revolution

Meet organizations where they are. Don’t demand a clean break from everything they’ve done before.

The MBSE adoption pattern has been catastrophically binary: either you’re “doing MBSE” (full SysML, dedicated modelers, enterprise tooling) or you’re not. There’s no recognized middle ground. No on-ramp. No way to get value from partial adoption.

This is why MBSE deployments fail. Organizations are told they need to transform everything at once - new tools, new processes, new roles, new thinking. The investment is massive. The disruption is total. And when the results don’t materialize in 18 months, leadership declares the experiment a failure.

MBSE 2.0 must support progressive maturity - a clear path from “we track requirements in spreadsheets” to “we have a living, connected system model” that delivers value at every step along the way. Each increment should be independently useful. Organizations should be able to start with structured block diagrams, add traceability when they’re ready, incorporate behavioral models when the complexity demands it, and eventually reach full model-based workflows. Demanding perfection on day one guarantees failure by month three.

4. Convergence over handoff

Systems engineering and software development must share artifacts, not translate between them.

The handoff between SE artifacts and development artifacts is one of the most expensive failure modes in modern engineering. A systems engineer creates a functional decomposition. A software architect creates a design. A developer creates an implementation. At each boundary, information is translated - from SysML to UML to code, from requirements documents to user stories to acceptance tests - and at each translation, intent is lost.

MBSE 2.0 eliminates the translation layer. The system model and the development artifacts share a common representation - or at minimum, a bidirectional, automated bridge. SysML v2’s textual syntax and API architecture make this possible: interface definitions in the system model can generate code stubs. Test specifications in the model can generate test scaffolds. Requirements in the model can appear as tracked items in the development workflow. Not through manual export, but through continuous synchronization. When SE and dev share artifacts, the “two tribes” problem from Week 5 dissolves - not because the cultures merge, but because the artifacts stop requiring interpretation.

5. Intent over structure

Every model element should carry “why,” not just “what.”

In Week 7, we argued that intent doesn’t survive the engineering pipeline. Requirements capture what the system must do, but the rationale - the trade-offs, the constraints, the rejected alternatives - is lost as soon as the requirement is written. Developers implement the “what” and infer the “why.” When they infer wrong, the defect isn’t in the code. It’s in the communication.

MBSE 2.0 makes intent a first-class citizen of the model. Every allocation, every decomposition, every interface definition should be annotatable with rationale - not as a free-text comment that nobody reads, but as a structured element that can be queried, traced, and audited. Why was this function allocated to this subsystem? What trade-off drove the interface protocol selection? What failure mode motivated the redundancy architecture? These decisions are the most valuable engineering knowledge an organization produces. Today they live in meeting minutes, email threads, and the memories of senior engineers. They should live in the model.

6. Continuous assurance over end-stage gates

Verification moves left, or it arrives too late.

The traditional verification model - design, build, then test - is a relic of an era when building physical prototypes was the only way to discover integration problems. In a world where models can be queried, simulated, and analyzed computationally, there is no excuse for waiting until integration test to discover that two subsystems have incompatible interfaces.

Continuous assurance means that every model change triggers automated validation. Constraint checks, consistency verification, coverage analysis, compliance assessment - these run on every commit, not at milestone gates. The model doesn’t just describe the system; it continuously evaluates itself against the constraints the system must satisfy. When a design decision violates a safety constraint, the engineer learns immediately - not six months later when the test fails and the redesign costs ten times what it would have cost to catch it in design. Verification is not a phase. It is a continuous property of the engineering process.

7. Views for every role

The model serves the program manager, the safety analyst, the executive, and the modeler.

In Week 6, we described the priesthood problem: a small group of modelers who can read the models, and everyone else who gets PowerPoint translations. This is not a tooling failure alone. It’s a design philosophy failure. MBSE tools were built on the assumption that the model has one audience - the modeler - and everyone else should receive filtered exports.

MBSE 2.0 assumes the model has many audiences, each with different needs, each equally legitimate. The program manager needs a view that shows schedule risk, resource allocation, and requirement completion. The safety analyst needs a view that shows hazard-to-mitigation traceability and ASIL allocation. The executive needs a view that shows program health in five minutes, not five hours. The developer needs a view that shows interface contracts and behavioral specifications. The modeler needs the full ontological view. All of these are valid. All of them should be derivable from the same underlying model. A tool that serves only one audience has chosen to exclude the others. That choice should not be acceptable.

8. Honesty over roadmap theater

Ship with acceptance criteria. Communicate direction changes. Earn trust.

This final principle is directed at tool vendors - including ourselves. The MBSE tool market has a trust deficit, and vendors have earned it. Features are announced at conferences and don’t ship for years. Roadmaps are presented as commitments and treated as aspirations. Organizations invest in tools based on promised capabilities that never materialize. When features do ship, they ship without acceptance criteria - no way for customers to evaluate whether the feature actually solves the problem it claimed to address.

MBSE 2.0 demands transparency. Ship features with clear, testable acceptance criteria. When a roadmap changes, communicate why. When a feature doesn’t work as advertised, acknowledge it and commit to a timeline. This isn’t corporate virtue - it’s the minimum standard of professional conduct in an industry where tool decisions have multi-year consequences and multi-million-dollar implications. The era of slideware-driven sales must end. Practitioners deserve tools that are as honest about their limitations as they are ambitious about their vision.

This is what we’re building toward

These eight principles are not abstract ideals. They are the design criteria we hold ourselves to at Luvian. Every product decision, every feature prioritization, every architecture choice gets measured against them.

We don’t claim to have achieved all of them. We have not. Accessibility is strong but incomplete. Connection is growing but not universal. Progressive maturity is in our DNA but needs more on-ramps. We’re further along on some principles than others, and we are honest about the gaps.

But we believe that naming these principles - publicly, in writing, with specificity - creates accountability. Not just for us, but for the industry.

Here’s how you can hold us accountable:

Ask us which principles a new feature serves. We should be able to answer immediately.
Ask us for acceptance criteria. Every feature should ship with testable success conditions.
Ask us what’s not working. We should tell you honestly, without hedging behind roadmap promises.
Ask the other vendors the same questions. The answers will tell you everything you need to know about who is serious about fixing MBSE and who is just selling the next version of the same broken paradigm.

A final word

Ten weeks ago, we opened this series with a blunt assessment: MBSE has won the argument but is losing the war. The tools are failing practitioners. The models are disconnected from the work. The industry is stuck.

We stand by that assessment. But we also believe - genuinely, not as a marketing position - that the path forward is visible. SysML v2 provides the semantic foundation. Modern web architecture provides the platform. AI provides the accessibility bridge. And a growing community of frustrated, talented practitioners provides the demand signal.

What’s been missing is honesty about the problem and commitment to a different set of priorities. Not ontological completeness above all else. Not vendor lock-in disguised as platform strategy. Not conference demos that bear no resemblance to the production experience.

Instead: accessibility, connection, progressive maturity, convergence, intent, continuous assurance, role-based views, and honesty.

MBSE 2.0 is not a product. It’s not a standard. It’s a set of principles that the industry must adopt to serve the practitioners who are building the most complex systems humanity has ever attempted. Autonomous vehicles. Hypersonic platforms. Surgical robots. Space systems. These engineers deserve tools that work as hard as they do.

That’s what this series has been about. That’s what we’re building. And that’s the conversation we hope the rest of the industry is ready to have.

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

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

If these ideas resonated, subscribe to our newsletter for what comes next. The reckoning is just the beginning.