Digital Representations in Acquisition Lifecycle Phases

The Test & Evaluation (T&E) community faces a growing challenge: how to ensure rigorous, mission-ready systems in an environment constrained by cost, safety, physical exposure, and classification barriers. These limitations often lead to fragmented evaluations and delayed insights, increasing risk across the acquisition lifecycle. Missing from the T&E community is a shared framework and common language for leveraging Digital Representations (DRs)—especially Digital Twins (DTs)—to transform how we design, test, and sustain complex systems. This paper addresses that gap by providing a resource for T&E practitioners to align on terminology and demonstrates how DRs can enable continuous, integrated evaluation from concept through sustainment. By doing so, we aim to accelerate innovation, reduce risk, and foster collaboration across programs and organizations.

This paper, developed through collaboration among academia, industry, and government expertise explores the transformative role of DRs  [1], [7], [23], [26]. The purpose of this paper is to provide clear definitions of and delineate how the DRs of a system can provide value across the entire program acquisition lifecycle of that system [1], [7], [14], [23].

Table 1.1 System Attributes
Performance	Affordability
Reliability	Interoperability
Maintainability	Testability
Scalability	Sustainability
Usability	Resilience
Flexibility	Lethality
Security	Effectiveness
Suitability	Survivability

Extra focus is placed on the benefits of DRs to the T&E community because comprehensive live testing of future warfighting systems will not be possible in many cases due to environmental, fiscal, safety, classification, or ethical constraints [14], [16], [23]. T&E will increasingly rely on complex, high-fidelity, time-synchronized DRs [7], [23], [26]. DRs enable robust virtual testing of system attributes, reducing dependence on physical testing while maintaining rigor through verification, validation, accreditation, and uncertainty quantification. Actual system attributes, like those listed in Table 1-1, may be evaluated through DRs. This structure helps acquisition teams identify which aspects of system performance can be assessed virtually and where DRs offer the greatest value across the lifecycle. This paper outlines how DRs deliver value across all lifecycle phases, with practical applications.

The paper is organized as follows: in §2, Background, we discuss the major areas of the acquisition lifecycle phases (ALPs), including their definitions (§2.1) and associated testing types (§2.2); in §3, Digital Engineering Elements, we detail the characteristics and taxonomy of DRs, including Digital Models (DMs), Digital Shadows (DSs), and DTs (§3.1), their synchronization options (§3.1.5), and derivations such as Digital Twin Aggregates (DTA) and Digital Threads (DTH) (§3.2); in §4, Lifecycle Phases of Digital Models and Twins, we illustrate the application of DRs across each lifecycle phase—D&D (§4.1), Integration (§4.2), T&E (§4.3), and O&S (§4.4); in §5, Conclusion, we summarize the transformative impact of DRs; and in Appendix A, Digital Twin Standard Contract Language, we provide contract language guidance for integrating DRs into acquisition programs across all phases this structured framework aligns with Department of Defense Instruction (DoDI) 5000.97 “Digital Engineering” [35], offering actionable insights for the T&E and acquisition communities to accelerate capability delivery and enhance system performance.

2.1 System Acquisition Lifecycle Phases (ALPs)

The system acquisition lifecycle comprises of four iterative principal phases – 1) Design & Development (D&D), 2) Integration, 3) Test and Evaluation (T&E), and 4) Operations & Sustainment (O&S)– each of which contributes to the structured development and operational deployment of a system [14], [23], [26]. Stakeholders are responsible for providing initial system requirements and specifications, which are inherited by the D&D phase, and iteratively impacted by and throughout remaining phases [14], [23]. These ALPs and their relationship to system requirements, as shown in Figure 2.1, guide the progression of the project from initial conceptualization to operational implementation, with iterative, continuous improvements that enhance traceability, system quality, and stakeholder satisfaction.

Figure 2-1 Acquisition Lifecycle Phases (ALPs).

Design & Development (D&D): During the initial phase of D&D, stakeholder requirements are systematically translated into comprehensive system architectures, subsystem designs, and component specifications. Throughout the development process, individual components are fabricated and subjected to unit-level testing to verify compliance with stakeholder-defined performance criteria [3], [4], [6], [7], [14], [23]. [35], [38]. This phase serves to validate component functionality and establishes the foundation for subsequent system integration [7],[23], [35].

Integration: Once individual components are validated under unit testing, they are incrementally integrated into subsystems and eventually into the complete system [7], [14], [23], [35], [38].The integration process seeks to ensure that the assembled system conforms with requirements and specifications, thereby validating functional correctness, interface consistency, and overall performance within simulated operational environments [7], [10], [13], [15]. This phase is critical to establishing the technical integrity of the system, thereby facilitating the transition to comprehensive testing [7], [14], [23], [35].

Test and Evaluation (T&E): In this phase, the fully integrated system is subjected to rigorous T&E activities and procedures to confirm adherence and alignment technical requirements, end-user expectations, and operational effectiveness in realistic environments [14], [16], [23], [35], [36].Testing rigorously assesses system reliability, performance metrics, and interoperability parameters, thereby establishing a robust foundation for user acceptance and deployment [14], [16], [23], [26], [36]. Operational T&E (OT&E) is performed to determine the effectiveness, suitability, and survivability, and, where applicable, lethality of the system under test within operationally realistic scenarios and under realistic adversarial threats [14], [23], [36]. The T&E Verification, Validation, Accreditation, and Uncertainty Quantification (VVAUQ) process ensures that models and simulations are credible, testable, and accurately reflect system requirements, providing continuous validation throughout the system lifecycle. By aligning with system development phases, VVAUQ improves test realism, refines models through test feedback, and delivers critical technical confidence for acquisition decisions.

Operations, and Sustainment (O&S): The final phase of the acquisition lifecycle facilitates the transition of the system into operational use [9], [13], [17], [23], [35], [36]. Deployment activities encompass installation, configuration, and end-user training to ensure operational readiness [9], [13], [23]. Post-deployment operational activities focus on ensuring sustained system performance within intended operational environments. The sustainment aspect of the phase emphasizes proactive maintenance, updates, and performance optimization to address evolving operational requirements and technological advancements. Importantly, this phase incorporates continuous improvement practices, including ongoing T&E, to extend system lifecycle value, and maximize long-term effectiveness. The desire for continuous improvement necessitates the development of a capability for continuous testing of the systems [9], [10], [11], [13], [19], [23], [35], [36].

Collectively, these four iterative ALPs establish a disciplined framework that ensures the delivery of a high-quality system that meets end-user needs, achieve operational reliability, and maintain adaptability to future mission requirements.

2.2 Testing Types

This paper aims to demonstrate the benefits of utilizing digital engineering (DE) elements [35], [7], [23], as described in more detail §3, to support the various types of T&E that take place during the ALPs listed in §2.1. The engineering testing types presented in Table 2.1 are designed to ensure that the system under test fulfills its technical specifications, operational objectives, and end-user requirements [36], [14], [23], thereby facilitating the delivery of a robust and reliable product or capability [7], [14], [23].

Table 2.1 Summary of Acquisition Lifecycle System Testing Types [36]

Testing Type	Purpose	Phase
Unit	Validate individual components function correctly	Design & Development
Integration	Ensure components and subsystems work together	Integration
Verification	Ensure the system meets design and technical specifications (focuses on correctness)	Integration
Interface	Validate communication and data links between subsystems	Integration
Functional	Confirm the system performs required functions	Test & Evaluation
Performance	Evaluate speed, efficiency, and resource use	Test & Evaluation
Stress/Load	Test system stability under extreme conditions	Test & Evaluation
Validation	Ensure the system fulfills user needs and performs in its operational environment	Test & Evaluation
User Acceptance	Validate usability and satisfaction with end-users	Test & Evaluation
Security/Threat	Ensure the system is secure and protects against vulnerabilities	Test & Evaluation
Environmental	Validate performance under environmental stressors (e.g., temperature, humidity, vibration)	Test & Evaluation
Interoperability	Validate compatibility and integration with external systems	Test & Evaluation
Operational	Evaluate readiness for deployment in real-world operational conditions	Test & Evaluation
Regression	Verify updates or fixes do not introduce new defects	Operations & Sustainment
Cybersecurity	Ensure system cybersecurity, postulated threats survivability, and resilience requirements are met	Throughout the lifecycle

The scope of this article does not include a detailed examination of each test type, however throughout §4, we present demonstrative use cases where digital elements support the successful T&E processes.

The initial use of DRs and digital signal processing is roughly 80 years old, having effectively started with the advances and rise of digital compute in the 1960s [7], [23]. All the forms of DRs presented have existed in the DE community for decades, and the terminology has evolved to use terms like “Digital Twin” (circa ~2000) and more recently, “Digital Shadows” [1], [7], [23], [26].  The use of DRs and DE practices within the Department of War has now become a mandatory component of defense system D&D and sustainment, formally codified under DoDI 5000.97,

DoDI 5000.97 emphasizes the shift from document-centric processes to data-centric digital ecosystems, where validated DMs serve as authoritative sources of truth. This section establishes a unified terminology aligned with the directive to standardize communication and ensure interoperability across the T&E community [35], [23].

3.1 Digital Representations (DRs)

Digital Representation (DR): digital abstractions or models used to represent physical systems, processes, or entities in a digital form. These representations vary in complexity, fidelity, and functionality based on their level of connection to the physical system, their ability to interact or provide system, and their ability to interact or provide insights.

Consistent with the definitions and framework established in DoDI 5000.97 [35], DRs are systematically categorized based on three fundamental dimensions by their fidelity, synchronization cadence, and degree of interaction with respect to their physical system counterparts [1], [7], [23], [26], [36]. Fidelity refers to the level of detail, precision, and accuracy with the DR reflects the physical system, ranging from abstract conceptual models to high-resolution, physics-based simulations [1], [2], [3], [7], [23]. Synchronization cadence captures the frequency and method by which data from the physical system is updated to the digital environment, ranging from intermittent manual updates to continuous, real-time, high frequency streaming [9], [12], [19], [22], [25]. The degree of interaction denotes whether the DR operates in a passive observational capacity, as with DMs and DSs, or whether it maintains an active, bi-directional interface capable of influencing the physical system in real-time, as with DTs [7], [13], [14], [23], [26].

The following structured classes enables acquisition programs to apply DRs appropriately according to mission requirements, system complexity, and ALPs, ensuring alignment with authoritative data management principles and secure DE practices [4], [6], [8], [23], [24], [33]. As delineated in DoDI 5000.97, the three principal and widely adopted categories of DRs within the ALPs are: DMs, DSs, and DTs [7], [11], [14], [23], [26].

3.1.1 Digital Model (DM)

A digital model (DM) is a standalone, independently updated, digital representation of a physical system, developed without automated directional updates [7], [23]. DMs provide foundational analytical capabilities throughout the acquisition lifecycle [3], [4], [23], [26]. During early program phases, they aid in concept development and system design by enabling a controlled environment for visualization, simulation, and theoretical analysis [2], [7], [23]. In the T&E planning and requirements definition phases, DMs assist in identifying design risks, validating requirements and informing testing strategies, thereby reducing developmental risks [14], [16], [35]. In subsequent phases, DMs facilitate system optimization, performance prediction, validation activities, and operator training [4], [11], [18], [23]. Additionally, DMs are leveraged in procurement and sustainment phases to support lifecycle cost analysis, decision-making, performance monitoring, lifecycle management activities in accordance with authoritative data principles outlined in DoDI 5000.97 [35].

3.1.2 Digital Shadow (DS)

A digital shadow (DS) is an enhanced DM that incorporates automated unidirectional updates from its physical counterpart, reflecting the current state of the physical system [7], [9], [12], [23]. Within T&E environments, DSs enable operational monitoring and in-situ data capture and post-test-event analytics [14], [19], [23]. They allow for dynamic assessment of system performance under operational conditions, facilitate fault isolation, and enable the adaptation of test designs in response to observed behaviors [14], [23]. DSs are particularly valuable during integration, T&E, and O&S phases by providing near-real-time situational awareness [9], [19], [23], [35]. However, due to the lack of bi-directional interaction, DSs are unsuitable for scenarios that require active system reconfiguration or real-time control [35], [36].

3.1.3 Digital Twin (DT)

Digital Twin (DT): A digital representation of a specific real-world system of interest that bi-directionally sends and receives updates between itself and its real-world physical counterpart at a frequency and fidelity befitting the use case. [23]

Synchronization frequency and fidelity between the digital and physical twins should aligned with the operational system and T&E requirements [7], [12], [19], [22]. DTs not only reflect the physical system’s state but also influence it, providing actionable feedback for decision-making, predictive analytics, and system optimization [7], [9], [14], [23].

The bi-directional and synchronous capabilities of DTs allow them to perform similar analyses as DSs, but with the added ability of adaptive system performance management, enabling T&E teams to conduct real-time system verification, fault prediction, and mission-level effectiveness assessments and adjustments [7], [14], [23]. In high-stakes military environments, DTs enable comprehensive and continuous T&E across the entire acquisition lifecycle, from initial D&D through O&S, ensuring operational precision, mission reliability, and system resilience [6], [13], [17], [18], [23], [35].

However, the implementation of DTs poses significant technical and financial challenges [6], [19], [23], [26]. Full-spectrum DTs require precise time synchronization, high-throughput data exchange, and robust cybersecurity protocols, as emphasized in DoDI 5000.97 [35]. Consequently, many current implementations termed “Digital Twins” fall short of this ideal but still offer substantial value in developmental and operational settings [14], [18], [19], [23]. The adoption of DTs also introduces new data rights concerns and cybersecurity risks, such as data poisoning and adversarial exploitation, making it necessary to implement strong cybersecurity practices and comply with the requirements set by Department of War (DoW) programs [9], [13], [17], [23], [35], [39].

3.1.4 Summary of Digital Representations

Instead of viewing DMs, DSs, and DTs as entirely discrete entities, it is more accurate to conceptualize them as progressive instances along a continuum of DRs. This continuum is characterized by varying degrees of fidelity, synchronization cadence, and system interactivity. Such an approach reflects current best practices within the DE community and is consistent with the taxonomy outlined in DoDI 5000.97 [7], [9], [12], [19], [22], [25], [23], [26], [33], [35].

Figure 31 Physical & Digital Manual and Automatic Data Flows [23]

This classification framework clarifies the distinct functional attributes associated with each type of DR, mitigating confusion arising from overlapping terminology and providing an operationally relevant lexicon for T&E professionals. By distinguishing DRs through this structured taxonomy, acquisition programs can more effectively determine the appropriate application of DR across the ALPs. Figure 3.1 illustrates the directional data flows-manual and automated-between physical and digital objects and provides a visual summary of the defining features of DMs, DSs, and DTs for practical [3], [4], [6], [14], [16], [23], [35], [36].

The realization of fully synchronous, high-fidelity DTs, meeting the highest standards of automation and bidirectional interaction, remains an aspirational objective for most defense systems [13], [18], [19], [23], [26]. Therefore, this article adopts the pragmatic definition of DTs provided in §3.1.3, consistent with current Department of Defense policy guidance [35], [36], [39]. To clarify, §3.1.3 provides a definition that emphasizes functional utility even when full synchronization is not achieved or available, whereas §3.1.4 highlights that fully synchronous DTs are an aspirational ideal requiring near-instantaneous updates. This distinction separates practical application from theoretical aspiration.

Each type of DR provides unique capabilities that contribute to overall system performance and continuous improvement, depending on the required fidelity, real-time synchronization, and system interactivity [2], [5], [10], [15], [24], [31]. Understanding these nuances is crucial for determining how and when to employ different forms of DRs throughout each phase; the remainder of the manuscript delineates each of the DR conceptual frameworks and explicates their application to the ALPs [7], [23], [35].

3.1.5 Time Synchronization of Digital Twins and Shadows

An often-contested topic when discussing DTs in the DE community is the degree to which perfect time synchronization and automation required to qualify as a true or “full-fledged” DT [23], [7], [9], [12], [19], [22], [26]. The definition from [23], shown in §3.1.1, neutralized this issue. For better context in Table 3.1 we provide a subset of data-update time intervals available for DSs and DTs. With respect to the degree of automation, DTs require fully automated synchronization. Any need for manual data entry, batch updates, or human filtering reclassifies the system as a DS [8], [19], [22], [25].

Table 31 Digital Twin and Shadow Synchronization Options

Update Method	Description
Streaming	Continuous real-time updates occur as changes happen (e.g., real-time IoT data streaming).
Fixed Cadence	Updates occur at a predetermined, regular interval (e.g., every minute, hourly, daily).
Event-Driven	Updates are triggered only when a specific event occurs (e.g., a transaction is completed, an error is detected).
On-System-Demand	Updates occur when one system explicitly requests new data from another (e.g., user refreshes a webpage, API call on request).
Threshold-Based	Updates happen when a monitored value crosses a predefined threshold (e.g., temperature sensor sends an update when exceeding 100F).
Batch Processing	Updates are collected and sent in groups at scheduled times (e.g., satellite upload/download when in line of sight).
Manual Update	Updates occur manually, requiring human intervention to trigger the update (e.g., a system administrator manually refreshing a database).
Predictive Update	Updates are predicted based on patterns, Artificial Intelligence models, or Machine Learning forecasts (e.g., predictive maintenance for machinery before failure occurs).
Adaptive Scheduling	The update schedule adjusts dynamically based on network load, data importance, or system conditions
Hybrid	A mix of any update methods based on system and environmental conditions

3.2 Derivations of Digital Representations

As DT technologies mature, a range of subtypes and classes have emerged, reflecting the diverse operational roles these representations can fulfill within defense ALP and T&E environments [7], [23], [26], [35]. Understanding these various subtypes, classes, and their respective use cases are critical for determining how DTs can be leveraged to assess system performance, validate operational effectiveness, and inform strategic decisions across the lifecycle of military assets [6], [13], [14], [17], [18]. Each type of DT provides a structured approach for deploying digital systems based on specific requirements for synchronization, fidelity, and the extent of automation needed to support high-stakes missions and sustainment strategies [7], [9], [19], [23], [26]. Each subtype offers tailored capabilities based on specific requirements for synchronization, fidelity, and automation, in alignment with DoDI 5000.97 [35].

While there are numerous possible DT subtypes), this article focuses on key subtypes most relevant to the ALPs – namely DTAs and DTHs, which reflect both the complexity and flexibility needed to evaluate and optimize a wide range of military systems, from individual components to integrated fleets and multi-domain operations [7], [13], [14], [15], [23], [26].

3.2.1 Digital Twin Aggregate (DTA)

A Digital Twin Aggregate (DTA) represents a coordinated grouping of individual DTs instances, either homogenous or heterogenous systems, aligned to DoDI 5000.97’s emphasis on system-of-systems digital integration. DTAs incorporate built in analytical functions to assess joint asset performance, emergent threat behaviors, and operational interdependencies [6], [13], [14], [17], [23]. This approach is consistent with DoDI 5000.97 (i.e., Section 3.2.b(2)), which advocates for the use of synchronized DMs to support developmental and operational testing in multi-domain environments. DTAs are valuable for evaluating multi-domain, all-domain, and joint missions, where synergistic behaviors and interdependencies drive mission performance [13], [14], [15], [17], [23]. By aggregating data streams from constituent DT instances, DTAs provide acquisition stakeholders (e.g., mission commanders) a higher-level view of the joint or combined force’s overall status, performance, and emergent dynamics, making it possible to identify trends, predict optimal maneuvers, and most efficiently allocate assets in a dynamically adaptive way [13], [15], [23], [26].

Example: A DTA could be employed to monitor and manage a battalion of autonomous ground vehicles conducting a coordinated reconnaissance mission. Each vehicle has its own DT instance, and the DTA integrates data from all units to track collective mission status, identify emergent behaviors, and supports coordination across the fleet. This approach is particularly valuable in multi- or all-domain operations, where the ability to monitor joint or combined force performance is essential for maintaining operational superiority.

3.2.2 Digital Thread

A digital thread (DTH) is a core construct defined in DoDI 5000.97 (Section 3.2.b(3)), serving as an extensible, traceable, and authoritative analytical framework that connects system data, models, decisions, and outcomes across the entire acquisition lifecycle [3], [4], [7], [23], [26], [35]. Each DT instance operates in conjunction with its corresponding DTH, ensuring that validated data flows seamlessly between the ALPs [35], [36], [39]. DTHs enable cross-stakeholder alignment, continuous evaluation, and sustainment traceability, providing enduring value throughout the four ALPs [4], [6], [8], [31], [35], [39]. A successful DTH implementation incorporates 1) transparent data flow, per DoDI 5000.97’s data visibility objectives, 2) explainability of system decisions, supporting traceability and auditability, 3) Secure configuration management to protect mission-critical data assets [9], [19], [22], [39]. This ensures that DTHs serve as the foundation for data-driven decision-making, enabling agile upgrades, operational adaptability, and enhanced lifecycle optimization per DoDI 5000.97 mandates [35].

This section describes how DRs including DMs, DSs, and DTs contribute value across the ALPs (i.e., D&D, Integration, T&E, and O&S). This structure aligns with the DoDI 5000.97 emphasis on leveraging DE methodologies to enhance system performance, reduce program risk, and support authoritative data continuity across the acquisition lifecycle [7], [9], [23], [26], [35].

The ALPs are interconnected, beginning with the derivation of system requirements, which serve as the foundational drivers for subsequent phases. Requirements inform and underpin the D&D phase, cascade into Integration & T&E, and are ultimately validated or refined through O&S. Throughout this process, DRs play a beneficial role in ensuring requirement traceability, design integrity, and performance accountability [6], [13], [14], [17].

A foundational element enabling this continuous application of DRs is the early and deliberate establishment of data rights. As stipulated in DoDI 5000.97 and reinforced in DoDI 5010.44 (Intellectual Property Acquisition and Licensing), programs must proactively define data rights strategies to secure enduring access to the digital artifacts and underlying data essential for DR utility [35], [39]. Data rights govern not only access to DMs, DSs, and DTs but also the ability to reuse, modify, and update these assets throughout the program lifecycle. Clear contract language addressing data ownership, intellectual property protections, and VVAUQ processes are critical to mitigate risks such as vendor lock-in, data loss, and cybersecurity vulnerabilities. Without robust data rights, programs risk losing control over critical design baselines and sustainment data, limiting their ability to execute lifecycle activities effectively. Conversely, properly secured data rights enable programs to perform independent design verification, optimize integration processes, accelerate T&E cycles, and sustain systems with greater flexibility and autonomy [19], [21], [31]. Appendix A provides recommended acquisition contract language and guidance for incorporating DRs, including DTs, into system acquisition contracts.

With this foundation established, the following sections outline how DRs and their associated derivations (such as DTA and DTHs) directly support each phase of the acquisition lifecycle, with a particular focus on their role in enhancing integration, driving down costs, improving schedule efficiencies, and ensuring warfighter readiness.

4.1 Design and Development (D&D)

The lifecycle begins with the definition of system-level requirements, which establish the capability needs and performance objectives of the system. These requirements are translated into technical specifications and engineering baselines, forming the cornerstone for subsequent D&D (and ALP) activities. According to DoDI 5000.97 (Section 3.2.b(2)), programs must develop configuration-controlled DMs to accurately represent system requirements and intended system behaviors. These requirements underpin the D&D phase and serve as the foundation for all downstream acquisition phases [6], [9], [25], [29], [30], [35], [36].

In the D&D phase, conceptual designs are refined into detailed schematics, model-based systems engineering (MBSE) artifacts, and executable simulations. The Model Development Plan (MDP), as described in DoDI 5000.97 (Section 3.5.a), captures system assumptions, design constraints, validation strategies, and configuration management procedures, ensuring fidelity and traceability of evolving design baselines [28], [29].

In order to best leverage and enable the concept of a DR in the D&D phase, models must be defined parametrically and be minimally hardcoded so that future iterations can efficiently pull from real-world insights to inform the next cycle of design. This implies that systems must have a digital “Single Source of Truth” that not only is readily accessible and easily updatable but also has a robust change configuration management infrastructure to enable the simultaneous development of both production and development branches. Designs should identify and predict failure modes to enable fault tracing throughout the development and operational lifecycle. This should be done in conjunction with emphasis on manufacturability, maintainability, and testability for validating system performance as well as for required DoW cyber defense strategy from the ground up. The contractor bears the burden of effort in this phase and works collaboratively with the government to feed inputs from O&S to inform future requirements and the next phase of design.

Critically, D&D activities must be directly traceable to system requirements, because they have enduring impacts throughout the ALPs, most critically on the effectiveness of mission-critical activities. Early design choices determine lifecycle maintenance needs, system resilience, and upgrade pathways, making robust DE practices essential for sustaining long-term operational capabilities.

4.1.1 Digital Representations for D&D

Digital Models in D&D: DMs allow engineers to translate system requirements into executable design simulations. They are used to conduct functional analysis, trade studies, and performance optimization without reliance on physical prototyping. By directly aligning DMs with system requirements, programs can conduct early design verification, identify misalignments with capability objectives, and reduce technical risk prior to integration activities. For example, a DM of a new solid rocket motor or liquid rocket engine can simulate thrust parameters and structural integrity across a range of operational conditions, thereby enabling engineers to optimize design parameters prior to initiating physical prototyping [1], [3], [4], [7], [35].

Digital Shadows in D&D: DSs introduce retrospective operational data into the design process, enhancing design quality with insights from similar field systems. For example, a DS of existing platforms allow engineering to identify performance degradation trends and operational bottlenecks, which are then used to refine new system requirements and design specifications during the D&D phase. This proactive approach helps mitigate historical failure modes early in the design lifecycle [12], [14], [19], [23], [25].

Digital Twin in D&D: DTs are implemented during the D&D phase to enable dynamic simulation and iterative design validation. By creating DTs aligned to initial system requirements, programs can virtually test system performance under expected mission profiles, identifying requirement gaps or over-specifications prior to costly hardware production. As prototypes evolve, DT fidelity increases, allowing programs to validate not only technical parameters but also operational suitability before proceeding to full-scale integration [7], [9], [13], [18], [23], [26]. For example, a DT of a new vehicle can simulate real-world performance, enabling earlier identification of deficiencies and their corrections. This ensures that the design meets all requirements before moving to the integration phase.

4.1.2 Derivations of Digital Representations to Enhance D&D

DT Aggregate in D&D: Although DTAs are most impactful during later lifecycle phases, DoDI 5000.97 (Section 3.2.b) recommends early planning for system-of-systems interoperability within the D&D phase. Programs should architect asset- or-operational-aggregation strategies, define component-level DT interactions, and develop early integration frameworks to ensure operational coherence at the force level. This involves defining how multiple DTs will be aggregated to provide a comprehensive view of the system in the O&S phase. For example, by establishing DTAs during D&D, programs can plan for multi-vehicle coordination in complex missions such as swarming or autonomous convoy operations [6], [7], [9], [13], [23], [26], [35].

Digital Thread in D&D: DTHs maintain persistent traceability across the D&D phase by connecting system requirements, design decisions, test results, and sustainment actions. Per DoDI 5000.97 (Section 3.2.b), DTH serves as the authoritative pathway for data flow, enabling full visibility of requirement derivation, design rationale, and verification evidence. This enables stakeholders to assess design integrity, adapt to evolving requirements, and validate mission suitability throughout the acquisition lifecycle. For example, a DTH can track the lifecycle of a component from initial design through development, providing a comprehensive record that aids in troubleshooting and validating performance. This ensures that all design activities are accurately documented, and any issues are promptly addressed [7], [19], [21], [23], [35].

In summary, integrating DRs and DTHs from the earliest phases of system development ensures traceability from system requirements through D&D, enhances system design quality, performance, reliability, and reduces lifecycle risk. These DRs provide valuable insights, enable real-time decision-making, and support proactive design strategies, ensuring the system is robust and ready for the next phase.

4.2 Integration

The integration phase focuses on assembling individual components and subsystems into a unified system that satisfies technical and operational performance requirements. This phase serves as the critical transition from isolated subsystem development to system-wide capability realization. According to DoDI 5000.97 (Section 3.1), integration activities are enhanced through the deliberate application of DE practices to enable accurate alignment of interfaces, optimize system configuration, and verify interoperability across all system elements [3], [4], [7], [9], [26], [35], [36].

Integration is directly informed by the system requirements established in the early phases of the acquisition lifecycle, which serve as the authoritative baseline against which integration success is measured, thus ensuring system performance aligns with defined capability needs. Data and artifacts produced during D&D are also inherited into the Integration phase, facilitating seamless handoffs between phases through configuration-controlled DRs as outlined in DoDI 5000.97 (Section 3.5). DRs, such as DMs, are invaluable for achieving seamless system performance during the Integration phase, where the goal is to ensure that individual system elements function properly as a whole and meet technical requirements and operational capabilities [3], [4], [7], [9], [26], [35], [36].

The key for enabling effective DRs during the Integration phase is that all interface control documents are accurately and comprehensively represented. Any unknowns shall be vetted for impact and assumed unavailable/non-functional to the maximum extent possible. Placement and employment of sensors for both initial testing and pulling diagnostic data through the life of the system should be analyzed not just for suitability and calibrated for performance but also secondary confirmation of functionality should sensors fail, to mitigate false readings. Integration of this data should be commonly formatted, extensively documented, and available to the government. The contractor bears the burden of effort in this phase, with the government acting as an intermediary between vendors as needed to protect proprietary data.

The Integration phase typically follows the bottom-up progression within the engineering V-Model, incorporating tasks such as system assembly, subsystem alignment, interface validation, and system-level verification [40]. Throughout this process, bidirectional data flows between the physical and digital elements are essential to monitor integration status, identify anomalies early, and refine system configurations in real-time.

4.2.1 Digital Representations for Integration

Digital Models in Integration: DMs provide essential early-phase support in Integration by enabling subsystem compatibility assessments, interface definition validation, and system-level interaction mapping. Because they do not require synchronization with physical assets, DMs are particularly well-suited for verifying conformance to interface control documents, mapping data flows, and conducting structural and functional compatibility simulations prior to physical assembly [1], [3], [4], [7], [35]. For example, a DM of a space asset can simulate various configurations and analyze load-bearing capacity during assembly. This pre-integration analysis helps engineers understand potential alignment issues before physical integration. Per DoDI 5000.97 (Section 3.2.b), these configuration-controlled models are integral to ensuring requirement compliance and reducing integration risk.

Digital Shadows in Integration: DSs enhance integration accuracy by incorporating automated, unidirectional updates from physical components, offering a near-real-time reflection of subsystem performance during assembly and alignment tasks. DSs can bridge the gap between non-system-interactive DMs and dynamic DTs by enabling timely status monitoring of physical system components. They are ideal for retrospective analysis, interface diagnostics, and discrepancy detection [10], [12], [14], [19], [23], [25]. By mirroring physical states, DSs provide a view of how subsystems behave within the larger system, which is invaluable for assessing component-level integration success. For instance, a DS of a missile system component can reflect data transmit or receive issues or data corruption during assembly. These insights allow integration teams to identify misalignments or performance issues that static models cannot capture.

Digital Twins in Integration: DTs represent the highest fidelity of DRs, offering synchronous, bidirectional connectivity with the evolving physical system during Integration, making them ideal for integration activities requiring immediate feedback and system optimization. The ability to both simulate and influence the physical system allows DTs to dynamically adjust integration strategies and system configuration settings, validate system performance under different scenarios, and optimize subsystem interactions [7], [9], [13], [14], [17], [18], [23], [26], [35]. For example, during the assembly of an unmanned aerial vehicle, a DT can continuously simulate flight stability and adjust the calibration of physical sensors in real-time to ensure alignment with design specifications. This capability ensures that the entire system meets operational requirements before moving to the testing phase. Furthermore, DTs support the incremental build-up approach defined in DoDI 5000.97 (Section 3.4.a), allowing for iterative integration with dynamic verification checkpoints.

In summary, the Integration phase leverages DRs to bridge the gap between subsystem development and system-level performance validation. The structured application of DMs, DSs, and DTs enhances interface compatibility, reduces integration errors, and accelerates progression toward operational readiness.

4.2.2 Derivations of Digital Representations to Enhance Integration

DT Aggregate in Integration: DTAs consolidate multiple DTs to support system-of-systems integration activities, enabling engineers to analyze cross-system interactions and proactively identify integration risks. DTAs are especially valuable in environments involving multi-domain or joint operations, where subsystems must operate cohesively under complex operational conditions. For example, during the integration of a new multi-domain command and control system, a DTA can simulate the interactions between various subsystems, such as communication networks, sensors, and control units. This simulation can identify potential integration challenges, such as data bottlenecks or latency issues, and optimize resource allocation to ensure smooth interoperability. By providing a holistic view of the entire system, the DTA helps engineers address integration issues proactively, ensuring that all subsystems work together effectively before full-scale deployment [6], [9], [13], [18], [23], [26], [35].

Digital Thread in Integration: DTHs serve as the authoritative lineage of technical data, connecting design artifacts, configuration baselines, and integration test outcomes across the lifecycle. In the integration phase, DTHs are instrumental in ensuring configuration traceability, managing system updates, and supporting rigorous VVAUQ during the subsequent T&E phase [19], [21], [23], [25], [35]. For example, a DTH can track the lifecycle of an aircraft component from design through integration, providing a comprehensive record that aids in troubleshooting and validating performance. This ensures that all integration activities are accurately documented, and any issues are promptly addressed, facilitating a smooth and efficient integration process.

In summary, integrating DRs in the integration phase enhances system performance, reliability, and interoperability. These DRs provide valuable insights, enable real-time decision-making, and support proactive integration strategies, ensuring systems function cohesively and effectively [9], [13], [14], [23], [25], [35].

4.3 Test and Evaluation (T&E)

The T&E phase is the cornerstone of the ALPs, serving as a critical validation point to ensure system readiness and operational suitability and mission effectiveness prior to deployment. Traditionally, T&E has relied heavily on extensive physical testing; however, evolving environmental, fiscal, safety, classification, or ethical constraints have imposed limitations on the scope and depth of live testing [5], [7], [14], [23], [26], [35], [36]. In response, the DoW is transitioning towards greater reliance on DRs, particularly DTs, to augment and in, some cases, reduce physical testing. Consistent with DoDI 5000.97 (Section 3.1.b), DRs are leveraged to accelerate data-driven decisions throughout the system lifecycle by enhancing T&E capabilities to test the performance and interoperability of our systems. DRs enable composability, editability, and parallelism of testing processes, expanding the T&E envelope beyond traditional methods. While physical testing remains irreplaceable, DRs reduce the overall volume, cost, and time of physical testing, while increasing test fidelity across system, subsystem, and system-of-systems levels [5], [7], [14], [23], [26], [27], [32], [35], [36].

As emphasized in DoDI 5000.97 (Section 3.2.a(3)), DTs used in T&E must undergo formal VVAUQ processes to ensure the credibility of simulation results. Techniques such as uncertainty quantification are applied to characterize model limitations, validate predictive accuracy, and support operational decision-making. Program managers are advised to account for the development, sustainment, and VVAUQ requirements of DRs early in the acquisition strategy, especially in scenarios where live testing will be constrained. To achieve this, DTs must pass VVAUQ prior to their use in T&E, following all relevant DoW policies on the use of modeling and simulation and its VVAUQ [14], [23], [26], [35], [36], [31]. For example, the use of such VVAUQ approaches as Uncertainty Quantification (UQ) have become prescribed as a means of identifying and reducing uncertainty in DRs within various modeling & simulation communities. Program managers should plan early for the investment required to develop and validate DTs while considering the expected limitations of live testing that DTs will mitigate.

T&E for systems that are developed with a DR must be assessed for physical performance of the system as well as digital accuracy of the model. Analysis models from the D&D phase must match to a predefined level of accuracy between what is predicted and what is observed on the real-world system, as captured by the instrumentation implemented during the Integration phase. Participation of test events should entail a combined contractor, developer, and end user test team and results should be available to all parties. Cyber testing should be planned and conducted as early as practical to inform system vulnerabilities from cyber attack, with special emphasis on the link between the physical model and the DR. Beyond deficiency reporting, extensive documentation should be compiled regarding the implications for operating a physical system with DR, whether manually updated or automatically synchronized. The DR must be assessed to help and never hinder the effective operation of the system.

In modern defense and warfighting contexts, the T&E phase is a critical step in ensuring system readiness, safety, and operational effectiveness. However, real-world constraints, such as safety, budget, and security classification, often limit the scope and depth of physical testing. Consequently, the use of DRs plays a pivotal role in augmenting or even replacing traditional T&E practices.

4.3.1 Digital Representations for T&E

Digital Models in T&E: DMs offer static, theory-driven simulations suitable for early T&E efforts, particularly in controlled environments. For instance, a DM can simulate how different environmental conditions affect a radar system’s performance, helping to understand how to optimize its deployment across various terrains. Additionally, DMs can be used to test software updates with existing hardware components, ensuring seamless integration and functionality before physical implementation. DMs are also useful for software-in-the-loop  and hardware-in-the-loop simulations to evaluate subsystem performance under nominal and edge-case conditions [1], [3], [4], [7], [14], [35]. For example, the Air Force’s development of a common virtual training environment leverages DRs to simulate operational scenarios, enhancing training effectiveness and system evaluation [34].

Digital Shadows in T&E: DSs are effective in the T&E phase due to their ability to incorporate real-world data for real-time monitoring. This capability makes them invaluable for validating operational conditions and ensuring systems perform as expected under actual use. DSs reflect the current state of a system, which supports condition-based maintenance and anomaly detection [10], [12], [14], [19], [23]. For example, a DS of an aircraft engine can be used during T&E to simulate various flight conditions and monitor parameters such as temperature and vibration levels. This allows engineers to identify potential issues and validate the engine’s performance under different scenarios before it is deployed.

DTs in T&E: DTs are particularly advantageous in the T&E phase due to their dynamic interaction, real-time scenario testing, and predictive analytics capabilities. These features make DTs ideal for evaluating complex systems and optimizing their performance in real-time [7], [9], [14], [17], [18], [20], [23], [25], [26], [35]. For example, a DT of a new missile defense system can simulate various attack scenarios to test the system’s response and effectiveness. This allows engineers to identify potential weaknesses and optimize the system’s performance before it is deployed in the field. Another example is a DT of an autonomous vehicle, which can be used to simulate different driving conditions and scenarios to evaluate the vehicle’s decision-making algorithms and safety features. Again, this helps ensure that the vehicle performs reliably and safely under a wide range of conditions before it is put into operational use.

4.3.2 Derivations of Digital Representations to Enhance T&E

DT Aggregate in T&E: DTAs enable system-of-systems T&E by aggregating multiple DTs to analyze emergent behaviors and interoperability across platforms [6], [9], [13], [18], [23], [26], [35]. For example, a DTA of military vehicles can simulate coordinated maneuvers and logistics, identify potential bottlenecks and optimizing resource allocation. Another example is using a DT Aggregate to test the interoperability and performance of a fleet of drones under various mission scenarios, ensuring they can operate effectively as a cohesive unit.

Digital Thread in T&E: DTHs ensure data continuity from design through T&E, maintaining configuration traceability and supporting robust VVAUQ processes. For instance, a DTH can track the lifecycle of an aircraft component from design through testing, providing a comprehensive record that aids in troubleshooting and validating performance. Another example is using a DTH to document the T&E history of a naval fleet, ensuring that all test results and modifications are accurately recorded and accessible for future reference [19], [21], [23], [25], [35].

The integrated use of DRs in T&E supports enhanced performance verification, operational validation, and long-term sustainment readiness. By combining physical and virtual testing methodologies, the DoW can increase T&E rigor while reducing costs, compressing timelines, and expanding the scope of testing across diverse operational scenarios.

4.4 Operations and Sustainment (O&S)

In the O&S phase, DMs, DSs, and DTs play a pivotal role in enabling continuous monitoring, maintenance, and optimization of systems. In accordance with DoDI 5000.97 (Section 3.1), DE principles are leveraged throughout the system lifecycle, with the O&S phase activities particularly benefiting from these DRs to inform and optimize manufacturing processes, sustain mission readiness, reduce lifecycle cost, and extend operational longevity. These DRs play a crucial role in T&E activities, ensuring that systems remain mission-ready and cost-effective throughout their lifecycle [5], [7], [9], [13], [14], [23], [26], [35], [36].

DR is crucial to the effective employment of capabilities in this age of Network-Centric warfare. This is a dogfight not in the physical sense, but along the domain of time. Being able to efficiently decide on a course of action and out maneuver the adversary in the decision-space means that the operator must not only receive the right amount of data at a relevant rate but also given the tools to make sense of the data and decide on a course of action. This also means that the operator must be able to adapt the system to the changing needs of the battlefield, agnostic of domain so that the fight is against the adversary alone, not with the fielded system. To accomplish this, the end user must retain access to not only the documentation but also the right to modify the systems in collaboration with industry so that at all points of time, the system is optimized to fight and win. Insights from not just system performance but also the holistic needs of the warfighter is enabled by the DR to then inform the D&D of the next generation of capabilities that will be wielded by the warfighter to defend and deter conflict.

A key priority in O&S is the modernization of sustainment strategies, particularly regarding how T&E infrastructure is maintained. In alignment with DoDI 5000.89, Section 3.4 highlights the need to integrate DE practices to shift from reactive maintenance towards predictive and condition-based maintenance postures. Leveraging DMs, DSs, and DTs enables data-driven sustainment decisions, facilitating earlier detection of performance degradation, optimized maintenance schedule, and more informed investment planning for T&E and operational infrastructure.

4.4.1 Digital Representations for O&S

Digital Models in T&E: During the O&S phase, DMs can be employed to simulate various operational configurations and conduct “what-if” analyses. For example, a DM of a military vehicle can be used to test different maintenance schedules and predict their impact on the vehicle’s longevity. This helps planners make informed decisions about maintenance strategies and resource allocation. DMs also support early identification of lifecycle sustainment risks, enabling more proactive decision-making during O&S activities [1], [3], [4], [7], [14], [34], [35].

Digital Shadows in T&E: DSs offer a higher degree of synchronization with the physical system, making them useful for real-time monitoring and basic maintenance scheduling. In the O&S phase, DSs can be used to track the current state of a system and detect anomalies [10], [12], [14], [19], [23]. For instance, a DS of an aircraft engine can continuously monitor parameters such as temperature and vibration levels, alerting maintenance crews to potential issues before they become critical. This supports condition-based maintenance strategies and helps prevent unexpected failures.

Digital Twins in T&E: DTs, with their bi-directional, synchronized data flow, are indispensable for maintaining optimal system performance during the O&S phase. They enable timely scenario testing, predictive maintenance, and system optimization based on current operational conditions [7], [9], [14], [17], [18], [23], [25], [35]. For example, a DT of a naval vessel can continuously monitor engine performance, predict potential failures, and adjust operational parameters to optimize fuel efficiency and extend the vessel’s operational life. This dynamic feedback loop ensures that the system remains aligned with its mission objectives and operational requirements.

4.4.2 Derivations of Digital Representations to Enhance O&S

DT Aggregate (DTA): A DTA can support fleet-level management by providing a holistic view of system health and performance across multiple units. This approach may enable coordinated sustainment activities, such as synchronizing maintenance schedules, anticipating fleet-wide failures, and optimizing resource allocation across interconnected assets. For example, a hypothetical DTA of a fleet of military vehicles could identify common maintenance issues, streamline parts inventory, and improve mission readiness [6], [9], [13], [18], [23], [26], [35].. In addition, when combined with a model-based design infrastructure such as MDAO, DTAs may help reduce integration risks by using modeling and simulation to explore sustainment trade spaces and assess upgrade paths for complex system-of-systems.

DT Thread (DTH): A DTH can provide a cohesive record of sustainment activities, ensuring that changes made during the O&S phase are documented and traceable to requirements. This traceability supports compliance with standards, accountability, and smoother transitions when systems are upgraded or retired. For example, a DTH of an aircraft component could maintain a comprehensive history from manufacturing through deployment and maintenance, supporting troubleshooting and upgrades. In combination, DTAs and DTHs may offer insights into system integration readiness, moving beyond reliance on Technology Readiness Levels (TRLs) alone. This integration could help reduce the level of effort required to sustain upgraded systems through design, integration, and T&E phases.

4.5 Summary

Overall, the use of DMs, DSs, DTs, DTAs, and DTHs in the O&S phase is expected to enhance system performance, reliability, and longevity. As summarized in Table 4.1, these DRs provide conceptual pathways for enabling timely decision-making and supporting proactive maintenance strategies. While the examples presented are illustrative, they highlight potential directions for how digital derivations may be leveraged to keep systems operational and effective throughout their lifecycle.

Table 4.1: Summary of similarities and differences across lifecycle phases (D&D, Integration, T&E, O&S).

Phase	DMs	DSs	DTs	Derivations (DTA, DTH)
D&D	Concept exploration, theoretical analysis	Leverage data from similar systems	Early prototypes with limited sync	Threads preserve design traceability
Integration	Interface/compatibility checks	Monitor subsystem states	Real-time validation & adjustment	Aggregates for SoS integration
T&E	Baseline simulation & performance	Condition-based monitoring	Scenario-based optimization	Aggregates & threads for VV&A
O&S	What-if analysis for sustainment	Real-time anomaly detection	Predictive maintenance, optimization	Aggregates for fleet management, threads for traceability

DTs are reshaping how industries and defense organizations approach D&D, T&E, integration, and O&S by bridging the gap between the physical and digital worlds. They enable more informed decision-making, risk reduction, and improved efficiency across system lifecycles while providing deeper insights into performance.

In this paper, we presented a baseline definition and understanding of DRs—including DTs, DSs, and DMs—and discussed their potential applications across acquisition lifecycle phases. The use cases described throughout the paper should be regarded as illustrative examples that demonstrate possible benefits of DRs for T&E and throughout the acquisition lifecycle, rather than as empirically validated results.

The primary contribution of this work lies in consolidating terminology, clarifying distinctions among DRs, and systematically applying these concepts to ALPs with a focus on the implications for T&E practices. By providing a unified framework and examples, this paper aims to help the T&E community envision how DE elements could be leveraged under real-world program constraints.

We recommend continuing collaboration among government, industry, and academia to provide empirical validation of DT applications, refine standards, derive additional use cases, and develop metrics for DT fidelity and synchronization. Lessons learned, best practices, and validated methods must be shared to advance the application of DTs. As acquisition programs seek to accelerate capability delivery and gain deeper understanding of operational performance, now is the time to further develop, test, and refine the role of DTs in T&E and beyond.

5.1 Further Research

Future research should focus on empirically validating the illustrative use cases presented in this paper to quantify the benefits and limitations of DTs in T&E contexts. Key areas for investigation include: (1) developing standardized metrics for DT fidelity, synchronization, and trustworthiness; (2) assessing cybersecurity risks and potential vulnerabilities introduced by bi-directional digital–physical couplings; and (3) conducting comparative studies to evaluate cost, performance, and reliability outcomes of DT-enabled versus traditional T&E approaches. In addition, further work is needed to define best practices for integrating DTAs and DTHs into acquisition programs and to ensure that lessons learned can be shared across government, industry, and academia.

[1] M. Farsi, A. Daneshkhah, A. Hosseinian-Far, and H. Jahankhani, Eds., Digital Twin Technologies and Smart Cities. Cham: Springer International Publishing, 2020. doi: https://doi.org/10.1007/978-3-030-18732-3.

[2] B. He and K.-J. Bai, “Digital twin-based sustainable intelligent manufacturing: A review,” Advances in Manufacturing, vol. 9, pp. 1–21, May 2020, doi: https://doi.org/10.1007/s40436-020-00302-5.

[3] Y. Xie, K. Lian, Q. Liu, C. Zhang, and H. Liu, “Digital twin for cutting tool: Modeling, application and service strategy,” Journal of Manufacturing Systems, vol. 58, pp. 305–312, Jan. 2021, doi: https://doi.org/10.1016/j.jmsy.2020.08.007.

[4] K. Schützer, J. de A. Bertazzi, C. Sallati, R. Anderl, and E. Zancul, “Contribution to the development of a digital twin based on product lifecycle to support the manufacturing process,” Procedia CIRP, vol. 84, pp. 82–87, 2019, doi: https://doi.org/10.1016/j.procir.2019.03.212.

[5] Y. Himeur et al., “AI-big data analytics for building automation and management systems: A survey, actual challenges and future perspectives,” Artificial Intelligence Review, vol. 56, Oct. 2022. [Online]. Available: https://link.springer.com/article/10.1007/s10462-022-10286-2

[6] A. L. J. Walton, N. N. Shah, D. L. Sandall, and E. L. Demirjian, “Modeling the return on investment of digital twins and associated product life cycle management,” Naval Engineers Journal, vol. 136, no. 1–2, pp. 281–290, 2024. https://bonotom.com/flipbook/2096/#2096/281

[7] D. Jones, C. Snider, A. Nassehi, J. Yon, and B. Hicks, “Characterising the digital twin: A systematic literature review,” CIRP Journal of Manufacturing Science and Technology, vol. 29, pp. 36–52, 2020, doi: https://doi.org/10.1016/j.cirpj.2020.02.002.

[8] X. Tu, J. Autiosalo, R. Ala-Laurinaho, C. Yang, P. Salminen, and K. Tammi, “TwinXR: Method for using digital twin descriptions in industrial eXtended reality applications,” Frontiers in Virtual Reality, vol. 4, Jan. 2023, doi: https://doi.org/10.3389/frvir.2023.1019080.

[9] F. Emmert-Streib, “What is the role of AI for digital twins?” AI, vol. 4, pp. 721–728, 2023, doi: https://doi.org/10.3390/ai4030038.

[10] J. Biron, “How IoT, AI, and digital twins are helping achieve sustainability goals,” Nov. 14, 2022. [Online]. Available: https://azure.microsoft.com/en-us/blog/how-iot-ai-and-digital-twins-are-helping-achieve-sustainability-goals/

[11] F. Akbar, “Transform your business with the capabilities of digital twin and AI,” Oct. 10, 2024. [Online]. Available: https://www.toobler.com/blog/digital-twin-and-ai

[12] A. Sharifi et al., “Application of artificial intelligence in digital twin models for stormwater infrastructure systems in smart cities,” Advanced Engineering Informatics, vol. 61, p. 102485, 2024, doi: https://doi.org/10.1016/j.aei.2024.102485.

[13] R. Uppal, “Digital twins: Accelerating innovation, enhancing reliability, and revolutionizing military readiness,” May 15, 2024. [Online]. Available: https://idstch.com/technology/ict/digital-twins-accelerating-innovation-enhancing-reliability-and-revolutionizing-military-readiness/

[14] D. Bergin et al., “Tailoring the digital twin for autonomous systems development and testing,” ITEA Journal of Test and Evaluation, vol. 44, no. 4, Dec. 2023. [Online]. Available: https://itea.org/journals/volume-44-4/tailoring-the-digital-twin-for-autonomous-systems-development-and-testing/

[15] Skydio, “Using an AI-powered drone to autonomously capture digital twins of tactical environments,” Dec. 6, 2021. [Online]. Available: https://www.skydio.com/blog/autonomous-capture-of-digital-twins-of-tactical-environments

[16] C. O’Carroll, “Bringing test and evaluation into the digital future,” Feb. 11, 2021. [Online]. Available: https://www.defenceiq.com/defence-technology/articles/bringing-test-and-evaluation-into-the-digital-future

[17] D. Panigrahi, “Leveraging AI, digital twins, AR/VR for military aircraft maintenance,” May 31, 2024. [Online]. Available: https://www.c4isrnet.com/opinion/2024/05/31/leveraging-ai-digital-twins-arvr-for-military-aircraft-maintenance/

[18] MOSIMTEC LLC, “Model One: Revolutionizing digital twins in military and industry,” July 25, 2024. [Online]. Available: https://mosimtec.com/model-one-revolutionizing-digital-twins-in-military-and-industry/

[19] F. Abdoune et al., “Integration of artificial intelligence in the life cycle of industrial digital twins,” IFAC-PapersOnLine, vol. 55, no. 10, pp. 2545–2550, 2022, doi: https://doi.org/10.1016/j.ifacol.2022.10.092.

[20] A. Cosmas et al., “Digital twins and generative AI: A powerful pairing,” Apr. 11, 2024. [Online]. Available: https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/tech-forward/digital-twins-and-generative-ai-a-powerful-pairing

[21] C. Moates, “How AI can help power digital twins,” Jun. 20, 2024. [Online]. Available: https://landvault.io/blog/how-ai-can-help-power-digital-twins

[22] K. Muhammad, T. David, G. Nassisid, and T. Farus, “Integrating generative AI with network digital twins for enhanced network operations,” Jun. 24, 2024. [Online]. Available: https://arxiv.org/html/2406.17112v1

[23] B. Banerjee et al., “Digital twin: A quick overview,” ITEA Journal of Test and Evaluation, vol. 45, no. 1, Mar. 2024. [Online]. Available: https://itea.org/journals/volume-45-1/digital-twin-a-quick-overview/

[24] V. P. Ankitha, “11 amazing digital twin examples for industries,” Oct. 16, 2024. [Online]. Available: https://www.toobler.com/blog/digital-twin-examples

[25] I. Wright, “Where artificial intelligence meets the digital twin,” Apr. 19, 2024. [Online]. Available: https://www.engineering.com/where-artificial-intelligence-meets-the-digital-twin/

[26] D. M. Botín-Sanabria et al., “Digital twin technology challenges and applications: A comprehensive review,” Remote Sensing, vol. 14, no. 6, p. 1335, 2022, doi: https://doi.org/10.3390/rs14061335.

[27] C. L. Tomovic, L. B. Ncube, A. Walton, and M. Grieves, “Development of product lifecycle management metrics: Measuring the impact of PLM,” Int. J. Manuf. Technol. Manag., vol. 19, no. 3/4, pp. 167–179, 2010.

[28] A. L. J. Walton, M. W. Grieves, D. L. Sandall, and M. L. Breault, “Developing a unified product lifecycle management value model,” in Product Lifecycle Management for Digital Transformation of Industries, IFIP WG 5.1 Int. Conf., PLM 2016, Columbia, SC, USA, Jul. 11–13, 2016, Revised Selected Papers, vol. 13, pp. 569–578. Springer International Publishing.

[29] A. L. J. Walton, C. L. Tomovic, and M. W. Grieves, “Product lifecycle management: Measuring what is important—Product lifecycle implementation maturity model (PLIMM),” in Product Lifecycle Management for Society, pp. 406–421, 2013, doi: https://doi.org/10.1007/978-3-642-41501-2_41.

[30] A. L. J. Walton, Product lifecycle management: Strategic technology road mapping, Ph.D. dissertation, ProQuest Dissertations and Theses Global, 2009.

[31] T. W. Simms, “Using modeling and simulation to increase speed to market, reduce risk, and foster interoperability in the industrial base,” Office of the Under Secretary of Defense for Research and Engineering, pp. 117–118, Dec. 2022. [Online]. Available: https://ac.cto.mil/wp-content/uploads/2022/12/Using-Modeling-and-Simulation-to-Increase-Speed-to-Market-Reduce-Risk-and-Foster-Interoperability-in-the-Industrial-Base.pdf

[32] S. Roodhouse, “The digital twin: Compressing time to value for digital industrial companies,” General Electric, 2018. [Online]. Available: https://www.ge.com/digital/sites/default/files/download_assets/The-Digital-Twin_Compressing-Time-to-Value-for-Digital-Industrial-Companies.pdf

[33] ITEA 2022 National Symposium Participants, “Digital twin ITEA – Industry definition ITEA 2023 symposium,” Dec. 4, 2023. [Online]. Available: https://itea.org/digital-twin-itea-industry-defitnion-itea-2023-symposium/

[34] S. Carberry, “Air Force aims for common virtual training environment,” National Defense Magazine, Nov. 11, 2022. [Online]. Available: https://www.nationaldefensemagazine.org/articles/2022/11/11/air-force-aims-for-common-virtual-training-environment

[35] Department of Defense Instruction (DoDI) 5000.97: Digital Engineering, Office of the Under Secretary of Defense for Research and Engineering, Dec. 21, 2023. [Online]. Available: https://www.esd.whs.mil/DD/

[36] Department of Defense Instruction (DoDI) 5000.89: Test and Evaluation, Office of the Under Secretary of Defense for Research and Engineering and Office of the Director, Operational Test and Evaluation, Nov. 19, 2020. [Online]. Available: https://www.esd.whs.mil/DD/

[38] Department of Defense Instruction (DoDI) 5000.88: Engineering of Defense Systems, Office of the Under Secretary of Defense for Research and Engineering, Nov. 18, 2020. [Online]. Available: https://www.esd.whs.mil/DD/

[39] Department of Defense Instruction (DoDI) 5010.44: Intellectual Property (IP) Acquisition and Licensing, Office of the Under Secretary of Defense for Acquisition and Sustainment, Oct. 16, 2019. [Online]. Available: https://www.esd.whs.mil/DD/

[40] S. Mathur and S. Malik, “Advancements in the V-Model,” International Journal of Computer Applications, vol. 1, no. 12, pp. 29–34, 2010.

[41] P. D. Ciampa, G. La Rocca, and B. Nagel, “A MBSE approach to MDAO systems for the development of complex products,” in AIAA Aviation 2020 Forum, 2020, p. 3150

This section offers guidance and examples for incorporating Digital Twin (DT) model contract language throughout a system’s full acquisition lifecycle, which includes the phases of Design & Development (D&D), integration, Test & Evaluation (T&E), and Operations & Sustainment (O&S).

The integration of Artificial Intelligence (AI) components necessitates careful consideration of specific drivers and constraints. These considerations must ultimately be formalized as clear terms and conditions within a negotiated contract mechanism.

Specifically, the contract serves to establish the precise parameters for information sharing among all involved participants. The use of AI, however, introduces new challenges to this process. Consequently, data rights—including the validation and verification (V&V) of training data, the handling of data from diagnostic instrumentation, and the protection of intellectual property—are becoming increasingly important features that must be explicitly addressed in the contract.

T&E professionals can provide essential support by:

• Advising Program Managers (PMs) on the specific information required for the V&V of models;
• Estimating the potential cost and schedule impacts that might result from the failure to secure specific data rights;
• Considering the necessary information needed to effectively plan for and augment physical testing

Below are examples of Digital Twin (DT) contract language organized by Acquisition Lifecycle Phase:

A.1 Design and Development (D&D)

• Produce, provide access to, and deliver a DT that provides an accurate representation of the [enterprise, system of systems, system, subsystem, product] at a sufficient level of fidelity to verify performance of the [enterprise, system of systems, system, subsystem, and/or product].
• The DT shall be a Configuration Item [with associated Government approvals described elsewhere].
• Include in the Model Development Plan (MDP) a plan for Model Based Systems Engineering (MBSE) activities necessary to develop the design [production, delivery, maintenance] of [system] using Systems Modeling Language (SysML) compatible models as needed for acceptance into the Government’s modeling software
• Deliver a System Solution, Architecture Model shall include traceability between system requirements, architecture, system design, and V&V
• Provide a complex requirement decomposed into multiple simpler requirements
• Provide a model elements that may refine a requirement by additional clarification and context to the requirement
• Verification cross reference tables that provide clear evidence of requirement verification
• Reference a government provided MBSE Style Guide or develop an MBSE Style Guide
• Produce, provide access to, [and deliver] a DT that provides an accurate representation of the [enterprise, system of systems, system, subsystem, product] at a sufficient level of fidelity to verify size, weight, and power of the [system, subsystem, product]. The digital twin shall be a Configuration Item [with associated Government approvals described elsewhere]. This DT shall be verified by a physical twin
• DE must be addressed in the acquisition strategy, including how and when DE will be used in the system life cycle and expected benefits of its use. In addition, as specified in DoDI 5000.88, certain programs must include a DE
• Provide a complex requirement decomposed into multiple simpler requirements
• Enforce the mode checking rules on the model elements
• Programs initiated before the date of this issuance may incorporate DE when it is practical, beneficial, and affordable, but are not required to do so
• The DE/MBSE technical package shall contain the DE/MBSE model
• Price central repository(ies) identification or if it exists now, or future iterations in work or Final implementation
• Manage the model(s) configurations by identifying the relationships between models, dependencies between model libraries and program data management
• Manage the interrelationship between model and system entities and include sync-merge and be able to manage multiple model baselines
• Document the model configuration management plan in the MDP
• Develop CONOPS, behavior, logical / physical definition of system structure and function, and external interfaces

A.2 Integration

• Delivered model(s) shall be capable of integration with the enterprise model as specified
• Provide a complex requirement decomposed into multiple simpler requirements
• Develop, collect, and document metrics for the change management
• Verify performance of the [enterprise, system of systems, system, subsystem, and/or product]
• Verify the [enterprise, system of systems, system, subsystem, and/or product] can be produced, and produced at rates meeting program plans [reference document describing production objectives, rates/quantities, schedules, support for production simulations, etc.]
• Manage the model(s) configuration by identifying the relationships between models, dependencies between model libraries and program data management; manage the interrelationship between model and system entities; include sync-merge strategies between different model versions; be able to manage multiple model baselines; be defined in the model development plan; develop, collect, and document metrics for the change management
• Allow designated Government Program Office personnel to participate in the configuration management processes related to the Contractor’s MBSE environment
• Document the model configuration management plan in the MDP
• Deliver model(s) shall be capable of integration with the enterprise model as specified
• Allow designated Government Program Office personnel to participate in the configuration management processes related to the Contractor’s MBSE environment
• Develop traceability between system requirements, architecture, and system design

A.3 T&E

• Develop and document model validation rules to enforce semantic constraints on system elements
• Deliver a System Solution, Architecture Model shall include traceability between system requirements, architecture, system design, and VV&A
• Develop model validation plan/scripts/procedures as part of the model development
• Document the model validation and verification plan as part of MDP or as a separate document
• Model shall be installable, usable and executable in the Government environment as described
• Use the SSIO Digital Lifecycle Reference Model or specific Digital + Life + Cycle + Reference + Model to determine appropriate model(s), quantity, and fidelity to support test & training throughout the lifecycle of the program
• Encourage but not required DoDI 5000.97 OTTI Digital Test & Training creates legacy models as needed
• Produce, provide access to, [and deliver] a DT that provides an accurate representation of the [enterprise, system of systems, system, subsystem, product] at a sufficient level of fidelity to verify size, weight, and power of the [system, subsystem, product].
• The DT shall be a Configuration Item [with associated Government approvals described elsewhere].
• DT shall be verified by a physical twin
• Produce a DT [or set of DTs] that provides an accurate representation of SystemX to conduct [training, wargaming, operations, maintenance scheduling, other] activities
• The DT shall have a sufficient level of fidelity to:  Characterize the [functional, allocated, and/or
• product] baseline; Verify size, weight, and power of the [system, subsystem, product].
• Verify interfaces [within and] at the boundaries of the [enterprise, system of systems, system, subsystem, product
• Produce, provide access to, [and deliver] a DT that provides an accurate representation of the [enterprise, system of systems, system, subsystem, product]at a sufficient level of fidelity to verify performance of the [enterprise, system of systems, system, subsystem, and/or product]
• The DT shall be a Configuration Item [with associated Government approvals described elsewhere]
• Develop traceability between system requirements, system design, and verification, validation, and test

A.4 O&S

• The model shall be installable, usable and executable in the Government environment as described
• Enable manufacturing of the [enterprise, system of systems, system, subsystem, and/or product] [Reference document describing production and/or sustainment objectives as needed]
• Enable installation and functional checkout of the [system, subsystem, product, modification, other] [Reference document describing functional procedures to be used as needed
• Identify the software and hardware tools for modeling, number of licenses for each, and the analysis the Offeror performed (including all assumptions made) to determine the quantity associated with the licenses the Offeror will deliver
• Provide access to DT accurate level of fidelity to enable maintenance (troubleshooting, predictions, simulations, training, users guide, maintenance manuals, tech orders, etc.) of the system, subsystem, product modification, and other