Introduction

This paper describes three classes of recurring, model-based system patterns applicable to the scientific understanding and engineered advancement of innovation ecosystems, including their regulatory and other aspects. The premise that this is even practically feasible rests upon an updated and more unified understanding of what is meant by “system level model”, based on the centuries longer traditions of models successfully used by physical sciences and mathematics. It is directly connected to this Special Issue’s theme of “Modeling for Advancing Regulatory Science”, and we assert that it provides key support for the US FDA’s related definition:

“Regulatory Science is the science of develo** new tools, standards, and approaches to assess the safety, efficacy, quality, and performance of some FDA-regulated products.” (FDA)11 (emphasis added)

Many large-scale human endeavors have grown up and proliferated through the evolutionary forces of large-scale interactions and selection processes. However, as whole interacting systems of systems, they have generally not been consciously human-engineered or objects of scientific study in the traditional senses. Human-performed systems of innovation include interacting elements such as competitive markets, scientific research, engineering, production, distribution, sustainment, and regulatory processes, and other life cycle management familiar to the systems engineering community.16,45 In the natural world, systems of innovation provide a much longer history for discovery and study than the more recent human-performed cases.31 In cases of development of medicines, medical devices, and systems of health care delivery, both the human-engineered and natural world’s innovation are present. For this paper’s interest in human-performed cases for human use, we define “innovation” as delivery of significantly increased stakeholder value,40 with “value” further defined in Ref [37]. The term “ecosystem”, borrowed from life sciences, has become more frequently applied to label human-performed cases, out of recognition of the vast extent, complexity, and dynamic evolution of human-performed innovation.17

This paper is organized as follows. First, the Materials and Methods section describes three classes of model-based system reference patterns summarized by Table 1:

  1. A.

    The System Phenomenon has been successfully represented throughout 300 years of science and engineering, and is associated with the first reference pattern, the S*Metamodel.

  2. B.

    Product domain-specific patterns describe engineered products and their environments, represented as configurable, re-usable reference models, domain-specific S*Patterns.

  3. C.

    Larger-scale socio-technical systems of systems that engineer, produce, distribute, use, maintain, and regulate life cycles are represented by the Innovation Ecosystem S*Pattern.

Table 1 Overview of three classes of reference patterns.
Full size table

(As applied by the INCOSE Patterns Working Group, the S* prefix above refers to meeting a minimal neutral system model content called “Systematica”, from pattern A above.)

The Materials and Methods section also notes aspects concerned with model-related tooling, associated methods, management of uncertainty, trust phenomena, digital engineering, digital twins and threads, consistency management, and model metadata.

The Results section describes how these reference patterns have been applied to date, and samples of their impacts. These applications span multiple domains, including regulated segments in which science-based models are already recognized as important.

The Discussion section proposes, to fulfill the promise implied by the term “Regulatory Science” and the special issue theme, how future applications of the reference patterns can advance:

(1) ability to apply science-based models of products for regulatory purposes, and

(2) ability to represent the regulatory process itself as a socio-technical system phenomena that can be studied on a scientific basis.

Materials and Methods

The System Phenomenon and the S*Metamodel Pattern

The first reference pattern is the S*Metamodel, informally summarized in Fig. 1. This “model of models” was developed and applied over two decades as an answer to the question “What is the smallest model content that history has found necessary to represent a system over its life cycle, for the purposes of science and engineering?” 30. It is independent of specific modeling languages and commercial tools, and is formally mapped to a variety of third-party industry tooling and standard languages. Although applied by the INCOSE MBSE Patterns Working Group in systems engineering, it is intended to conceptually span the content of models of all types, including computational models grounded in the physical sciences and data-driven models of machine learning. Any model satisfying the S*Metamodel through map** is called an S*Model.23 The formal definition of the S*Metamodel is provided by Ref [41].

Figure 1
figure 1

Informal subset of S*metamodel key concepts, supporting models of system patterns.

Full size image

This reference pattern is intended to emphasize the lessons of three centuries of models of the physical sciences, based on representation of observable phenomena in the context of interactions. “The System Phenomenon” it describes is the explanatory framework and mathematics of Newton, Lagrange, Hamilton, and the perspective of analytical mechanics as recurring patterns in the sciences and mathematics.32,37

The S*Metamodel combines the lessons of patterns in the physical sciences and their mathematics with the recurring pattern-based perspectives of representing system families, engineered platforms, architectural frameworks, and model ontologies. S*Patterns are configurable S*Models of such recurrent families of systems at any scale.23

This reference framework leads to a different perspective on terms like “system level model”, “systems engineering” and “systems science”, reflected in Fig. 2. Systems Engineering, a relatively young discipline, is often described as shown in the left side of Fig. 2. In that perspective, specific phenomena of mechanics, electrical science, chemistry, etc. provide the theoretical foundations for the traditional engineering disciplines, and systems engineering is performed “across the top” of these to coordinate their technical work with each other, with the interests of stakeholders, and with management of risk. This reflects the perceived origins of formal systems engineering in the mid twentieth century to overcome real challenges of large scale multi-disciplinary engineering projects.

Figure 2
figure 2

Two different perspectives on systems engineering and science.

Full size image

The right side of Fig. 2 reflects a different perspective, recognizing the base phenomena and theories of the other disciplines are all special cases of the physical–mathematical framework expressed by Newton, Lagrange, and Hamilton. The interactions-based generalized phenomenon they very successfully addressed is the basis of the foundations of all the specific disciplines, and is referred to in this perspective as The System Phenomenon.32 The right side of Fig. 2 then points out that new phenomena will continue to emerge on a combinatorial basis.

Society, including its innovators and regulators, is challenged (but also rewarded) by the newer, larger-scale emergent phenomena that arise as interactions of sub-phenomena. In each case described by configurations of the first reference model, each brings unique new behaviors that are usually not predicted in advance, often analyzed and explained after they are observed. This perspective suggests that the Innovation Ecosystem of the third reference model described later below needs to develop skills in continually dealing with emergent new levels of phenomena, and that includes applicable regulatory science.

At the time of this writing, what are referred to as “system level” or “descriptive” models, such as sometimes seen in Model-Based Systems Engineering (MBSE) are often perceived as very distinct from the phenomena-based mathematical-physical models that are used by the engineering disciplines (ME, EE, ChE, etc.) in many computational model simulations. We assert that this is because of the perspective of the left side of Fig. 2, which we have suggested be replaced by the perspective of the right side of that diagram.37 That is the perspective of the S*Metamodel as a unified reference model spanning the content of “system” and “physics” models. As shown in Fig. 3, this connects the “system semantics” of the left side of that diagram, found in many MBSE models and ontologies, with the “quantitative couplings” of the right side of that diagram. The current simulation model VVUQ practices of documenting “Phenomena Identification and Ranking Table” (PIRT) information as part of simulation planning and documentation hints at exactly this point: It is the observable interaction-based phenomena that generate the structural semantics of an MBSE model’s ontology.

Figure 3
figure 3

Semantic/ontological/descriptive models and quantitative/simulation models are joined by the interaction model of the phenomenon identification and ranking table (PIRT).

Full size image

Applying the S*Metamodel as the first reference model has provided means for describing domain-specific models of families of systems, the reference patterns of the next section.

Domain-Specific Patterns for Engineered Products

When the S*Metamodel is used to generate models of recurring patterns, they are sometimes called Domain-Specific Patterns, including models of families of engineered products. This is the second class of reference models described in this paper. Table 2 illustrates some of the S*Model components typical of these reference patterns in different sub-domains.

Table 2 Examples from domain-specific patterns for engineered products.
Full size table

S*Patterns were originally developed to improve ability to rapidly generate high quality models of domain-specific Requirements, Designs, and Risk Analyses in specific domains, from a domain specific reference pattern that is configured based upon stakeholder needs. This is illustrated by the “downstroke” arrow on the left side of Fig. 1, and is referred to as “generating a configured S*Model from an S*Pattern”.23,39

The broad range of domain-specific S*Patterns that have been generated in this way over two decades is described in Sect. 3 Results.

For engineered products, this is closely related to the ideas of Product Line Engineering (PLE), Architectural Frameworks, Model Schema, and Model Ontologies.23 Some of the distinctions are:

  1. 1.

    Simpler Variant Rules The minimal logical structure of the STEM-based S*Metamodel constrains the variant degrees of freedom found in modeled requirements, designs, failure modes, etc., by applying the causal aspects of the S*Metamodel before any domain-specific specialization. This means that configuration of an S*Model generated from an S*Pattern can be performed by inputs into S*Feature space alone, with automated propagation of the causal constrained variant implications built into the S*Pattern.

  2. 2.

    Not Just Framework Architectural Frameworks and Ontologies most often describe useful templates in which partially-compatible models can be constructed, but with high degrees of freedom calling for more modeling by the framework user. Ontologies help improve semantic interoperability of models across different humans and across different information systems, and are evident in the biomedical space.43 S*Patterns can be viewed as special cases of these frameworks, in which the pattern has been more fully built out as a complete model of stakeholder issues, requirements, designs, failure modes, etc. This leaves only configuration of the specific variant remaining, not requiring modeling skill but knowledge of the stakeholder application and awareness of the pattern’s user semantics.

More recently, the INCOSE Patterns Working Group has been carrying out demonstration of automating not only pattern-based generation of models, but also pattern-based checking of other models against the same type of pattern.28

The Innovation Ecosystem Pattern

The third reference model type describes a much larger system scope—the entire ecosystem in which an engineered product is developed, produced, distributed, used, and improved, along with the system of governance and improvement of not just the engineered product but the ecosystem itself. This scope includes the entire product supply chain and more. While this may seem an ambitious scope, we are reminded that it is improvements of this system that are the aim of improved methods of innovation, including among others advancement of Regulatory Science. The Innovation Ecosystem Pattern makes this “elephant in the room” explicit, as a configurable S*Pattern of the related socio-technical system of systems.

The engineering community is certainly not without high value historical models of at least portions of the human-performed Innovation Ecosystem. ISO standards such as Ref. [16], regulatory guidance such as Ref. [10], technical society guides and standards such as Ref. [1], the ubiquitous “Vee” model,20 new model-based standard efforts to describe the Model-Based Enterprise,18 enterprise-specific descriptions, and others provide vital guidance. Out of respect for those historical assets and the importance of building upon them, they are accommodated within and mate up with the larger-scale Innovation Ecosystem reference model’s configurations.

Why is an ecosystem-level reference model needed? Smaller-scale models have served to inform teams about what work needs to be done, coordinate flows of information, plan information systems, and other purposes. Is there really a need for an ecosystem level reference? Do our innovation ecosystems work well enough, and do we understand them well enough?

Ecosystem-level efforts and issues are arising that challenge our group-level abilities to effectively understand (individually and together) and communicate about the innovation ecosystem across life cycles, and particularly so while that ecosystem itself is evolving and the stakes are rising. We are increasingly interested in how to understand the basis of performance of the ecosystem as a whole (as in its timely delivery of competitive solutions) through its system components and their organization—for performance improvement, robustness, pathology, and security reasons, including interests of regulation in these and other areas. How do we integrate across supply chains? Are there other effective architectures besides historical OEM and captive supplier relationships? How can we improve the real effectiveness of those or other combinations? Can we even effectively communicate about this subject without a shared neutral reference model? What is the connection of the engineering community’s interest with the business management community’s interest in “business ecosystems”?17

Growth in conversations about “digital engineering”, “digital twins” and “digital threads”, all illustrate a growing need for foundational insight to support the “buzz” and to better connect to history even where departures are needed. The Innovation Ecosystem Reference Model described in this paper focuses on such a set of ecosystem issues.

Figure 4 provides a “Level 1” view of this reference model’s three key system boundaries.

Figure 4
figure 4

Innovation ecosystem (ASELCM) pattern logical architecture, Level 1.

Full size image

System 1—The Engineered System of Interest Viewed at any and all times in its life cycle.

System 2—The Life Cycle Domain System The environment with which the Engineered System interacts, across its life cycle. This includes all Life Cycle Management systems responsible for the Engineered System (research, engineering, manufacturing, distribution, markets, utilization, sustainment). System 2 is responsible to observe and learn about System 1 and its environment, not just engineer and deploy it. A model or artifact describing System 1 is a subsystem of System 2, which also includes collaborating users of that information.

System 3—The Innovation Ecosystem Includes the system responsible to plan, deploy, and evolve System 2, responsible to observe and learn about System 2 and its environment. Writing and reading this article are System 3 activities, as are many other technical society activities intended to improve the future System 2’s of the world.

The details of the Innovation Ecosystem S*Pattern are built on the same S*Metamodel elements as the other configurable S*Patterns. Table 3 samples some of those elements.

Table 3 Examples from innovation ecosystem pattern.
Full size table

The high-level neutral logical architecture of Fig. 4 is intended to be descriptive, not prescriptive, and configurable to any innovation ecosystem, however implemented. That “Level 1” architecture is decomposed to the “Level 2” descriptive architecture of Figs. 5, 6, 7. These show eight generic roles, for processes (upper half, three roles) and information (lower half, five roles). Together, these eight roles describe the “gasket” which mates up any set of innovation ecosystem business processes with the underlying information it depends upon—no matter how it is implemented, digital or not, effective or not, providing a neutral analysis reference model. Figure 5 illustrates that configured pattern is mapped to the local enterprise business processes, whether they are standards based or unique, whether they are effective or not.

Figure 5
figure 5

Configured reference pattern maps to any local enterprise business processes.

Full size image
Figure 6
figure 6

Sources of credibility and descriptions of information.

Full size image
Figure 7
figure 7

The consistency thread, antecedent to the digital thread and digital twin.

Full size image

Figure 6 illustrates sources of information from empirical observation, stakeholders, and virtual model simulation, along with the generation of configured domain-specific models from generic patterns. Figure 7 illustrates the role of metadata in describing models, patterns, and data. None of the concepts necessarily implies the use of digital implementation, as all these ideas also apply to human-performed, tribal knowledge and culture roles as well as digital implementations.

Additional details of Levels 2, 3, and 4 of the reference pattern, not all shown, describe phenomena of learning as pattern extraction, management of uncertainty and propagation of trust, and the role of trusted repositories.

The representation of semantic interoperability (including between people, not just machines) are likewise built into those levels.

The traditional systems engineering “Vee diagram” in the lower left of Fig. 5, along with the other adjacent enterprise models, all remind us that all engineering methods in one way or another inherently manage a series of “gaps” into acceptable “consistencies”:

  • Consistency of formally recorded system requirements with stakeholder needs

  • Consistency of system designs with system requirements

  • Consistency of virtual simulations with empirical measurements (model VVUQ)

  • Consistency of system component production with system design

  • Consistency of system performance with system requirements

  • Consistency of system operation with system requirements and design

  • Consistency of system sustainment with system requirements and design

  • Consistencies of many aspects with applicable technical standards, regulation, and law

  • Consistencies of many aspects with learned experiences, formal patterns of requirements and design, physical science, product line rules, architectural frameworks, shared ontologies, domain specific languages, and model semantics

  • Many other types of consistencies

Nearly all of these were also required consistencies in the traditional, more “tolerant” human-performed ecosystems lacking as much digital technology, even if not recognized as so. The Consistency Management Role in Figs. 5 and 6 represents the configurable set of process roles responsible for consistency management of issues such as the above list—whether performed by humans or automated, and whether performed well or not. It is understandable that much of this role has historically been performed by humans, because of required skills, judgement, experience, and information forms. It plays a key role in regulatory science, and is a candidate for further automated support. Figure 7 illustrates the related Consistency Thread concept that supports the Digital Thread but also earlier approaches, including Design History File.9

Results

The three classes of reference patterns described above connect to different historical periods, so that their results, described in this section, differ in time.

Results—S*Metamodel Reference Model

The first and most fundamental reference pattern of this article is the S*Metamodel, intended to increase system engineering emphasis on the impactful core of the successful models of the physical sciences and mathematics over the three centuries since Newton and those who followed. The impact of the STEM revolution and its associated models have transformed the quality and possibilities of human life. This story is well-known, so why repeat it through this formal pattern? Physics-based computational models used for regulated medical devices and medical sciences have already advanced tremendously and earned a growing place in the regulatory submission process.10,21 Why, then, has the System Phenomenon described earlier above proven worth re-emphasizing through the S*Metamodel?

The increasing engineering interest in generating and using “system models”, as in Model-Based Systems Engineering (MBSE), is much more recent. Unlike the other engineering disciplines, it is not widely recognized as based on underlying observable phenomena having a scientific theoretical basis in phenomena and mathematics. Many system models have been driven by conventions of changing languages and standards to resemble models of information about systems instead of models of the systems themselves. For those of us who create and use these more recent “system models”, the S*Metamodel reminds us that phenomenological–mathematical foundation does in fact exist historically, has been well-known for two centuries, and is exactly the basis of the foundations of each of the more specific disciplines. Because systems practitioners, and their formal training, sometimes overlook that foundation, it is common to see system models which lack fundamental aspects of system-ness, such as the interactions that account for literally all behavior and the selectable feature sets that account for fitness, risk management, and product evolution.

The re-emphasis of the S*Metamodel has enabled creation of diverse MBSE models (listed in the next section) better capturing essential ideas, across medical devices, advanced manufacturing, aerospace systems, consumer products, and socio-technical systems of innovation.42 The System Phenomenon is itself a recurring pattern, and by reconnecting the theoretical foundations of those models, the ability to represent families of configurable generic systems in these same domains has also advanced, as described in the next section.

Impacts on MBSE representation practice include:

  • Explicit Interactions must be central to every system behavior model: Nature has no known “naked behavior” in absence of interactions, beginning with system context (environment). Representation of (both discrete and continuous) state is likewise essential to every system model. Modeling frameworks, metamodels, schema, and ontologies should support explicit interactions and states as central.

  • Historical distinctions between “system models” and “physics-based simulation models” can be reduced, improving their consistency, integration, and user awareness and understanding.

More domain-specific frameworks necessarily continue to emerge:

  • Emergent domains and domain specific languages/ontologies arise for each new case of cross-domain interactions, as described earlier above. Efforts to create and sustain frameworks must recognize continuous creation of new domains is inherent to nature of systems.

  • For researchers, small underlying foundational framework content is important, but the main continuing work is needed for domains which continue to emerge.

Results—Domain-Specific Product S*Pattern Reference Models

Table 4 illustrates a sampling of the wide range of domain-specific system patterns that have been generated over two decades, based on the S*Metamodel. More than half of these describe manufactured products or their manufacturing systems. In the FDA regulated space, system patterns have been generated to describe families of system models of injectors, combo products, pumps, blood glucose and coagulation meters, implants, IVD instruments, pharmaceutical and biotech manufacturing systems, as well as pharmaceutical container filling and packaging systems and their building and utility facilities.3,15,33,35

Table 4 Examples of types of domain-specific system patterns created.
Full size table

Creating domain-specific patterns across many domains has allowed system models to be generated in an order of magnitude less time and effort.30,39 However, it has also taught us that some environments are so accustomed, or in some cases even incentivized, to “one-off” unique project business that being prepared for this improvement requires more than technical modeling skills. Both individuals and organizations may encounter strong incentives to in effect resist the use of pre-established configurable models, in favor of longer and more expensive (for someone else) modeling approaches. This also negatively impacts model semantic interoperability across enterprise and supply chain ecosystems, and for reasons other than information technologies.

The formalization of IP (intellectual property) as domain-specific S*Patterns has taught us that the standards of financial accounting for software allow for the financial capitalization of these pattern assets. This changes the economics of projects’ “front-end” systems engineering, and has paired with the additional learned concept of Information Debt in agile systems engineering.6,44

Experience in creating, maintaining, and using model-based patterns has improved our understanding of how organizational (group) level learning occurs (effectively or not) over the course of multiple innovation programs, and this has led to the Innovation Ecosystem Pattern results in the next section.

The S*Patterns insight that system variability of any consequence can be modeled as connected to selectable Stakeholder Feature variability has led to improved appreciation of the evolutionary forces on systems in a System of Innovation, also discussed in the next section.

Results—Innovation Ecosystem S*Pattern Reference Model

The Innovation Ecosystem Pattern is the most recent of the three reference pattern classes, originating in Ref. [2]. It has been applied to describe and discover principles of agile systems engineering environments in public INCOSE case studies,5,6,7,8 to describe digital engineering ecosystems,38 principles of digital threads,4 and case studies of digital twins.12 It has been used as the basis of ecosystem analysis and planning24 for individual private sector enterprises and for analysis and planning of supply chain collaboration with learning.27 It has been used for study of virtual verification and validation of product design and manufacturing processes, including uses of pattern-based metadata. It has been expressed in OMG SysML language, mapped to the S*Metamodel.

The reference pattern has taught us about the opportunity for a more unified view of the paradigm of consistency management spanning the wide range of traditional risk areas across life cycle management.13,14,19,25,29,36 It has illustrated the capability to automate or semi-automate larger portions of this consistency management using advanced model-checking and model synthesis capabilities of semantic and other information technologies.28 It has been used to facilitate group discovery activity for identification of priority needs across the health care delivery ecosystem.33

The Innovation Ecosystem Pattern has been used to study adaptation of innovation ecosystems in the sense of optimal estimation and control, and as a basis to better understand the nature of group learning, or its absence, in the performance of the ecosystem. This involves the roles of models developed in the historical physical sciences, and the behaviors that go with them, as to the nature of effective group learning.26,34

The reference pattern has been used to understand that semantic interoperability between different people, information systems, functional departments, enterprises, and larger collaborations that include regulatory agencies, is not primarily an information technology issue. The S*Metamodel reference pattern also explains why newer “incompatible” ontologies must continue to emerge as a part of the innovation process, the Ecosystem Pattern has helped us learn that skill in creating shared ontologies or map**s between them is an essential part of an effective Innovation Ecosystem.37

Discussion

Based on the foregoing, this section suggests how the reference patterns described may be further utilized in support of Regulatory Science that improves the performance of the Innovation Ecosystem.

  1. 1.

    Unified System and Computational Models The growing complexity, scale, and criticality of engineered systems in the BME and other regulated health care sectors makes the increased use of effective “system level” models all the more important. The S*Metamodel reminds us why it is critical that those models explicate the interactions at the heart of systems. The potential of semantic information technologies combined with computational models promise new levels of integrated consistency checking of models against trusted patterns.

  2. 2.

    Shared Domain-Specific Ontologies for Regulatory Submissions The description of a medical device or its manufacturing system is submitted to a regulatory authority in connection with its development and approval for introduction into service. As the series of such engineered systems and submissions become more complex over time, and the diversity of innovative systems grows, the problem of semantic interoperability (for humans as well as computers) becomes greater for both the regulators and the suppliers, with negative impact on the protected public. This is a special case of the general pattern evolution and semantic interoperability problems that are also seen across other boundaries within the ecosystem. Studying how this is addressed informally and intuitively in even mostly informal human-based Innovation Ecosystems also informs the more formal case of model-based system descriptions. Community investment in shared domain-specific ontological patterns (e.g., for insulin pumps, artificial pancreases, IVD instruments, biotech reactors, etc.) can improve ecosystem communities’ ability to process each other’s descriptions, spot problems or gain approvals. Domain-specific ontological patterns include ability to determine validity of claims of derivative product status. Community investment in these “Patterns in the Public Square” can include collaborations with neutral third-party entities such as technical societies.

Important guidance provided by Ref. [10] can be seen as an early sign of Discussion items (1) and (2) above, as follows. The body of that reference is grounded in universal parameters of STEM-informed technical descriptions of all systems, shown by Ref. [35] to align with Reference Pattern 1, the S*Metamodel. The five appendices of Ref [10] then proceed to more phenomena-specific descriptions that would also be seen in the domain-specific patterns of Reference Patterns 2. Discussion items (1) and (2) above carry this approach further in the sense of model-assisted rigor.

  1. 3.

    Semantic Technology Automation Assistance As domain patterns for shared ontologies become more prevalent, the information landscape becomes conducive to increasing the use of semantic technologies to assist in human judgment of consistencies. See for example, Ref [28]. This can bring greater automation assistance to items (1) and (2) above, advancing the overall Ecosystem of Reference Pattern 3.

  2. 4.

    Regulated Systems of Innovation as Objects of Scientific Study The first requirement for studying phenomena is observational data. The “steering mechanism” of the Innovation Ecosystem is based on the Value Selection Phenomenon and the Group Learning Phenomenon, discussed above.34,37 This adaptive behavior is a form of regulatory feedback. If an Innovation Ecosystem offers enough transparency to allow observations of its performance under feedback to be reliably accumulated and aggregated (think across Design History Files and their regulatory and life cycle outcomes), it enables the scientific study of what is valued, what is believed (learned), the dynamic timing and consistency of subsequent decision-driven action (regulatory steering) with respect to that learning, and the later consequences of those selections. All of these are subject to various uncertainties, dynamics, and pathologies. We also know from control system theory that an understanding of the dynamics of the “regulated plant” is required in selecting such a feedback control system. A scaled-down example of such observation is the study of “escapes” in the review of engineered designs, and the correlation of that escape data with various design methodologies.22

  3. 5.

    Science of Decision-Making Phenomena Whether decisions are made by humans or engineered algorithms, in sufficiently uncertain and complex situations they are subject to error. Behavioral Economics and its extensions have grown up a body of scientific knowledge concerning phenomena associated with decision-making and its pathologies. “Moneyball for Regulators” may seem like a bridge too far, but remember that it was also viewed that way by baseball team management, before it become a key way to make professional sports management decisions.

  4. 6.

    Effective Propagation of Trust and Understanding, as a Phenomenon The mathematical methods of model verification, validation, and uncertainty quantification (model VVUQ), learning machine algorithms, and optimal estimation and control teach us about the propagation of uncertainty through system models and across time, and optimal mixing of new observational data with past learning. However, the mathematics of propagation of trust across human populations is yet another kind of uncertainty propagation. As dramatically demonstrated by the waves of public opinions during the COVID-19 pandemic, the transmission of credibility across populations exhibits phenomena more like Ising models of statistical mechanics. Because regulatory systems are for the protection of a public which is also the medium of transmission of trust, it is suggested that a science-based model of the related phenomena is important to a scientific understanding of the dynamical behavior of regulated Innovation Ecosystem behavior in Public Health.

  5. 7.

    Science of System 1 vs System 2 Regulatory submissions and decisions currently involve description and evaluation of both System 1 (the engineered product) and System 2 (the engineering process and other life cycle management processes). The Innovation Ecosystem Pattern helps clarify that the science employed by regulation is both concerned with System 1 phenomena and System 2 phenomena. The first is domain specific, but the second is more abstract (and therefore more reusable across diverse device products), as indicated by Table 1. (Think of Quality Management Systems, as in Ref. [9].) The second encourages use of domain-specific patterns.

Definitions of key terms discussed in the above material are consolidated in Table 5.

Table 5 Terminology definitions.
Full size table