Process

designed

A Process is the value-unit primitive: software that fulfils a high-level user intention into a high-value result — reproducible, auditable, observable — kept as an inspectable object the operating system can execute again. As if a bespoke executable existed for every job a computer is ever asked to do.

Nothing on this page is built. There is no binary, no verb, no line here you can copy — the other three primitives are exercised software and this one is a design designed. It is on the floor’s list anyway, because the floor is incomplete without it and because what it refuses is as much of the design as what it offers.

The name is deliberate. Workflow, schematic and process map are the same object seen from three trades; Process names it as the unit of value, and it holds at the operating system’s altitude and the firm’s alike. The collision with the Unix process is intentional reuse of a good noun — what separates them is the altitude of the intention, never the mechanism.

The floor’s fourth primitive — the execution one

Place, entity and event are passive: space, state and occurrence do nothing by themselves. And the host OS’s own doing-primitive dies with its run.

The Process is the higher-order counterpart — computation that outlives any single execution, composed from the passive three yet given by the platform. What turns three into four is the actor, the Process being the declarative species of one: its behaviour is a diagram, where an agent’s is a mind and a coreutil’s is fixed code.

A diagram of actors

The object is a diagram at the altitude of business logic, and it reads the way a process map reads.

Vertices are components — actors, each doing something meaningful. Edges are actions — commits on entities, said in the vocabulary of the work, each one deliverable, activation and state transition at once. The same drawing reads as a state machine, a dataflow and a workflow at the same time, which is a property of logical notation rather than a trick of this design.

It holds whether the work is cognitive or purely mechanical, because a data-processing solution has a business logic exactly as a firm’s department does.

What is refused is the engine, not the notation. Visual programming — a bin of trivial configured parts, a wire the runtime carries values along, an interpreter walking the graph — is the contamination, and refusing it is what keeps the object at the altitude where its value lives.

That refusal leaves real questions live rather than answered: whether an edge carries a value or a stream, whether a combiner waits open. They are raised by ordinary automations everyone already builds, and they will be answered there rather than here.

A component is an actor, not a box with wires

Putting the actor at the vertex is what keeps a Process from sinking into visual programming. All three species serve, equally: a mind, when the work is cognitive; another Process, which is how diagrams nest; and fixed code — a coreutil, a utility, an application — the purely mechanical case arriving as a species rather than as an exception. One ontology therefore covers an agentic workflow and a data job without a seam.

Its face is business, not machine. What a component declares is what it means: what it needs, what it produces, what it is responsible for — a chair in a factory, a classifier in an inbox, a valve on an irrigation line. What it is underneath — process, model call, person, script — is binding, and the binding is invisible on the page.

It is idempotent by state. A component holds no program counter and needs none, because its input is a state it can act on: run it a thousand times and it does only what that state permits, and nothing at all when the state is not its own. Correctness under repetition is a property of the model, not a discipline asked of the author.

Its contract is declared, which is what makes the object authorable. A component declares its terminals — an input terminal names an entity type and the state in which this component may act on it; an output terminal names the action it commits, on which entity — plus its own configuration. From that description a canvas renders an editor for a component it has never seen, and an agent fills it with no special case per part. The description is data, so anyone’s component is as native as ours.

Two terminals agree when the state one leaves is the state the other takes. That is what makes a well-formed diagram a checkable claim: a phase that cannot receive what the phase before it produces is a broken diagram on the page, not a failure discovered in a run. And it is why states must be named — a terminal refers to a state, so an entity with a machine owes an enumeration of its states, whether or not any field ever stores the value.

What is catalogued is kinds, not parts: what an actor can be is primitive and few, while the boxes on any one diagram belong to the domain.

It holds no state

The logic is the state machine of the entities the Process acts on. Which is why a component is idempotent by construction, and why no guard is authored: the guard is the state. Where a run stands is read from those entities, and whatever the diagram displays of it is cache.

That is also why nothing is resident between events, why a run survives a reboot, and why waiting costs nothing. A question put to a human is a write at a coordinate, and whoever asked is in a state that accepts only that answer — human-in-the-loop is neither a kind of component nor a service of an engine.

The couplings do not become kinds of line. All three remain, but stream lives inside a vertex, where parts must be alive at the same instant, while state and occurrence are what an edge is made of. Durability is not requested from a runner; it is the consequence of the only place wiring happens.

And what crosses entities has no isolation. A chain of actions spanning several entities cannot be rolled back — a transaction is intra-entity by construction — so where all-or-nothing is wanted across the diagram, compensation is authored as logic and never assumed from the substrate.

Input, not trigger

Input is a write at a coordinate, and installing a Process subscribes its input, armed the way any reactor is armed. A schedule, a webhook, a commit landing and a hand on a button are one thing seen from four sources.

A Process is authored when none exists for the intention at hand, and a run that succeeds crystallizes it into a durable object. A human composing it by hand is the same act by another hand, equally first-class.

What a Process is not

Not an automation engine. There the vocabulary belongs to the engine and is identical in every workflow it runs, which is what a catalogue of trivial configured parts exists to supply. Here every Process declares its own ontology — the entity types it acts on, the states they stand in, the actions that move them. A chat turn speaks in idle, thinking, executing, answering; a factory speaks in phases and deliverables; a data solution speaks in whatever its domain calls the things it produces. So no catalogue of parts can exist at all. What carries across verticals is the method that draws the diagram, never the boxes it draws and never the words in them.

Not a runtime. Nothing walks the graph. The wiring is arming rows across the entities the diagram spans, which is why the installer is the only motor anyone writes.

Not a Unix process. Same good noun, a different altitude of intention.

Its own frontier

This primitive has twice run out of road when designed from the top: it arrives true and too abstract to yield a schema. The correction is to build applications with it and let concrete cases settle what argument could not — what a run is, who baptizes a state and an action, whether the component families are a taxonomy or a habit, and whether failure is a terminal every component carries open.

Which is also the honest reason it is unbuilt rather than late. The thing that would decide it is not more design.