How to Achieve Trustworthy Engineering Data in A&D Programs?

The tools are there (MBSE, PLM, ALM), and most A&D programs have invested heavily in their Engineering Toolchain over the years. Yet they still struggle with fragmented data, unclear authoritative sources, broken traceability, and lack of cross-tool analytics and viewpoints.

Meanwhile, the US DoD Data Strategy requires that engineering data be visible, accessible, linked, trustworthy, interoperable, secure, and understandable. DoDI 5000.97 makes this mandatory for acquisition and engineering programs.

Meeting these goals requires more than domain tools. As a matter of fact, implementing tools without a deliberate and thought-out data architecture and infrastructure behind them is where most engineering programs stall.

This article explores why and identifies the architectural foundations that are typically missing:

• Standard-based interoperability
• Cross-domain traceability
• Cross-domain viewpoints and analytics
• Configuration management

It concludes with a practical picture of how these foundations translate into trustworthy, connected engineering data within programs.

👉 What you'll learn in this article:

• Why the DoDI 5000.97 raises the bar for defense engineering data →
  
  
• The seven DoDI requirements defense programs must satisfy →
  
  
• How VAULTIS defines what trustworthy engineering data must look like →
  
  
• Where A&D programs fall short: seven recurring architectural gaps →
  
  
• Why a Digital Engineering Environment (DEE) is the missing layer →
  
  
• The four architectural foundations of a working DEE →
  
  
• Key takeaways →
  
  
• FAQ →

The 7 High-Level DoDI Requirements for Digital Engineering Capability

1. Extensive Cross-Functional Accessibility

Eliminate functional silos: everyone, from the initial requirements author to the frontline sustainment mechanic, must operate within the same digital fabric.

2. End-to-End Lifecycle Connection

Ensure continuous, bidirectional information flow across program phases. For example, operational and testing data collected in the field is fed back into engineering to inform design updates.

3. Rigorous Model Management & Environmental Fidelity

Mandate strict data governance and configuration control over program models, specifically ensuring that models are accurate enough to replace or significantly reduce physical testing.

Replacing physical (hardware-in-the-loop) testing iterations with virtual and model-based validation is a key strategy to make A&D programs much more efficient. Nevertheless, this requires the model to be trustworthy.

4. DevSecOps and Automated Testing Infrastructure

DevSecOps is an augmentation of the software DevOps lifecycle model with embedded security operations. The DevOps lifecycle promotes agility based on repeated “plan/build/test/deploy/integrate feedback” iterations.

The DoDI requires systems engineering to follow this pattern with automated software/hardware pipelines to:

• Support verification and validation of requirements

• Enable automated cyber/security testing

• And ensure frequent, time-bound, and repeatable software deployment to the field

5. Secure Information Ecosystem (Zero Trust)

Address the security risks of aggregating massive amounts of program data in one place. It mandates advanced data security such as Zero Trust (where anything, even within the network, is considered a threat and needs to be secured), and strict compliance with privacy regulations, such as the Privacy Act.

6. Operational Security (OPSEC) Compliance

Guarantee that critical program indicators and sensitive military capabilities remain protected from adversary exploitation, even as the ecosystem promotes broader data sharing and collaboration.

7. Alignment with the DoD Data Strategy

Align DE capabilities with the DoD Data Strategy, which focuses on ensuring the usefulness, trustworthiness, and security of all DoD data, not just engineering data, as outlined below.

VAULTIS: The DoD Data Strategy’s Goals

The DoD Data Strategy defines several goals outlining what any DoD data, including engineering data, must meet to be usable across programs and stakeholders.

These goals are described using the acronym VAULTIS,  which stands for:

• V – Visible: Users and applications must be able to locate and discover the data they need easily.
• A – Accessible: Authorized users and applications must be able to seamlessly retrieve the data through standardized, secure interfaces.
• U – Understandable: Data cannot just be raw bytes: its context, content, definitions, and applicability must be explicitly clear so users can interpret it accurately.
• L – Linked: Data elements must be mapped to showcase their inherent relationships, dependencies, and lineage.
• T – Trustworthy: Users must be able to trust the integrity, quality, and accuracy of the data when making decisions across domains.
• I – Interoperable: Data must be represented using common formats, open standards, and standardized schemas, so that distinct machine-to-machine environments can exchange and process it natively, without custom translation layers.
• S – Secure: Data must be protected at rest, in motion, and in use.

Why and Where A&D Programs Struggle to Meet These Goals?

In practice, however, meeting the DoDI requirements and DE strategy goals runs into a recurring set of architecture gaps. It starts with fragmented data, unclear authoritative sources, and broken traceability, and cascades into several more that we are going to address in this section.

1. Reliance on Unstructured Document-Based Engineering Data

Legacy A&D program data is by nature mostly ambiguous, unstructured, and fragmented document-based data.

This is precisely why DE strategy is built on a core principle: representing engineering specifications, designs, and other engineering knowledge as coherent digital models. These models need to rely on common semantics and clearly defined relationships between concepts, instead of unstructured text that embodies them implicitly and ambiguously.

But this requires the ability to create various models, such as operational, functional, architectural, component behavior, analysis, and verification models. Many programs fall short of fulfilling this fundamental requirement, and engineering knowledge often remains locked in unstructured documents without the coherent, well-defined models this requires.

2. Poor interoperability across domain tools

Once engineering data is represented as digital models, the next challenge is to enable interoperability across them. A functional model, for example, drives the architectural models that implement it, which in turn drive the verification models that validate them, and so on. Different engineering disciplines use different tools to capture digital engineering information:

• Requirement tools
• MBSE tools
• High-fidelity simulation tools
• Physical design tools
• And testing tools

Yet these tools are typically siloed with a low level of interoperability in terms of data exchange and cross-domain relationships.

3. Lack of cross-domain traceability

Domain model silos covered above directly undermine digital traceability. Poor interoperability prevents seamless creation and analysis of cross-tool traceability. For example, requirements stored in a requirements tool repository cannot be digitally linked to architectural model elements in a modeling tool without an additional traceability backbone. In the absence of such digital traceability, programs rely on ‘ad hoc’ manual markers or external tables, which are error-prone. As a result, when a requirement is updated, there is no digital flag that marks the corresponding model element as 'suspect’.

📖 Read also: How to Bridge the Traceability Gap Between Requirements and Models?

3. Unclear Authoritative Source of Truth

Engineering data may be replicated across domains, creating overlapping representations with no designated authoritative source. For example, a stakeholder requirement may exist both in a requirements tool and in an MBSE system specification tool. Without a proper underlying backbone to designate which one owns the "truth", the two representations can drift out of sync.

4. Inconsistent data versioning and provenance

Engineering data in domain tools is constantly evolving, and is organized using versioning systems, either built into the tool or external to it.

The ability to version and baseline data is one of the DoDI requirements, and a standard practice across industry frameworks such as ISO 15288 or ARP 4754. Yet aligning consistent baselines across a multitude of domain tools requires an architectural backbone that most programs don’t have.

5. Stakeholder viewpoints out of reach

Stakeholder viewpoints, as described by the INCOSE DEIXWG Digital Viewpoint Model (DVM)¹, support the need for stakeholders to perform cross-domain analysis and reviews that are not bound to a single domain’s digital model. Such a capability requires querying data originating in multiple ASOTs and generating cross-domain views to enable the stakeholder to perform their analysis. In practice, most programs lack the architecture to produce such viewpoints on demand, putting them effectively out of reach for the stakeholders who need them. 

1The DVM is a conceptual data model that specifies how stakeholder viewpoints shall be satisfied by an underlying engineering data model. For example, a safety stakeholder needs to analyze safety aspects across multiple models, from requirements through logical design to physical design.

6. Lack of a Scalable Multi-Tool Architecture

A&D providers often need to align their tooling with the customer or the integrator. This either forces them to use a multitude of tools, such as different system modeling tools, or requires support for cross-tool data exchange. Either way, it creates a real challenge for both integrators and suppliers: how to effectively support multiple tools within their engineering infrastructure.

Ideally, adding a new tool requirement should not trigger a full ripple of new integrations and delays across the program.

The Need for a Digital Engineering Environment (DEE)

If we put the different gaps described above side by side, one pattern stands out. None of them come from the tools. The tools themselves were never the problem. The real root cause here is the absence of tools that were never architected to work together. And by that, I mean no shared ownership, no common exchange layer, no shared sense of version or baseline.

Filling that gap is the main objective of what we call a Digital Engineering Environment (DEE). A DEE is the architectural, or to be more specific, the connecting layer that allows the existing tools to stay authoritative, exchange data without duplicating it, and remain traceable across a wide range of domains.

What are The Architectural Foundations to Meet the DoDI Requirements?

So far, we've covered what the DoDI demands and where programs fall short of delivering it. But knowing the destination isn't the same as knowing the way there, right?  The DoDI itself stops short of prescribing specific technologies: it calls for a "digital engineering ecosystem" built on "authoritative sources" and "digital models," but leaves the "how" open.

This section looks at some of the architectural patterns that can support programs in meeting those requirements.

1. Maintaining consistency with the authoritative source 

The foundational assumption behind the DoDI guidance is that program data always spans a multitude of domain tools, used by various stakeholders and focused on different functionalities needed for specific program phases. This is why it avoids the term “Single Source of Truth,” because in practice, there isn't such a single source. Instead, each domain tool repository is the authoritative source for its own domain data. 

The key challenge with authoritative data is unnecessary replication across domain repositories. Once a digital artifact is replicated, there's no guarantee it stays consistent with the original, authoritative version. 

So, one key measure consists of relying on cross-tool linking instead of replication, using a linked data architecture such as the Open Services Lifecycle Collaboration (OSLC). With OSLC, each artifact is exposed by its owning tool through a stable URI and consumed elsewhere as a live link, so the data never leaves its authoritative source.

And where data replication is unavoidable, for various reasons such as analysis and computation, a traceability link should be established between the replicated artifact and the original so the copy can be updated whenever the original changes.  

2.  Enabling systematic cross-domain data exchange 

To scale data exchange across different domains, programs should rely on common data representations, preferably standards-based.

Two main approaches stand out.

➡️ Ontological approach with OSLC

An ontological approach built on standardized vocabularies, such as those published by OSLC, works particularly well here, given its flexibility to represent and bridge data across domains.

By mapping common concepts to a shared vocabulary, or ontology, programs avoid the need to define domain-to-domain pairings, which carry a quadratic complexity. For example, with 5 domain tools, connecting each one to a common ontology requires 5 mappings, while direct tool-to-tool connections would have required 10 more.

And because the vocabulary is standardized, such as with OSLC, most domain tools already support it out of the box, with no further work required.

➡️ Standard representation with SysML v2

Another option is a standard representation such as SysML v2, which can capture a wide range of systems engineering data.

Like OSLC, it is standardized, so domain tool vendors typically support it out of the box. Bridging foreign domains may still require cross-domain transformation, in which case transformation frameworks that implement these rules are particularly useful.

Enabling this level of interoperability is essential to keep data consistent across the entire program.

📖 Read also: A Practical Guide for SysML v2 Adoption

3. Powering Cross-Domain Viewpoints with Lifecycle Graphs

The DoDI aims to enable data-driven, analytical decision-making throughout the life of a program. This requires curating engineering data from across all engineering domains to run analytics and render the viewpoints each stakeholder needs.

The common technique for this is to maintain a unified lifecycle graph, representing the artifacts and relationships across all authoritative sources (ASOTs). This graph consolidates data from every ASOT and can be queried to run analytics and render viewpoints.

Curation itself can be handled in different ways, such as incremental data update feeds or on-demand queries against the various ASOTs.

For example, a verification engineer would use a view that shows how test cases cover stakeholder requirements across two domains. And a safety engineer would inspect safety aspects across safety requirements, risk analysis, architectural mitigations, and the corresponding test coverage.

Enabling cross-domain viewpoints and analytics is essential to keep data consistent across domains and program phases, assess the impact of changes quickly, and give stakeholders easy access to relevant data. The net result is faster program delivery and less rework.

4. Coordinating configurations across domains

Because engineering data is constantly evolving, each Authoritative Source of Truth (ASOT) manages its own local configurations: artifact versions, dataset configurations, and baselines. But since data is federated across multiple ASOTs, keeping it consistent across domains requires a "global" configuration capability allowing each ASOT to interact with it whenever it references or fetches from another ASOT.

Cross-domain lifecycle graphs must also be aware of these configurations. Rendering a cross-domain viewpoint or running cross-domain analytics only makes sense against a consistent dataset, defined by a global baseline or global configuration. For example, if a program manager wants to assess how many stakeholder requirements have already been successfully validated, that analysis needs to run against a specific program baseline. If you run against an undefined dataset, it won't yield a meaningful result.

Effective cross-domain configuration management prevents the inconsistencies that lead to rework, and, in the worst cases, to program failures in the field.

Implementing the DoDI vision in Practice

These architectural building blocks can be implemented with different approaches. Some rely on linked data principles for cross-domain traceability, RDF  vocabularies to standardize how domain data is represented, and RDF graphs to capture lifecycle artifacts and their relationships.

Several commercial platforms already deliver these capabilities. I could have mentioned IBM ELM here, which offers a fairly pure implementation of the OSLC architecture.

But the one I'll use for the illustration that follows is SodiusWillert SECollab, because it implements the four foundations described above within a single environment.

SodiusWillert SECollab

SECollab uses standard OSLC vocabularies to represent domain data, and a graph database (Neo4j) to implement the cross-domain lifecycle graph that enables analysis, reporting, and review across domains.

SECollab also supports cross-domain links (called “collaboration links”), and cross-domain “global configurations” aligned with OSLC configuration management.

Data is curated from lifecycle ASOTs using publishing agents or dedicated client publishers, which populate the lifecycle graph and enable the creation of cross-domain links that enrich it further.