====== TWIN-010 — Control Twin Interaction ====== [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-03-twin-node-requirements:start|Go to C.3.3 Twin Node Requirements]] TWIN-010 is a non-leaf requirement group governing interactions among [[dido:99_annexes:annex-b-terms-and-definitions:t:twin_realization|Twin Realizations]] and between a Twin Realization and another entity participating in a [[dido:99_annexes:annex-b-terms-and-definitions:t:twin_relationship|Twin Relationship]]. A Twin Relationship does not, by itself, grant a Twin Realization authority to modify another Twin Realization, a corresponding [[dido:99_annexes:annex-b-terms-and-definitions:n:node|Node]], or another [[dido:99_annexes:annex-b-terms-and-definitions:r:resource|Resource]]. Interaction control establishes which interactions are permitted, the permitted direction of those interactions, and the authority required for interactions that change state. Communication connectivity, DDS discovery, Topic matching, [[dido:99_annexes:annex-b-terms-and-definitions:q:qos|Quality of Service]] compatibility, or possession of a technically usable interface does not establish permission to perform an interaction. Conformance is assessed against the individual leaf requirements listed below. TWIN-010 does not establish a separate conformance obligation. ===== Requirements ===== ^ Requirement ID ^ Requirement Title ^ Purpose ^ | TWIN-010a | Identify Permitted Twin Interactions | Identify the interactions permitted for a Twin Relationship. | | TWIN-010b | Specify Twin Interaction Direction | Specify the permitted direction of each configured interaction. | | TWIN-010c | Require Authorization for Resource State Changes | Require authorization for each permitted interaction that changes the state of a Resource. | | TWIN-010d | Prevent Unauthorized Resource State Changes | Prevent execution of a state-changing interaction with a Resource that lacks authorization. | | TWIN-010e | Reject Prohibited Twin Interactions | Reject interactions that are not permitted by the governing Configuration. | ===== Contents ===== {{indexmenu>dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-03-twin-node-requirements:twin-010-control-twin-interaction#1|js navbar nocookie maxjs#1 id#dido_te_twin_010_requirements_nav}} ===== Source ===== * [[dido:03-dido-te:99-annexes:annex-b-references:dte-001|[DTE1] U.S. Patent Application US20220237111A1]], virtual and physical Twin Node concepts, modification of Twin Nodes, comparison of results, and validation * [[dido:03-dido-te:99-annexes:annex-b-references:dte-002|[DTE2] Non-Traditional BAA Submission]], Digital Twin concepts, monitoring, scenario testing, integration, and Twin Nodes Selection * [[dido:03-dido-te:99-annexes:annex-b-references:dte-009|[DTE9] Distributed Immutable Data Object Reference Architecture (DIDO-RA)]], Digital Twin, distributed data, DDS publish-subscribe, and Quality of Service concepts ===== Rationale ===== A [[dido:99_annexes:annex-b-terms-and-definitions:t:twin_relationship|Twin Relationship]] establishes a semantic relationship among one or more [[dido:99_annexes:annex-b-terms-and-definitions:t:twin_realization|Twin Realizations]]. That relationship may support observation, information exchange, synchronization, simulation, or other interactions. The existence of a Twin Relationship does not imply that every participating entity may initiate every possible interaction. In particular, the ability to observe or receive information from another entity does not imply authority to change that entity's state. Explicit interaction control separates semantic relationships and communication capabilities from authorization to act. Interaction direction also requires explicit control. A relationship may permit information to flow from one entity to another without permitting the reverse interaction, or it may permit different interactions in each direction. State-changing interactions require stronger control because they can alter the conditions under which Test Execution, synchronization, comparison, or Validation occurs. Technical connectivity, middleware discovery, Topic matching, API availability, or compatible Quality of Service characteristics do not override the interaction permissions established by the governing [[dido:99_annexes:annex-b-terms-and-definitions:c:configuration|Configuration]]. ===== Applies To ===== * [[dido:99_annexes:annex-b-terms-and-definitions:d:dido-te|DIDO-TE]] * [[dido:99_annexes:annex-b-terms-and-definitions:t:twin_identity|Twin Identity]] * [[dido:99_annexes:annex-b-terms-and-definitions:t:twin_relationship|Twin Relationship]] * [[dido:99_annexes:annex-b-terms-and-definitions:t:twin_realization|Twin Realization]] * [[dido:99_annexes:annex-b-terms-and-definitions:n:node|Node]] * [[dido:99_annexes:annex-b-terms-and-definitions:r:resource|Resource]] * [[dido:99_annexes:annex-b-terms-and-definitions:c:configuration|Configuration]] * [[dido:99_annexes:annex-b-terms-and-definitions:d:data_source|Data Source]] * [[dido:99_annexes:annex-b-terms-and-definitions:c:communication_parameter|Communication Parameter]] * [[dido:99_annexes:annex-b-terms-and-definitions:q:qos|Quality of Service]] * [[dido:99_annexes:annex-b-terms-and-definitions:d:dds|DDS]] * [[dido:99_annexes:annex-b-terms-and-definitions:t:test_definition|Test Definition]] * [[dido:99_annexes:annex-b-terms-and-definitions:t:test_execution|Test Execution]] ===== Traceability ===== {{backlinks>.}} ===== ConOps Relationship ===== This requirement group supports controlled interaction among Twin Realizations and other entities participating in testing. The governing Configuration establishes permitted interactions and their direction before those interactions occur. State-changing interactions additionally require authorization before execution. Interaction control applies independently of the communication mechanism used to realize the interaction. ===== Delivery Phase ===== TBD ===== Requirement Status ===== Draft ---- ===== Notes for Editors ===== TWIN-010 is a non-leaf requirement group and does not contain an independent normative Statement or Verification section. The explicit child links under Contents remain while the subordinate requirement pages are being created and reviewed. After all child pages exist, you may remove the explicit links because the ''indexmenu'' automatically discovers them. Do not infer authority to modify a corresponding Node, Twin Realization, or Resource from the existence of a Twin Relationship. Do not infer interaction permission from technical connectivity, DDS discovery, Topic matching, API availability, or Quality of Service compatibility. TWIN-010 governs permission and control of interaction. Communication Configuration remains governed by TWIN-003e, Quality of Service Configuration by TWIN-003f, synchronization by TWIN-006, and general Security requirements by C.4. ---- © 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.