Talk:Holarchy

Content may be incorporated at some point

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.