Challenges in Modeling and Unmodeling Emergence, Rule Composition, and Networked Interactions in Complex Reactive Systems

A key question in natural sciences is how can order emerge from disorder considering the universal tendency toward disorder dictated by the second law of thermodynamics (Schrödinger, 1944). Furthermore, one asks, why did certain forms of order evolve, like the particular species of our biosphere, and not others. Study of the respective theories is often supported a variety of models and modeling methods. Our own research (Cohen and Marron, 2020; Cohen and Marron, 2022) is inspired by many questions that the classical Darwinian theory of natural selection and survival of the fittest, and its synthesis with genetics, leave open. We argue that the emergence, sustenance, and evolution of species is driven by the ability of networks of repeating interactions to retard the inevitable destruction of organized structures and processes. To put the discussion in context, consider the dependence of all multi-cellular organisms on a diverse microbiome (Blaser, 2014), the networks in which trees and fungi exchange energy, matter and information (Simard, 2018), and the rich diversity and symbiosis in a coral colony within and among species (Rosenberg et al., 2007). The networks are sustained not only by the value of what is exchanged or done in each interaction, but by the very repetition of patterned interactions. When such networks experience innovations like genetic mutations or environmental changes, they may be reshaped into different sustained configurations. This is evolution. Furthermore, we show that a process we term natural autoencoding is the mechanism by which typed structures are created, each with its species interaction code, a set of shared essential interactions that enable individual organisms to fulfil their sustaining role in their internal and external networks. Winning in competitions over limited resources and having reproductive advantages are only part of the picture. The implications of this theory of evolution, extend beyond pure biology, affecting human social, economic, governance and education perspectives.

Modeling natural autoencoding, with its emphasis on the emergence of patterns subject to numerous laws of nature and the unbounded web of natural interactions, internal and external to each organism and species, presents intriguing technical challenges. In this paper we outline domain-independent methodologies for tackling three of these difficulties.

Our group is also associated with a variety of efforts in science education (See, e.g., (Armoni et al., 2021); https://www.iamplethora.com).

Consider the following simplified account of developing a scenario-based model for educational purposes, using the Plethora Science platform (presently under development) describing certain aspects of an ecological niche. Initially the model consists of rules, or scenarios, that can be summarized as:

Students experiment with various parameters to visualize a range of behavior patterns for bees and flowers. However, for the model to show that if the temperature rises above $t\_\{min\}$ in months when daylight hours are fewer than $h\_\{min\}$, the now active bees die of hunger, additional rules are needed, like:

Rule #9, about the implications of dying, is of particular interest. For a model to be correct, or useful, tacit assumptions must often be explicitly modeled. Through counterexamples to asserted properties, formal verification of models can help uncover such missing rules. We also note that the dependency of flowers on bee pollination is not presently modeled.

One then asks whether such model completeness aspects can be supported, at least partially, by modeling tools. The coming sections contribute to an affirmative answer.

Anticipating Emergence. For types of emergent properties and entities that the modelers expect and that may persist in the system, add the ability to sense them and to react to them into the basic model. The required sensors may be reused from programmed components that aid in automated simulation analysis. One still has to model and simulate the system's reactions to these emergent properties. For example, in detecting the emergence of traffic jams in transportation models, the model must be able to detect not only long lines of slow cars, but also secondary effects like route changes or blocked intersections. However reaction to emergent properties that are undesired or do not exist in the real system, may not need be modeled. For example, in modeling a chemical reaction that might cause an explosion, if in simulations explosions indeed occur, one is likely to change the real system, or the real environment, or the specification of the model.

Responding to Emergence. When noticing an emergent entity that was not expected: (i) discover properties of this entity and interactions and behaviors that it is capable of; for example, if it is discovered that certain model entities assemble into clusters, these clusters have properties like size and speed and they may interact with other entities, say, by serving as an obstacle to motion or by creating a shadow; (ii) determine the system's reaction to these properties and behaviors. Where applicable, and when not already implied directly by lower-level rules, the model could include all these new entities, properties, and behaviors. Note that real world processes too often evolve in such an incremental reactive manner.

Unmodeling Emergence. Such incremental modeling may be unbounded, almost Sisyphian, and must stop at some point. The decision to stop or suspend this iterative incremental modeling should be justified and documented; justifications may be related to time scales or abstraction levels that are larger or finer than what is necessary for the purposes of the model.

Reactive systems respond to stimuli based on the nature of the input and the current system state. For example, the software for a web application includes specification of the responses to different combinations of user inputs and system states. In some cases, the responses are specified in procedural programs, checking various aspects of the input and the state before making a choice. However, in models of complex systems, this may not be possible, since the action is not a single choice but the result of the composition of multiple concurrent rules specifying actions and constraints. Each such rule has a narrow view of the system and the environment, never checking all possible state variables. Naïvely, a rule may seem as stating “Always, when condition C holds, take action A!” or “Always, when C holds, forbid A!”. However, despite the word “Always” (which is often only implied) such rules are frequently subject to exceptions, probabilistic choice, and overriding priorities.

These rules may be coded in the executable rule-based and scenario-based specification of a model, or they may comprise the essence of the requirements for development or validation of such a model. Such rules consolidate scientific knowledge about nature, or expertise in some engineering domain. As such, knowledge bases are incrementally built, new rules of reactive behavior may be added in a stand-alone manner, considering only a small number of other related requirements. For example, consider regulators, or QA engineers trying to find out whether an autonomous vehicle (AV) will “always obey a red traffic light”, “always obey the instructions of a police person”, and “always put the safety of humans first”. At various states, these requirements may conflict with each other, and some priority order or other composition semantics must be specified, for example:

Collective Execution. This is probably the most standard composition. All actions triggered by a program are eventually carried out in the real world in some order; for example, consider an AV activating its signal light, slowing down and turning right, all at the same time. Documentation of the semantics of the execution environment, like Rhapsody for statecharts (Harel and Kugler, 2004), should specify this execution order, be it sequential (say, by time stamp of activation command), random, priority-based, or arbitrary (say, by rule sequence number), etc.

Aggregate Execution. Multiple actions are carried out in a way that their effects are joined or summed up. For example, consider two AVs joining forces in pulling a load in the same direction. The effect experienced by the load is the sum of the two forces.

Exclusionary Execution. Only one of a set of tentative actions is carried out. For example, an AV may have to choose between stopping at a red traffic light, or driving forward in response to a concurrent police person directive; or, two collaborating robots that intend to remove the same faulty widget from a conveyor belt, may have to decide which of them should act, and which one should retreat. Such choices may be based on priorities, probabilities, vote counting, and more. A variant of exclusionary execution is unification. Two nearly identical actions are triggered by different rules or software components, only one of them is executed, but both components continue as if “their” action was executed, unaware that the two actions were unified into one. For example, two components concurrently delete a database record; the record is deleted once, but each component proceeds as if “its own action” was successful.

Intersection of Conditions. Self-standing rules may specify multiple conditions that should be in effect concurrently. For example, specifying for an AV multiple constraints for minimum and maximum speeds, minimum and maximum distances from certain objects, etc., and all have to hold at the same time.

Meta Specifications. Rule specification may include references to other rules. For example, a rule $R\_1$ may specify that when unit $U\_2$ is in state failed other units should not comply with rule $R\_2$ associated with $U\_2$.

The details of composition semantics may be critical for model correctness and/or usefulness. For example, in the physical world, when two equal opposing mechanical forces operate on an object, the object remains at rest; in a model, depending on the time scale and synchronization and visualization of processes, the forces may appear to work one at a time, causing the object visualization to wobble.

In theory, one would need to specify the composition semantics between each pair, or even each set, of rules in the model’s specification. This applies both to the executable specifications that drive actions in a simulation run, and to descriptive or interpretive specifications explaining to stakeholders like modelers, customers, users, and regulators, what the system does or should do under different conditions.

When domain experts examine a model, they need to be convinced that their requirements and assumptions are implemented in a manner aligned with their domain knowledge. Also, for every behavior observed in a simulation, one needs to know if it has

been programmed directly or has emerged from programming of other entities.

Pairwise Rule Composition Analysis. Consider all actions that the system may trigger and all constraints that it may impose. For every pair, or set of such actions and/or constraints, determine and document how they should be composed if they occur together.

Defining Concurrency. As a sub-task of the above, for every such pair or set, document what “occurring together” means. Various possibilities include: (i) for systems that have synchronization points, being initiated at the same synchronization point; (ii) for actions and conditions that have a non-zero duration, having some of their duration overlap; (iii) for serial actions that may be queued or delayed, being queued and awaiting execution at the same time.

Group-Wise Rule Composition Analysis. Organizing rules in groups (say, based on common effects, or common resources) may reduce the complexity of rule-composition analysis. Since examining all possible pairs of actions may be impractical, determining fine grain composition only within each group, and for each pair of groups, coarse-grain composition for all pairs of actions that belong to these two groups.

Semantics Refinement. The varieties of composition semantics listed above (concurrent, aggregate, exclusionary, intersection and meta specification) do not cover all possibilities and variants within these categories can also be formalized. For example, consider logical operations between rules (AND, OR, and fuzzy logic), weighted voting, maximum or minimum consensus, Etc.

Almost by definition, a model that is implemented in a computer program represents a closed system. When the environment of that system is included in the model, this environment is regularly subjected to a limited number of behavioral assumptions, and the system of interest and its environment are modeled as a closed system. However, any system that operates in the real world, interacts with numerous other systems. For example, an AV is exposed to other road users, weather conditions, road wear and tear due to environmental conditions and due to use and abuse by other vehicles, construction projects, etc.; furthermore, such a vehicle leaves its own mark on its environment: most importantly, its presence and behavior affects the behavior of other road users; then there are the wear and tear, pollution, and noise that it creates; and, we should not forget the effects of stalled vehicles (including the modeled vehicle), accidents, commands imposed by passengers and external controllers, effects of changing fuel costs, and more.

And, the biological realm, as mentioned in Section 2 the biosphere consists of countless rich networks. When modeling a cell in an organism, a major factor is its dependence on the function of various organs for providing nutrients, water and oxygen, removing outputs and refuse, maintaining temperature, exchanging sensory information, and much more. Furthermore, within the cell, innumerable biochemical processes concurrently operate (Karr et al., 2015).

Even a seemingly closed human-made real-world system, say, of gas in an insulated tank, is subject to wear and tear, leaks, fluctuations of external temperature, presence of contaminants, and more (Woodward and Pitbaldo, 2010). Stated differently, everything in nature, in the real world, is connected.

The modeling challenges presented by these unbounded interaction networks include the sheer number of different types of interactions, the variability and unpredictability of many of the parameters of these interactions, and, the multiple time scales within which they operate.

Cataloging Interactions. A model cannot use a blanket assumption that all external influences are accounted for. All assumptions about internal and external influences and interfaces with other systems should be documented, detailing which ones were incorporated and which ones were ignored or abstracted away, with proper justification.

Outward Effects. In incremental development of the above interaction catalog, the model should document how the modeled system affects other entities, including additional instances of itself, and how these effects can in turn affect the system in new ways.

Fixed Conditions. A preprogrammed condition that stays fixed throughout a simulation, may point at a reductive or simplified assumption about the environment. Identifying and documenting such conditions can help identify overlooked external interactions.

Frame Management. In models that are simulated within some frame or canvas, behaviors around the frame of the model should receive special attention—checking what entities, energy and information may

pass through the frame, how agents interact with the frame itself (like bouncing back, or departing from the model), and whether and which properties throughout the model area depend on distance from the frame. For example, when the temperature of the system is regulated by an external source, the temperature may still vary within the modeled space.

Multi-Model Integration. When models for relevant entities outside of the system, or of components of the system, are available, modelers should consider connecting the model at hand to such external models. When this is not practical, summaries and abstractions of the behaviors of these distinct models should be added to the model as separate agents. For example, a model of a truck platoon may be connected to larger traffic models, to models of individual other vehicles and of individual trucks, and to additional instances of itself.

Incremental Interaction Development. It is impractical to cover all the interactions of a given real-world system in any one modeling project. While some of the above steps may trigger unmodeling, others may draw attention to interactions that were omitted but that should be programmed and incorporated later.

Dynamism and Reflection. Many programming and modeling languages support dynamic entities: from forking a new process through creating new object instances in defined classes to creating new classes or changing properties of classes at run time. Reflection allows the running programs to examine their current definitions. Such dynamism and reflection would be mandatory in any modeling platform for almost all model entities.

Write-Only Variables. Modeling platforms should enable listing modeled variables or properties that are computed, but that no behavioral rule takes as input. Such data fields may represent emergent properties whose effects on the system should be specified.

Catalog Anticipated Observed Emergence. Modeling platforms should prompt the modeler to formally document, or even program as test cases, modeling goals and questions that successful simulation runs should answer, and then suggest adding related emergent entities and properties.

Automated Detection of Emergence. Modeling platforms should provide built-in components for the detection of patterns and trajectories. For example, a model for an AV that maps a certain terrain and collects soil samples should be able to automatically detect when the vehicle is moving in circles—revisiting certain areas while missing others—or that in long runs or in large areas the vehicle runs out of fuel or its sample container fills up before the task is done. Modelers may be able to direct the tools to data fields whose behavior should be monitored.

Visibility of Composition Semantics. Fine operational semantics of modeling languages and execution environments are often specified in arcane documentation, or have to be learned through experimentation. Instead, they should be clearly documented with executable examples.

Plug-In Compositional Semantics. Modeling platforms should accommodate and assist modelers in specifying, documenting and generating examples for extensions and refinements to the platform’s composition semantics.

Dependency Analysis. Modeling platforms should support listing model variables/fields that are affected by more than one action or function and resources that are used by multiple rules. Prompt the modeler to specify composition semantics for related rules.

Concurrency Experimentation. Manually programming test cases to force concurrent triggering of certain actions and conditions is difficult. Modeling platforms should support specifying such simultaneity, and pace parallel execution of test cases such that the specified events indeed occur together.

Catalog of Initial Conditions and Fixed Fields. Modeling platforms should automatically highlight variables and conditions that, once set, do not change, and prompt the modeler to check if they represent closed-system assumptions that should be replaced, or justified, or elaborated upon in unmodeling.

Separation of Model Observation. Modeling platforms should clearly distinguish model entities that are part of the modeled system, model entities that simulate the environment of the modeled system, and entities that only help humans observe the model.

Domain Knowledge. The modeling platform should include domain specific expertise, like physical laws or traffic regulations, and enable modelers to incorporate these into the models, specify how the system is affected by these environmental characteristics, or unmodel the related effects.

Rule-Based Summaries. Regardless of whether the underlying execution engine is rule based or not, the modeling platform should enable modelers to create rule-based model specifications or descriptions at various abstraction levels (with the necessary rule composition semantics). This will support development, validation and use of the model, and streamline integration of model components and of gained knowledge into other models.