Any entity issuing a new identifier to data in this way must implement the Monitorable interface and should register itself with the Monitor before or at the point of assigning this new identifier. Some cases may register child items rather than delegating to the children themselves, for example a workflow definition may register all its processors as children and deregister on workflow completion rather than the process happening for each processor but however it is accomplished the result is the creation within the Monitor of a tree where nodes contain references to Monitorable objects within the workflow definition.
The Monitorable interface defines a simple contract - once registered the implementing class can return a list of MonitorableProperty instances defining the exposed dynamic state at this node in the context of a given process identifier. Any of these properties may be mutable in which case they will extend SteerableProperty, a sub-interface of MonitorableProperty which allows for the mutation of the property.
By design the Monitor is rather powerful - it has the ability to modify steerable properties in any running workflow. It is obviously desirable to restrict this, passing any given monitoring or steering agent a restricted subset of the monitor tree rooted at a specific process identifier and preventing direct access to the Monitor class. The Monitor interface defines methods to expose subsets of the monitorable state for this reason.