Glad to have found your channel, really useful! The way I had been intuitively thinking about it is that differently from deliverables, activities and tasks tend to be written prescriptively, so a good litmus test for me has been what would happen if I were to outsource the process of completing that deliverable. So if my project requires an image of a robot and I have in the plan an activity that says "Draw an image of a robot" just because that's the way I might personally go about it, I just created an unnecessary constraint: maybe the vendor would produce the image by using 3D software or photo compositing or AI generation, or maybe I could use a stock image. What my project really cares about is that the image of the robot exists in a way that satisfies the acceptance criteria. Of course this particular problem could be solved by just changing the wording to "Produce an image of a robot", but that's when the definition you mentioned kicks in: processes are a series of steps, so tracking the "process" of producing the image adds a lot more complexity than the binary question of "Does the image of the robot exist in a satisfying state or does it not?" By looking at the robot image as a deliverable, even if it's going to be produced internally with its own phases and tasks, that can be its own (smaller) project without its granularity polluting the main project.
