DI-SESS-82483A
Digital Twin Description (DTD)
Describes the design, function, interfaces, context, and lifecycle of a Digital Twin (DTw) in a descriptive model, standardizing how contractors document a DTw to support acquisition, engineering, logistics, and lifecycle management activities.
Approval DateApril 24, 2026
AMSC NumberF10654
Preparing Activity19 (SSC)
Project NumberSESS-2026-010
OPR—
DTIC ApplicableNo
GIDEP ApplicableNo
Limitation—
Applicable Forms—
Approval Limitation—
Form Version—
DID Formatfree_text
963C CompliantYes
DISTRIBUTION STATEMENT A: Approved for public release; distribution is unlimited.
Supersedes
—Related
—Description & Purpose
—
Application & Interrelationship
—
Use & Relationship
A Digital Twin Description (DTD) describes the design, function, interfaces, context, and lifecycle of a Digital Twin (DTw) in a model written in a descriptive modeling language (e.g., SysML, UAF, or other modeling language acceptable to the acquiring organization). The data requirements contained within this Data Item Description (DID) standardizes the way contractors describe a DTw. The intention is to support program offices in their acquisition, production, inspection, engineering, logistics, maintenance, integration, and upgrade activities of a DTw.
A DTw is a computerized representation (integrated set of models) that serves as a real-time1 digital counterpart of a physical object or process2, 3.
A DTw is also a virtual representation of a physical asset, system, or service that mirrors a real-world counterpart4.
For the purposes of this DID, a DTw is a Non-Physical Representation of a Real-World Counterpart that should have a Feedback Loop. If the requirements of the DTw do not account for all three aspects of the DTw, this description shall clearly state what aspects are removed (i.e., a partial DTw).
In addition to the above definitions, how a DTw is integrated (i.e., the act of combining disparate pieces) and federated (i.e., the act of managing disparate pieces) with other DTw's across the lifecycle will impact what constitutes 'a delivered DTw'. Thus, this DID is written to consider a DTw in any of the following three ways where the System(s)-of-Interest (SOI) is the system a DTw is intended to represent:
1) How the delivered DTw interacts with another DTw that supports the same lifecycle functions and the same System-of-Interest (e.g., DTw at 'Facility A' interacts with DTw at 'Facility B').
2) How the delivered DTw interacts with another DTw that supports different lifecycle functions for the same System-of-Interest (e.g., DTw for 'System A Design' interacts with DTw for 'System A Operations').
3) How the delivered DTw interacts with another DTw that supports the same lifecycle functions for different Systems-of-Interest (e.g., DTw for 'System A manufactured at Time A' interacts with DTw for 'System A manufactured at Time B').
The following are additional points of consideration for this DID:
a) Consider the use of DI-SESS-82400: DID for a System Architecture Model (SAM) to standardize the user-views of the DTD in support of section 2.1.
b) The acquiring organization will provide Use Cases for the DTw whether they are 1) provided by the government, or 2) proposed by the contractor and agreed to by the government to support section 3.1.6.
c) The acquiring organization will specify the descriptive model's level of detail.
d) Consider the use of DI-SESS-82426: DID for Model-Based Engineering Failure Modes, Effects, and Criticality Analysis Profile (SysML Version) to standardize documentation in support of section 3.1.6.5.
e) Consider the use of DI-SESS-82433 and DI-SESS-82434: DID for Cybersecurity Supply Chain Risk Management (C-SCRM) Software / Hardware Bill of Materials (S/HBOM) to standardize documentation of the DTw's supply chain in support of section 3.1.10.6.
f) Consider the use of DI-SESS-82380: DID for Model Based Systems Engineering Development Plan (MDP) to standardize a development plan for the DTD in support of section 3.1.11.
g) If the DTw, described by this DTD, requires a Technical Data Package (TDP), consider referencing MIL-STD-31000: DoD Standard Practice: Technical Data Packages to understand whether the resulting deliverable constitutes a complete TDP or a partial TDP (i.e., TDP Element).
h) This DID assumes the government has not identified an existing integrated environment (i.e., an environment to fully utilize a set of integrated or federated DTw's and its components) and, therefore, includes data requirements to describe any multi-organizational integrated environment whether it is contractor-developed, contractor-proposed, government-specified, or government-owned for test, training, exercises, and mission planning.
i) This DID contains data requirements spanning a number of DTw use cases. Standard use of a DID allows for removal of statements to tailor for specific program needs.
j) Consider the types of requirements (in section 3.2) to standardize the DTw Statements of Work (SOW) or DTw System Requirements.
Footnotes:
1 'Real-Time' to be taken as relative to the need and use cases.
2 Definition taken from DoD Instruction 5000.97: Digital Engineering - dated December 21, 2023.
3 In the context of this DID, a Digital Twin (bidirectional interactions between an SOI and a DTw) can be rudimentarily achieved when a Digital Shadow (unidirectional interaction from SOI-to-DTw) is paired with a human or user who manually supports the data transport and data transformation functions from the DTw to the SOI.
4 Definition taken from MIL-HDBK-539A: Digital Engineering and Modeling Practices - dated March 12, 2026.
Preparation Instructions
1Reference DocumentsThe applicable issue of the documents cited herein, including their approval dates and dates of any applicable amendments, notices, and revisions, shall be as specified in the contract.
2Format
2.1Description FormatThe term "description" in this DID means a collection of data, regardless of its medium. The term "model" in this DID means a medium that follows a semi-formal language (e.g., SysML, UAF, or other modeling language acceptable to the acquiring organization) where there are strict and repeatable rules on syntax. Therefore, the deliverable shall be a description model (colloquially known as a descriptive model) so that data required by this DID can be made individually available to stakeholders and their tools using automated techniques (such as Application Programming Interfaces (APIs)). The descriptive model's level of detail shall conform to the acquiring organization's specifications. In some cases, multiple DTw's could be delivered, so the description(s) shall be organized such that the SOI and the lifecycle functions the DTw will support are evident. If requirements are tailored out of this DID, the descriptive model shall contain a corresponding placeholder appended with "This content has been tailored out."
2.2Additional Description FormatThe term "document" in this DID is in contrast with "model" to mean a medium where portions of its content cannot be made individually available to stakeholders and their tools using automated techniques (such as APIs). Therefore, a description document in the contractor's preferred format shall be an acceptable appendix so that data required by this DID can be made accessible to stakeholders when tools using automated techniques are not available. Should conflicts arise between the descriptive model and the description document from the same delivery, the descriptive model will hold precedence.
3ContentThe deliverable shall include content to address both description and implementation needs. If portions of the required content have already been provided by the government, the DTD shall indicate what information has been provided and show any traceability where government-provided information differs from what the contractor is using internally.
Note 1: For brevity, this DID uses the term "component" to refer to Hardware Configuration Items (HWCIs) and Computer Software Configuration Items (CSCIs). Components-including HWCIs and CSCIs classified as "Major System Components" and "Modular Systems"-may occur at different levels of a hierarchy and may consist of other Components. The DTD shall identify which components are designated as "Major System Components" and "Modular Systems".
Note 2: For brevity, this DID uses the term "interfaces" to include "Modular System Interfaces". The DTD shall identify which interfaces are designated as Modular System Interfaces that describe the shared boundary between "Major System Components" and "Modular Systems".
3.1Description ContentThe description shall include all data items that can allow an independent party to verify the definition, development, operation, and decommission of a delivered DTw on a continuing basis. Sections 3.1.1 through 3.1.8 require descriptions about the DTw system. Sections 3.1.9 through 3.1.16 require descriptions for its lifecycle context. While a description model is the preferred format, a narrative document may be appended to more strongly focus the narrative content and allow comprehension of the DTw when a compatible software application is not available.
3.1.1ScopeThe scope shall include the following:
3.1.1.1IdentificationA full identification of the SOI, its components, and its interfaces, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s), and release number(s).
3.1.1.2Digital Twin OverviewA summary of the purpose of the DTw to which this DTD applies. It describes the general nature of the DTw and its key use cases defined within the Statement of Work (SOW) such as development or operational testing; summarizes the history of DTw development, deployment, operation, maintenance, and decommissioning; identifies the project sponsor, acquirer, user, developer, and support agencies; and identifies current and planned operating sites.
3.1.1.3Description Model OverviewA summary of the purpose and contents of the model-based description, including the security, privacy, or intellectual property rights considerations associated with its use.
3.1.1.4Description Document OverviewA summary of the purpose and contents of the document-based description, including the security, privacy, or intellectual property rights considerations associated with its use.
3.1.1.5Description Model FidelityA definition of the degree to which the DTD describes the DTw at government-defined levels of abstraction.
3.1.2Digital Twin Architecture Design Decisions and PrinciplesThe description shall include the design decisions and principles that govern the DTw Architecture.
3.1.3Digital Twin ComponentsThe description shall include the following. If part (or all) of the design depends upon the maturity, state, or condition of the represented system, this dependency shall be indicated. Design conventions needed to understand the design shall be presented or referenced.
3.1.3.1Components of the DTwIdentification of the CSCIs, HWCIs, data and their repositories, and Human-Machine Interfaces (HMI) for operator decision points, the type of component it is (Software Modeling, Sensing, or Infrastructure Component) and each assigned a project-unique identifier.
3.1.3.2Relationships of the DTw ComponentsIdentification, including a diagram of the static (such as "consists of") relationship(s) of the DTw components. Multiple relationships may be presented, depending on the design methodology.
3.1.3.3Purpose of Each DTw ComponentIdentification of the DTw requirements allocated to each DTw component.
3.1.3.4Development Type of Each DTw ComponentIdentification of each DTw component's development type (e.g., new, existing used as-is, existing to be reengineered) and status (e.g., being designed, testing, fit-for-use, accreditation). All development types and statuses are identified and defined with a unique identifier. Additionally identify when HWCI's are used due to cost or performance limitations of a CSCI.
3.1.3.5Modularity of Each DTw ComponentDescriptions for the following Technical Areas for each DTw component:
Note: Taken from Office of the Under Secretary of Defense for Research and Engineering's "Implementing a Modular Open System Approach in Department of Defense Programs (February 2025)" Appendix A (pg. 31)
3.1.3.5.1InteroperabilityDescriptions of how quickly modular components will be able to exchange information between themselves and appropriately use each other's functional capabilities.
3.1.3.5.2MaintainabilityDescriptions of what architectural characteristics address obsolescence and provide for timely technology refresh, fixes, and upgrades, and the proposed system's ability to be retained in, or restored to, a specified condition by appropriately skilled personnel.
3.1.3.5.3ExtensibilityDescriptions of the well-defined system engineering processes the contractor will follow to expand the DTw's capability during contract performance.
3.1.3.5.4ComposabilityDescriptions of the extent to which the Contractor's DTw is composed of well-defined components whose functionality is partitioned into discrete, cohesive, and self-contained units so that functionality is not spread over more than one component and updates to, or replacement of one component will not affect functionality featured by other components in the DTw's architecture.
3.1.3.5.5ReusabilityDescriptions of the ability of all components residing within the architecture of the DTw to be readily available and maintain certification, reliability, and performance when installed in other DTw's.
3.1.3.6Certifications NeededIdentification of the certification(s) that were needed to accredit each component, as applicable.
3.1.3.7System or Aggregate ComponentFor each system or other aggregate of components identified for use in the DTw (e.g., computer system, simulators, emulators), include a description of its resources (e.g., power, processor capability, memory). Each description, as applicable, identifies the configuration items that will use the resource, the allocation per system, conditions under which utilization will be measured, and the characteristics of the resource (e.g., manufacturer name and model number, type of resource, growth capabilities).
3.1.4Digital Twin BehaviorThe description shall include descriptions of the concept of operations, behavior, states, and processes through DTw Components, including diagrams showing the dynamic relationship of the DTw components. That is, how they will interact during DTw assembly, storage, deployment, and operations.
3.1.4.1Workflows of the DTwThe specific sequence of steps, tasks, or actions to accomplish a goal or use case of the DTw (including verification and testing workflows) and each unique sequence assigned a project-unique identifier.
3.1.4.2States or Modes of the DTwThe states or modes are identified as the specific sets of inputs the DTw responds to, the sets of outputs it produces, and the triggers the DTw can transition states or modes with. Each unique set assigned a project-unique identifier.
3.1.4.3Purpose of Each Workflow, State, or ModeIdentification of the DTw Use Cases allocated to it and whether it supports the physical-to-digital interaction (or vice versa).
3.1.4.4States or Modes of the DTw Components for each DTw State or ModeFor each state or mode of the DTw, include an identification of the state or mode of each DTw component (identified in section 3.1.3.1: Digital Twin Components) and what workflows are involved during that state or mode.
3.1.4.5Flow Through DTw Components for each DTw WorkflowFor each workflow of the DTw, include a description and diagram of the flow sequence through the DTw components (identified in section 3.1.3.1: Components of the DTw), what states or modes are involved, and what input data initiates the workflow.
3.1.5Digital Twin Interface DesignThe description shall include the following to describe and characterize the interfaces of the DTw. Including both the interfaces among DTw components and their interfaces with external entities such as other systems, other system DTw, configuration items, and users.
3.1.5.1Interface CriteriaIdentification of the criteria used to separate the DTw into its components, the DTw from external entities, and how the criteria impacted interface design decisions.
3.1.5.2Interface Data DefinitionIdentification of the individual data elements and data element assemblies (e.g., records, files, reports) that interfacing entity(ies) will provide, store, send, access, etc. and their characteristics as follows:
3.1.5.2.1Unique Identifier
3.1.5.2.2Non-technical (natural language) name
3.1.5.2.3Technical Name (e.g., field or data structure name in code or database)
3.1.5.2.4Abbreviation or synonymous name(s)
3.1.5.2.5Characteristics unique to Data Elements
3.1.5.2.5.1Data Type (e.g., alphanumeric, integer)
3.1.5.2.5.2Size and format (such as length and punctuation of a char string)
3.1.5.2.5.3Unit of measurement (such as meters, dollars, nano seconds)
3.1.5.2.5.4Range or enumeration of possible values (such as 0-99)
3.1.5.2.5.5Accuracy (how correct), precision (number of significant digits)
3.1.5.2.6Characteristics unique to Data Assemblies
3.1.5.2.6.1Data Elements in the assembly and their structure (e.g., order)
3.1.5.2.6.2Medium (e.g., disk) and structure of data elements on the medium
3.1.5.2.6.3Visual and auditory characteristics of displays and other outputs (e.g., colors, layouts, fonts, icons)
3.1.5.2.6.4Relationships among assemblies, such as sorting/access characteristics
3.1.5.2.7Minimum maturity of data element or assembly (i.e., application to the DTw's life cycle phase)
3.1.5.2.8Priority, timing, frequency, volume, sequencing, and other constraintsPriority, timing, frequency, volume, sequencing, and other constraints, such as whether the data element or assembly may be updated and whether business rules apply
3.1.5.2.9Sources (setting/sending entities) and recipients (using/receiving entities)
3.1.5.3Interface Communication Method DefinitionIdentification of the communication methods that interfacing entity(ies) use for interfaces.
3.1.5.3.1Unique identifier(s)
3.1.5.3.2Communication links, bands, frequencies, media and their characteristics
3.1.5.3.3Message formatting
3.1.5.3.4Flow control (such as sequence numbering and buffer allocation)
3.1.5.3.5Data transfer rate, whether it is periodic or aperiodic, and interval between transfers
3.1.5.3.6Routing, addressing, and naming conventions
3.1.5.3.7Transmission services, including priority and grade
3.1.5.3.8Safety, security, and privacy considerations such as encryption
3.1.5.4Interface Protocol DefinitionIdentification of the protocols that the interfacing entity(ies) use for the interface.
3.1.5.4.1Unique identifier(s)
3.1.5.4.2Priority and layer of the protocol
3.1.5.4.3Packeting, fragmentation and reassembly, routing, and addressing
3.1.5.4.4Legality checks, error control, and recovery procedures
3.1.5.4.5Synchronization, including: connection establishment, maintenance, termination status, identification, and any other reporting features
3.1.5.5Interface Identification and DiagramsIdentification of the interfacing entities by name, number, version, and documentation references, as applicable, and each assigned a project-unique identifier. The identification includes which entities have fixed interface characteristics (and therefore impose interface requirements on interfacing entities) and which are being developed or modified (thus having interface requirements imposed on them). If needed, one or more interface diagrams shall be provided, as appropriate, to depict the interfaces. Include a revision record for all released/approved interface information, including release dates.
3.1.5.6(Unique Interface Identifier)For each unique interface, include identification of the interfacing entities and descriptions for the interface characteristics of one or both of the interfacing entities.
3.1.5.6.1Priority assigned to the interface by the interfacing entity(ies)
3.1.5.6.2Purpose of interface to be implemented
3.1.5.6.3List of individual data elements involved at interface
3.1.5.6.4List of data element assemblies involved at interface
3.1.5.6.5List of communication methods involved at interface
3.1.5.6.6List of protocols involved at interface
3.1.5.6.7Other characteristics, such as physical compatibility of the interfacing entity(ies)
3.1.6Digital Twin User Stories, Use Cases, and Digital ThreadsThe description shall include the following:
3.1.6.1Derived User Stories and Use Cases of the DTwList that includes a unique identifier and description of each derived assumption, clarification, or extension from the government provided:
3.1.6.1.1Users (entities that interact with the DTw)
3.1.6.1.2User Stories (desired interactions with the DTw by one or more User)
3.1.6.1.3Use Cases (specific interaction implementations between the DTw and Users)
3.1.6.2Static Relationships of the Derived Use CasesIdentification, including a diagram of the static (such as "consists of") relationship(s) of the derived Use Cases.
3.1.6.3Purpose of Each Derived User Story and Use CaseIdentification of the DTw requirements allocated to each Derived User Story and Use Case, the objectives, and intended users.
3.1.6.4Digital Threads for each Derived Use CaseFor each derived Use Case, include identification of the layers of separation between the DTw and the SOI and each sequence of layers with a unique identifier. This can be understood as the communication or analytic framework that any piece of information or data must be transformed through to produce actionable information. The accuracy of the data retrieved through the derived use case shall also be documented.
Note: Digital Threads are defined in DoDI 5000.97 as an extensible and configurable analytical framework that seamlessly expedites the controlled interplay of technical data, software, information, and knowledge in the digital engineering ecosystem, based on the established requirements, architectures, formats, and rules for building digital models. It is used to inform decision makers throughout a system's life cycle by providing the capability to access, integrate, and transform data into actionable information.
3.1.6.5Failure Modes, Effects, and CriticalityIdentification of Failure Modes, their effects, and criticality and each provided a project-unique identifier.
3.1.7Digital Twin Requirements and Requirements TraceabilityThe description shall include the following:
3.1.7.1Stakeholder Needs and RequirementsIdentification and descriptions of the derived assumptions, clarifications, or extensions from the government provided Requirements or Source Documents.
3.1.7.2Requirements of the DTwIdentification of all DTw functional and performance requirements and the unique requirements needed to integrate components of the DTw, to federate unique DTw, and to integrate with other pre-existing DTw components to perform as a stand-alone DTw and each assigned a project-unique identifier.
3.1.7.3Non-Functional Requirements of the DTwIdentification of the programmatic and resilience (i.e., interoperability, maintainability, extensibility, composability, and reusability) requirements derived during the requirement definition and decomposition process, and each assigned a project-unique identifier.
3.1.7.4Traceability to RequirementsThe list of traces from each DTw Component, DTw Behavior, and DTw Interface identified within this deliverable to the DTw requirements allocated to it.
3.1.7.5Traceability from RequirementsThe list of traces from each DTw requirement to the DTw components, DTw Behavior, DTw Interface, DTw Use Cases, and Digital Threads to which it is allocated.
3.1.8Digital Twin Verification, Validation, and AccreditationThe description shall include the verification, validation, and accreditation (VV&A) information for the DTw. Where verification information identifies whether the DTw is built to DTw Requirements, validation information identifies whether the DTw satisfies government-provided DTw Use Cases and Needs, and accreditation information identifies whether the DTw meets a standardized level of capability and performance. The information provided may be documented in a Test and Evaluation Master Plan (TEMP), but shall contain the following:
3.1.8.1Verification Plans for the DTwIdentification of the plans that will be used to verify how the implemented DTw meets DTw requirements, and each assigned a project-unique identifier. A plan includes the following:
3.1.8.1.1Type of Verification (e.g., live, predicted, simulated, scenarios)
3.1.8.1.2Quality of Required Data (e.g., level of fidelity, significant figures, or simplifying assumptions)
3.1.8.1.3Range of conditions necessary to perform verification test
3.1.8.1.4Criteria for an acceptable result
3.1.8.1.5The list of traces from each Plan to the set of DTw Components, DTw Behaviors, or DTw Interfaces being verified
3.1.8.1.6The list of traces from each Plan to a User Story, Use Case, or Digital Thread
3.1.8.1.7The list of traces from each Criteria to a performance condition stated in a requirement
3.1.8.2Verification ResultsFor each implementation of a Verification Plan, identification of whether the DTw met the criteria for an acceptable result and to what degree the criteria was or was not met. If the criteria was not met, include a description of the root cause with the following:
3.1.8.2.1Component (identified in section 3.1.3)
3.1.8.2.2Failure mode
3.1.8.2.3DTw operational state at time of failure
3.1.8.2.4Immediate effects on the DTw
3.1.8.3Validation RoadmapIdentify the traceability between contractor verification plans to government-required validation events to support a government-led digital verification campaign.
3.1.8.4Accreditation InformationIdentification of the information, information type (e.g., model, data, documentation, and the IP rights necessary to use or access the information), and Subject Matter Expertise (SME) support necessary to ensure the consistent accreditation of each DTw (and instances thereof) across the lifecycle of the System-of-Interest.
3.1.8.5DTw Measures of PerformanceIdentification of the measures or attributes (Measure of Performance) necessary to assess and verify the accuracy of DTw generated content, including the objective thresholds for acceptable performance for each measure.
3.1.8.6Approach to Representing PhenomenaIdentification and description of the approach for credibility (or statistical confidence) thresholds that a DTw (or instances thereof) must meet while representing the modeled phenomena (e.g., physical, behavioral) of the System-of-Interest under relevant environmental conditions and each provided a project-unique identifier. Including known limitations of the representation and the risk of uncertainty to model performance compared to the represented phenomena and identify what DTw Measures of Performance were used to make that assessment.
3.1.8.7Approach to Representing System-of-InterestIdentification and description of the approach for credibility (or statistical confidence) thresholds that a DTw (or instances thereof) must meet while representing the System-of-Interest and each provided a project-unique identifier. Including known limitations of the representation and the risk of uncertainty to DTw performance compared to the physical system and identify what DTw Measures of Performance were used to make that assessment.
3.1.8.8Approach to Representing Build-UpIdentification and description of the approach for credibility (or statistical confidence) thresholds that a DTw (or instance thereof) must meet while representing the build-up (e.g., manufacturing, supply chain) of the System-of-Interest and each provided a project-unique identifier. Including known limitations of the representation and the risk of uncertainty to model performance compared to the represented context and identify what DTw Measures of Performance were used to make that assessment.
3.1.8.9Approach to ASOT ConfidenceIdentification and description of how the DTw asserts its statistical confidence as an Authoritative Source of Truth (ASOT) throughout its life, including what specific, recurring test plans, maintenance, and events will be used to validate those assertions on a continuing basis. List the classes of telemetry and performance data that contribute to ongoing confidence.
3.1.8.10Approach to Documentation Within the Digital Engineering Ecosystem (DEE)Identification and description of how the DEE (such as an Integrated Development Environment for Software Development) documents VV&A evaluations of the DTw and descriptions for how it is linked to inform program decisions.
3.1.9Information Technology InfrastructureIf the government does not identify an integrated environment to support DTw infrastructure needs, the description shall identify the IT Infrastructure necessary to support the deployment, operation, maintenance, evaluation, protection, and functions of other components of the DTw, its interfaces, and, as applicable, interfacing components. The infrastructure described supplements Section 3.1.3: Digital Twin Components, thus supplementing Sections 3.1.4: Digital Twin Behavior and 3.1.5: Digital Twin Interface Design.
3.1.9.1Components of the Requisite IT InfrastructureIdentification of the HWCIs, CSCIs, data repositories, and networks and each assigned a project-unique identifier. Include resource requirements and constraints such as power and memory. List Contract Data Requirements Lists (CDRLs) and DIDs as applicable to each IT Component.
3.1.9.2Initial Storage Requirements for the DTwBoth non-recurring and recurring. Non-recurring storage requirements are expected to define the storage necessary to host and operate the DTw. Recurring storage requirements are expected to define the storage necessary to retain the data created or collected over the course of DTw operations. Including identification of redundancy and backup requirements to ensure availability of the DTw.
3.1.9.3Resource Growth ProjectionsIdentification of the Storage Requirements that have the capacity to change over the life of the DTw, the specific metrics that inform that change, and the extent of that change. Identify similar technologies that were used to create projections based on their historical trends. If historical trends are not available, list the specific data and models by which any resource growth projections were made.
3.1.9.4Static Relationships of the IT ComponentsIdentification, including a diagram of the static (such as "consists of") relationship(s) of the IT components. Multiple relationships may be present.
3.1.9.5Data Handled by the IT InfrastructureIdentification of the data that will be shared across the IT Infrastructure between components of the DTw and each assigned a project-unique identifier.
3.1.9.6Data LifecycleIdentification and description, including a diagram, of the lifecycle of each identified data and its flow through the infrastructure. Multiple flows may be present, and the flow may change as the DTw matures through the represented system's lifecycle. Include resource requirements and constraints to sustain the end-to-end flow and its scalability.
3.1.9.7Purpose of Each IT Component and Data HandledIdentification of the DTw requirements allocated to it.
3.1.9.8Identification of LicensesIdentification of the license(s) to the IP that describes or is each IT Component, as applicable, as stated within the contract.
3.1.9.9Lifecycle Needs for each Data Repository Component within the IT InfrastructureFor each data repository component within the IT Infrastructure supporting DTw needs, include descriptions for development, deployment, maintenance, and access needs.
3.1.10Security and ProtectionsThe description shall describe the risks, threats, and controls unique to the DTw context. The information provided may be documented in a Security Plan, Security Classification Guide (SCG), or System Engineering Management Plan (SEMP), but shall contain the following:
3.1.10.1Risks and Threats to DTw ConfidenceIdentification of the risks or threats that could compromise the confidence in or operations of the DTw throughout its life (e.g., conflicting data, acquired or faulty components, incomplete model), particularly in its capacity as an ASOT. Including the likelihood of occurrence over the DTw's life and the severity of the impact to DTw confidence or operations. Assign each a project-unique identifier.
3.1.10.2Mitigations of Risks and Threats to DTwFor each identified risk or threat, describe the mitigation strategy proposed or used to limit impacts to DTw Confidence. Assign each a project-unique identifier.
3.1.10.3Controls on the DTwIdentification of the mechanisms, techniques, technologies, or various solutions implemented to secure and protect the DTw against risks and threats throughout its life (called Controls) (e.g., physical controls, cybersecurity, data protections, operational controls), including its purpose, where it is implemented within the DTw or IT Infrastructure context, and each assigned a project-unique identifier.
3.1.10.4Controls TraceabilityThe list of traces from each Control to the risks or threats the Control intends to protect against, the confidence to which the Control will sustain its protection over time (or over discrete events), how that protection can be tested and validated over the DTw's life, and who will be validating that protection.
3.1.10.5Risk and Threat Growth ProjectionsIdentification of the risks and threats that have the capacity to change over the life of the DTw, the specific metrics that inform that change, and the extent of that change. Identify similar technologies that were used to create projections based on their historical trends. If historical trends are not available, list the specific data and models by which any risk and threat growth projections were made. Include when those risks and threats exceed the capabilities of implemented Controls.
3.1.10.6Software and Hardware Bill of Materials (S/HBOM)Identification of the supply chain and heritage of all DTw Components, in particular, the third-party or open-source software or hardware used within or in the development of the DTw.
3.1.11Development MethodologyThe description shall include a summarization of the unique methodologies used in developing the DTw. The information provided may already be documented in some development plan, but shall contain the following:
3.1.11.1DTw and ASOT Development MethodologyIdentification of the approach, practices, and processes used during the development lifecycle of the DTw (e.g., scope, define, design, build, certify) and the ASOTs required of the government.
3.1.11.2DTw Refinement MethodologiesIdentification of the approach, practices, and processes used during the refinement lifecycle (e.g., define, decompose, manage) of the following:
3.1.11.2.1DTw Requirements
3.1.11.2.2DTw User Stories, Use Cases, and Digital Threads
3.1.11.2.3DTw User Experience(s)
3.1.11.3DTw Monitoring MethodologyIdentification of the approach, practices, and processes used during the monitoring lifecycle (e.g., track, report) of the following:
3.1.11.3.1Development of the DTw (and auxiliary resources) system and its alignment with the physical system
3.1.11.3.2Discrepancies between instances, versions, or branches of the DTw
3.1.11.3.3Schedule of the DTw development, deployment, maintenance, and decommissioning (and its instances)
3.1.11.4DTw Verification & Validation MethodologiesIdentification of the approach, practices, and processes used during the verification and validation lifecycle (e.g., verification, validation, testing) of the following:
3.1.11.4.1Digital Engineering Ecosystem (DEE) so the government may independently reproduce, test, and evaluate the DEE (such as an Integrated Development Environment for Software Development)
3.1.11.4.2Metrics to verify, validate, and test DTw functionality over time
3.1.11.4.3Metrics to verify, validate, and test DTw ASOTsInclude areas of known limitations of the ASOT and whether other ASOTs must be developed.
3.1.11.5Assurance MethodologiesIdentification of the approach, practices, and processes used to ensure the following:
3.1.11.5.1Incorporation of standards, guidelines, policies, and regulations into the development process
3.1.11.5.2Conformance of the DTw to cybersecurity and classified system requirements
3.1.11.5.3Configuration Management of the DTw, evolution of its components over time, and any alignment to open systems architecture approaches
3.1.11.5.4Management of the DTw Program (e.g., cost, schedule, risk)
3.1.11.5.5Data storage and backups of exchanged data between DTw and system, to include periodicity of backup, redundancy, and frequency of data overwrite
3.1.11.5.6Interactions with intellectual property content are controlled and intentional
3.1.11.5.7Evaluation (and optimization) of the DTw for modularity, extensibility, and resource use
3.1.12Digital Twin DeploymentThe description shall include the following where deployment is defined as all the activities that make a version of the described Digital Twin available for operational use in the relevant environment:
3.1.12.1Use Case Deployment TiersFor each Use Case (provided by the government and defined while satisfying requirements from section 3.1.6: User Stories, Use Cases, and Digital Threads), define the criteria to deploy an initial operational capability with additional criteria and milestones (called Use Case Deployment Tiers) as functionality or technology evolves through the life of the DTw; each assigned a project-unique identifier.
3.1.12.2Levels of DTw CapabilityConsidering the DTw as the sum of all its Use Cases, define key Levels of DTw Capability, where each level is a unique configuration of Use Case Deployment Tiers of increasing operational capability, and provide a rationale for why that level is being defined (e.g., all Use Cases have achieved an initial operational capability, a new database is being integrated and will affect Use Cases x-z). Assign a project-unique identifier for each Level of Deployment.
3.1.12.3Deployment LocationsIdentify all locations the DTw will be deployed, instantiated, or otherwise where computer or network resources must be allocated for the DTw to perform to a stated Level of DTw Capability. Each assigned a project-unique identifier.
3.1.12.4Deployment CapabilitiesIdentification of the tools, infrastructure, and expertise necessary to deploy the DTw (or instances thereof) (called Deployment Capabilities) and state its purpose. Each assigned a project-unique identifier.
3.1.12.5Deployment MethodologyIdentification and description of the approaches, practices, and processes used during the deployment lifecycle (e.g., when, where, and how a DTw shifts from a development environment to a production environment specified by the government.
3.1.12.6Deployment ScheduleIdentification and description of the sequence of activities and milestones with dates (called Deployment Schedule) of each instance (and incremental delivery) of the Digital Twin through its life and potential evolutions. For each instance or increment to be deployed through the life of the DTw, describe a Deployment Schedule for each portion of the DTw that needs to be separately deployed. If absolute dates are not possible, the Deployment Schedule shall define relative dates that are explicitly anchored to verifiable government program milestones.
3.1.12.7Entities Responsible for DeploymentFor each Deployment Schedule, identify the entity responsible for performing that portion of deployment.
3.1.12.8Deployment LimitationsIdentification of the limitations on when and where DTw may be deployed (called Deployment Limitations) and each assigned a project-unique identifier.
3.1.12.9Deployment UncertaintyFor each DTw that will be deployed, include a quantifiable estimate of the uncertainty and risk to deployment criteria and each assigned a project-unique identifier.
3.1.12.10Technology Impacts on Future DeploymentsIdentification of the impact that technology development will have on future Deployment Tiers, Levels, Schedules, and Limitations using historical trends.
3.1.13Digital Twin MaintenanceThe description shall include the following:
3.1.13.1Types of Maintenance ActivitiesIdentification and description of the types of maintenance activities that would be performed over the lifecycle of the DTw (and its infrastructure), and each assigned a project-unique identifier.
3.1.13.2Maintenance CapabilitiesIdentification of the tools, infrastructure, expertise, resources, and dependencies necessary to maintain the DTw (or instances thereof) (called Maintenance Capabilities) and state its purpose. Each assigned a project-unique identifier.
3.1.13.3Maintenance MethodologyIdentification and description of the approaches, practices, and processes used during the maintenance lifecycle (e.g., personnel training).
3.1.13.4Maintenance ScheduleIdentification and description of the sequence of activities and milestones with dates (called Maintenance Schedule) of each instance of the DTw through its life and potential evolutions. For each instance to be maintained through the life of the DTw, describe a Maintenance Schedule for each portion of the DTw that needs to be separately maintained. If absolute dates are not possible, the Maintenance Schedule shall define relative dates that are explicitly anchored to verifiable government program milestones.
3.1.13.5Entities Responsible for MaintenanceFor each Maintenance Schedule, identify the entity responsible for performing that portion of maintenance.
3.1.13.6Impacts from Operational and Maintenance Need ChangesIdentification of each change to the operation and maintenance needs of the DTw with a project-unique identifier and a listing of the impacts to DTw Use Cases, DTw Components, and DTw Behavior. Including impacts to data quality, data flows, and data structure.
3.1.13.7Maintenance LimitationsIdentification of the limitations on when and how the DTw may be maintained and each assigned a project-unique identifier.
3.1.13.8Maintenance UncertaintyFor each DTw that is to be maintained, include a quantifiable estimate of the uncertainty and risk to maintenance criteria and each assigned a project-unique identifier.
3.1.14Digital Twin DecommissioningThe description shall include the following:
3.1.14.1Decommissioning CriteriaIdentification and description of the conditions when instances of or every instance of a DTw will be considered for decommission and each assigned a project-unique identifier.
3.1.14.2Decommissioning PlansIdentification of the plans that will be used to decommission the implementation of the DTw and each assigned a project-unique identifier.
3.1.14.3Decommissioning StatesIdentification of the various states of decommissioning the DTw can be in and each assigned a project-unique identifier.
3.1.14.4Archival Standards of the DTwFor each state of decommissioning, list (as applicable) the archival standards the state conforms to, the minimum and maximum time a DTw shall stay in that state, the conditions that shall transition a DTw between states, the conditions that shall transition a DTw back to full operational capability, and the defined access controls, rights, and methods for various user roles to the archived features and data.
3.1.15InteroperabilityThe description shall include the following:
3.1.15.1Methodologies for Interoperability AssuranceIdentification of the approach, practices, and processes that ensure metadata, data, and component interoperability and each assigned a project-unique identifier.
3.1.15.2Instances of InteroperabilityIdentification of interoperability between uniquely deployed DTw of the System-of-Interest (or parts thereof), uniquely deployed DTw of other systems, (or parts thereof), and other virtual or physical assets (e.g., government-furnished threat models, other contractor-provided system models, or live-data feeds from operational systems). Each instance of interoperability is assigned a project-unique identifier.
3.1.15.2.1Federation within Government EnvironmentsIdentification of interoperability with, and ability to execute within, a government-provided reference environment. This includes government-provided interface standards and government-defined open data standards.
3.1.15.3Characteristics of the InteroperabilityFor each instance of interoperability, describe what is needed to enable the interoperation, the limitations of the interoperability, and the protections that support the protection of constituent components. This includes how well the interoperability addresses Visible, Accessible, Understandable, Linked, Trustworthy, Interoperable, and Secure (VAULTIS) goals.
Note: Goals taken from DoD Data Strategy's Section 4: Goals and Enabling Objectives (September 2020)
3.1.15.3.1VisibleThe ability for authorized government users and systems to discover DTw's, its data, its interfaces, and its services through enterprise catalogs and registries.
3.1.15.3.2AccessibleThe ability for authorized government users and systems to retrieve DTw's and its data through documented, standardized, and reusable APIs specified within governing Interface Control Documents (ICDs).
3.1.15.3.3UnderstandableThe ability for government tools to correctly interpret and use DTw's and its data without manual intervention.
3.1.15.3.4LinkedThe ability for DTw's and its data elements to be related to other elements that exist within the government environment.
3.1.15.3.5TrustworthyThe ability for authorized government users and systems to understand the pedigree, lineage, and VV&A status of each DTw and its data elements.
3.1.15.3.6InteroperableThe ability to exchange and use data from other system models, other data models, and other DTw's.
3.1.15.3.7SecureThe ability to protect DTw from unauthorized use or manipulation.
3.1.15.4A list of all incoming data from the system-of-interestto the DTw, the system component that created the data, and what information (if any) was used to create that data. Each assigned a project-unique identifier.
3.1.15.5Programmatic Traceability of Incoming DataA list of how the incoming data to (or usage of) the DTw is in accordance with the identified use cases, cybersecurity protections, and model development plan.
3.1.15.6A list of all the outgoing data to the system-of-interestfrom the DTw, the DTw component that created the data, and what information (if any) was used to create that data. Each assigned a project-unique identifier.
3.1.15.7Programmatic Traceability of Outgoing DataA list of how the outgoing data from (or usage of) the DTw is in accordance with the identified use cases, cybersecurity protections, and model development plan.
3.1.15.8Resources Involved During InteroperabilityIdentification of the information, data, or power used or processed through the DTw, and each assigned a project-unique identifier.
3.1.15.9Lifecycle for Each ResourceIncluding a description and diagram of the lifecycle(s) of that resource. Multiple lifecycles may be represented as the DTw matures.
3.1.15.10Interfaces Necessary for InteroperabilityList of all governing ICDs with rationale as to why the interface is necessary for interoperability.
3.1.16User ExperienceThe description shall include the user experience information unique to the DTw context. The information provided may be documented in a dedicated Instruction or Manual, but shall contain the following:
3.1.16.1User AccessibilityIdentification of the standards that ensure the DTw and auxiliary resources (e.g., User Manual, User Interface(s), and User Training) are accessible to identified Users.
3.1.16.2User ManualIncludes detailed descriptions and its intended audience (e.g., operator, analyst, maintainer) of the computer operational environment, connectivity needed to external environments (including connections to external ASOTs for use cases where up-to-date system status and configuration will be needed), and any third-party commercial software and tools (e.g., with any needed plug-ins) needed to operate the DTw.
3.1.16.3User Interface(s)Descriptions of the User Interface(s) used in the development, deployment, operation, and maintenance of the DTw including dashboards and visualizations to interrogate, visualize, and interact with the DTw and associated data.
3.1.16.4User TrainingDescriptions of the learning materials, instructor led classes, or practical simulations on how to use DTw.
3.2Implementation ContentThis content describes the types of requirements that will be imposed on a specific DTw to enable its functional capability. To the extent that the following functions are required for the DTw, this shall include:
3.2.1System Component StatusHow the DTw incorporates the known operational and maintenance status of applicable system components throughout their life cycles, when authorized and connected to authoritative sources of such operational and maintenance status.
3.2.2Analysis Support - Interface & Integration TradesHow the DTw provides integration and interface analysis/test with systems and system components outside of the program on contract.
3.2.3Analysis Support - Operator Decision TradesHow the DTw provides system operations trades and operator decision support.
3.2.4Analysis Support - Sustainment, Maintenance, and Logistics TradesHow the DTw provides sustainment trades, sustainment design, maintenance decision support (including predictive maintenance), and informs product support (supportability) analysis.
3.2.5Analysis Support - Enterprise TradesHow the DTw provides enterprise operations trades and decision support conducted by external organizations that use models for real-time operations. Note: this shall include system modeling supporting activities.
3.2.6Analysis Support - As-Is Model for the Future EnterpriseHow the DTw provides "as is" models supporting future enterprise architecture and enterprise operational planning and analysis that use or potentially use the System-of-Interest (SOI).
3.2.7Analysis Support - Could-Be SystemsHow the DTw provides a foundation for future system iterations, versions, or evolutions.
3.2.8Deployment ThresholdHow the DTw meets deployment thresholds over the System-of-Interest's designated design life, by deployer personnel having the Deployment Capabilities indicated in Section 3.1.12.3.
3.2.9Deployer TrainingHow the DTw provides initial and sustained deployer training.
3.2.10Operation ThresholdHow the DTw meets operation threshold over the System-of-Interest's designated design life.
3.2.11Operator TrainingHow the DTw provides initial and sustained training to operator personnel. These include training scenarios that are impractical or unsafe to replicate in live training events.
3.2.12Maintenance ThresholdHow the DTw meets maintenance thresholds over the System-of-Interest's designated design life, by deployers having the Maintenance Capabilities indicated in Section 3.1.13.2.
3.2.13Maintainer TrainingHow the DTw provides initial and sustained training to maintenance personnel.
3.2.14Model Credibility - Initial AccreditationHow (and to what specified fidelity) the DTw represents the System-of-Interest at the moment of System accreditation.
3.2.15Model Credibility - FitnessHow (and to what specified fidelity) the DTw represents the System-of-Interest at regular intervals and over a specified (discrete or continuous) range of stakeholder events. Where "regular intervals" is a practical definition of "real-time" or "continuous".
3.2.16Model Credibility - ExternalHow (and to what specified fidelity) the DTw represents the System-of-Interest at regular intervals and over a specified (discrete or continuous) range of external environmental interactions. Where "regular intervals" is a practical definition of "real-time" or "continuous".
3.2.17Model InteroperabilityWhat government-specified open standards the DTw must be compatible with to interoperate with government capabilities and other contractor solutions.
References
—
Schema v3.0Community-maintained · Verify against ASSIST
Community-maintained — not an official government database.
Verify against ASSIST·GitHub·About·Disclaimer
Verify against ASSIST·GitHub·About·Disclaimer