Operads for complex system design specification, analysis and synthesis

As the complexity and heterogeneity of a system grows, the challenge of specifying, documenting and synthesizing correct, machine-readable designs increases dramatically. Separation of the system into manageable parts is needed to support analysis at various levels of granularity so that the system is maintainable and adaptable over its life cycle. In this paper, we argue that operads provide an effective knowledge representation to address these challenges. Formal documentation of a syntactically correct design is built up during design synthesis, guided by semantic reasoning about design effectiveness. Throughout, the ability to decompose the system into parts and reconstitute the whole is maintained. We describe recent progress in effective modelling under this paradigm and directions for future work to systematically address scalability challenges for complex system design.


Introduction
We solve complex problems by separating them into manageable parts [1,2]. Human designers do this intuitively, but details can quickly overwhelm intuitive insights. Multiple aspects of a problem may lead to distinct intuitive decompositions and complementary models of a single system-e.g. competing considerations for cyberphysical systems [3,4]-or simulation of behaviour may require many levels of fidelity-e.g. in  modelling and simulation [5]-leading to a spectrum of models which are challenging to align. We argue that operads, formal tools developed to compose geometric and algebraic objects, are uniquely suited to separate complex systems into manageable parts and maintain alignment across complementary models. Operads provide three ways to separate concerns for complex systems: (1) designs for subsystems are separated into composable modules; (2) syntactic designs to compose systems are separated from the semantic data that model them; and (3) separate semantic models can be aligned to evaluate systems in different ways. The three relationships are illustrated in figure 1.
Hierarchical decomposition (figure 1, (1)) is nothing new. Both products and processes are broken down to solve problems from design to daily maintenance. Operads provide a precise language to manage complex modelling details that the intuitive-and highly beneficialpractice of decomposition uncovers, e.g. managing multiple, complementary decompositions and models.
Operads separate the syntax to compose subsystems from the semantic data modelling them (figure 1, (2)). Syntax consists of abstract 'operations' to design the parts and architecture of a system. Semantics define how to interpret and evaluate these abstract blueprints. Operad syntax is typically lightweight and declarative. Operations can often be represented both graphically and algebraically (figure 4), formalizing intuitive design diagrams. Operad semantics model specific aspects of a system and can range from fast to computationally expensive.
This paper articulates a uniform and systematic foundation for system design and analysis. In essence, the syntax of an operad defines what can be put together, which is a prerequisite to decide what should be put together. Interfaces define which designs are syntactically feasible, but key semantic information must be expressed to evaluate candidate designs. Formulating system models within operad theory enforces the intellectual hygiene required to make sure that different concerns stay separated while working together to solve complex design problems.
We note five strengths of this foundation that result from the three ways operads separate a complex problem and key sections of the paper that provide illustrations.
Expressive, unifying meta-language. A meta-or multi-modelling [14] language is needed to express and relate multiple representations. The key feature of operad-based meta-modelling is its focus on coherent mappings between models (figure 1, (2), (3)), as opposed to a universal (a) Contribution to design literature There are well-known examples of the successful exploitation of separation. For instance, electronic design automation has had decades of success leveraging hierarchical separation of systems and components to achieve very large-scale integration of complex electronic systems [16][17][18]. We do not argue that operads are needed for extremely modular domains. Instead, operads may help broaden the base of domains that benefit from separation and provide a means to integrate and unify treatment across domains. On the other hand, for highly integral domains the ability to separate in practically useful ways may be limited [19,20]. The recent applications we present help illustrate where operads may prove useful in the near and longer term; see §7c for further discussion.
Compared to related literature, this article is application-driven and outward focused. Interest in applying operads and category theory to systems engineering has surged [21][22][23][24][25][26] as part of a broader wave applying category theory to design databases, software, proteins, etc. [27][28][29][30][31][32][33]. While much of loc. cit. matches applications to existing theoretical tools, the present article describes recent application-driven advancements and overviews specific methods developed to address challenges presented by domain problems. We introduce operads for design to a general scientific audience by explaining what the operads do relative to broadly applied techniques and how specific domain problems are modelled. Research directions are presented with an eye towards opening up interdisciplinary partnerships and continuing application-driven investigations to build on recent insights.

(b) Organization of the paper
The present article captures an intermediate stage of technical maturity: operad-based design has shown its practicality by lowering barriers of entry for applied practitioners and demonstrating applied examples across many domains. However, it has not realized its full potential as an applied meta-language. Much of this recent progress is not focused solely on the analytic power of operads to separate concerns. Significant progress on explicit specification of domain models and techniques to automatically synthesize designs from basic building blocks has been made. Illustrative use cases and successful applications for design specification, analysis and synthesis organize the exposition; see figure 2. Section 2 introduces operads for design by analogy to other modelling approaches.
Our main examples are introduced in §3. Section 4 describes how concrete domains can be specified with minimal combinatorial data, lowering barriers to apply operads. Section 5 concerns analysis of a system with operads. Automated synthesis is discussed in §6. Future research directions are outlined in §7, which includes a list of open problems.
Notations. Throughout, we maintain the following notional conventions for:

Applying operads to design
We introduce operads by an analogy, explaining what an operad is and motivating its usefulness for systems modelling and analysis. The theory [34][35][36] pulls together many different intuitions.
Here, we highlight four analogies or 'views' of an operad: hierarchical representations (tree view), strongly typed programming languages (API 1 view), algebraic equations (equational view) and system cartography (systems view). Each view motivates operad concepts; see table 1. The paradigm of this paper is based on a typed operad, also known as a 'coloured operad' [36] or 'symmetric multicategory' ( [34], 2.2.21). A typed operad O has -A set T of types.
-Sets of operations O(X 1 , . . . , X n ; Y) where X i , Y ∈ T and we write f : X i → Y to indicate that f ∈ O(X 1 , . . . , X n ; Y). -A specific way to compose any operation f : Y i → Z with g i : X ij → Y i whose output types match the inputs of f to obtain a composite f • (g 1 , . . . , g n ) = h : X ij → Z. These data are subject to rules ( [36], 11.2) governing permutation of arguments and assuring that iterative composition is coherent, analogous to associativity for ordinary categories ( [37], I).

(a) The tree view
Hierarchies are everywhere, from scientific and engineered systems to government, business and everyday life; they help to decompose complex problems into more manageable pieces. The fundamental constituent of an operad, called an operation, represents a single step in a hierarchical decomposition. We can think of this as a single branching in a labelled tree, e.g. Together with the original operation, these represent four views of the same system at different levels of granularity; compare, e.g. ( [38], fig. 2). This reveals an important point: an operad provides a collection of interrelated models that fit together to represent a complex system. The relationship between models is constrained by the principle of compositionality: the whole is determined by its parts and their organization. Here, the whole is the root, the parts are the leaves, and each tree is an organizational structure. Formally, associativity axioms, which generalize those of ordinary categories, enforce compositionality. For example, composing the left-hand tree above with op 2 must give the same result as composing the centre tree with op 1 . Both give the tree on the right, since they are built up from the same operations. In day-to-day modelling, these axioms are mostly invisible, ensuring that everything 'just works', but the formal definitions ( [36], 11.2) provide explicit requirements and desiderata for modelling languages 'under the hood'.
Operads encourage principled approaches to emergence by emphasizing the organization of a system. Colloquially speaking, an emergent system is 'more than the sum of its parts'; operations provide a means to describe these nonlinearities. This does not explain emergent phenomena, which requires detailed semantic modelling, but begins to break up the problem with separate (but related) representation of components and their interactions. The interplay between these elements can be complex and unexpected, even when the individual elements are quite simple. 2 Compositional models may develop and exhibit emergence as interactions between components are organized, in much the same way as the systems they represent.

(b) The API view
For most applications, trees bear labels: fault trees, decision trees, syntax trees, dependency trees and file directories, to name a few. A tree's labels indicate its semantics either explicitly with numbers and symbols or implicitly through naming and intention. If an operad is an API-a collection of abstract types and methods-then an operad algebra A is a concrete implementation. An algebra declares: (1) a set of instances for each type; and (2) a function for each operation, taking instances as arguments and returning a single instance for the composite system. That is, A : O → Set has -for each type X ∈ T, a set A(X) of instances of type X, and -for each operation f : X i → Y, the function A(f) acts on input elements a i ∈ A(X i ) to obtain a single output element A(f)(a 1 , . . . , a n ) ∈ A(Y).
Required coherence rules ( [36], 13.2) are analogous to the definition of a functor into Set ([37], I.3). For example, we might declare a state space for each subsystem, and a function to calculate the overall system state given subsystem states. Alternatively, we might assign key performance indicators (KPIs) for each level in a system and explicit formulae to aggregate them. The main thing to remember is: just as an abstract method has many implementations, an operad has many algebras. Just like an API, the operad provides a common syntax for a range of specific models, suited for specific purposes. Unlike a traditional API, an operad provides an explicit framework to express and reason about semantic relationships between different implementations. These different implementations are linked by type-indexed mappings between instances called algebra homomorphisms. For example, we might like to extract KPIs from the system state. The principle of compositionality places strong conditions on this extraction: the KPIs extracted from the overall system state must agree with the KPIs obtained by aggregating subsystem KPIs. That is, in terms of trees and in pseudocode For any state instances for Sub 1 and Sub 2 at the base of the tree, the two computations must produce the same KPIs for the overall system at the top of the tree. Here, KPI(op) and State(op) implement op in the two algebras, while extr(−) are components of the algebra homomorphism to extract KPIs. Similar to associativity, these compositionality conditions guarantee that extracting KPIs 'just works' when decomposing a system hierarchically.

(c) The equational view
We have just seen an equation between trees that represent implementations. Because an operad can be studied without reference to an implementation, we can also define equations between abstract trees. This observation leads to another view of an operad: as a system of equations.
The first thing to note is that equations occur within the sets of operations O(X 1 , . . . , X n ; Y); an equation between two operations only makes sense if the input and output types match. Second, if one side of an equation f = f occurs as a subtree in a larger operation g, substitution generates a new equation g = g . Two trees are equal if and only if they are connected by a chain of such substitutions (and associativity equations). In general, deciding whether two trees are equal (the word problem) may be intractable. Third, we can often interpret composition of operations as a normal-form computation We then compare composed operations directly to decide equality. For example, there is an operad whose operations are matrices. Composition computes a normal form for a composite operation by block diagonals and matrix multiplication, Operad axioms constrain composition. For example, the axiom mentioned in §2a corresponds to The key point is that any algebra that implements the operad must satisfy all of the equations that it specifies. Type discipline controls which operations can compose; equations between operations control the resulting composites. Declaring equations between operations provides additional contracts for the API. For instance, any unary operation f : X → X (a loop) generates an infinite sequence of composites id X , f, f 2 , f 3 , . . .. Sometimes this is a feature of the problem at hand, but in other cases, we can short-circuit the infinite regress with assumptions like idempotence (f 2 = f) or cyclicity (f n = id X ) and ensure that algebras contain no infinite loops.

(d) The systems view
When we apply operads to study systems, we often think of an operation f : X i → Y as a system architecture. Intuitively, Y is the system and the X 1 , . . . , X n are the components, but this is a bit misleading. It is better to think of types as boundaries or interfaces, rather than systems. Instead, f is the system architecture, with component interfaces X i and environmental interface Y. Composition formalizes the familiar idea ( [38], fig. 2) that one engineer's system is the next's component; it acts by nesting subsystem architectures within higher-level architectures.
Once we establish a system architecture, we would like to use this structure to organize our data and analyses of the system. Moreover, according to the principle of compositionality, we should be able to construct a system-level analysis from an operation by analysing the component-level inputs and synthesizing these descriptions according to the given operations.
The process of extracting computations from operations is called functorial semantics, in which a model is represented as a mapping M : Syntax −→ Semantics. The syntax defines a system-specific architectural design. Semantics are universal and provide a computational context to interpret specific models. Matrices, probabilities, proofs and dynamical equations all have their own rules for composition, corresponding to different semantic operads.
The mapping M encodes, for each operation, the data, assumptions and design artefacts (e.g. geometric models) needed to construct the relevant computational representations for the architecture, its components and the environment. From this, the system model as a whole is determined by composition in the semantic context. The algebras (State, KPI) described in §2b are typical examples, with syntax O and taking semantic values in sets and functions. The mappings themselves, called functors, map types and operations (System, op) to their semantic values, while preserving how composition builds up complex operations.
The functorial perspective allows complementary models-e.g. system state versus KPIs-to be attached to the same design. This includes varying the semantic context as well as modelling details; see §5 for examples of non-deterministic semantics. Though functorial models may be radically different, they describe the same system, as reflected by the overlapping syntax.
In many cases, relevant models are not independent, like system state and KPIs. Natural transformations, like the extraction homomorphism in §2b, provide a means to align ostensibly independent representations. Since models are mappings, we often visualize natural transformations as two-dimensional cells (2.2) Formal conditions guarantee that when moving from syntax to semantics ( [36], 13.2) or between representations ([34], 2.3.5), reasoning about how systems decompose hierarchically 'just works. ' Since functors and higher cells assure coherence with hierarchical decomposition, we can use them to build up a desired model in stages, working backwards from simpler models This is a powerful technique for at least two reasons. First, complexity can be built up in stages by layering on details. Second, complex models built at later stages are partially validated through their coherence with simpler ones. The latter point is the foundation for lazy evaluation: many coarse models can be explored before ever constructing expensive models.
Separating out the different roles within a model encourages efficiency and reuse. An architecture (operation) developed for one analysis can be repurposed with strong coherence royalsocietypublishing.org/journal/rspa Proc. R. Soc. A 477: between models (algebra instances) indexed by the same conceptual types. The syntax/semantics distinction also helps address some thornier meta-modelling issues. For example, syntactic types can distinguish conceptually distinct entities while still mapping to the same semantic entities. We obtain the flexibility of structural or duck typing in the semantics without sacrificing the type safety provided by the syntax.

Main examples
Though operads are general tools [34][35][36], we focus on two classes of operads applied to system design: wiring diagram operads and network operads. These are complementary. Wiring diagrams provide a top-down view of the system, whereas network operads are bottom-up. This section introduces three examples that help ground the exposition as in figure 2.

(a) Specification
Network operads describe atomic types of systems and ways to link them together with operations. These features enable: (1) specification of atomic building blocks for a domain problem; and (2) bottom-up synthesis of designs from atomic systems and links. A general theory of network operads [40][41][42][43]  2) customized to a domain problem. The first example illustrates designs of search and rescue (SAR) architectures. The domain problem was inspired by the 1979 Fastnet Race and the 1998 Sydney to Hobart Yacht Race and we refer to it as the sailboat problem. It illustrates how network operads facilitate the specification of a model with combinatorial data called a network template. For example, figure 3 shows the carrying relationships between different system types to model (e.g. a Boat can carry a UAV (unmanned aerial vehicle) but a Helo cannot). These data specify a network operad O Sail whose: (1) objects are lists of atomic system types; (2) operations describe systems carrying other systems; and (3) composition combines carrying instructions. We discuss this example in greater detail in §4.

(b) Analysis
A wiring diagram operad describes the interface each system exposes, making it clear what can be put together [26,44,45]. The designer has to specify precisely how information and physical quantities are shared among components, while respecting their interfaces. The operad facilitates top-down analysis of a design by capturing different ways to decompose a composite system.   The second example analyses a precision-measurement system called the length scale interferometer (LSI) with wiring diagrams. It helps illustrate the qualitative features of operads over and above other modelling approaches and the potential to exploit their analytic power to separate concerns. Figure 4 illustrates joint analysis of the LSI to address different aspects of the design problem: functional roles of subsystems and control of the composite system. This analysis example supports these illustrations in §5.

(c) Synthesis
The third example describes the automated design of mission task plans for SAR using network operads. The SAR-tasking example illustrates the expressive power of applying existing operads and their potential to streamline and automate design synthesis. Figure   but whereas a sparse matrix specifies an architecture problem, here a Petri net is used to model coordinated groups of agents.
For the SAR-tasking problem, much of the complexity results from agents' need to coordinate in space and time, e.g. when a helicopter is refuelled in the air, as in τ 3 of figure 5a. To facilitate coordination, the types of the network operad are systematically extended via a network model whose target categories add space and time dimensions; compare, e.g. [41]. In this way, task plans are constrained at the level of syntax to enforce these key coordination constraints; e.g. figure 5b where two UH60s at the same space-time point (c, 2) manoeuvre together to d. We describe automated synthesis for this example in §6.

Cookbook modelling of domain problems
In this section, we describe some techniques for constructing operads and their algebras, using an example-driven, cookbook-style approach. We emphasize recent developments for network operads and dive deeper into the SAR architecture problem.

(a) Network models
The theory of network models provides a general method to construct an operad O by mixing combinatorial and compositional structures. Note that this lives one level of abstraction above operads; we are interested in constructing a language to model systems, e.g. for a specific domain. This provides a powerful alternative to coming up with operads one-by-one. A general construction allows the applied practitioner to cook-up a domain-specific syntax to compose systems by specifying some combinatorial ingredients.
The first step is to specify what the networks to be composed by O look like. Often this is some sort of graph, but what kind? Are nodes typed (e.g. coloured)? Are edges symmetric or directed? Are loops or parallel edges allowed? What about n-way relationships for n > 2 (hyperedges)? We can mix, match and combine such combinatorial data to define different network models, which specify the system types and kinds of relationships between them relevant to some domain problem. The network model describes the operations we need to compose the networks specific to the problem at hand.
Three compositional structures describe the algebra of operations. The disjoint or parallel structure combines two operations for networks with m and n nodes, respectively, into a single operation for networks with m + n nodes. More restrictively, the overlay or in series structure superimposes two operations to design networks on n nodes. The former structure combines separate operations to support modular development of designs; the latter supports an incremental design process, either on top of existing designs or from scratch. The last ingredient  permutes nodes in a network, which assures coherence between different ordering of the nodes. This last structure is often straightforward to specify. If it is not, one should consider if symmetry is being respected in a natural way. We can distill the main idea behind overlay by asking, what happens when we add an edge to a network? It depends on the kind of network being composed by O:

In a simple graph but in a labeled graph and in a multigraph
x y x y x y These differences are controlled by a monoid, 3 which provides each + shown. Above, the monoids are bitwise OR, addition, and maximum, respectively. As a further example, if edge addition is controlled by Z/2Z then + will have a toggling effect. Consider simple graphs. Given a set of nodes n, write U n for the set of all undirected pairs i = j (a.k.a. simple edges i-j), so that |U n | = |n| 2 . Then we can represent a simple graph over n as a U n -indexed vector of bits b i-j describing which edges to 'turn on' for a design. Each bit defines whether or not to add an i-j edge to the network and the overlay compositional structure is given by the monoid SG(n) := Bit U n , whose + is bitwise OR for the product over simple edges, i.e. adding i-j then adding i-j is the same as adding i-j a single time. The disjoint structure : SG(m) × SG(n) −→ SG(m + n) forms the disjoint sum of the graphs g and h. Finally, permutations act by permuting the nodes of a simple graph. Together, these compositional structures define a network model SG : S → Mon, which determines how operations are composed in the constructed network operad; see figure 6 (or [40], 3.2, 7.2) for complete technical details.
This definition has an analogue for N-weighted graphs, LG(n) := (N, +) U n , with overlay given by sum of edge weights and another for multi-graphs, MG(n) := (N, max) U n , with overlay equivalent to union of multisets; see ( [40], 3.3, 3.4) for details. More generally, we can label edges with the elements of any monoid. Many of these examples are strange-binary addition makes edges cancel when they add-but their formal construction is straightforward; see ( [40], Thm. 3.1).
Equivalently, we can view the undirected edges in U n as generators, subject to certain idempotence and commutativity relations: SG(n) := e ∈ U n |e · e = e, e · e = e · e . Here, the idempotence relations come from Bit while the commutativity relations promote the single copies of Bit for each i-j to a well-defined network model. Similar tricks work for lots of other network templates; we just change the set of generators to allow for new relationships. For example, to allow self-loops, we add loop edge generators L n = n + U n to express relationships from a node i to itself. Likewise, network operads for directed graphs can be constructed by using generators D n = n × n, and one can also introduce higher-arity relationships.
In all cases, the formal definition of a network model assures that all the combinatorial and compositional ingredients work well together; one precise statement of 'working well together' is given in ([40], 2.3). Once a network template-which expresses minimal data to declare the ingredients for a network model-is codified in a theorem (as in [40], 3.1), it can be reused in a wide variety of domains to set up the specifics of composition.

(b) Cooking with operads
The prototype for network operads is a simple network operad, which models only one kind of thing, such as aircraft. The types of a simple network operad are natural numbers, which serve to indicate how many aircraft are in a design. Operations of the simple network operad are simple graphs on some number of vertices. For example, figure 6 above shows a simple network operad to describe a design for point-to-point communication between aircraft.
Structural network operads extend this prototype in two directions: (1) a greater diversity of things-to-be-modelled is supported by an expanded collection of types; and (2) more sorts of links or relationships between things are expressed via operations. To illustrate the impact of network templates, suppose we are modelling heterogeneous system types with multiple kinds of interactions. For simplicity, we consider simple interactions, which can be undirected or directed.
A network template need only declare the primitive ways system types can interact to define a network model, e.g. a list of tuples (directed : carrying, Helo, Cut). These data are minimal in two ways: (1) any framework must provide data to specify potentially valid interactions; and (2) this approach allows only those interactions that make sense upon looking at the types of the systems involved. Thus, interactions must be syntactically correct when constructing system designs.
Presently, we will consider an example from the DARPA CASCADE program: the sailboat problem introduced in §3a. This SAR application problem was inspired by the 1979 Fastnet Race and the 1998 Sydney to Hobart Yacht Race, in which severe weather conditions resulted in many damaged vessels distributed over a large area. Both events were tragic, with 19 and six deaths, respectively, and remain beyond the scale of current SAR planning. Various larger assets-e.g. ships, aeroplanes, helicopters-could be based at ports and ferry smaller SAR units-e.g. small boats, quadcopters-to the search area.
Specifically, there were eight atomic types to model: P = {Port, Cut, Boat, FW, FSAR, Helo, UAV, QD}. The primary relationship to specify a structural design is various assets carrying another types, so only one kind of interaction is needed: carrying. This relationship is directed; e.g. a cutter (Cut) can carry a helicopter (Helo) but not the other way around.
Specifying allowed relationships amounts to specifying pairs of type (p, p ) ∈ P × P such that type p can carry type p; see figure 3 for examples. Figure 3 data are extended to: (1) specify that Port can carry all types other than Port, UAV and QD; and (2) conform to an input file format to declare simple directed or undirected interactions, e.g. the JSON format in figure 7.
If another type of system or kind of interaction is needed, then the file is appropriately extended. For example, we can include buoys by appending Buoy to the array of colours and augmenting the relationships in the carrying node. Or, we can model the undirected (symmetric) relationship of communication by including an entry such as

(c) Cooking with algebras
Because all designs are generated from primitive operations to add edges, it is sufficient to define how primitive operations act in order to define an algebra. For the sailboat problem, semantics are oriented to enable the delivery of a high capacity for search-known in the literature as search effort ( [46], 3.1)-in a timely manner. Given key parameters for each assete.g. speed, endurance, search efficiency across kinds of target and conditions, parent platform, initial locations-and descriptions of the search environment-e.g. expected search distribution, its approximate evolution over time-the expected number of surviving crew members found by the system can be estimated ( [46], ch. 3). Among these data, the parent platform and initial locations vary within a scenario and the rest describe the semantics of a given scenario. In fact, we assume all platforms must trace their geographical location to one of a small number of base locations, so that the system responds from bases, but is organized to support rapid search. Once bases are selected, the decision problem is a choice of operation: what to bring (type of the composite system) and how to organize it (operation to carry atomic systems). Data for the operational context specify a particular algebra; e.g. table 2. Just as for the operad, these data are lightweight and configurable.

(d) Related cookbook approaches
Though we emphasized network operads, the generators approach is often studied and lends itself to encoding such combinatorially data with a 'template', in a cookbook fashion. The generators approach to 'wiring' has been developed into a theory of hypergraph categories [22,47], which induce wiring diagram operads. Explicit presentations for various wiring diagram operads are given in [45]. Augmenting monoidal categories with combinatorially specified data has also been investigated, e.g. in [48].

Functorial systems analysis
In this section, we demonstrate the use of functorial semantics in systems analysis. As in §2d, a functor establishes a relationship between a syntactic or combinatorial model of a system (components, architecture) and some computational refinement of that description. This provides a means to consider a given system from different perspectives, and also to relate those viewpoints to one another. To drive the discussion, we will focus on the LSI and its wiring diagram model introduced in §3b.

(a) Wiring diagrams
Operads can be applied to organize both qualitative and quantitative descriptions of hierarchical systems. Because operations can be built up iteratively from simpler ones to specify a complete design, different ways to build up a given design provide distinct avenues for analysis. Figure 4 shows a wiring diagram representation of a precision measurement instrument called the LSI designed and operated by the US National Institute of Standards and Technology (NIST). Object types are system or component boundaries; figure 4 has: six components, the exterior, and four interior boundaries. Each boundary has an interface specifying its possible interactions, which are implicit in figure 4, but define explicit types in the operad.
An operation in this context represents one step in a hierarchical decomposition, as in §2a. For example, the blue boxes in figure 4 represent a functional decomposition of the LSI into lengthmeasurement and temperature-regulation subsystems: f : LengthSys, TempSys → LSI. These are coupled via (the index of refraction of) a laser interaction and linked to interactions at the system boundary. The operation f specifies the connections between blue and black boundaries.
Composition in a wiring diagram operad is defined by nesting. For this functional decomposition, two further decompositions l and t describe the components and interactions within LengthSys and TempSys, respectively. The wiring diagram in figure 4 is the composite f(l, t).
This approach cleanly handles multiple decompositions. Here, the red boxes define a second, control-theoretic decomposition g : Sensors, Actuators → LSI. Unsurprisingly, the system is tightly coupled from this viewpoint, with heat flow to maintain the desired temperature, mechanical action to modify the path of the laser and a feedback loop to maintain the position of the optical focus based on measured intensity. The fact that these two viewpoints specify the same system design is expressed by the equation: f(l, t) = g(s, a); see §2c for related discussion.
Relative probabilities compose by multiplication. This allows us to compute more complex distributions for nested diagrams. For the operation shown in figure 4, this indicates that the bath leads to nearly half of all errors (60% × 80% = 48%) in the system.
Operad equations must be preserved in the semantics. Since f(l, t) = g(s, a), failure probabilities of source components do not depend on whether we think of them in terms of functionality or control. For the bath, this relative failure probability is

(c) Interacting semantics
Its toy-example simplicity aside, the formulation of a failure model W → Prob, as in table 3 is limited in at least two respects. First, it tells us which components fail, but not how or why. Second, the model is static, but system diagnosis is nearly always a dynamic process. We give a high-level sketch of an extended analysis to illustrate the integration of overlapping functorial models.
The first step is to characterize some additional information about the types in W (i.e. system boundaries). We start with the dual notions of requirements and failure modes. For example, in the temperature regulation subsystem of the LSI, we have Requirements at different levels of decomposition are linked by traceability relations. These subsystem requirements trace up to the measurement uncertainty for the LSI as a whole. Dually, an out-of-band temperature at the subsystem level can be traced back to a bad measurement in the Box enclosure, a short in the Bath heater or fluctuations in the Lab environment. Traceability is compositional: requirements decompose and failures bubble up. This defines an operad algebra 5 Req : W → Rel + . Functoriality expresses the composition of traceability requirement across levels. See ( [49], 5) for discussion of how to link these relations with table 3 data.
For dynamics, we need state. We start with a state space for each interaction among components. For example, consider the laser interaction coupling Chassis, Intfr and Box. The most relevant features of the laser are its vacuum wavelength λ 0 and the ambient temperature, pressure and humidity (needed to correct for refraction). This corresponds to a four-dimensional state-space (or a subset thereof) A larger product defines an external state space at each system boundary

State(TempSys)
The projections from these (partial) products form a relation, and these compose to define a functor W →   There is a functor Context : Ent → Rel × , which extracts the relation across the bottom row of each entailment. Noting that the State relations occur in the validity entailment, we can reformulate requirement specification as a lifting problem (figure 8a): given functors State and Context, find a factorization Val making the triangle commute. The second and third diagrams (figure 8b,c) show how to extend the lifting problem with prior knowledge, in this case a top-level requirement and a known (e.g. off the shelf) component capability. Finally, we are ready to admit dynamics, but it turns out that we have already done most of the work. All that is needed is to modify the spaces attached to our interactions. In particular, we can distinguish between static and dynamic state variables; for the laser, T, P and RH are dynamic while λ 0 is static. Now we replace the static values T, P, RH ∈ R by functions T(t), P(t), RH(t) ∈ R τ , thought of as trajectories through the state space over a timeline t ∈ τ . For example, we have From this, we construct Traj : W → Rel × using exactly the same recipe as above. Trajectories and states are related by a pair of algebra homomorphisms inst and const. The first picks out a instantaneous state for each point in time, while the second identifies constant functions, which The problem is that the state space explodes; function spaces are very large. Nonetheless, all of the system integration logic is identical, and using the entailment operad Ent, we can build in additional restrictions to limit the search space. In particular, we can restrict attention to the subset of functions that satisfies a particular differential equation or state-transition relationship. This drastically limits the set of valid trajectories, though the resulting set may be difficult to characterize and the methods for exploring it will vary by context.

Automated synthesis with network operads
An operad acting on an algebra provides a starting point to automatically generate and evaluate candidate designs. Formally correct designs (operations in some operad) combine basic systems (elements of some algebra of that operad) into a composite system.

(a) Sailboat example
Consider the sailboat problem introduced in §3a and revisited in §4b,c. Network operads describe assets and ports carrying each other while algebra-based semantics guided the search for effective designs by capturing the impact of available search effort.
To apply this model to automate design synthesis, algorithms explored designs within budget constraints based on costs in table 2. Exploration iteratively composed up to budget constraints and operational limits on carrying. 7 With these analytic models, greater sophistication was not needed; other combinatorial search algorithms-e.g. simulated annealing-are readily applied to large search spaces. The most effective designs could ferry a large number of low-cost SAR units-e.g. quadcopters (QD)-quickly to the scene, e.g. via helicopters (Helo).

(b) Tasking example
Surprisingly, network operads-originally developed to design systems-can also be applied to 'task' them: in other words, declare their behaviour. An elegant example of this approach is given in [41] where 'catalyst' agents enable behavioural options for a system.

(i) The SAR-tasking problem
The sailboat problem is limited by search: once sailboat crew members are found, their recovery is relatively straightforward. In hostile environments, recovery of isolated personnel (IP) can become very complex. The challenge is balancing the time criticality of recovery with the risk to the rescuers by judiciously orchestrating recovery teams. 8 Consider the potential challenges of a large-scale earthquake during severe drought conditions that precipitates multiple wildfires over a large area. The 2020 Creek Fire near Fresno, CA required multiple mass rescue operations (MROs) to rescue over 100 people in each case by pulling in National Guard, Navy and Marine assets to serve as search and rescue units (SRUs) [82,83]. Though MRO scenarios are actively considered by US SAR organizations, the additional challenge of concurrent MROs distributed over a large area is not typically studied.
In this SAR-tasking example, multiple, geographically distributed IP groups compete for limited SRUs. The potential of coordinating multiple agent types-e.g. fire-fighting airplanes together with helicopters-to jointly overcome environment risks is considered as well as aerial refuelling options for SRUs to extend their range. Depending on available assets, recovery demands and risks, a mission plan may need to work around some key agent typese.g. refuelling assets-and maximize the impact of others, e.g. moving protective assets between recovery teams.
Under CASCADE, tasking operations were built up from primitive tasks that coordinate multiple agent types to form a composite task plan. Novel concepts to coordinate teams of SRUs are readily modelled with full representation of the diversity of potential mission plan solutions.
(ii) Network models for tasking A network model for tasking defines atomic agent types C and possible task plans for each list of agent types. Whereas a network model to design structure Γ : S(C) → Mon has values that are possible graphical designs, a network model to task behaviour Λ : S(C) → Cat has values that are categories whose morphisms index possible task plans for the assembled types; compare, e.g. ( [41], Thm. 9). Each morphism declares a sequence of tasks for each agent, many of which will be coordinated with other agents.
If the system is comprised of only a single UH-60 helicopter, its possible tasks are captured in Λ(UH60). In this application, these tasks are paths in a graph describing 'safe manoeuvres'. and tasks for another UH-60 (right coordinate), define the corresponding joint tasking of the pair. Here, the joint tasking is: each UH-60 operates independently within the safe graph. On the other hand, tasks in Λ(UH60 ⊗ UH60) to manoeuvre in unsafe regions cannot be constructed from independent taskings of each UH-60. Such tasks must be set for some pair or other allowed team, e.g. a CH-47 teamed with an UH-60.
(iii) Applying the cookbook: operads While the above discussion sketches how to specify a network model for tasking, which constructs a network operad [40], these precise details [84] need not concern the applied practitioner. 9   is sufficient to provide a Petri net as a template, from which a network operad is constructed. Whereas a template to design structures defines the basic ways system types can interact, a template to task behaviour defines the primitive tasks for agent types C, which are token colours in the Petri net.
No specification of 'staying put' tasks are needed; these are implicit. All other primitive tasks are (sparsely) declared. For example, each edge of the 'safe graph' for a solo UH-60 declares: (1) a single agent of type UH60 participates in this 'traverse edge' task; and (2) participation is possible if a UH60 is available at the source of the edge. Likewise, each edge of the 'unsafe graph' for pairs of UH-60s should declare similar information for pairs, but what about operations to refuel an UH-60 with a HC-130? It turns out that transitions in a Petri net carry sufficient data [41,84] and have a successful history of specifying generators for a monoidal category [55,85,86]. The Petri net figure 9a shows examples where, for simplicity, tasks to traverse edges are only shown in the left to right direction. This sparse declaration is readily extended, e.g. to add recovery focused CH-47s, which tested their operational limits to rescue as many as 46 people during the 2020 Creek Fire-C and the set of transitions are augmented to encode the new options for primitive tasks.
This specification of syntax is almost sufficient for the SAR-tasking problem and would be for situations where only the sequence of tasks for each agent needs to be planned. When of each colour; see, e.g. figure 9a. Compared with ( [41], Thm. 9), C corresponds to token colours, rather than catalysts ( [41], Def. 6), and species index discrete coordination locations. Target categories encode allowed paths for each atomic agent type, e.g. for figure 9a Λ(UH60) is (freely) generated by objects {a, b, c, d} and morphisms τ 1 : a → c and τ 2 : b → c, whereas Λ(HC130)  is just by generated {a, b, c, d} since no transition involves a single HC130. By describing each target category as an appropriate subcategory of a product of path categories, the symmetric group action is given permuting coordinates, which allows the role of each atomic agent in a task to be specified. tasking SAR agents, when tasks are performed is semantically important because where and how long air-based agents 'stay put' impacts success: (1) fuel burned varies dramatically for ground versus air locations; and (2) risk incurred varies dramatically for safe versus unsafe locations. For comparison, in a ground-based domain without environmental costs, these considerations might be approximately invariant relative to the time tasks occur, and therefore, can be omitted from tasking syntax.
Timing information creates little added burden for building a template-transitions declaring primitive tasks need only be given durations derivable from scenario data-and it is technically straightforward to add a time dimension to the network model.

(iv) Constraints from syntax
A direct translation of primitive tasks to decision variables for a constraint program is possible. For syntax, the idea is very simple: enforce type-matching constraints on composing operad morphisms. Here, we will briefly indicate the original mixed integer linear program developed for SAR tasking; later this formulation was reworked to leverage the scheduling toolkit of the CPLEX optimization software package.
To illustrate the concept, let us first consider the constraint program for an operad to plan tasks without time and then add the time dimension. 10 Operad types are translated to Boolean vectors m j , whose entries capture individual agents at discrete coordination locations. Parallel composition of primitive operations is expressed with Boolean vectors Σ j indexed over primitive tasks for specific agents. Type vectors m j indicate the coordination location of each agent with value one; operation vectors Σ j indicate which tasks are planned in parallel.
Assuming an operation with task vector Σ j and source vector m j , the target is m j+1 = m j + MΣ j , where M describes the relationship between source and target for primitive tasks. Rows of M correspond to primitive tasks while columns correspond to individual agents. The target to source constraint for a single step of in-series composition is m j+1 ≥ M s Σ j+1 where M s has rows that give requirements for each primitive task. Here, the LHS describes the target and the RHS describes the source. The inequality appears to allow for implicit identities for agents without tasking, e.g. if Σ j is a zero vector, then m j+1 = m j . This constraint prevents an individual agent from being assigned conflicting tasks or 'teleporting' to begin a task.
As seen in figure 9b, additional agents: (1) enable more primitive tasks, indexed by Petri net transitions (top two rows); and (2) expand the type vector/matrix column dimension to account for new agent-location pairs and increase the matrix row dimension to account for new tasks (bottom two rows). For example, the first four rows of M(UH60 ⊗ UH60) correspond to the image of Λ(UH60) × Λ(UH60) in Λ(UH60 ⊗ UH60). The last row corresponds to a new task, τ 4 , for the available pair of UH-60s. During implementation, the constraints can be declared task-bytask/row-by-row to sparsely couple the involved agents. Once a limit on the number of steps of in series composition is set-i.e. a bound for the index j is given-a finite constraint program is determined.
Time is readily modelled discretely with tasks given integer durations. This corresponds to a more detailed network model, Λ t , whose types include a discrete time index; see figure 5b for example operations. Under these assumptions, one simply replaces the abstract steps of in series composition with a time index and decomposes M and Σ j by the duration d of primitive tasks so that Σ t,d describes tasks beginning at time t; the inequality allows for 'waiting' operations. One can also model tasks more coarsely-with Λ • : N(C) → Cat-to construct an operad to task counts of agents without individual identity. Then, the type vectors m j (resp., operation vectors Σ j ) have integer entries to express agent counts (resp., counts of planned tasks) with corresponding reductions in dimensionality. These three levels of network models naturally induce morphisms of network operads 11 ([40], 6.18) and encode mappings of syntactic variables that preserve feasibility. In particular, the top two levels describe a precise mapping from task scheduling (highest) to task planning (middle). The lowest level Λ • forgets the individual identity of agents, providing a coarser level for planning. This very simple idea of enforcing type-matching constraints is inherently natural. 12 However, further research is needed to determine if this natural hierarchical structure can be exploited by algorithms-e.g. by branching over pre-images of solutions to coarser levels-perhaps for domains where operational constraints coming from algebras are merely a nuisance, as opposed to being a central challenge for SAR planning. For instance, a precise meta-model for planning and scheduling provides a common jumping off point to apply algorithms from those two disciplines.
(v) Applying the cookbook: algebras Because the operad template defines generating operations, specifying algebras involves: (1) capturing the salient features of each agent type as its internal state; and (2) specifying how these states update under generating morphisms, including, for operads with time, the implicit 'waiting' operations. For the SAR-tasking problem, the salient features are fuel level and cumulative probability of survival throughout the mission. Typical primitive operations will not increase these values; fuel is expended or some risk is incurred. The notable exception is refuelling operations, which return the fuel level of the receiver to maximum. By specifying the non-increasing rate for each agent-location pair, the action of 'waiting' operations are specified. In practice, these data are derivable from environmental data for a scenario so that end users can manipulate them indirectly.

(vi) Operational constraints from algebras
Salient features of each agent type are captured as auxiliary variables determined by syntactic decision variables. The values of algebra variables are constrained by update equations, e.g. to update fuel levels for agents with max(f j + FΣ j , f max ) = f j+1 , where f max specifies max fuel capacities. Having expressed the semantics for generating operations, one can enforce additional operational constraints, e.g. safe fuel levels: f j+1 ≥ f min .

(vii) Extending the domain of application
As noted above, this sparse declaration of a tasking domain is readily extended, e.g. to add a new atomic type or new ways for agents to coordinate. Syntactically, this amounts to new elements of C or transitions to define primitive tasks. Semantics must capture the impact of primitive operations on state, which can be roughly estimated initially and later refined. This flexibility is especially useful for rapid prototyping of 'what if' options for asset types and behaviours, as the wildfire SAR-tasking problem illustrates.
Suppose, for example, that we wanted to model a joint SAR and fire-fighting problem. Both domains are naturally expressed with network operads to task behaviour. Even if the specification formats were independently developed: (1) each format must encode the essential combinatorial  (2) category theory provides a method to integrate domain data: construct a pushout. Analogous to taking the union of two sets along a common intersection, one identifies the part of the problem common to both domains-e.g. MAFFS-equipped HC-130s and their associated tasks appearing in both domains-to construct a cross-domain model The arrows in this diagram account for translating the file format for the overlap into each domain-specific format and choosing a specific output format for cross-domain data.
On the other hand, suppose that the machine readable representation of each domain was tightly coupled to algorithms, e.g. mathematical programming for SAR and a planning framework for fire fighting. There is no artefact suitable for integrating these domains since expression was prematurely optimized. We describe a general workflow to separate specification from representation and exploitable data structures and algorithms in §7e.

(c) Other examples of automated synthesis
Though network templates facilitate exploration from atoms, how to explore valid designs is a largely distinct concern from defining the space of designs, as discussed in §1.

(i) Novel search strategies via substitution
For example, in the DARPA Fundamentals of Design (FUN Design) program, composition of designs employed a genetic algorithm (GA). FUN Design focused on generating novel conceptual designs for mechanical systems, e.g. catapults to launch a projectile. Formulating this problem with network operads followed the cookbook approach: there were atomic types of mechanical components and basic operations to link them.
The operad-based representation provided guarantees of design feasibility and informed how to generalize the GA implementation details. Specifically, composition for atomic algebra elements defined genetic data; crossover produced child data to compose from atoms; and mutation modified parameters of input algebra elements. Crafting a crossover step is typically handled case-by-case while this strategy generalizes to other problems that mix combinatorial and continuously varying data, provided these data are packaged as an operad acting on an algebra. Guarantees of feasibility dramatically reduced the number unfit offspring evaluated by simulation against multiple fitness metrics. Moreover, computational gains from feasibility guarantees increase as the design population becomes more combinatorially complex.

(ii) Integrated structure and behaviour
Large classes of engineering problems compose components to form an 'optimized' network, e.g. in chemical process synthesis, supply chains and water purification networks [87][88][89][90]. Given a set of inputs, outputs and available operations (process equipment with input and output specification), the goal is to identify the optimal state equipment networks for behavioural flows of materials and energy. A given production target for outputs is evaluated in terms of multiple objectives such as environmental impact and cost. For example, the chemical industry considers the supply chain, production and distribution network problem [90] systematically as three superstructure optimization problems that can be composed to optimize enterprise level, multi-subsystem structures. Each sub-network structure is further optimized for low cost and other metrics including waste, environmental impact and energy costs. The operadic paradigm would provide a lens to generalize and refine existing techniques to jointly explore structure and behaviour. CASCADE prototyped integrated composition of structure and behaviour for distributed logistics applications. Here, an explicit resupply plan to task agents was desired. Structural composition was needed to account for the resupply capacity for heterogeneous delivery vehicles and the positioning of distributed resupply depots. Probabilistic models estimated steady state resupply capacities of delivery fleet mixes to serve estimates of demand. First, positioning resupply locations applied hill climbing to minimize the expected disruption of delivery routes when returning to and departing from resupply locations. Second, this disruption estimate was used to adjust the resupply capacity estimate of each delivery asset type. Third, promising designs where evaluated using a heuristic task planning algorithm. At each stage, algorithms focused on finding satisficing solutions which allowed broad and rapid explorations of the design and tasking search space.
In the next section, we discuss research directions to develop the meta-modelling potential of applied operads to: (1) decompose a problem within a semantic model to divide and conquer; and (2) move between models to fill in details from coarse descriptions. We also discuss how the flow of representations used for SAR-network template, operad model of composition, exploitation data structures and algorithms-could be systematized into a reusable software framework.

Towards practical automated analysis and synthesis
In this section, we describe lessons learned from practical experiences with applying operads to automated synthesis. We frame separation of concerns in the language of operads to describe strategies to work around issues raised by this experience. This gives not only a clean formulation of separation but also a principled means to integrate and exploit concerns.

(a) Lessons from automated synthesis
The direct, network template approach facilitates correct and transparent modelling for complex tasking problems. However, computational tractability is limited to small problems, relative to the demands of applications. More research is needed to develop efficient algorithms that break up the search into manageable parts, leveraging the power of operads to separate concerns.
Under CASCADE, we experimented with the CPLEX scheduling toolkit to informally model across levels of abstraction and exploit domain-specific information. In particular, generating options to plan, but not schedule, key manoeuvres with traditional routing algorithms helped factor the problem effectively. These applied experiments were not systematized into a formal meta-modelling approach, although our prototype results were promising. Specification of these levels-as in §4-and controlling the navigation of levels using domain-specifics would be ideal.
The FUN DESIGN genetic algorithm approach illustrates the potential operads have to: (1) generalize case-by-case methods 13

(b) Formal separation of concerns
We begin by distinguishing focus from filter, which are two ways operads separate. Focus selects what we look at, while filter captures how we look at it. These are questions of syntax and semantics, respectively. To be useful, the what of our focus must align with the how of the filter.
Separation of focus occurs within the syntax operad of system maps. In §2a, four trees correspond to different views on the same system. We can zoom into one part of the system while leaving other portions black-boxed at a high level. Varying the target type of an operation changes the scope for system composition, such as restricting attention to a subsystem.
Filtering, on the other hand, is semantic; we choose which salient features to model and which to suppress, controlled by the semantic context used to 'implement' the operations. As described in §5b, the default semantic context is Set where: (1) each type in the operad is mapped to a set of possible instances for that type; and (2) each operation is mapped to a function to compose instances. Instances or algebra elements for the sailboat problem ( §4) describe the key features of structural system designs. For SAR tasking ( §6), mission plan instances track the key internal states of agents-notably fuel and risk-throughout its execution. Section 5 illustrates alternative semantic contexts as such probability Prob or relations between sets Rel.
Focus and filter come together to solve particular problems. The analysis of the LSI system in §5 tightly focuses the syntax operad W to include only the types and operations from figure 4. Formally, this is accomplished by considering the image of the generating types and operations in the operad of port-graphs ( [49], 3). This tight focus means semantics need only be defined for LSI components. In each SAR-tasking problem of §6, an initial, source configuration of agent types is given, narrowing the focus of each problem. The SAR focus is much broader because an operation to define the mission plan must be constructed. Even so, semantics filter down to just the key features of the problem and how to update them when generating operations act.
Functorial semantics, as realized by an operad algebra A : O → Sem, helps factor the overall problem model to facilitate its construction and exploitation. For example, we can construct the probabilistic failure model in table 3 by normalizing historical failures. First, we limit focus from all port-graphs P to W then semantics for counts in N + , an operad of counts and sums, are normalized to obtain probabilities in Prob: The power to focus and filter is amplified because we are not limited by a single choice of how to filter. In addition to limiting focus with the source of an operad algebra, we can simplify filters. Such natural transformations between functors are 'filters of filters' that align different compositional models precisely, e.g. requirements over state ( §5c) or timed scheduling over two levels of planning ( §6b). In this first case, the syntax operad W stays the same and semantics are linked by an algebra homomorphism ( §2d). In the second case, both the operad and algebra must change to determine simpler semantics, e.g. to neglect the impact of waiting operations, which bound performance. Such precision supports automation to explore design space across semantic models and aligns the ability to focus within each model. By working backward relative to the construction process, we can lift partial solutions to gradually increase model fidelity, e.g. exploring schedules over effective plans. This gives a foundation for lazy evaluation during deep exploration of design space, which we revisit in §7e.
For a simple but rich example of these concepts working together, consider the functional decomposition f(l, t) in figure 4. We could model the length system l using rigid-body dynamics, the temperature system t as a lumped-element model and super-system f as a computation (Edlén equation) that corrects the observed fringe count based on the measured temperature: The upper and lower paths construct implementations of dynamical models based on the aforementioned formalisms. The centre path implements a correction on the data stream coming from the interferometer, based on a stream of temperature data. The two natural transformations indicate extraction of one representation, a stream of state values, from the implementation of the dynamical models. Composition in W then constructs the two data streams and applies the correction.
A key strength of the operadic paradigm is its genericity: the same principles of model construction, integration and exploitation developed for measurement and SAR apply to all kinds of systems. In principle, we could use the same tools and methodology to assemble transistors into circuits, unit processes into chemical factories and genes into genomes. The syntax and semantics change with the application, but the functorial perspective remains the same. For the rest of this section, we describe research directions to realize such a general purpose vision to decompose a complex design problem into subproblems and support rapid, broad exploration of design space.

(c) Recent advancements, future prospects and limits
Progress driven by applications. Section 4 describes how cookbook-style approaches enable practitioners to put operads to work. Generative data define a domain and compositionality combines it into operads and algebras to separate concerns. Network operads [40][41][42] were developed in response to the demands of applications to construct operads from generative data. Section 5 describes rich design analysis by leveraging multiple decompositions of complex systems and working across levels of abstraction. Focusing on a specific applied problem-the LSI at NIST-provided further opportunities for analysis since model semantics need only be defined for the problem at hand; see also equation (7.1). Progress in streamlining automated synthesis from building blocks is recounted in §6 where the domain drives coordination requirements to task behaviour.
Prospects. If interactions between systems are well-understood (specification) and can be usefully modelled by compositional semantics (analysis), then automated design synthesis leveraging separation for scalability becomes possible. For instance, most references from the end of §5 correspond to domains that are studied with diagrams that indicate interactions and have associated compositional models. This allows intricate interactions to be modelled-compare, e.g. classical [18] versus quantum [75,76,103] computing-while unlocking separation of concerns. Cookbook and focused approaches guide practitioners to seek out the minimal data needed for a domain problem-as in the examples presented-but operads for design require compositional models.
Limitations. We note three issues limiting when operads apply: (1) key interactions among systems and components are inputs; (2) not all design problems become tractable via decomposition and hierarchy; and (3) there is no guarantee of compositional semantics to exploit. For instance, though the interactions for the n-body problem are understood (1), this does not lend itself to decomposition (2) [20] notes that integral mechanical system design must address safety issues at high power levels due to challenging, long-range interactions. Some aspects of mechanical system design may yield to operad analysis-e.g. bond graphs [57] or other sufficiently 'diagrammatic' models-but others may not.
Both examples illustrate how overnumerous or long-range interaction can lead to (2). Operads can work at the system rather than component level if system properties can be extracted into compositional models. However, operads do not provide a means to extract such properties or understand problems that are truly inseparable theoretically or practically.

(d) Research directions for applied operads
We now briefly overview research directions toward automated analysis and synthesis.
Operad-based decomposition and adaptation. Decomposition, ways a complex operation can be broken down into simpler operations, is a dual concept to the composition of operations. Any subsystem designed by a simpler operation can be adapted: precisely which operations can be substituted is known, providing a general perspective to craft algorithms. To be practical, the analytic questions of how to decompose and when to adapt subsystems must be answered.
One research direction applies the lens of operad composition to abstract and generalize existing algorithms that exploit decomposition, e.g. to: (1) generalize superstructure optimization techniques discussed in §6c; (2) extend the crossover and mutation steps for the FUN DESIGN work §7a, which are global in the sense that they manipulate full designs, to local steps which adapt parts of a design, perhaps driven by analysis to re-work specific subsystems; and (3) explore routing as a proxy for tasking planning, analysing foundational algorithms like Ford & Fulkerson [104] and decomposition techniques such as contraction hierarchies [105]. An intriguing, but speculative, avenue is to attempt to learn how to decompose a system or select subsystems to adapt in a data-driven way, so that the operad syntax constrains otherwise lightly supervised learning. A theoretical direction is to seriously consider the dual role of decomposition, analogous to Hopf and Frobenius algebra [106], and attempt to gain deeper understanding of the interplay of composition and decomposition, eventually distilling any results into algorithms. 14 Multiple levels of modelling. The LSI example shows how a system model can be analysed to address different considerations. This sets the stage to adapt a design-e.g. bolster functional risk points and improve control in back and forth fashion-until both considerations are acceptable. Applied demonstrations for SAR tasking suggest a multi-level framework: (1) encoding operational concepts; (2) planning options for key manoeuvres; and (3) multi-stage planning and scheduling to support these manoeuvres.
Unifying top-down and bottom-up points of view. We have laid out the analytic-exemplified by wiring diagrams-and synthetic-exemplified by network operads-points of view for complex systems. Even if the goal is practical automated synthesis, scalability issues promote analytic decomposition and abstraction to efficiently reason towards satisficing solutions. Two approaches to unification include: (1) create a combined syntax for analysis and synthesis, a 'super operad' combining both features; and (2) act by an analytic operad on the synthetic syntax, extending composition of operations. While the former approach is arguably more unified, the latter more clearly separates analysis and synthesis and may provide a constructive approach to the former.

(e) Functorial programming with operads
At this point, experience implementing operads for design suggests a software framework. While conceptually simple, this sketch helps clarify the practical role of a precise meta-model.
Rather than working directly with operads to form a core meta-modelling language, cf. [14], a workflow akin to popular frameworks for JavaScript development would put developers in the driver's seat: adopters focus on controlling the flow of data and contribute to an ecosystem  Figure 10. A software framework to leverage a meta-model: templates define each level and how to move between, libraries exploit each level, and core meta-model facilitates control across levels.
of libraries for lower-level data processing. Achieving this requires work before and after the meta-model. First, transferable methods get an applied problem into operads (figure 10, left). As in §4, these data construct operads and algebras to form the core meta-model. Core data feed explicitly exploitable data structures and algorithms to analyse ( §5) and automatically construct ( §6) complex systems (figure 10, right). On the far left, end user tools convert intent to domain inputs. Rightmost, libraries access exploitation data structures and algorithms, including those exploiting the syntax and semantics separation or substitution and adaptation. At the centre, the core meta-model guarantees that the scruffier ends of the framework exposed to end users and developers are correctly aligned and coherently navigated. This framework provides significant opportunities to separate concerns compared with other approaches. Foremost, the core model separates syntax from semantics. As noted in §1, applied methods tend to conflate syntax and semantics. For instance, aggregate programming [107] provides: (1) semantics for networked components with spatial and temporal extent; and (2) interactions are proximity-based. The former feature is powerful but limiting: by choosing a single kind of semantics, modelling is wedded to the scales it abstracts well. The individual component scale is not modelled, even syntactically, which would complicate any attempt to align with other models. The latter precludes syntactic declaration of interactions-e.g. to construct architectures not purely based on proximity-and the absolute clarity about what can be put together provided by the operad syntax. Relative to computational efforts to apply operads or monoidal categories, e.g. [95,96,98], this sketch places greater emphasis on specification and exploitation: specification of a domain is possible without exposing the meta-model, algorithms searching within each model are treated as black boxes that produce valid designs. Separate specification greatly facilitates set up by experts in the domain, but not the meta-model. Separate exploitation encourages importing existing data structures and algorithms to exploit each model.

(f) Open problems
The software framework just sketched separates out the issues of practical specification, metamodelling and fast data structures and algorithms. We organize our discussion of open problems around concrete steps to advance these issues. In our problem statements, 'multiple' means at least three to assure demonstration of the genericity of the operadic paradigm.
Practical specification. The overarching question is whether the minimal combinatorial data, which can specify operads, their algebras and algebra homomorphisms in theory, can be practically implemented in software. We propose the following problems to advance the stateof-the-art for network template specification of operads described in §4: (i) Demonstrate a specification software package for operad algebras for multiple domains. (ii) Develop specification software for algebra homomorphisms to demonstrate correctly aligned navigation between multiple models for a single domain. This last point is in line with the discussion of extending a domain in §6b and motivates a need to reconcile independently developed specification formats.
(iv) Demonstrate automatic translation across specification formats. Core meta-model. As a practical matter, state-of-the-art examples exercise general principles of the paradigm but do not leverage general purpose software to encode the meta-model.
(v) Develop and demonstrate reusable middleware to explicitly encode multiple semantic models and maps between them which (a) takes inputs from specification packages; and (b) serves as a platform to navigate models.
We have seen rich examples of focused analysis with wiring diagrams in §5 and automated composition from building blocks in §6. Theoretically, there is the question of integrating the top-down and bottom-up perspectives: (vi) Develop unified foundations to integrate: (a) analytic and synthetic styles of operads; and (b) composition with decomposition.
Potential starting points for these theoretical advancements are described in §7d. Developing understanding of limitations overviewed in §7c requires engagement with a range of applications: (vii) Investigate limits of operads for design to (a) identify domains or specific aspects of domains lacking minimal data; (b) demonstrate the failure of compositionality for potentially useful semantics; and (c) characterize complexity barriers due to integrality.
Navigation of effective data structures and algorithms. Lastly, there is the question of whether coherent navigation of models can be made practical. This requires explicit control of data across models and fast data structures and algorithms within specific models. The general-purpose evolutionary algorithms discussed in §7c motivate: For this last point, isolating the impact of each way to separate concerns is of particular interest to lay groundwork to systematically analyse complex domain problems. Finally, there is the question of demonstrating an end-to-end system to exploit the operadic, meta-modelling paradigm.
(xi) Demonstrate systematic, high-level control of iteration, substitution and moving across multiple models to solve a complex domain problem. (xii) Develop high-level control framework-similar to JavaScript frameworks for UIor programming language-similar to probabilistic programming-to systematically control iteration, substitution and movement across multiple models.

Conclusion
Operads provide a powerful meta-language to unite complementary system models within a single framework. They express multiple options for decomposition and hierarchy for complex designs, both within and across models. Diverse concerns needed to solve the full design problem are coherently separated by functorial semantics, maintaining compositionality of subsystems. Each semantic model can trade-off precision and accuracy to achieve an elegant abstraction, while algorithms exploit the specifics of each model to analyse and synthesize designs. The basic moves of iteration, substitution and moving across multiple models form a rich framework to explore design space. The trade-off is that the technical infrastructure needed to fully exploit this paradigm is daunting. Recent progress has lowered barriers to specify domain models and streamline tool chains to automatically synthesize designs from basic building blocks. Key parts of relevant theory and its implementation in software have been prototyped for example applications. Further research is needed to integrate advancements in automatic specification and synthesis with the analytic power of operads to separate concerns. To help focus efforts, we described research directions and proposed some concrete open problems.
Ethics. This article does not present research with ethical considerations. Data accessibility. This article has no additional data.