A unified theory of systems and flows

We have been quietly working on a small synthesis: when you strip a process down to its essentials, what remains? We found that almost every process — biological, computational, organizational — can be reduced to three primitives. This is not a new theory; it is a vocabulary, and we are sharing it because we keep finding it useful in our own engineering work.

The three primitives are information, rules, and an executor. Information is the reason the process exists; without something to act on, no process is needed. Rules define what should happen at each step — read, write, decide where to go next. The executor is the thing that actually performs each step. Information is the meaning of a process. Rules define its ceiling. The executor decides whether that ceiling can actually be reached.

Once you accept this trio, six earlier categories that often show up in flowcharts — triggers, nodes, control flow, state, constraints, exits — collapse into a single unit: a node with a processing slot and a routing slot. A decision node has only routing. An entry node has tight input contracts. Constraints are not independent things — they are properties of the edges. Control flow is not a thing — it is the topology of the graph. The whole system becomes one shape: identical nodes, varying connections.

The next observation is that this structure is fractal. A node can expand into a subnetwork, and a stable subnetwork can be wrapped back into a single node. The condition for wrapping is stability: only stable subsystems can be safely treated as black boxes. This is exactly how working physicists treat rigid bodies, and how working mathematicians treat formulas. Newton wrapped Kepler's three laws into one equation; we wrap small reliable services into deployable units. Abstraction is not laziness — it is the deliberate decision about what no longer needs to be known at this level. Knowing what to forget is part of understanding.

Layered on top of the node model, we find six rough levels that any system can fall into: closed systems, passively open systems, actively processing systems, self-adapting systems, self-organizing systems with emergent order, and self-creating systems that produce themselves. Workflows in software belong to the third — purposeful, bounded, mostly deterministic; the system itself does not change. The interesting boundary is the fourth level: self-adaptation, which can mean changing parameters, rules, structure, or even goals. The further you climb, the harder it is to predict and the more careful the engineering needs to be.

The same trio shows up — and this is the part that surprised us — at the heart of three foundational computing models. Turing's machine (1936) is information on a tape, rules in a table, and a read-write head with no intelligence of its own. Petri nets (1962) generalize this to many concurrent processes sharing resources, with an explicit place for queueing and synchronization. Artificial neural networks (1943, learning rule 1986) keep the structure but learn the rule from data instead of writing it down. In every case: information, rules, executor. The executor is not where complexity lives — complexity lives in the rule.

Petri nets in particular taught us a lesson that is easy to miss when you only think in terms of Turing machines. The Turing model answers "what can be computed." Petri's question is different: "how do we model many things happening at once, contending for the same resources, and verify the design before we build it?" In our own systems, this is the difference between writing the code and being able to argue, before deployment, that it cannot deadlock or starve. We try to keep both questions alive when designing infrastructure.

Neural networks add a twist. The rule is no longer something a person writes; it is something the system learns by repeatedly being wrong and adjusting weights. During training, the network is a self-adapting system at the parameter level. Once deployed with frozen weights, it falls back to a purposeful, deterministic processor. The same artifact lives in two regimes depending on whether learning is active.

We find the same vocabulary helpful when reasoning about agent-based software architectures. A user request is information. A skill — a triggered, narrowly scoped behavior — is a rule. The model that runs the skill is the executor. One skill can call another, and a process becomes a network of nested processes. Whether you call this "agent orchestration" or just "modular design," the underlying shape is the same node-and-edge graph that Turing and Petri were already drawing.

There is one more lens worth holding alongside the others: thermodynamics. A working process is, locally, entropy reduction — disorder turned into order. This never happens for free. Two inputs are always required: energy to drive the work, and information to direct that energy along a specific path. The price is global: the universe gets a little hotter so that one corner can become more ordered. This is the deepest reason that compute is not free, that good engineering matters, and that abstractions are not just elegant — they are physical.

We will not pretend this synthesis is novel. It rhymes with systems theory, complex adaptive systems literature, the cybernetics tradition, and foundational work in computability. What is useful for us is having a single short vocabulary to point at. When we ask "what is this thing's information, what are its rules, who is the executor," we tend to find the parts that are unstable, the boundaries that are wrong, and the abstractions that are leaking. It is a cheap question that pays back often.

If you take only one sentence from this note: a system is identical nodes connected by configured edges; each node reads, writes, and decides; complexity is built bottom-up by stabilizing and wrapping; everything that flows is, in physical terms, a small local entropy reduction paid for by a larger global increase. Everything else is detail.