Technically that means that the ParentID of the Activity is the Object_ID of the Pool or Lane.
Good point. Just some additions:
The ParentID of the Activity is the "Object_ID of the parent of the Activity shown in the Project Browser".
1. If the Activity is in a Lane, the ParentID should always be the Lane.
2. If the Activity is in a Pool, two places (in EA's project browser) are valid to be the parent of the Activity:
(1) The Pool itself (this is very obvious)
(2) A BusinessProcess which is referenced by the Pool.
Tips: in the Project browser, context menu on a pool | Encapsulate Process
3. If the Activity is not in the "Main(Internal) Pool", which will not show the boundaries. (Ref BPMN2.0 Specification: Figure 9.5) , the valid parenting places are:
(1) If the Collaboration element does not exist, the Activity simply stays as root (directly under the package);
(2) If the Collaboration exists:
the Activity stays inside the Collaboration.
the Activity stays inside the main pool elememt (referenced by the mainPool tag of collaboration that owns the diagram)
the Activity stays inside a process referenced (by processRef tag) by the main pool element which is referenced by the mainPool tag of that collaboration owns the diagram

Tips: in the Project browser, context menu on the collaboration diagram | Encapsulate Process
Actually, the user don't have to remember these, they are transparent.Another feature is worth to mention, on the bpmn diagram, there is a "
Validate Diagram" option, which is suggested before generate the docs. One of the validatiors will evaluate the project browser's parenting relationship and give warning/errors if any.
In summary, user can easily make the BPMN models; meanwhile, EA guaranteed the BPMN import/export are fully conforming to the specification (with a trade off of the above internal efforts) and make a solid ground for further usages. E.g. BPSim Configuration and Execution.