The Priesthood Problem: MBSE's Stakeholder Visibility Crisis

Picture the weekly program review for a major defense system. Twenty people in the room. The program manager needs to know whether the system architecture can absorb a scope change from the customer. The safety analyst needs to confirm that the new operating mode doesn’t violate the hazard analysis. The test lead needs to understand which interfaces are affected so they can update the verification plan. The engineering VP just wants to know if they’re on track.

The systems engineer pulls up a SysML block definition diagram.

Half the room stops paying attention. The other half is trying to figure out which box represents the subsystem they care about. The SE narrates the diagram for ten minutes. Someone asks a question that requires switching to an internal block diagram. Then a requirements diagram. Then a parametric diagram. Forty-five minutes later, the SE has answered maybe two of the five questions that actually mattered, and every answer required real-time interpretation by the only person in the room who can read the notation.

This is MBSE’s stakeholder visibility crisis. The model was supposed to be the single source of truth that gives everyone a shared understanding of the system. Instead, it created a priesthood - a small group of specialists who can navigate the models - and everyone else gets secondhand translations.

The PowerPoint translation layer

In practice, most MBSE stakeholder communication follows a remarkably consistent and remarkably wasteful pattern:

The SE builds or updates a model in their MBSE tool of choice
The SE exports a screenshot or diagram view
The screenshot gets pasted into a PowerPoint slide
The slide gets annotated with plain-English explanations
The annotated slide gets presented in a meeting
The meeting generates discussion and decisions
Someone takes notes on the decisions
The notes may or may not get reflected back into the model

Every step in this chain degrades information. The model contains structure, relationships, constraints, and traceability. The screenshot loses the relationships. The PowerPoint loses the constraints. The meeting discussion introduces interpretations that may not match the model’s semantics. The notes capture conclusions without preserving the reasoning. And the feedback loop back to the model is manual, intermittent, and frequently broken.

This is the information equivalent of the telephone game, except the stakes are a multimillion-dollar engineering program.

The irony is suffocating. The whole point of MBSE was to replace document-centric engineering with model-centric engineering. Instead, organizations have replaced one set of documents - Word specifications - with a different set of documents - PowerPoint translations of models. The model exists, but it’s not the communication medium. It’s the thing that gets translated into the communication medium.

Who gets left out

The priesthood problem doesn’t affect all stakeholders equally. Different roles have different information needs, and the current model-centric approach fails each of them in different ways.

Program managers need to track scope, schedule risk, and resource allocation. They need to know which requirements are at risk, which interfaces are unstable, and which subsystems are behind. They don’t need to understand parametric diagrams. They need a dashboard that shows program health in terms they understand - requirements coverage, verification status, change impact, and critical path items.

Safety analysts need to trace hazards through the architecture to safety requirements and verification evidence. They need to confirm that design changes don’t invalidate existing safety analyses. They operate in a world of HARA, FMEA, and fault trees - all of which reference the system architecture but use their own notation and mental models. Asking a safety analyst to extract this information from SysML diagrams is asking them to translate between two formal systems in real time.

Test engineers need to understand what changed and what needs to be re-verified. They need interface specifications, performance budgets, and requirement allocations - not as diagram views, but as structured data they can feed into test planning tools. A test engineer looking at a block definition diagram is looking at the wrong abstraction level for the question they’re trying to answer.

Executives need to make resource decisions, manage risk, and report to customers or regulators. They need system maturity indicators, readiness gates, and compliance status. They need this information at a glance, updated in near-real-time, and presented in business terms. What they typically get is a monthly briefing with screenshots from a tool they don’t have access to.

Developers - as we discussed in Part 5 - need architecture decisions expressed as API contracts, interface specifications, and code scaffolds. They don’t need SysML fluency. They need the model’s output in a form that integrates with their workflow.

In each case, the failure is the same: the model contains the information the stakeholder needs, but it’s not accessible in a form the stakeholder can use.

The cost of mediation

The priesthood doesn’t just create an information bottleneck. It creates a dependency chain that has real costs.

First, there’s the direct cost of translation. Every time a stakeholder needs model information, a systems engineer has to stop doing engineering work and start doing interpretation work. In organizations we’ve spoken with, senior SEs report spending 30-40% of their time creating presentations, answering questions about diagrams, and manually extracting data from models for consumption by other roles. This is highly skilled labor being used as a human API layer.

Second, there’s the latency cost. When a program manager needs to assess the impact of a scope change, they can’t query the model directly. They have to ask the SE, wait for the SE to analyze the model, wait for the SE to translate the analysis into stakeholder-friendly terms, and then review the result. A question that could be answered in seconds with a proper query interface takes days or weeks to resolve through the mediation chain.

Third, there’s the accuracy cost. Every mediation step introduces interpretation. The SE decides what’s relevant to show, how to frame it, and what to omit. These are judgment calls made under time pressure, and they’re not always correct. The stakeholder receives a filtered view that may not include the information they actually need - but they have no way to know what was filtered out.

Fourth - and most insidiously - there’s the decision quality cost. When stakeholders make decisions based on mediated information, they’re making decisions based on someone else’s interpretation of the data. Good SEs are good interpreters, but interpretation is not the same as direct access. The stakeholder who can interrogate the data directly will make better decisions than the stakeholder who receives a curated summary.

Dashboards, not diagrams

The solution isn’t teaching every program manager to read SysML. That’s the MBSE community’s version of “let them eat cake” - technically correct and practically useless. You wouldn’t ask a CEO to read the codebase to understand product status. You build dashboards, reports, and alerts that surface the right information at the right abstraction level.

The same principle applies to system models. The model is the data layer. What’s missing is the presentation layer - role-specific views that extract relevant information from the model and present it in terms each stakeholder understands.

For a program manager, that means: requirements coverage by subsystem, verification status against milestones, change impact analysis in terms of schedule and resource effects, and a risk register that’s automatically updated when the architecture changes.

For a safety analyst, that means: a risk posture view showing hazards, their mitigations, and the current verification status of each mitigation. When a design change occurs, the safety analyst sees which hazards are potentially affected - not because someone told them, but because the tool traced the change through the architecture to the relevant safety requirements.

For an executive, that means: readiness gates that aggregate across all dimensions - requirements maturity, architecture stability, verification completeness, and safety compliance. Green, yellow, red - with the ability to drill down when something isn’t green.

For a test engineer, that means: a structured feed of interface changes, performance budget updates, and new verification requirements - in a format that integrates with their test management tooling, not a format that requires them to open a modeling tool.

None of this is technically exotic. The information is already in the model. The problem is that MBSE tools were designed by modelers for modelers, and the concept of “stakeholder view” was an afterthought - a reporting feature bolted onto a modeling workbench, not a first-class design concern.

Democratization vs. dumbing down

There’s a legitimate objection here, and it deserves a direct answer. Some in the MBSE community worry that “making models accessible” means diluting them - stripping away the rigor and precision that makes them valuable in the first place. If you simplify the model for non-technical stakeholders, do you lose the engineering fidelity that’s the whole point?

The answer is no, but only if you draw the right distinction.

The model stays rigorous. The underlying SysML representation, the formal relationships, the typed interfaces, the constraint equations - all of that remains. The model doesn’t get simplified. It’s the canonical representation, maintained by people who understand modeling, governed by the standards that ensure consistency and completeness.

The views get tailored. What changes is how non-modelers interact with the model’s information. A program manager doesn’t need to understand the model’s internal structure. They need to understand what the model tells them about program health. A safety analyst doesn’t need to navigate block definition diagrams. They need to see hazard traceability. These are views - projections of model data onto role-specific concerns - not simplifications of the model itself.

This is exactly how every other data-intensive discipline works. A database administrator maintains a normalized schema. Business analysts query it through dashboards. Financial analysts see it through reporting tools. Nobody suggests that the existence of a dashboard means the database should be less rigorous. The rigor is preserved at the data layer. The accessibility is provided at the presentation layer.

MBSE has been missing this separation. The modeling workbench is simultaneously the authoring tool, the data store, and the only presentation layer. Opening up the presentation layer doesn’t compromise the data layer. It completes the architecture.

The developer is disconnected too

It’s worth noting that the priesthood problem isn’t limited to non-technical stakeholders. As we explored in Part 5, developers are equally disconnected from the system model. They don’t see architecture decisions in a form they can use. They don’t receive requirement changes as structured notifications. They don’t have traceability from their code back to the model that justified it.

The developer is as mediated from the model as the program manager is. They just get their translations in a different format - issue tracker tickets and wiki pages instead of PowerPoint slides.

This means the priesthood problem isn’t about technical sophistication. It’s not that some stakeholders are too unsophisticated to read models. It’s that the model’s communication interface is limited to a single modality - the modeling workbench itself - and that modality serves exactly one audience: the modeler.

Every other audience - PMs, safety analysts, test engineers, developers, executives - is receiving degraded translations of model data. The system that was supposed to be the single source of truth is, in practice, the single source of PowerPoint screenshots.

What breaks when visibility fails

The consequences of the priesthood problem compound over time. In the early phases of a program, the model is small enough that a single SE can mediate effectively. But as the system grows - more requirements, more interfaces, more subsystems, more stakeholders - the mediation workload grows superlinearly. The SE becomes a bottleneck. Stakeholders stop asking questions because the turnaround time is too long. Decisions get made without model data. The model drifts from reality because the feedback loop that would correct it - stakeholders identifying discrepancies - is broken.

This is how organizations end up with a model that nobody trusts. Not because the model is wrong, but because the model is invisible. And an invisible source of truth isn’t a source of truth at all.

The fix isn’t more SEs or better PowerPoint templates. It’s treating stakeholder visibility as a first-class engineering concern - building the views, dashboards, and role-specific interfaces that make the model’s information directly accessible to every role that needs it.

The model should serve every audience, not just the modeler.

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

Previous: Part 5 - Two Tribes
Next: Part 7 - Intent Doesn’t Survive the Pipeline

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