Multi-model and transdisciplinarity ​

Modeling in systems thinking is the main means of combating complexity in projects. High complexity occurs when there are too many details in the descriptions, requiring the brain (and the computers helping it) to perform numerous calculations. The number of calculations can be drastically reduced by eliminating calculations on unimportant matters. It is usually not immediately clear what is important and what is unimportant in these descriptions. Modeling is the description of only the most important elements and the omission of the unimportant in the descriptions. Documenting models allows not only to describe the important, but also to keep the important in focus for as long as necessary for reasoning. The unimportant is not retained in focus, remaining only in discussions during modeling.

Modeling is a way to obtain descriptions of important characteristics, where one object (model) is used to make judgments about another (modeled) object. Modeling involves knowledge at least on three ontological levels (as studied by ontology, one of the disciplines in the intelligence stack):

• The Situation (related objects in a specific domain) being modeled. Ultimately, these are physical objects in the world, with important and unimportant aspects known about them. There may even be a chain of modeling, wherein the talk is about a model of another model. There is a lot of information, many objects of attention, and the task of modeling is precisely to address this problem: it is difficult to think about the subject area itself, the computational agent (brain and computers, and even a workforce), who acts in the subject area, is overwhelmed with processing unimportant information. Complexities such as distinguishing between reality and actuality are not taken into account here. Reality is everything that exists, and actuality is what we know about what exists in reality and can describe, hence we perceive not the entire reality, but only the actuality. Examination of the subject area is the subject of ontology.
• Types of objects that need to be identified. They are defined by the description method, which contains the meta-model. This meta-model, which defines the types of important objects in the subject area in order to isolate only the important objects from reality, is determined by some discipline (applied or intellectual) from the intelligence stack. However, there are transdisciplines ("disciplines about all applied disciplines") in the intelligence stack, which define the meta-meta-model, allowing reasoning about meta-models: comparing them, consolidating, supplementing, clarifying, checking reasoning against them, and discussing the required meta-model at the moment.
• The model itself. In the case of a physical model, these are objects that retain the fundamental characteristics defined by the meta-model, and in the case of an information model, these are elements of description whose types are defined by the meta-model.

How to determine what is important? The descriptions should only include what helps answer questions about a specific area of interest. Different project roles have different important characteristics in a system - these roles want to move the values in different directions, and in order to do this, they need to know the values of many other characteristics. Since everything in systems is interconnected, the values of all characteristics are linked, and all roles understand this. What is important for a role is defined by the meta-model. The meta-model is always part of the stack of meta-models in modeling; it is determined by the hardware of a person's brain or a computer processing the world. The importance of an object deserving a separate concept is determined not in a single step of modeling but in multiple steps; even the fact that the world contains objects and relations is the result of meta-meta-meta-modeling, or foundational ontology. The upper ontology (objects described in transdisciplines of the intelligence stack, for example, the concept of "system" coming exactly from there) and the middle ontology or applied ontology are still being refined, and the types are also being specified; whereas the model of instances/operational model is simply a "model" of certain instances of objects, and not types of objects. However, any of the meta-models can also be referred to as a "model," making it easy to get confused. There can be many levels of "meta," i.e., levels of specifying types for types, i.e., levels of classification relationships, although usually three to four levels are enough.

We will repeat this reasoning several more times, as it is important: you focus your attention not on random objects in the world and in other models that "stand out" to you (they can be important or unimportant), but on important objects (sometimes actively seek them out, especially in the case of design), but the very fact of their importance is set by the meta-model in place at that moment. And if you don't have a meta-model, you still look for these objects in the same way, by focusing on the objects set by the meta-meta-model, as this reasoning works at any ontological level. If you are looking for something important in the meta-meta-model, then you have a meta-meta-meta-model in your mind, which is effectively a meta-model for the meta-model. The importance is determined through multiple levels, as we catch our attention on non-random objects. Education is needed to understand which important objects we are looking for in the world or (in the case of inventing something new) in our imagination. Education is needed to save time on calculations about unimportant things! Education is also needed to understand why it is needed (as strange as it sounds). For example, education is needed to understand: without knowledge of ontology, there will be no system thinking because you will not be able to consciously build systematic descriptions.

The next paragraph literally contains a description of a real situation annotated with types from our course. How this is done is studied not in our course, but in the "Modeling and Coherence" course.

Financier::role wants to prevent::preference/interest cash gap::subject of interest - and the cash flow model::description will answer his questions on this subject of interest. Everything else even from finance (balance, profits and losses) is unimportant in this context; other models from different descriptions will be used to answer other questions for the same or different project roles.

A systems thinker will ensure that labor planning for the project includes financial management and compliance with practices to prevent cash flow issues. Therefore, the enabling system documentation will include a financial description that incorporates a documented (recorded on some information carriers, not just done "in mind") description of cash flow. This model will answer the financier's questions on this subject of interest and serve as the basis for the financier to discuss with other roles (in large projects, these will be conversations between different actors and their computers, in small projects, it will be discussions among different roles in the mind and computer of an actor playing multiple roles).

And now we will reiterate this reasoning again (unfortunately, ontology is not the simplest subject in the intelligence stack, so a recap may be helpful).

The subject of interest/concern is framed using a description/viewpoint method, and this description method specifies what is most important in the modeled object, what needs to be considered in various models derived using this description method. This "most important" is what is defined for a model and is called the meta-model. It is mainly expressed in the types of most essential objects.

For a map that represents a model of the territory, the meta-model is the map legend, the types of depicted objects on the map. The map contains a minuscule amount of information about the territory, but it's all important information. The map legend indicates what is important on the territories, therefore, it must be reflected in the models. You will see the road on a road map, which is important, but the color of the asphalt on this road is not, that's unimportant. On the wildlife map, you will not see roads because that's not important. The types of important objects like "road" for a road map and "wildlife habitats" for a wildlife map are set by the meta-model, the map legend. The objects on a road map are types of "road," while on a wildlife map, they are types of "habitat." The type is one (defined by the map legend, description method, meta-model - all ways of speaking about the same thing: "what important interests us"), but there can be multiple instances of objects of this type in the description, and this type can be used to build multiple descriptions. You can imagine a combined map that shows both roads and wildlife habitats. It is convenient to discuss things like animal migration and obstacles to migration on these combined maps (these are thematic maps, where multiple different descriptions are combined, and one description can be distinguished from others using filtering), you can place two separate thematic maps side by side and look at them simultaneously (this is a synthetic description: several different descriptions are gathered, and one description can be separated from others through filtering).

There are meta-meta-models since some descriptions can model others. For instance, a refrigerator is modeled by an engineer-repairman using its schematic diagram, which outlines the functional parts of the refrigerator and connections between them (schematic diagrams usually show symbols for functional parts that process flows of something, and lines are drawn between these symbols for functional parts to show interconnections between them. Electrical diagrams show electrical current, in a refrigerator schematic we will see heat mass transfer between functional parts of the refrigerator). The schematic diagram here is the model of the refrigerator, while its designations (legend) will be the meta-model of the refrigerator. The meta-model of the refrigerator consists of the types of objects that we must see in the refrigerator and reflect in its model. However, when we talk about how schematic symbols for refrigerators are modeled in computer-aided design, this is already about the meta-meta-model of the refrigerator. Modeling is multi-level, and structural computer models usually have three to four levels of meta-modeling.

A set of interconnected models made using various description methods (regardless of whether it is within a projective or synthetic approach to system description) are commonly referred to as a multi-model. This is similar to compiling multiple maps for the same territory: flora, fauna, population densities, relief, etc. It doesn't matter if all this is shown on a single map-document (projective model) or separate documents (i.e., physically a collection of different documents, a synthetic model). The reasoning is absolutely the same in both cases.

Typically, system modeling is multidisciplinary, and each discipline/theory provides its own system description, prescribing modeling for a specific set of its own models. This applied modeling, unlike systemic, is, therefore, multidisciplinary multi-modeling (and systemic modeling is in fact transdisciplinary, it is not based on any one discipline, but rather aggregates models from all these disciplines, involving a large number of transdisciplines in the intelligence stack).

People unfamiliar with the systemic approach find it difficult to grasp the idea of multiple models describing a complex system. They usually demand to identify a "main model" that is "correct" compared to other "secondary" or "auxiliary" models - but in systems thinking, there is no "main model"; each project role simply receives a set of models to answer their role-specific queries. There is no "main model"; all models are needed! Moreover, modeling should be "multi-scale," done at several system levels: models are required not only for the target system but also for the supersystem and subsystems (and due to the need to show emergent characteristics, different models are used at each system level, necessary for aligning the interests of different roles performing different practices. Models of a brick, wall, and building - are quite different models). Models are also needed for the lifecycle/creation of target systems. Multiple descriptions mean multiple modeling. Attention should be retained on the main, defined by types of the meta-model, and irrelevant aspects should not be represented in the model immediately for many disciplines required to manage the system creation project. Modeling serves to reflect the main, the types of which are taken from culture (if someone has worked with it before you) or acquired from research if you are the first to delve into a new domain and are trying to understand on which object types explanations are achieved, how causes and effects are related in this subject area and what are the connections between them.

How do you know what should be primary? Meta-model! But even in meta-modeling, the primary concern is not arbitrary but it is determined by types of the meta-meta-model. One of the criteria of a good model is the ease of discussing causal relationships in a situation and, for this reason, the suitability of conducting counterfactual reasoning with objects in that situation. Therefore, the types from the meta-model should not be random but suitable for such reasoning. This problem of suitability is addressed by the explanation creation method (part of the intelligence stack). Finding such types is the task of the research method, which is another thinking method included in the intelligence stack. As a result, the systemic thinking, which deals with compiling systematic descriptions/systemic modeling, utilizes quite a number of methods from the intelligence stack, and to master systemic thinking effectively, one should already be educated enough. This is why systemic thinking is not encountered so frequently – it requires learning not only it but also all the thinking methods of the intelligence stack. More about this in the "Intelligence Stack" and "Personality Engineering" courses, while modeling materials are disclosed in the "Modeling and Coherence" course. In our course, we only cover how to engage in not just any modeling but correct modeling of selected important objects in the surrounding world - systems, in other words: systemic modeling/models of systems/systemic modeling.

There are many project roles, and what is a model for one role is informational noise and overload for the agent's "thinking" handling that role (a processor with finite resources: be it the brain, brain with computer, or simply a computer) for another role, and vice versa. There is a temptation to model less, to get rid of unnecessary work, but this should not be done. Each model should be documented (and documented models) to satisfy all the interests of all involved project roles: errors in system descriptions can be costly, and these errors usually manifest as discrepancies/collisions between different system models. You will learn about the problems because project roles will have complaints about the models (and sometimes even complaints about meta-models). Errors/collisions in the system model are ideally identified and corrected during system description and documentation before manufacturing, not after manufacture, much less during system operation. Describe seven times, produce once!

Another mistake is that models are specific to project roles at each system level, and choosing the wrong system level can lead to reductionism or holism. Reductionism means trying to explain a complex system by the interactions not of its subsystems but of some parts of the system at substantially lower levels, even if at these inappropriately chosen levels to isolate something significant and omit everything unimportant at those levels in the descriptions. Yes, the human body consists of atoms, that's true - but this is the wrong system level to explain what distinguishes a human from robots and cats. If you want to repair an excavator, modeling the excavator from atoms or even molecules for these repair works will be extremely incorrect. The same applies to holism: explaining that everything in systems depends solely on their supersystems. No, models should be convenient for activity at each level; they should allow explanations (discuss the reasons and consequences of what is happening in the subject domain of interest) rather than being abstractly "scientifically correct." Let's reiterate: systemic thinking - it's not just pure mathematics or logic, its models and reasoning using them are determined by the interests in activities, relying on methodology as a discipline of the intelligence stack. If some models and reasoning based on them are formally correct but do not help accomplish anything in the physical world, they are useless and should not be enacted.

In summary: in systemic descriptions, there should be many models (multi-model), because systems are linked to numerous different activities/practices/jobs carried out by varied project roles implementing diverse intentions, arising from their preferences in very different areas of interest. And to ensure that attention on important descriptions does not drift during action coordination of roles performing various tasks, multi-models should be documented in a form that allows all interested roles to use them (this is sometimes called "information management": all models needed must be accessible, and changes in them should be communicated to all stakeholders/roles).