Tags and keywords
A «digital» 
@Entity always starts with isBound = false and in the state UnBound; it only becomes Bound once it has a «physical» PhysicalEntity (such as an ActualPhysicalAsset) that Exists ( has mass) assigned, noting that:
An «physical» ActualPhysicalAsset always starts by default with isExists = false and in the state Phantom (even if one is acquiring rather than creating one).
In the acquisition case, the state of an identified (candidate) ActualPhysicalAsset is immediately shifted to Exists (it is asserted that it is known to have mass) and then a «digital» @Entity binds to it after it has been populated with any initial mapping data (such as digital survey data, scanning data etc.).
The block «digital» PotentialPhysicalAsset tracks the integration of an acquired (pre-existing) or planned (to be built or otherwise created) «physical» ActualPhysicalAsset. It always starts off with isIntegrated = false and in the Potential state.
In the acquisition case, it moves from state Potential to Identified then Integrated.
In the creation case, it moves from state Potential to Planned then Integrated.
The state Integrated has a scripted OpaqueBehavior isIntegrated=true as 'entry' Behavior.
By the time it reaches the Integrated state, its target actual exists ( has mass) and then its active job as an acquisition or creation tracker is done forever.
A «digital» @Entity only enters the twinning synchronisation and control cycle under the management of a parent «twin» DigitalTwin once that twin and its «physical» PhysicalEntity (such as an ActualPhysicalAsset) have both 'attached' to any «sensor» Sensor or «actuator» 
Actuator items. The «twin» DigitalTwin has then become an active Digital Twin Instance (DTI).
You might be asking why some of these states (such as Planned and Integrated)) are not carried by the «physical» ActualPhysicalAsset block. Well, one could do it that way, but the approach here is that the «physical» ActualPhysicalAsset is a relatively passive target without explicit knowledge of the twinning, and the «digital» PotentialPhysicalAsset is its active "tracker". So all the ActualPhysicalAsset knows how to do is move from state Phantom to state Exists, which means it is then known to have mass.
The twinning entity «digital» @Entity can only become Bound once its mapped «physical» PhysicalEntity - in this case a «physical» ActualPhysicalAsset - is known to exist (has mass) and so can enter into a sensor/actuator control loop managed by the parent «twin» Digital Twin once it is Attached (and has become a functioning Digital Twin Instance).
A word on the modelling strategy for expert Magic Model Analyst® (Cameo Simulation Toolkit®) users:
The system uses mostly synchronous Operation triggers on Transitions with 'effect' Behaviors given by Activities; many of these could be done instead with concise OpaqueBehavior scripting, however using verbose Activity Diagrams does make it easier to annotate.
And in many cases one could use asynchronous Signal triggers, however that makes it a bit harder to coordinate the simulation and also harder to make a screencast video.
Note how some of the Operations return the target object (so-called method chaining). One advantage of this approach is that it helps reduce the number of Forks in the driving Activity Diagrams. To see how this is done visit this mini-tutorial (but afterwards please):
For now, the main thing to know is that Magic Model Analyst® (Cameo Simulation Toolkit®) knows how to match the 'effect' Activity parameters against the Operation parameters, including the synchronous return parameters.