Processes and Concurrent Behavior

So far, we have described systems as collections of facts, rules, effects, and invariants that evolve over time and under uncertainty.

But we have treated each system as a single, unified whole — one set of facts, one set of transitions.

Real systems are rarely so monolithic.

Systems Are Made of Parts

Consider our Asset System in practice.

There is not one agent performing one action at a time. There are multiple agents — buyers, sellers, regulators, automated services — each operating concurrently, each with their own view of the system.

A buyer initiates a transfer while a regulator reviews an audit. An automated service processes approvals while another agent updates asset metadata. These activities overlap in time, interact through shared state, and must coordinate to maintain consistency.

To model this faithfully, we need to think about processes.

From Effects to Processes

In earlier posts, effects described what actions are possible. A single effect like TransferOwnership represents one action within one transition.

A process is a richer concept: it describes a pattern of behavior over time — a sequence of actions, choices, and communications that an agent may perform.

For example:

• A buyer process: request transfer, wait for approval, receive confirmation or rejection
• An approval process: receive request, check policy, respond with decision
• An audit process: periodically inspect state, flag violations, report

Each of these is a structured description of behavior — not a single action, but a pattern of interaction.

Communication and Synchronization

When multiple processes operate concurrently, they must communicate.

The buyer sends a transfer request. The approval service receives it, evaluates it, and sends a response. These two processes synchronize at the point of communication.

This is a fundamental concept from process algebra: systems are composed of processes that interact through channels, and the behavior of the whole emerges from the behavior of its parts.

In Spine, communication between processes is explicit and typed. A process that sends a transfer request must match a process that expects one. The types of messages, the ordering of interactions, and the conditions under which communication occurs are all part of the system's definition.

Nondeterminism and Choice

Concurrent systems introduce a kind of nondeterminism that goes beyond uncertainty.

In a probabilistic system, outcomes have likelihoods. In a concurrent system, the order in which processes execute may be genuinely undetermined — not because of randomness, but because of scheduling, distribution, or independence.

A process may face a choice: accept a transfer request or handle a cancellation, whichever arrives first. The system must be correct regardless of which path is taken.

This requires reasoning about all possible interleavings of concurrent actions — not just one execution, but every way the processes might combine.

Behavioral Equivalence

Once processes are explicit, we can ask a powerful question: do two processes behave the same way?

This is not about whether they have the same code. It is about whether, from the perspective of any observer, they produce the same interactions.

For example: a manual approval process and an automated one may behave identically — same inputs, same outputs, same ordering — even though their internal structure differs.

This notion of behavioral equivalence allows us to reason about substitution: if two processes are equivalent, one can replace the other without affecting the rest of the system.

This is directly relevant to refactoring, optimization, and evolving systems over time.

Deadlock, Livelock, and Progress

Concurrent systems bring specific failure modes that sequential systems do not have.

Deadlock: two processes each wait for the other, and neither can proceed.

Livelock: processes keep acting but make no progress toward a goal.

Starvation: one process is perpetually denied access to a shared resource.

Because Spine makes processes and their interactions explicit, these properties become checkable. The system can verify that deadlock is impossible, that every process eventually makes progress, and that no agent is permanently excluded.

Processes in the Asset System

Let's extend our example.

We model the transfer workflow as a composition of processes:

• A transfer process that consumes an ownership fact and produces a new one
• An approval process that gates the transfer based on policy
• A notification process that informs affected parties

These processes run concurrently. The transfer cannot complete until approval is granted. Notification happens after completion. The composition is explicit, and the system can verify that the overall workflow preserves all invariants.

Connecting to Effects and Rules

Processes do not replace effects — they organize them.

An effect is a single action. A process is a structured sequence of effects, choices, and communications. Rules still constrain what each effect can do. Invariants still hold across all transitions.

What processes add is the ability to describe how multiple agents coordinate their effects over time.

A Subtle Shift

With processes in place, the system gains another dimension.

We no longer describe a system as one evolving whole. We describe it as a composition of concurrent behaviors — each with its own structure, interacting through explicit channels, and collectively maintaining the system's properties.

This shifts the perspective once more: from what a system does, to how its parts work together.

Looking Ahead

Processes describe how agents behave and interact. But they do not yet describe where things are.

In the next post, we will explore spatial structure: how processes, agents, and facts can be organized in space — nested, adjacent, or distributed — and how the structure of containment and proximity shapes what is possible.