A couple of weeks ago I had the chance to attend the Mathematics for Governance Design Workshop, where we explored avenues of collaboration between social scientists and category theorists in the task of modelling social dynamics and design of governance structures. Others are writing about the open games engine, but I wanted to focus on an idea that I discussed with Michael “Z” Zargham and David Spivak about systems engineering design and lenses.

Systems engineering

In traditional systems engineering, the system requirements, design and implementation details were captured in textual documents. This often led to inconsistency and redundancy in some large projects.

The modernization to the current model-based approach was made possible among other factors by system modeling languages, such as SysML, an extension of software’s UML that allows structured, visual representation of behaviour, architecture and requirements.

In addition to traditional (by which I mean Java-centric) general system modeling languages such as Cameo Systems Modeler or ModelIO, there are many new system modeling languages emerging that serve both as a visualization tool and also leverage the foundations of systems theory (one just this month!). My aim here is to prototype a modeling language that

• has both a visual representation via string diagrams and static analysis via basic types or attributes
• aids in the concept design and concept selection steps of the project’s lifecycle.

System processes as lenses

Design interfaces seem to always be bidirectional: there are some requirements as inputs, and value/products as outputs. The sketch that “Z” showed me was something like the following:

where the high level interface on the left gets translated to a low level interface on the right. An example is NASA’s “Systems Engineering Engine”, which can be depicted in some greater detail as:

where the two maps refer to processes related to “system design”, and “product realization & technical management”. One structure originating in functional programming with this interface is a lens. A lens from an interface ${A\choose B}$ to another ${C\choose D}$, written $\lambda\in\mathrm{Lens}({A\choose B},{C\choose D})$, is a bidirectional map characterized by a forward map $v:A\to C$ and a backward map $u:A\times D\to B$. They form a monoidal category, and have a formal graphical syntax similar to the one shown above. Their parallel (monoidal) composition serves as juxtaposition of independent subprocesses, and sequential composition acts as a “wrapper interface”.

Consider a set of requirements $R$ for an expected product $P$. One may know that $R$ can be decomposed into two independent sets of requirements $S_1,S_2$, for subproducts $Q_1,Q_2$ respectively. Suppose these two processes of creating the subproducts $Q_1,Q_2$ out of $S_1,S_2$ cannot be decomposed further, and we know how to create them (e.g. the definition of functions $u_i:S_i\to Q_i$ is known). These can be encoded as $\mathrm{Lens}({R\choose P},{S_1\times S_2\choose Q_1\times Q_2})$ composed with $\mathrm{Lens}({S_i\choose Q_i},{1\choose 1})$, depicted in the following diagram:

This coupling the feedback of execution to the process itself has two effects:

• an overhead to the process design. Every process that transforms a product’s requirement into smaller pieces has to describe how the subproducts realization satisfy the initial requirement.
• a simplification of some requirement verifications by composition of compatible interfaces. It modularizes the question “Does this system satisfy the stakeholder’s requirements?” into subproblems of checking whether the definition of the functions $u_i$ satisfy their declared type $S_i\to Q_i$.

My conjecture is that the improvements coming from the second point overcome the overhead of the first in concept design. Specialization from function to form. As with every framework, its misuse or application outside its intended scope might lead to redundant or unnatural boilerplate, but it forces at least to think about every components intended purpose and contribution to the overall goal.

Lenses in Poly and dynamic wiring diagrams

The second point to address is the aid in concept design and selection. Once a system model is defined, the verification process is straight forward, but how do we come up with the model itself? One possibility is to define an initial guess of a wiring diagram like the one above and define rewiring operations (e.g. to optimize some metric). In the framework of $\mathrm{Poly}$, this corresponds to the horizontal morphisms of $\mathbb{O}\mathrm{rg}$, i.e. $[p,q]$-coalgebras, which were introduced to model “dynamic wiring diagrams” by Shapiro and Spivak [1].

The usual way of understanding the relation between $\mathrm{Lens}$ and $\mathrm{Poly}$ is by the traditional “data-accessor” interpretation of lenses, which correspond to wiring diagrams: for a lens $\lambda:{A\choose B}\rightleftarrows{C\choose D}$, it’s forward map $v$ views part $B$ of a data structure $A$, and it’s backward map $u$ updates the datastructure $A$ with a new part $D$. This is exactly a morphism $Ay^B\to Cy^D$ in $\mathrm{Poly}$. The last string diagram above might be written as the composition of $\mathrm{Poly}(Ry^P,S_1y^{Q_1}\otimes S_2y^{Q_2})$ with $\mathrm{Poly}(S_iy^{Q_i},y)$.

However, I want to make explicit the constructor of lenses internally to $\mathrm{Poly}$, by considering the morphism $$ \mathrm{mkLens}:\mathrm{Poly}(Cy^A\otimes By^{AD}, CBy^{AD}) $$ $\mathrm{mkLens}(v,u)$ is a monomial with inputs (positions) $C\times B$ and outputs (directions) $A\times D$ arising from the composition of a view map $v\in Cy^A$ and an update map $u\in By^{AD}$, i.e. as the image of a particular wiring diagram that sends $(v,u)\mapsto A^2y^A\triangleleft (v\otimes u)$.

The reason for this embedding of lenses is to make a distinction between morphisms in $\mathrm{Poly}$ that are structural, and others that are computational. Given a set of $I$ different subprocesses/legacy products/COTS components (one might call it a “knowledge base”), a dynamical system that enables concept selection would be the morphism:

$$ Sy^S \to [\bigotimes_{i\in I}\mathrm{mkLens}(v_i,u_i), Ry^P] $$

This is an example of a $[p,q]$-coalgebra.

API and search heuristics

This sketches an idealized tool where the user provides pairs of (process, feedback) that get converted to a lens wiring diagram. The proposed composition of them would be the initial state of the $[p,q]$-coalgebra. The tool then checks the type compatibility between them, and suggests alternative wirings via the coalgebra evolution.

The difficulties from both the practice and theory sides are aligned:

• Composition of system processes is “easy”: verifying that certain processes achieve an overall requirements specification is modularized, and is realized by construction if formalized via a rich enough type system.
• Decomposition of system processes is hard: coming up with a suitable set of processes that accomplish an initial task is performed by heuristics from an experienced systems engineer, and in theory it is a search problem as hard as the word problem.

However, this last point might in practice not be as hard as it sounds; while for randomly generated system processes it might be hard, the system processes designed by engineers are hardly random. Incorporating search heuristics from experts also has a compounding benefit over development of similar products. Reducing the search space and approximating solutions via search heuristics from experts and Deep Learning methods are also strategies employed in many other fields that can be applicable here too.

Just the type compatibility would be a modernization of current system modeling tools. But building new tools is not always the most important part; one creates an ecosystem which might be efficient internally, but what use does it have to outsiders? This was one of the motivations that got me into category theory in the first place. While in some fields this can only be done by being efficient communicators, applied category theory has some tools to tackle this problem in a slightly more systematic way, and it is something that I find beautiful about parsers, compilers, and learning other human languages.