In the workflow context, a class is best understood as an ”organisational role”. Once instantiated, it performs various behaviours dynamically with respect to its local environment. It can have phases of operation, starting with the factory phase where it “installs” itself, embodying/backing behaviour variations that best fit the local environment, needs and preferences.

Thereafter it engages in regular stimulus-response operation (which may still involve phases and subphases like seasonal and weekly operations, or bull/bear market strategies etc).

The distribution, bandwidth, churn, ping-time can all change arbitrarily and the scale can still flow up or down, the system still operate, just the timing constraints changing.

Distributed (p2p) class groups form simply from diverse holons claiming to embody the class (embodiment includes being part of the class group, helping to maintaing and co-create the collective class). The important aspect here is the potentially-indefinite pausability of any thread when it needs to wait for an event, such as a message arriving or a state condition being satisfied.

The more foreign holons fill local scope’s roles (i.e. the more foreign siblings there are), the more distributed the computation of the group becomes. A local instance scope is an entirely local (think “offline first”) affair, which synchronises with the other instances on a best-effort basis. In this way the distributed holons can engage in “social computation” (p2p workflow) even though they’re all just continuing their local behaviour – allbeit in a delay-agnostic (asynchronous) way.