Webel Twin Pattern: DigitalTwin: The multiplicity of 'digitalEntity:@Entity' and 'physicalEntity:PhysicalEntity' MUST be [1] when the DigitalTwin is in the state Attached, the @Entity is in the state Bound, and the PhysicalEntity is in the state Exists.

Clearly, in a realistic representation of acquisition and creation scenarios, a «twin» DigitalTwin can't have an assigned «physical» PhysicalEntity and «digital» @Entity until they are created. However, in most diagrams in the following trail, the multiplicity of 'digitalEntity:@Entity' and 'physicalEntity:PhysicalEntity' within «twin» DigitalTwin is given as [1] (rather than [0..1]) to drive home the idea that a well-formed «twin» DigitalTwin always eventually has exactly 1 assigned «physical» PhysicalEntity and «digital» @Entity pair: Of course, one could use oclInState and Constraints, but that would only be clear to OCL-aware readers.