When an engineering workflow breaks down at scale, the answer is not always more data. Often, the answer is better structure around the data the team already has.

That was one of the strongest lessons from the VIPR-GS team’s autonomous ground vehicle project. Their early workflow could generate validation data, but the data did not automatically explain itself. The team needed a way to connect requirements, architecture, models, simulations, and validation results so that outcomes could become evidence for decisions.

Two ideas became central: executable architecture and evidence-based traceability.

Executable architecture gave the team a way to connect system structure with model-based design implementations. Instead of treating architecture as a static diagram, they could use it to organize components, variants, parameters, and behaviors in a way that supported exploration and validation. Chinmay described this as the place where MBSE and Model-Based Design came together.

Evidence-based traceability changed the role of validation results. Instead of having KPIs as data that engineers had to interpret manually, the team could trace results back to requirements and architectural elements. That helped shift the question from “what failed?” to “what caused the failure, which requirement was affected, and what should we change?”

For engineering leaders, this is a critical distinction. Traceability is not valuable just because artifacts are linked. It becomes valuable when those links help a team make better decisions, defend a design decision, understand the impact of change, and focus improvement efforts where they matter.

Interview

Tanmay Samak      Chinmay Samak

Q: What role did executable architecture play in the project?

Chinmay Samak: Executable architecture is where MBSE and Model-Based Design come together. You have a system architecture, and the components can be implemented with Model-Based Design. For something like an off-road autonomous vehicle, there are too many design variants, design choices, and parameters to manage without that structure.

Q: What made traceability valuable in this workflow?

Chinmay Samak: If you stop at the system architecture and simulation data, it is only partly valuable. The true value comes when the data has traceability back to requirements and components in the architecture. Then you do not need a gut feeling to associate a KPI with a system component. The digital thread gives you a causal relationship, including how design evolutions changed validation outputs.

Q: Did the structure slow you down at first?

Tanmay Samak: It can feel like inertia at the beginning because you have to think from the systems level from day one. But what you gain is the ability to offload complexity into a systematic digital thread with full traceability. You can inform design choices and the operational design domain from structured validation results rather than intuition.

Q: What did it feel like to work in an executable architecture from day to day? 

Tanmay Samak: It felt like we could manage complexity without being overwhelmed. We could work from the most granular level back up to the system architecture. That ability to zoom in and out across system, subsystem, and component levels was powerful because we could focus on a small piece without losing the larger context.

Q: What does evidence-based traceability mean to you?

Chinmay Samak: It means having causal evidence for what affects what. Without that, you cannot know when the system will work or fail, and you cannot make informed choices about how to improve it. With evidence-driven traceability, validation results can show not only that a system-level performance objective was missed, but also which component requirement was or was not met.

Key takeaways 

• Executable architecture connects system structure to executable behavioral models. This is where MBSE and Model-Based Design come together.  

• Traceability becomes more valuable when it is evidence-based, not just artifact-based. 

• Validation results should help teams understand causes, not just record outcomes. 

• The initial structure may feel like overhead, but it provides a systematic way to manage growing system complexity. 

• A connected workflow improves decision quality because results can be explained, defended, and acted on.

How much of your understanding of system behavior comes from traceable evidence, and how much relies on expert interpretation and intuition? 

Next in the series: Once the structure is in place, how do teams start adopting digital engineering without getting stuck on tools, terminology, or early process overhead? 

Bonus material: This video includes the latest version of the work discussed in this blog series that integrates agentic tools into the digital engineering workflow.

DISTRIBUTION STATEMENT A. Approved for public release; distribution is unlimited. OPSEC11080.</