Talk:Holarchy

Content may be incorporated at some point

Epistemic convergence

The mechanism naturally emerges from exceedingly simple initial conditions, making it an epistemically convergent concept, which means assuming that it is known and used in unknown scopes beyond is a valid assumption.

Hard to grok

Since the holarchy principle is natural and fundamental, applying to all possible organisations, these two patterns are very simple and general in terms of their structure as a model. But yet they're very difficult to grok, because they're in the form of a tangled-hierarchy or "strange loop" (i.e. a chicken and egg situation).

Two behaviours (merged)

At the highest conceptual level of the holon we have Koestler's self-assertive and integrative behaviours. These connect the public collective world beyond, and the private individual world within.

Koeslter sees the fixed rules coming from above and the flexible strategies within. In our model we see the fixed rules and flexible strategies as being the class and instance concepts, which are a separate dichotomy leading to the four quadrants described next. We place the collective aspect at the top and individual autonomy aspect at the bottom, but the two behaviours are dynamic and as such are modelled as flows moving between the top and bottom.

Note that our usage of the term "collective" refers to the way that holons behave in order to support a collective together, rather than to the collective itself (which in a p2p system can only by abstract or virtual).

Another note related to this is that it seems counter intuitive that the self-assertive behaviour comes from the collective and to the individual. But the movement from above to below represents a movement from external relationships and conditions of a holon to its internal intentions and actions, or in other words a movement from general to specific - which as we will see below, is an active top-down process.

The two behaviours form the most fundamental relationship in the holon model, because it's existential in nature. Individuals and the whole (as well as "wholes" over all scales of operation) exist in an interdependent relationship supporting each other. The individual's primary requirement from the whole is a secure autonomy-condusive environment, which the whole assures it in return for its conformance with the protocol.

The interaction between self-assertive and integrative, individual and environment, is a feedback loop (a bidirectional relationship) in which both sides co-evolve together.

Co-evolution implies complexity which is structural depth and hierarchy. This is why the axis is drawn as a one-to-many tree in the diagram. Every holon is a hierarchical structure of holons, the self-assertive behaviour a flow of focus that divides within. The integrative results from the bottom-up integration of informative accounts returning back up the tree from below.

Both processes together give rise to a second tree representing the abstract relationships between holons. We'll come back to these two trees soon, but for now the key point is that this second tree is made possible by the continuous alternation of top-down and bottom-up processes within the first tree.

The integrative behaviour represents the existence of the whole holarchy as an autonomous individual "organism". The holistic organism owes its existence to the ubiquitous support it receives from all scales of organisation within.

The self-assertive is the behaviour of individual autonomy that supports the whole by participating in accord with its protocol. The incentive for supporting the whole is that the whole assures its member's autonomy and maximises their potential.

The self-assertive behaviour with it's class and instance side is intuitive because it's what we're used to in an organisational system or OO software development project. It's about setting objectives, organising work to move towards them and adjusting the process through a continuous improvement cycle. The instance side is about the performing of the work to progress the organisation's state, and the class side about the adaptation of the processes in use. These two sides are often referred to as "in the organisation" and "on the organisation" respectively.

The integrative behaviour of a holon is not very well known. The easiest way to describe it is to look at the class side as being a process of integrating the self-assertive class side (the system adaptation). And the instance side as being the integration of the self-assertive instance side (the system operation).

Subjective autonomous

The instance-scope is set up by the integrative behaviour that operates in class-scope. In this way the private instance-scope extends the public class-scope within.

The core of the self-assertive behaviour is not defined by the system, because it's carried out by the local agents in accord with their own means within. But a standard executional environment still needs to be defined and set up in which this autonomy can operate.

This standard set up is actually occurring in class-scope and is therefore technically still part of the integrative behaviour, but we're putting it here within the discussion of the self-assertive, because it pertains to the instance-scope and how things operate within it.

Instances are actualised (instantiated) classes, which means that they're in a particular state and have associated spatio-temporal locality - an instance exists in a particular state, receives agentic focus and performs actions in the present in accord with it's role as determined by its class or other means within. It has a local point of view on a timeline and has private and public scopes, potential and historical activity. These things are the aspects of the instance scope that need to be set up before agentic focus can enter.

• performance of a role as determined by the class
• role takes the form of conditions and associated actions
• production-rule loop
• common form of expectation and performance

Quadrants and loops

Two orthogonal trees and four quadrants

Trees have a dimension where one end points "outwards" towards the root, and the other "inwards" towards greater depth. The two directions of a tree can also be called the parent and child, or "one" and "many". The two directions of any tree will have very clear meanings based on the role the tree as a whole plays in the system it's a part of.

In our system, the instance tree plays a role very much like function calling and returning. This leads to the parent meaning being public and the child meaning being private, just like in a runtime hierarchy of instances in any normal OOP language. The ultimate root of this tree is the most global context containing all instances in the whole network; the whole society of organisations.

In the class tree, the parent direction represents the abstract class that the holon operates in accord with. The child direction represents the current actual in-time operational state of the holon. The ultimate root of this tree is the most general class that all others depend on; the OO organisational layer itself.

As mentioned above, these two trees are interdependent, which means that the processes involved in the creation and maintenance of each trees must refer in its definition to the other tree. For this reason, we place these dimensions orthogonally in our model, yielding four quadrants each involving both trees. These quadrants are central to our system because all the dynamics are conceptually interactions between them.

The flow of executional focus through the instance tree takes the form of two loops involving top-down and bottom-up. This loop form is extended when we combine the trees into the four quadrants model as it creates the potential for loops connecting the abstract and the actual. This makes a total of four loops, each connecting an adjacent-quadrant pair.

In this discussion on the objective OO layer, we'll focus on the mechanism behind the trees and loops and the OO-like concepts that are defined by it. We'll come back to the quadrants and loops and go into more detail about them when we discuss the "subjective" abstraction layer that is enabled by the OO layer.

Objective and subjective

Matt (talk) 02:01, 21 December 2023 (UTC)-- 'This evolutionary knowledge aspect' - what evolutionary knowledge aspect? You haven't specifically talked about an evolutionary knowledge aspect before, only that the system allows evolution in general. Also, this section is confusing for me. You're talking about aspects and layers and systems somewhat interchangeably. What's the main thing you need to get across under this heading? The holarchy organisational system has two layers: first the objective layer, which provides the fundamental dynamics for the subjective layer? I think that's enough.

This evolutionary knowledge aspect of evolution is a class-instance system which we call the objective aspect. The selection and creation of variations takes place in an execution or cognition context which we call the subjective aspect of the holon.

• the objective sets up the subjective (T1 giving rise to T2, but we haven't talked about trees yet)

Matt (talk) 02:01, 21 December 2023 (UTC)-- Here you're sounding like T1 correlates to the objective layer and T2 to the subjective but below I understand both trees are part of the objective layer

• what its like from the subjective perspective (quadrants and loops)

We'll start the description at the most concrete level, the mechanics that support the higher-level organisational patterns.

• abstraction layers, objective -> subjective -> arbitrary complexity

Possible-actual-conditions-actions

In terms of loops and their meanings, we find the most fitting terminology for the four directions to be: conditions at the top, activity at the bottom, possible on the left and actual on the right. This gives us four quadrants with possible conditions at the top-left, actual conditions at the top-right, actual activity at the bottom-right and possible activity at the bottom-left.

Classification

This is the process of classification aggregates the activities and conditions into an ontological abstraction. It connects actual state to the ontology of classes, which makes the word classification very apt.

Where instantiation is a top-down process going deeper within, classification is a bottom-up process. The former is the establishment new activity like a function call expanding scope deeper within the instance tree, and the latter is the closing of the activity and the return upwards of its final account.

The bottom-up is only possible as a result of the top-down, the same way that there can only be a returned value from a function as a result of it having been called. This means that the bottom-up process occurs within the context set up by the top-down operation of instances. The classification applies specifically to those things which have changed, it's an abstraction of the local activity stream.

A class is a package of condition-action rules (a rule-set), and the aggregated metrics (such as performance and usage statistics) associated with the actual performing of actions and the actual conditions that led to it, accumulate in the ontology. Thus the knowledge from the edges is made available to all the instances that it's applicable to.

Knowledge

Knowledge in the context of the holarchy refers to imperative knowledge, i.e. knowledge in the form of actionable instructions, and knowledge used when performing such actions. imperative knowledge is what is instantiated, used by instance, it represents behaviour patterns, executable knowledge.

• knowledge was mentioned in the above DD quote
• knowledge is the left-hand ontological shared language side

Evolution

The general concept of evolution can be boiled down to an extremely simple foundation. David Deutsch described evolution as "the creation of knowledge through alternating variation and selection".

• selection is permitted by all holons providing an honest account of usage (integrative)
• the integrative integrates usage into organised variations that afford selection
• adaptation uses simulation (intention, self-instantiation)

The holarchy model incorporates this base evolutionary dynamic of variation and selection. The rules and their variations are organised within the ontological context of the conditions they apply within. The prominence of the variations is derived from how established in usage they are.

To go back to object-oriented terminology, we would say that the holon architecture is the base-class of organisation itself. Every possible organisation in the network has the holon class-instance network-node functionality in common.

Koestler's central thesis was that complex systems could be understood as interconnected networks of holons. In the terms of OO, we could say that arbitrarily diverse and complex organisations can all be extended from the common base-class of the holon. Since complex organisations are composed of patterns of simpler organisations, the holon principle implies a recursive fractal structure. Fractal because the organisational upper ontology are common to all, no matter their depth of containment.

This means that the whole network is also a holon, and that all holons take the form and behaviour of the whole holarchy as microcosm and macrocosm. But most importantly it means that the common base-class needs to be a scale-independent function. There's also a second kind of loop operating on a wider time frame at the scale of the whole network. This is the evolutionary selection loop which leads to useful adaptations to knowledge propagating amongst the users of the knowledge. The knowledge and all its variations are all memes competing for establishment by their local utility.

• knowledge and evolution, knowledge is formed from general->specific
• knowledge is the product specialisation
• evolutionary loop, "development branches"
• things start general, the most general agency initiates things
• AI agency facilitates this flow, makes pattern language work
• evolutionary society....

Four quadrant model

The system described above is founded on a number of conceptual dichotomies which lead to a model consisting of four quadrants which are akin to organisational departments. The details of the organic software design pattern are all defined with respect to these quadrants of operation and the aforementioned control loops.

• Koestler Holarchy
• Organic Design Holarchy
• Integral Theory
• Plan-Do-Check-Act Loop (PDCA)

The integrative and self-assertive dichotomy together with the class-instance dichotomy give us a model of four quadrants.

Koestler's holon model relates to the four directions (sides) rather than the quadrants. The integrative behaviour corresponds is the top outward facing public side, and the self-assertive to the bottom inward-facing private side. The fixed-rules are the left-hand class/ontological abstract side, and the flexible strategies are the right-hand instantiated side.

Each of the directions is abstract, but the quadrants that each represent a concept consisting of two adjacent sides, are more specific and can be thought as four distinct aspects of behaviour like departments in the holon-organisation.

Following is a quick summary of these four quadrants and how they map to two other popular four quadrant models, the PDCA loop for continuous improvement, and the four quadrants of integral theory. The fact that these two map so well is interesting because the former is a temporal (instance activity oriented) and the latter is ontological (class knowledge oriented).

• todo: relate to multiplexing

Top-left (ontology, public-class): This is our instantiation phase and also includes the factory design pattern. This is about selection from class-supplied options of specific sub-classes that best fit the local instantiated environment. These selections and their accumulating usage statistics are integrated unconditionally as part of the network protocol and contribute to the ontology and its reliability. This maps to the plan phase in PDCA and to the culture quadrant in integral theory.

Top-right (holarchy, public-instance): This concerns the flow of resource in the market and its transparency, which ultimately comes from local objective evaluation of activity and circumstance. This involves generating (as part of the objective public protocol) an immutable account of the activity including its performance metrics and usage statistics. This maps to the check phase in PDCA and to the society quadrant in integral theory.

Bottom-left (class, private): This is all about adjusting the local class structure to fit our needs. This maps to the act/adjust phase in PDCA and to the intentional quadrant in integral theory. This quadrant also relates strongly to the standardisation aspect of its corresponding phase in PDCA, because these adjustments are a concepts similar to a commit or release in software development. Indeed this phase can be seen as the development phase, except that it is the users themselves that play the main development role by raising issues and expressing requirements.

Note: The bottom left is about structural (ontological, system) changes which are based on issues and requirements, not from accounts information which changes work but not structure.

Bottom-right (instance): This is all about the day-to-day operation and usage of the system (the instantiated class structure). This is the performing of activities (including exchanges) during sessions of interaction between agency and internal interfaces. This maps to the do phase in PDCA and to the behavioural quadrant in integral theory.

*   *   *

This organic design pattern is explained in detail in the four quadrant holon model article.

PDCA

Plan-do-check-adjust maps to the four quadrants/phases holarchy model.

Plan: This maps to our instantiation phase and also includes the factory design pattern, and belongs in the top-left (ontology) quadrant. This is about selection from class-supplied options of specific sub-classes that best fit the environment. These selections and their associated usage statistics are integrated unconditionally as part of the network protocol and contribute to the ontology.

Do: This maps to our instance quadrant which is all about the day-to-day operations and usage of the system (instantiated class structure). It's in bottom-right (instance) quadrant. This is the performance of activities (including exchanges) during sessions of interaction between agency and internal interfaces.

Check: This maps to our top-right (holarchy) quadrant which concerns the flow of resource in the market. This involves generating (part of the objective public protocol) an immutable account of the activity including its performance metrics and usage statistics.

Act: This maps to our class quadrant which is all about adjusting the local class structure to fit our needs.

These quadrants can be seen as being in the form of two feedback loops, one on the left class side and one on the right instance side. Each loop is formed from a top public half and a bottom private half.

The left loop is the evolutionary loop, it is a continuous fitting of the local class structure to the local real circumstances. The public side of the loop contributes to the emergence of the ontology, and is the source of evolutionary change.

The right loop is the cybernetic loop, it is a continuous fitting of the local state to match reality, and also fitting the reality (using the representation as an interface) to our objectives. In other words navigating reality.

Scope and control-flow

All control-flow, in its most general form, refers to focus moving from scope to scope within a tree of scopes (namespaces) which contain instructions and data from which decisions are made within the context of that scope. In practice these scopes may come in different forms such as function calls, objects, classes, conditional blocks etc. But all these essentially form an overall tree of general namespace scopes. But the key point here is that the essence of control-flow is structure.

Control-flow also implies a context of attentional focus in which some kind of agency is expressed in the form of assessing conditions, making decisions and performing actions.

This agency requires imperative knowledge (supplied by the context) as well as it's own tacit and participatory (experiential) knowledge.

In our system all control-flow is represented by the structure itself, it's the structured ontological context within which all the descriptions for agency are organised. The descriptions themselves have no reference to control-flow, only to the conditions and actions to be assessed and performed by local agency, they are declarative in nature.

Pattern language

In 1977 Chris Alexander wrote a book called "A Pattern Language"...

Working with a pattern language is done as follows:

1. Identify the Problem: Begin by clearly defining the problem you're facing. Understand its nuances and the context in which it exists.
2. Research Existing Patterns: Explore established pattern languages or repositories related to your domain. Familiarize yourself with common solutions that might address your problem.
3. Choose Relevant Patterns: From your research, select patterns that resonate with your specific challenge. Remember, patterns are modular and can be combined in various ways.
4. Adapt Patterns to Your Context: No pattern is a one-size-fits-all solution. Customize and adjust patterns to fit the unique constraints and requirements of your project.
5. Iterate: As you apply patterns, iterate on the solutions. Patterns provide a starting point, but real-world application may require tweaks and modifications.
6. Document Your Insights: As you work through your project, document new insights or patterns you observe. This can be invaluable for future projects.
7. Share and Collaborate: Engage with the community. Share your adaptations and new patterns. Collaboration can lead to richer, more refined pattern languages over time.

The pattern language offers a structured approach, leveraging collective wisdom to address challenges. It's a tool to be used flexibly, iteratively, and collaboratively. Although the book was originally set in the context of architectural design, it embodies a general approach to development and construction in any domain.

The pattern language fits very naturally with OO and software design patterns. In 1995 Ward Cunningham created the first wiki called The Portland Pattern Repository inspired by the book. He liked the idea that there was a set of named patterns (or solutions) that could be used to address common problems, and he wanted to develop a platform where software design patterns could be recorded, shared, and refined by the community.

The wiki format, with its emphasis on collaborative editing, ease of linking between pages, and simplicity of use, was a fitting medium for this vision. The Portland Pattern Repository became an important formative part of the software design pattern domain.

In terms of its dynamics, Chris Alexander's pattern language also follows this same declarative form. And unsurprisingly, the organisational systems that have developed within large modern wiki projects like Wikipedia are also perfect examples of the declarative Blackboard Metaphor as well.

The patterns are designed for in-situ human agents who can understand them and act on the relevant pattern. This action takes the form of assessing the present local conditions for any "problems" (things needing to be acted upon in order to "move towards" the objective). Different patterns are effectively activating and deactivating. The presence of the problem, and the process of solving the problem often lead to the "execution" of other related patterns. The project is completed when there are no problems to solve.

The "pattern language" is the general protocol of organising functionality as named packages of declarative local condition:action rules. With all these packages connected by relations such as dependency and sequence. But the rules themselves are described in language that's specific to the local context in question. There may also be many variations of these rules catering for different related circumstances and languages.

The elegance of this model is that it cleanly delineates the general and specific aspects of organisation. This is known as the separation of concerns in software engineering which is essential for ensuring a high level of organisation and maintainability in complex software development projects.

• connections between the patterns, i.e. the ontology. Connections of dependency, sequence and variation.
• bottom line re pattern language is its a universal organisation, independent of the descriptions and their domain-specific languages

Declarative and imperative

Declarative programming is a programming paradigm that expresses the logic of computation without describing its control flow. They describe what the program must accomplish in terms of the problem domain, rather than describing how to accomplish it as a sequence of programming language primitives. The how being left up to the language's interpreter - the agency that interprets the statements and performs actions based on them.

A declarative approach is inherently more natural, intuitive, and organised because it focuses on specifying objectives rather than the detailed steps to needed to achieve them, mirroring how we ourselves think and communicate. We intuitively perceive things in terms of problems and solutions the we use, assess, categorise and share. By abstracting away the underlying complexities, declarative programming presents solutions in a conceptually clear and understandable way.

Another important reason the declarative approach is so natural is because it enforces a clear separation of concerns whereby the rules, regardless of their language, represent a definite concept purely in terms of the local environment. The methodology of how to interpret the language and conditions into activity is entirely encapsulated within the language interpreter (agency).

We can see this general declarative organisational pattern showing up in many diverse forms such as business rules engines, the Global Workspace Theory of mind, the Blackboard Metaphor for parallel processes and even the dynamics of proteins within biological cells. It's fundamental to the way we think, learn and reason and we see it reoccurring across all scales of experience and reality.

A class definition includes a structured rule-set, it is a "package" of production rules along with related knowledge and resources. When instantiated and active, the rules occupy the local instance scope together. The rules are declarative in nature as they're all defined in terms of the local scope.

• declarative is the conditional side, imperative is the action side
• declarative is state, imperative is process

Substrate independence

Substrate independence is a popular topic at the moment (2023). It's talked about in the context of possibly "uploading" a human mind into an technological information system of some kind in the near future. But if we think about this concept independently of the specifics of the cognitive architecture in question, then it really just means that we have an explicit model of the cognitive architecture that can be implemented universally. It means that the cognitive architecture is itself the root base-class of the system. It can implement itself in any other foreign context (substrate) that is accessible to the network.

Natural hierarchy

The ecosystem of life is organised as a holarchy. The hierarchical structure is seen in the distinct scales and regions of organisation such as cells and bodies. When we look at nature in terms of holarchy, we see that this same pattern of evolutionary organisations and societies continues up to the scale of Human societies and beyond. These are often referred as memes, that can be clearly physically delineated such as with nations and organisations, but can also be completely abstract such as an ideology or an ability.

Resource abstraction and AI

Developing this implementation requires two main things. First, informational resources such as servers, storage, transport and data sources need to be represented in the holarchy via resource abstraction and connection. And second, AI agency (AI within a cognitive architecture) to have threads of its focus within the subjective local context of each instance within a holon structure.

Philosophy

• archetypes, memes and the collective unconscious
• the current dominant patterns as archetypes
• the ship of theseus
• scale-independence and non-locality

Request for definition

• is this needed in the main doc? does it matter? maybe its only useful in philsophy

It was mentioned above that instantiation starts as a request. An imperative aspect of this which is logically derivable from the philosophy, is that emptiness (void, undefined) is interpreted as meaning a request from the parent.

Aligned with idealist models

Dreams and imagination show us that an idealist view is entirely plausible. Events of any arbitrary complexity (drawing from the dreamer's own knowledge about the world) play out experientially in space and time.

• the fact that experience has no direct connection to the material world makes it likely
• most modern idealist models are agent-oriented
• evolution is a minimal extension of agent basis
• evolution operates within the experiential space

Morality

• Hume: you can't derive an ought from an is (moral theories cannot be derived from factual knowledge). DD: Although factual evidence and moral maxims are logically independent, factual and moral explanations are not. Thus factual knowledge can be useful in criticising moral explanations.
• right and wrong are attributes of objectives and behaviours
• our behaviour is not in relation to the world, but rather to an abstraction of it

Variation

Variation is recursive in nature because it must treat itself as an object. In other words it must instantiate a version of itself within itself. This does not create any logical dilemma because it's the possibility that's infinite due to the recursion, not the instantiated actuality.

But the possibility of any instance is already infinite, since all objects are derived from root, so all instantiation is essentially the same thing as self-instantiation.

Mixins

The mixin class methodology offers a powerful alternative to traditional class hierarchies in object-oriented programming, bringing a host of advantages to software development. Unlike standard class hierarchies, mixins promote code reuse and modularity by allowing developers to create small, self-contained classes that encapsulate specific behaviour. These mixins can then be easily combined and composed to build flexible and extensible objects, reducing the need for deep and complex inheritance chains.

This approach permits cleaner and more maintainable code, as it promotes a "composition over inheritance" philosophy, an OO design principle favours composition (combining smaller, self-contained components or classes) over inheritance (creating complex class hierarchies) when designing software systems.

A class defines a group of child-classes that are mixed together in the instance scope when instantiated. Using the mixin model allows functionality to be intuitively composed together into complex mechanisms. When the class is instantiated, its child classes are also instantiated and so on within, resulting in a structured instance of arbitrary depth and complexity.

All the mixed-in instance siblings within each instance scope receive a portion of executional focus (agency), so that they all collaborate on the continuous progression of the instance's structure and state in accord with the class and local circumstance.

• the class is one of a group of variations that are used in that context
• an instance has only one class relationship at any given time, but it can change over time (a different variation may be selected)
• the class of an instance can move around through the variations, or can become more general, in this way it could potentially become any other class

The self-assertive loop

As discussed in the introduction, this autonomous behaviour comes in the form similar to the body schema, which is itself a complex form of the cybernetic loop and continuous improvement loop.

A cybernetic loop is a continuous error correction feedback loop, where the workloads for the various roles adjusts in response to changes in objectives and observed conditions. A continuous improvement loop is very similar to the cybernetic loop, but is focused on systemic change rather than mere state change.

In other words, the two loops are complimentary with one being focused on achieving objectives in terms of the system's state (operation), and the other being focused on improvement or developing the system itself (adaptation, specialisation).

This hybrid loop is at the heart of the self-assertive behaviour. All executional focus that is assigned to the self-assertive behaviour progresses this loop allowing continuous improvement in both state and structure.