Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
| dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-03-twin-node-requirements:twin-009-control-twin-interaction:start [2026/08/22 13:56] – removed - external edit (Unknown date) 127.0.0.1 | dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-03-twin-node-requirements:twin-009-control-twin-interaction:start [2026/08/22 14:09] (current) – nick_dido | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | ====== TWIN-009 — Control Twin Interaction ====== | ||
| + | [[dido: | ||
| + | |||
| + | TWIN-009 is a non-leaf requirement group governing interactions among [[dido: | ||
| + | |||
| + | A Twin Relationship does not, by itself, grant a Twin Realization authority to modify another Twin Realization, | ||
| + | |||
| + | Interaction control establishes which interactions are permitted, the permitted direction of those interactions, | ||
| + | |||
| + | Communication connectivity, | ||
| + | |||
| + | Conformance is assessed against the individual leaf requirements listed below. TWIN-009 does not establish a separate conformance obligation. | ||
| + | |||
| + | ===== Requirements ===== | ||
| + | |||
| + | ^ Requirement ID ^ Requirement Title ^ Purpose ^ | ||
| + | | TWIN-009a | Identify Permitted Twin Interactions | Identify the interactions permitted for a Twin Relationship. | | ||
| + | | TWIN-009b | Specify Twin Interaction Direction | Specify the permitted direction of each configured interaction. | | ||
| + | | TWIN-009c | Require Authorization for Resource State Changes | Require authorization for each permitted interaction that changes the state of a Resource. | | ||
| + | | TWIN-009d | Prevent Unauthorized Resource State Changes | Prevent an unauthorized interaction from changing the state of a Resource. | | ||
| + | | TWIN-009e | Reject Prohibited Twin Interactions | Reject interactions that are not permitted by the governing Configuration. | | ||
| + | |||
| + | ===== Contents ===== | ||
| + | |||
| + | * [[dido: | ||
| + | * [[dido: | ||
| + | * [[dido: | ||
| + | * [[dido: | ||
| + | * [[dido: | ||
| + | |||
| + | {{indexmenu> | ||
| + | |||
| + | ===== Source ===== | ||
| + | |||
| + | * [[dido: | ||
| + | * [[dido: | ||
| + | * [[dido: | ||
| + | |||
| + | ===== Rationale ===== | ||
| + | |||
| + | A [[dido: | ||
| + | |||
| + | 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' | ||
| + | |||
| + | 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, | ||
| + | |||
| + | State-changing interactions require stronger control because they can alter the conditions under which Test Execution, synchronization, | ||
| + | |||
| + | Technical connectivity, | ||
| + | |||
| + | ===== Applies To ===== | ||
| + | |||
| + | * [[dido: | ||
| + | * [[dido: | ||
| + | * [[dido: | ||
| + | * [[dido: | ||
| + | * [[dido: | ||
| + | * [[dido: | ||
| + | * [[dido: | ||
| + | * [[dido: | ||
| + | * [[dido: | ||
| + | * [[dido: | ||
| + | * [[dido: | ||
| + | * [[dido: | ||
| + | * [[dido: | ||
| + | |||
| + | ===== 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-009 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 '' | ||
| + | |||
| + | Do not infer authority to modify a corresponding Node, Twin Realization, | ||
| + | |||
| + | Do not infer interaction permission from technical connectivity, | ||
| + | |||
| + | TWIN-009 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. | ||
| + | |||
| + | ---- | ||
| + | |||
| + | <WRAP centeralign> | ||
| + | © 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc. | ||
| + | </ | ||