Four quadrant holon model

This article or section is a stub. Stubs are articles that have not yet received substantial attention from the authors. They are short or insufficient pieces of information and require additions to further increase the article's usefulness. The project values stubs as useful first steps toward complete articles. See Wiki workflow and Wikipedia:Stub for more details on this process. See all the stubs in Category:Stubs

The purpose of this article is to serve as a software design pattern from which a peer can be programmed. While the Holarchy article introduced the general concepts and introduced the four quadrant model, this article goes into the data-structure and top-down/bottom-up processes in enough detail to implement it. The Holarchy article did not talk about the data structure, or the top- down/bottom up aspects of the system. Also the Holarchy article briefly introduced multiplexing from a high-level conceptual level, but this doc goes into the detail of it.

Class and instance

The other top-level dichotomy in Koestler's holarchy model is of fixed rules and flexible strategies, which refers to the composition and organisation of the behaviour patterns. In our system, we refer to these as class and instance since they are a far better match for these concepts in the information technology context.

The class aspect of objects is analogous to Koestler's fixed rules, it defines structured possibility space within which instances can select and enact appropriate activities from all the possible ones. Koestler's fixed rules provide a repertoire of behaviours corresponding to the conditions under which they apply. In other words, classes define possibility; how an instance of it would behave if various conditions were the case.

The OO system that is used by a high-level programming language is fundamentally about classes and instances (even if they don't explicitly take those names), because all OO is about the organisation of implementation details into encapsulated packages behind established interfaces. The word "class" refers to the packaging aspect of this organisational process, and "instance" to an actual executing occurrence of a package. The difference between different kinds of OO languages is about the different ways of organising of the packaging and deployment of common functionality.

This general functional organisation that class and instance provide is exactly the purpose of the holon model as well. But a holon extends this idea to serve not only its local individual objective, but also serves the integrity of the whole formed by all holons. We can say that traditional OO defines just the self-assertive behaviour, but the holon model extends it to include the integrative behaviour as well.

Evolution and knowledge go hand-in-hand, one does not exist without the other, because they depend on each other and on the previously mentioned dependent dichotomy of society and individual.

Evolution is actually a class-instance system itself, because the evolutionary knowledge is captured in re-usable "packages" (genes and species), but cannot express itself or develop without individuals to actualise it. Individuals are encapsulations of actualised knowledge, and the society is an ecosystem of the combinations of such encapsulations that have become established in usage.

Class and instance are interdependent, instances are created in the form of their class, but yet the class (as a p2p collective) is merely the totality of all the instances of it. Even though they're interdependent, instance is primary and class is the derived principle. This is the same situation as with the individual and collective mentioned above. It's also similar to cause and effect, they're two sides of the same coin, one following the other.

When thinking about OO programs, we usually think of the class structure as a static structure built from program code, and the instances as existing in the runtime space of an actual live running instance of the program. But here we're talking about the design of the actual OO environment itself.

In any "OO program" built within this environment, both the classes and instances exist in the single unified "runtime" space of this live running OO environment. In other words, classes and instances go hand-in-hand, they cannot exist independently of each other, they are both features of the runtime space of the OO system.

All organisation, knowledge and meaning within the holarchy can be looked at in the dual light of how it works and what it's like. How something works, means a model of it in actionable terms, and this takes the form of structured classes (classes that represent further class structure within, a pattern). What something is like can only be known by participating in it, or in other words representing a particular operating example of a class-tree, which is to say an instance structure of the class. A class-tree is referred to by one class. A class is an actionable model.

In the following sections we'll discuss class and instance in more detail, first talking about instance and then class both in the context of what they're like from the perspective of a running instance. Then we'll talk about how they work as an actual mechanism that produces this perspective.

Being an instance

A holon is an individual with it's own "subjective" point of view (POV) and internal private "mental" world of intention and state. All holons find themselves to be within a public arena populated with other holons.

A actualised "live" holon is an instance, it has been instantiated and operates continuously through time. This section introduces this situation from the perspective of what it would be like to be the operating instance, seeing the world through its "eyes" from behind its public interface.

Instance-scope

Normal OO object instances have a private internal persistent state for their operational memory, their scope of operation. The persistent state is a structure of class names all representing local information and further instances within.

Instances are containers of state and associated functions. In a holon these functions are sibling holons, which may have further organisation within at a smaller scale of holon operation, or they may be foreign agency. The two scenarios make no difference from the perspective of the holon in question, because the complexity or simplicity within these child holons is also encapsulated behind their public interface.

The scope is a namespace, a list of all the things that exist directly by reference to only their name. It's scope that allows for the distinction between public and private. It's a flat (non-hierarchical) list because we do not have any access inside the siblings since their internals are private to them.

All scope is essentially a set of unique identifiers representing other instances, agents, information or resources etc. Private scope is private because only functions (or agents) referred to in that specific scope have access to it. None beyond or within can see it.

The instance scope is persistent, existing for the life of the instance, they're an informational context shared by the group of functions and other agents that constitute the instance. All the siblings in the group interact with the scope they all share, rather than co-ordinating with each other directly, i.e. operating in accord with the Blackboard pattern (described in the preliminary concepts).

With the concept of private scope comes the complimentary concept of public scope. A holon can mark any of its private scope that it chooses to as public. This doesn't mean that it actually is public in the sense that anyone can see it, just that its accessible to the containing scope (which we call "beyond", "above" or "parent").

This aspect that is made available beyond, is called the public interface, and works the same way as private and public scope work in traditional OO instances. The public aspect is presented to the parent scope by the local agents collaboratively.

Agency

In the context of the holon, "agency" and "agent" refers to the ability to apprehend state and instructions and perform any actions that may be implied by them. The actual actor involved could be a user, AI, an API or OS, a domain-specific language interpreter or many other things. The holarchy is an organisational system which is agency agnostic.

A holon instance is an abstract informational representation of something real in the world that's being organised. In other words it's able to represent itself as a holon within the holarchy, as an instance within another (parent) instance. The instance's informational content is a representation in the same sense as the body schema described in the preliminary concepts.

Instances map foreign informational domains into the holarchy, presenting them primarily as what they conceptually are in the ontology, and with the working details encapsulated within their private scope. Those details may be further holon structure within, or may be pure foreign agency.

The "fingers" of the ontology slowly reach in to any holon ever more deeply, mapping the information state and sibling agents ontologically, developing the territory within into more refined ontological representation. An inherent attribute of the holon environment is penetration, the ontology automatically spreads to be an ever more accurate conceptual abstraction of the reality it interacts with.

More complete and accurate abstract representation yields more diverse and complex interaction and the opening up of new potential for organisation and re-use. We'll come back to these aspects more in the AI integration section.

Regardless of their agentic complexity, it's fair to say that all instances have a subjective local point of view consisting of the information and threads of activity within their instance scope. They find themselves to be in an organisational context consisting of other sibling instances of various classes encapsulating their agency within and presenting their state publicly for apprehension by the other siblings.

The organisation context these siblings find themselves within is itself an instance, and the siblings public states all together make up the presented public state for the parent context beyond.

Continuity

Each instance context is one of a group of sibling holons sharing a local persistent instance-scope. The siblings are all continuous threads of execution with shared access to an immutable past and a collaborative future as an inherent attribute of the scope. We'll go into the mechanics of these threads and time soon, but in the section we describe the continuity in the general terms of what it's like from the perspective of an instance operating within the scope.

Instances are actualised class patterns, classes representing further class structure within. In terms of the continuity of time "experienced" by an instance, the threads are hierarchical which permits arbitrarily complex systems and stories; trees of timeslots. Since classes can specify that instances of them act in response to complex conditions, structure can be highly dynamic and meaningful.

This structure of timeslots is a model of computation where each holons instance-scope follows the form and dynamics of the blackboard pattern. The execution takes the form of production rules where actions are performed by sibling agents in response to conditions evaluated against the local shared blackboard state.

Each timeslot connects sequentially to the timeslot in the same context the previous time focus arrived there which forms a chain. From the perspective of an agent receiving focus in that context, this chain seems like a continuous thread of time. So the tree of timeslots is actually a tree of threads. In this way local instances can access the state at any time in the past.

Instances can also refer to the future by linking to timeslots that have not yet received any focus which opens up the possibility of scheduling and planning in the future.

An account of any actions performed that lead to change of state is logged as part of the blackboard state and becomes immutable history. The change is accounted for in a kind of "ontological log entry" called an activity associated with the timeslot on the time line at that scale. The activity stream is an instance's timeline as a thread of focus. This is the foundation structure of the holarchy as a cognitive agency, which will come back to soon.

Conditions can be evaluated in real-time by subscribing to activity streams rather than "polling" the informational representation. Conditions are simple abstractions extending the representation, but higher abstractions like queries or reports work just the same way, and can serve as conditions.

It's very similar to a blockchain where each timeslot records all the action accounts that occurred within it forming a block of changes connected into a historical chain. The instance's informational representation can be built by "replaying" the historical record of changes, so the representation is more like a cache that the system is not dependent on; the immutable history of events is the source of truth, not the informational representation.

Agency in any scope can refer to other local items by class-name and can also navigate to past and future timeslots too. This is like a process in calendar event timeslot being able to refer to previous and subsequent timeslots in which that same event occurs.

This standard way of talking about future and past is available in any context at any scale whether it be a simple parameter or an entire organisation. It allows us to clearly define objectives or problems and behaviours to achieve or resolve them.

This common understanding across all classes of the flow of time is the foundation of the autonomy of a holon. The thread, persistent scope and the evolving representation of reality give the instance an autonomous subjective perspective.

Production rules

• more on how production rules standardise process definition to support merging and mixins

The control flow aspect of the system (i.e. the flow of the program due to conditions, loops and function calls etc) is all encoded directly into the structure itself, rather than being determined by the production rules. In other words, production rules are a declarative paradigm, they do not refer to program flow or program mechanics in any way, they just involve the local "blackboard" state.

The actual performance of actions and the means by which conditions are evaluated in the local instance-scope are left to the local agency, but presented by the organisational environment in language which is appropriate to them. This is similar to the idea of internationalisation of interface messages, where each message has a key identifying its meaning and context, and has many variations of the message within catering to different languages. But in the case of the holarchy, this methodology applies to all kinds of domain-specific languages and local preferences as well.

The life-cycle of an instance

A holon goes through different phases of operation in a repeating cycles which play a similar role to the seasonal changes and the effect these changes have on operations.

These phases can be thought of from the subjective participatory perspective as a sort of general "template life-cycle" for a typical instance. This cycle can be thought of as continuous similar to the alternating seasons, or in the case of one-off processes it's more like a typical template for a holon on its journey from birth to death.

Although a simple cycle of the same four phases, the arbitrary width and depth of the holon structure allows for arbitrarily complex "lives". In other words, every year, day or moment follows this same life-cycle pattern of four phases.

An instance or an organisation is like a story, it can even start as a simple hand-wavey idea, but it has purpose. It slowly collects attention and resource becoming more manifest, until it's more like a user story, a story that is defined clearly in terms of specific roles, interfaces and resources.

Typically, instantiation is the process by which a class establishes itself into an actual live organisational context. This can be thought of as installation and is analogous to onboarding in a human organisation.

Once the instance is established it then enters its operational phase where it carries out its objective.

Instances can be one-off jobs, which enter a closing-down phase when they're completed. But many instances are not one-off, they're continuous behaviour patterns. They can still be easily removed or changed, activated and deactivated, but while they're instantiated and active they operate as a continuously improving and evolving holon.

In the holarchy, all the phases of the instance lifecycle are continuous. The local circumstances or the class itself could change at any time requiring various internal refactoring and refitting. We'll go into more detail about these phases when we get to the discussion of the four quadrant model further on.

First-class citizens

• this section is the conclusion of being an instance - does it cover everything?

All holons are "first class citizens" in that they all have the same fundamental system of organisation in common, and they all have the potential to evolve into anything over time.

• mention relation to all equal under the law here?

In the context of programming languages, a first-class citizen is an entity which supports all the operations generally available to other entities. These operations typically include being passed as an argument, returned from a function, and assigned to a variable. In most OO contexts, objects are first-class citizens, meaning they can be instantiated, manipulated, and passed around in the code just like other basic data types.

The holarchy is not a programming language or OO environment in the traditional sense, since it's a higher level of organisation which is language-agnostic. But we use the tern regarding holons to imply that every holon instance has all the same inherent abilities and treatment as every other holon instance, regardless of it's depth in the hierarchy of instances, its complexity or simplicity.

Another important related aspect is that all first-class citizens are able to be understood and progressed by general agency if it's available in the context. They all have the potential for autonomy and continuity of perspective in linear-time. And they all have the potential to evolve in any direction. It's completely plausible that a holon that starts life as a simple piece of information could eventually evolve into a thriving international organisation.

Classes (from the agents perspective)

• this section is describing what its like for agents being in an environment backed by a co-evolving ontology, and how they form the background for instances to follow
• the high-level purpose of a class is to be a package of actionable knowledge

Classes in the holarchy are not things that are designed independently outside the runtime, they're a dynamic product of their instances; interdependent and co-evolving together in the same space. One important consequence of this is that the development of the "programs" (which is essentially the creation and adjustment of class structure) takes place in the same evolving space as the running instances of these "programs".

Note that we put the word "program" in quotes above. This is because classes are not defined in terms of program code, but rather are collections of production-rules (condition-action pairs) which, being of such a standard form, permits their global organisational independently of their complexity or purpose. We'll come back to this soon.

Class-scope

• just a short intro because this section is about class from the perspective of instance-scope, class-scope will be discussed below in "the mechanism" section

The class-scope is information that is public and shared amongst all the instances of a class unconditionally. This scope is super-public and cannot be restricted in access at all, we call this kind of super-public scope non-local. In the holarchy, non-local also implies scale-independence.

Even though class-scope has the special property of being non-local in our system, there's still an equivalent concept in traditional OOP. A couple of traditional class-scope examples are static methods or properties and the factory design pattern.

• this is the integrative behaviour
• class-scope means abstract, not associated with a specific location or time
• the process takes the form of the evolutionary loop and forms the class-tree
• class-scope, class-tree and class-state (background, default)

merge: The factory pattern executes in class-scope which can be thought of as the class sending a representative to the local context in which the instance is being requested. The representative can assess the local needs in detail and then decide on the most suitable sub-class for the situation.

The factory pattern

• this should be just an intro, and more detail at the pattern level in the inherent patterns section
• the factory pattern is essentially about what processes operate in class-scope

The so-called factory design pattern is a foundational concept in OOP which permits new objects to be instantiated without knowing of which specific class that the created instance will be.

Essentially, a general class will be requested to carry out some particular purpose, and this general class will determine the most suitable specific sub-class to instantiate. Often the factory pattern will also instantiate the new class with various parameters fine-tuned to the specifics of the context.

In the holarchy, this class-scope aspect is very important, process operating in this scope can be thought of as "factory processes" in the sense that they're all about using the knowledge from the class as a whole to "install" instances locally using the most fitting classes and capabilities of the class, while also ensuring that no wasted resource is being used for redundant aspects.

The factory (integrative) processes in the holarchy are also responsible for the integration of the knowledge from all the instances of the class too. The process of "installation" involves a deep penetration into the local context to understand every aspect of it, while at the same time interfering as little as possible. The knowledge gained from this process is extremely valuable to the class as a whole, since so many other installations will involve the same patterns and issues.

The factory processes in class-scope is really what the integrative behaviour of a holon is, and it is completely aligned with the primary objective of the holarchy as a whole. For this reason we often refer to it as the objective layer or the upper ontology.

Continuous factory

In reality, circumstances in both the class and the local context change over time, so if the same instance had been instantiated at a later time it may have been structured differently during it's "installation".

As we discussed above in the instance life-cycle, all the processes in a holon are loosely-coupled and continuous. Although the factory phases is the first thing that needs to happen in the life of an instance, it's always possible that it may become active again to ensure that the sub-classes used and their structure are continuously "fitting" to meet the dynamic local circumstances.

Variations

We still need to introduce variations and the ontological structure of classes here, but remembering that we're coming from the instance-scope perspective

Ontology

• the high-level purpose of a class is to be a package of actionable knowledge
• the mergability of production rules due to the blackboard model, leading to ease of combination
• outro: the ultimate form of these packages and map of variations is the ontology, the collective map into the state of resource flow - but remember this is from the perspective of being an instance

The class-instance mechanism

So far we've introduced the holarchy system in terms of what those concepts are from the perspective of an operating holon in it's local instance-scope. In this section, we introduce the objective "nuts and bolts" mechanism which results in the two behaviours and the class and instance concepts, as well as the individual and collective forms they both take.

This mechanism is responsible for bringing about the instance-scope, and so it operates outside of instance-scope, which is to say in class-scope.

• it's here that we start to see how class and instance work in the integrative way to contribute to a collective system... more about p2p collective aspect... and that ontology/market are the final results which will be detailed more below

Two trees

In terms of data structure class and instance are a pair of graphs that each relate holons ("object instances") together in their own grouping structure. We call them trees, although technically only the instances are connected in the form of a true DAG (directed acyclic graph or one-to-many tree), the classes are connected as a more general semantic network.

These trees are very much like traditional OOP where there is a structure of live actualised instances and an ecosystem of classes from which instances are instantiated and which determines how they operate.

The instance-tree in the holarchy system is easily understood because it's much like a runtime structure of object instances in any traditional running OO program.

But the class-tree is conceptually more difficult to grasp, because it's very different to traditional OOP, due to the aforementioned interdependence with their instances, and their lack of program code. However familiarity with the mix-in style of OOP classes can help in understanding classes as collections of production-rules that can be merged together to form complex patterns functionality.

The class tree is an informational graph connecting instances and their classes into a semantic map. Individual classes are packages of knowledge and production-rules (condition-action pairs). Since this method of defining function does not involve grammar, packages can be easily merged into more complex patterns.

The class tree is created by a global process of merging all variations of the class across all the instances of it in the tree. The class tree does not define how variations can arise, just how to integrate them into a global whole if they did arise. This tree defines the structure of classes, and as a whole defines the shared unified ontology of classes.

The merging of variations essentially means that the parent-child relationships in this tree are not black and white, but rather each relationship is itself a tree of optional variations where prominence is based on local relevance based on condition and usage metrics.

• this paragraph is not very clear

Instances take on the form defined by their respective classes, and the classes are the collective product of their instances. So the class-instance relationship is itself in the form of a co-evolving feedback loop just like the two behaviours are as well.

When we talk about the "systemic", "ontological" or "structural" aspect of a holon, we're talking about its class-tree aspect. This aspect of the holon is abstract because it is has no specific location or time.

• mention here that class-addressable memory works over time?

Multiplexing

The two trees are created, maintained and related by a simple process called time-division multiplexing. This is a process by which a continuous flow of executional focus is quantised into atomic (O₁) units which cyclically iterate the entire instance-tree structure.

This iteration process is a movement of executional focus from one node to another. When focus enters a node it's akin to the calling of a method function in traditional OOP, because it's moving down into a more specific context that is deeper within the structure. Conversely the leaving of focus corresponds to the returning from a functional call back up the tree to the "caller" above. The movement down is a process of division of focus, and the movement up is a process of information integration, aggregation and propagation upward and outward.

The control-flow paradigm is an integral part of the structure, rather than being determined by the program code of method functions.

As with traditional OOP, the vertical directionality gives rise to a structured scope system where there is an outer public side and an inner private side to every node. These correspond to the outward-facing and inward-facing concepts in Koestler's model.

In the holon, the kind of time being multiplexed is executional attention (more generally agent attention). The multiplexing movement of focus throughout the structure is a repeating pattern determined by the structure itself. This pattern exhibits a continuous bidirectional flow of function-like calling and returning.

Multiplexing is a scale-independent process, which means that the same dividing process applies to arbitrary depth, forming a hierarchy of threads from what is ultimately just a single thread. The width or depth of any local group of threads is all arbitrary and can change dynamically.

The cycle of top-down and bottom-up movement is used to create the class-tree. Since the process is responsible for dividing the executional focus throughout the whole instance tree cyclically, it also has the option of using a portion of that focus unconditionally for maintaining the class-tree.

• need to introduce non-local here being the commonality of all local is the p2p pattern
• non-local operation must be a scale-independent operation

Classes are not associated with any specific time or location, which is why the class-tree is called abstract and non-local.

The two trees define the different scopes of operation within the holarchy system. The class-tree defines non-local scope which groups all instances of the same class together regardless of their whereabouts in the holarchy. The instance-tree defines public scope and private scope which correspond to a specific location and time-slot.

• public is not necessarily actually public, it simply means not encapsulated

Linear time

The multiplexing movement of focus is such that quanta of focus always flow into the present time slot at every level in the instance-tree. This means that every node in the tree receives regular focus and so can be a further holon within. This regular pattern makes all holons into threads as a linked sequence of time-slots.

By also maintaining back-links between consecutive time-slots, both future and past are made available to the autonomous agency apprehending the local focus within. The mechanism makes the past immutable and leaves the future open for local collaboration within.

In multiplexing, time takes the form of a hierarchical schedule just like we naturally use ourselves by using a shared range of time intervals that are rationally related; seconds ... years etc.

Variations

In this section we need to go into the details of the class-tree structure being based on variations

• variations are a group of sub-classes
• variation prominence by establishment-in-usage
• an instance's class may change over time to another variation
• an existing variation may be instantiated, or a new class may be added
• this is source of adaptation

Conclusion

This multiplexing mechanism permits any "experiential" structure, i.e. combinations of holons of various types; some of specific types, some of general types, some informational, some agentic etc, all in a manifest state of instance, experiential, developing in time within an evolving society.

But these are just speculations so far. Thinking in terms of an offline-first network of organisations constituted from informational resources, agents and users all together in a evolving market ecosystem is a down-to-earth enough level to develop and deploy and that's where our main focus is in our instance of the universal holarchy project.

• FCC, recursion, scale-independence are all directly related
• every instance is a beginning of infinity (DD)
• infinite potential, scale independent
• scale-independence also means that children may be more complex than their parents

See also

• Holarchy
• Four quadrant holon philosophy