Intent Doesn't Survive the Pipeline (And That's the Real Problem)

Over the past six weeks, we’ve catalogued five structural problems with MBSE as it’s practiced today: hostile tooling, disconnected workflows, unmeasured maturity, the SE-developer divide, and the stakeholder visibility crisis. Each one is real. Each one is independently damaging. And each one is a symptom of something deeper.

Here’s the thesis: intent degrades at every handoff in the engineering pipeline. Not sometimes. Every time. Structurally and predictably. At each boundary between disciplines, roles, and tools, the “why” gets stripped away, leaving only the “what” - and often a lossy version of the “what” at that.

This is the root cause. Everything else we’ve discussed in this series is a consequence.

The intent degradation pipeline

Follow the life of a product decision through a typical engineering organization:

Stakeholder to Product. A customer articulates a need: “We need autonomous navigation in GPS-denied environments.” This statement carries enormous context - operational scenarios, threat environments, mission profiles, acceptable risk levels, competitive pressures, regulatory constraints. The product manager translates this into a feature specification. In that translation, the operational context gets compressed. The threat environment becomes a paragraph. The acceptable risk becomes a TBD. The competitive pressures are omitted entirely because they don’t fit in the requirements template.

Product to Systems Engineering. The product specification arrives at the SE team as a set of requirements and a concept of operations. The SE decomposes these into a system architecture - subsystems, interfaces, behaviors, constraints. In this translation, the business context evaporates. The SE knows what the system must do but has limited visibility into why this particular capability matters more than another, or which trade-offs the stakeholder would accept. The architecture optimizes for technical elegance within the constraints as stated, but the constraints as stated are already a lossy encoding of the stakeholder’s actual intent.

Systems Engineering to Development. The architecture arrives at the development team as design documents, interface specifications, and issue tracker tickets. In this translation - as we explored in Part 5 - the architecture intent gets compressed further. A carefully designed interface becomes a ticket that says “implement telemetry API.” The rationale for the interface’s structure, the constraints that shaped it, the alternatives that were considered and rejected - all of this is lost. The developer implements what the ticket says, using their best judgment to fill in the gaps.

Development to QA. The implementation arrives at QA as a feature to be tested. The test engineer writes tests based on the requirements as they understand them - which is the requirements as interpreted by the developer, as decomposed by the SE, as specified by product, as articulated by the stakeholder. Four translation layers deep. The test verifies that the code does what the ticket said to do. It cannot verify that what the ticket said matches what the stakeholder actually needed.

At each boundary, context is lost. Rationale is stripped. Trade-off decisions become invisible. The final implementation may be technically correct against every specification it received and still fail to deliver what the stakeholder needed - because the specifications themselves were degraded copies of the original intent.

What gets lost at each boundary

The losses aren’t random. They follow predictable patterns:

Business context gets lost at the stakeholder-to-product boundary. Why this capability? Why now? What’s the competitive pressure? What’s the regulatory deadline? What happens if we deliver 80% of this capability instead of 100%? Product managers carry this context, but it rarely survives serialization into requirements documents. Requirements capture the “shall” but not the “because.”

Architecture intent gets lost at the product-to-SE boundary. Why this decomposition? What alternatives were considered? What constraints drove the interface design? Which architectural decisions are load-bearing and which are provisional? The SE knows, but the artifacts they produce - diagrams, specifications, allocation matrices - capture the result of the reasoning without capturing the reasoning itself.

Design rationale gets lost at the SE-to-developer boundary. Why is this interface shaped this way? Why does this constraint exist? What would break if a developer made a different structural choice? The ticket says “implement X.” It doesn’t say “implement X because Y would violate constraint Z, which exists because of stakeholder requirement W.” The developer fills in the blanks with assumptions.

Acceptance context gets lost at the developer-to-QA boundary. What does “correct” mean for this feature? Not in terms of requirements satisfaction - that’s checkable - but in terms of user expectation. Is there an edge case the stakeholder mentioned verbally that never made it into the spec? Is there a performance threshold that was discussed but not formalized? The tester verifies against the written specification, which is a subset of the actual expectation.

The pattern is consistent: each handoff preserves structure and strips meaning. The formal artifact gets passed along. The informal knowledge - the context, rationale, constraints, and trade-offs that shaped it - stays in the head of the person who created it.

Three compounding patterns

Intent degradation doesn’t just happen in isolation. Three organizational patterns make it worse.

Handoff translation costs

Every boundary between disciplines requires a translation. Product to SE is a translation from business language to engineering language. SE to developer is a translation from architecture language to implementation language. Each translation takes time - often weeks - and introduces interpretation errors.

Organizations respond to these translation costs in predictable ways. They create more documents to capture the translations. They schedule more meetings to synchronize the translations. They hire more program managers to coordinate the translations. None of this reduces the underlying problem. It just adds layers of overhead to a fundamentally lossy process.

The cost is staggering. In the organizations we’ve spoken with, engineers estimate that 40-60% of their time is spent on coordination, communication, and documentation - not on engineering. The majority of that coordination overhead is translation work: converting information from one discipline’s format to another’s.

Coordination overhead

As systems grow in complexity, the number of handoffs grows combinatorially. A system with five subsystems, each owned by a different team, doesn’t have five handoffs. It has handoffs between every pair of teams that share an interface - and that number grows quadratically with the number of teams.

The moment product decisions become tickets, work enters a system dependent on interpretation and prioritization rather than direct execution. The ticket queue becomes a bottleneck not because there’s too much work, but because every ticket requires the recipient to reconstruct the intent that was stripped away during the handoff. Engineers spend time decoding tickets, asking clarifying questions, scheduling alignment meetings, and building mental models of what was actually meant - all before they write a line of code.

This coordination overhead doesn’t scale. As programs grow, the ratio of coordination work to engineering work gets worse, not better. Organizations respond by adding more processes, more reviews, and more checkpoints - each of which adds latency without addressing the underlying cause.

Engineering as sole constraint

There’s a subtler pattern at work too. In most organizations, engineering bandwidth is treated as the primary constraint. Product backlogs are prioritized based on engineering capacity. Roadmaps are built around sprint velocity. Delivery timelines are estimated based on implementation complexity.

But engineering capacity hasn’t been the binding constraint for years - and with AI-accelerated development, it’s becoming even less so. The binding constraint is intent coordination: the ability to ensure that what gets built matches what was needed, across every handoff in the pipeline.

A team that can implement features in days but takes weeks to align on what to implement isn’t constrained by engineering velocity. It’s constrained by the speed at which intent traverses the pipeline. Speeding up implementation without speeding up intent coordination just means you build the wrong thing faster.

The speed paradox

This brings us to the central paradox of AI-accelerated engineering: AI makes implementation faster, but intent coordination is still manual.

Coding assistants can generate boilerplate in seconds. Test generation tools can produce test suites from specifications. Deployment automation can ship changes continuously. The implementation phase of the pipeline is being compressed dramatically.

But the front of the pipeline - stakeholder alignment, requirements decomposition, architecture decision-making, trade-off analysis - is still manual. Still meeting-driven. Still dependent on human translators at every boundary. Still lossy.

The result is a pipeline that’s fast in the middle and slow at both ends. Features get implemented quickly but specified slowly and validated slowly. The bottleneck shifts from “how fast can we build it” to “how fast can we agree on what to build and verify that we built the right thing.”

Organizations that don’t recognize this shift will invest in making implementation even faster while ignoring the coordination bottleneck that actually determines delivery speed. They’ll buy AI coding tools and wonder why their programs aren’t finishing sooner.

Intent engineering as a structural solution

If intent degradation is the root cause, the structural solution is to preserve intent through the pipeline. Not through more documents. Not through more meetings. Through artifacts that carry context alongside content.

We’re calling this “intent engineering” - the practice of structuring work artifacts so that the “why” travels with the “what” at every handoff.

An intent-engineered work artifact includes:

Objective. What outcome we’re trying to achieve - stated in terms of the stakeholder’s need, not the implementation team’s task. Not “implement telemetry API” but “enable real-time health monitoring so operators can detect degradation before mission-critical failure.”

Outcomes. The measurable results that would demonstrate success. Not output metrics (features shipped, tests passed) but outcome metrics (operator response time reduced by X, false alarm rate below Y). These are the criteria that determine whether the intent was actually fulfilled, not just whether the specification was satisfied.

Health metrics. The indicators that tell you whether you’re heading toward the outcome or away from it. Leading indicators, not lagging ones. What would you check weekly to know if this work is on track - not in terms of schedule, but in terms of value delivery?

Constraints. The boundaries that shape the solution space. Not just technical constraints (performance budgets, interface compatibility) but business constraints (regulatory deadlines, competitive windows) and stakeholder constraints (acceptable risk levels, budget envelopes). The constraints that were in the stakeholder’s head when they articulated the need.

Autonomy. What the team is empowered to decide without escalation. What trade-offs they can make independently. What requires stakeholder input. This is where most intent degradation gets worse - teams encounter ambiguity, make assumptions rather than escalating, and the assumptions compound through the pipeline.

Stop rules. The conditions under which the team should pause and seek realignment rather than continuing. What would indicate that the original intent has been invalidated? What would signal that the problem has changed enough that the solution needs to change too?

This isn’t a new meeting format or a new document template. It’s a structural change to how work is specified - ensuring that context, rationale, and decision boundaries travel with the work item through every handoff.

The why behind the why

This is Part 7 of a ten-part series, and it’s here deliberately. We’ve spent five weeks diagnosing symptoms. The tools are hostile. The workflows are disconnected. The maturity isn’t measured. The two tribes can’t communicate. The stakeholders can’t see what’s happening.

Each of those problems is a manifestation of intent degradation at a specific boundary in the pipeline. Hostile tools strip context by forcing engineers to think in notation instead of engineering concerns. Disconnected workflows break the feedback loops that would correct intent drift. Unmeasured maturity means organizations can’t detect degradation until it’s catastrophic. The SE-developer divide is the highest-bandwidth intent loss channel in the entire pipeline. And the stakeholder visibility crisis means the people who hold the original intent can’t verify whether it survived.

The five gripes aren’t a list. They’re a causal chain. And the structural response isn’t to fix each one independently - it’s to build systems, tools, and practices that preserve intent across every boundary.

That’s what “MBSE 2.0” needs to be. Not better modeling tools. Not more comprehensive ontologies. Not stricter process frameworks. A system where the stakeholder’s intent is traceable, verifiable, and preserved from the moment it’s articulated to the moment it’s validated in the field.

Everything else is treating symptoms.

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

Previous: Part 6 - The Priesthood Problem
Next: Part 8 - AI Won’t Save MBSE (But It Might Make It Usable)

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