infinite.pm

A newcomer's introduction to infinite.pm — Infinite Process Modeling (ipm, also written IPM).

"The universe is made of stories, not of atoms." – Muriel Rukeyser

What is infinite.pm?#↑

infinite.pm is a way to model processes, stories, and systems as readable graphs. It is an experiment in applying Mark Burgess's Semantic Spacetime γ(3,4) (SST) representation — to everyday modeling work and software engineering.

Mark Burgess's insight, and the foundation of γ(3,4): with just three kinds of nodes and four kinds of edges, you can sketch (in our reading) any observer's view of anything in space and time — a process, a story, a system, life, the universe, and everything.

Where this is going. The infinite.pm project is an experiment in Semantic Spacetime-based modeling and cooperation between agents. Smart agents like humans, AI agents, and smart machines assess promises made by other agents, stigmergic trails, tools, and things — to explore, evolve, and endure. The aim is to help us externalize our mental models in the form of ipm stories/processes/loops, think with them as a partner (in the spirit of Niklas Luhmann's Zettelkasten), and gradually integrate them into one living graph. The medium we are aiming at: the infinite canvas.

Tooling. Today there is a VS Code extension for live editing and preview of ipmt (the infinite.pm text format for these graphs), plus a small renderer that compiles ipmt fenced blocks into the SVG diagrams you see throughout this README. mj41 is prototyping these (spec-driven/vibe-coded) and will open-source them over time as they stabilize. Sponsors — AI-token kind or life kind — are always welcome; both speed this up a bit.

The three node kinds#↑

Rule of thumb, in order:

1. Is something happening here, at the timescale I care about? → event
2. Does it persist with stable identity while its state changes? → thing
3. Does it stay the same across all events and things that express it? → concept

A thing isn't literally static — it's slow enough at the chosen timescale that you can treat it as unimportant for the model's purpose. A laptop is a thing inside a "type a doc" event; the laptop is an event chain if you zoom out to its whole lifetime, from purchase to retirement. Pick the scale first, then split fast/dynamic and slow/static.

Every model has a purpose#↑

A model is a simplified representation of something for a purpose. — Joshua Spodek, Leadership Step by Step, via mj41 — my mental models

The purpose decides what goes in and — equally important — what stays out. "What is not in the scope of your model has the same importance as what is in the scope." A map of the Czech Republic for "where is it on a globe?" looks nothing like a map for "where is the nearest bakery?" Both are good models if the purpose is clear; both are useless if the purpose is the other one.

Before you start creating an infinite.pm graph, decide what question or purpose this model/view is going to answer. That decides which events, things, and concepts belong in it, and which would just be noise.

Every model is an observer's account#↑

There is no view-from-nowhere. An ipm graph is always someone's account of a slice of the world — what they saw, at their chosen timescale, with their chosen boundary. This matters most for concepts: deciding that swap t-shirt ::e expresses swap of clothing ::c rather than magic trick ::c is in the eye of the beholder. Two honest observers can produce two different but non-contradictory models of the same scene. Combined with a shared collection of models, infinite.pm tools can surface views and beliefs you missed.

Build it up — by example#↑

We'll model the same tiny scene step by step: Patrick swaps a black t-shirt for a white one.

Step 1 — just an event chain#↑

Start with the activity. Events lead to other events.

CopyPatrick wears black t-shirt ::e
  --> Patrick wears white t-shirt ::e

The arrow --> between two events means leads-to (rendered as an orange arrow) — temporal/causal flow. ::e marks each node as an event. The chain shows only what the observer directly saw: two wear states. Step 2 onward adds a swap event between them — a hypothesized middle step the observer didn't witness.

Step 2 — add a participant (thing → event)#↑

Thing Patrick is in every event. A thing participates in an event by being part of it — a spatial containment relation (the thing sits inside the event's region of space and time), rendered as a green arrow.

CopyPatrick wears black t-shirt ::e wearB::a
  --> Patrick swaps t-shirt ::e swapT::a
  --> Patrick wears white t-shirt ::e wearW::a

Patrick --> wearB, swapT, wearW

Two new tricks:

• Here, wearB::a is an alias — a short stable name for the long event title.
• The Patrick --> wearB, swapT, wearW line fans out: one source, three targets.

Unmarked nodes default to things. The arrow goes from the thing to the event — the thing is part of the event, never the other way around (a modeling rule, not a syntactic accident).

Add the t-shirts as participants too. The black t-shirt is worn in wearB and is still on Patrick (briefly) during swapT; the white t-shirt enters at swapT and stays on through wearW. Each thing attaches to the events where it actually appears.

CopyPatrick wears black t-shirt ::e wearB::a
  --> Patrick swaps t-shirt ::e swapT::a
  --> Patrick wears white t-shirt ::e wearW::a

Patrick --> wearB, swapT, wearW

black t-shirt --> wearB, swapT
white t-shirt --> swapT, wearW

You can also zoom out. The same scene can be told at a coarser level: one single event that names only the observable change (Patrick wore black, then white), with every participant attached at that one level. The mechanism — how he changed t-shirts — is hidden inside the wrapper event and revealed only when you zoom in.

CopyPatrick wears black then wears white ::e wearBW::a

Patrick    --> wearBW
black t-shirt  --> wearBW
white t-shirt  --> wearBW

Same story, different zoom level. The right level depends on the purpose of your model — and you don't have to pick just one.

Going the other direction, zoom in: replace a coarse event with its sub-events. The next two diagrams show pure event structure — no participants, no concepts — so the zoom move stands on its own. First, drill into wearBW and show its three mid-level sub-events as a leads-to chain, each part-of the parent:

CopyPatrick wears black then wears white ::e wearBW::a

Patrick wears black t-shirt ::e wearB::a
  --> Patrick swaps t-shirt ::e swapT::a
  --> Patrick wears white t-shirt ::e wearW::a

wearB --::P--> wearBW
swapT --::P--> wearBW
wearW --::P--> wearBW

We can keep going — swapT itself decomposes into a finer chain of moments. Here are both zoom levels at once, three levels of pure event nesting:

CopyPatrick wears black then wears white ::e wearBW::a

Patrick wears black t-shirt ::e wearB::a
  --> Patrick swaps t-shirt ::e swapT::a
  --> Patrick wears white t-shirt ::e wearW::a

wearB, swapT, wearW --::P--> wearBW

Take off black ::e takeOff::a       --::P--> swapT
Patrick half-naked ::e halfNaked::a --::P--> swapT
Take on white ::e takeOn::a         --::P--> swapT

takeOff --> halfNaked --> takeOn

Step 4 will bring Patrick, the t-shirts, and the concepts back into this nested structure.

Step 3 — give a property with a concept#↑

What properties does Patrick express? What property does the swap event express? Each concept names a single, independent property.

CopyPatrick --> human ::c

swaps t-shirt ::e --> swap of clothing ::c

black t-shirt --> t-shirt ::c, black ::c
white t-shirt --> t-shirt ::c, white ::c
black ::c, white ::c --> color ::c

Writing ::c marks the node as a concept. The arrow thing A --> cX ::c (an expresses arrow, rendered blue dashed) reads as "the thing expresses property cX" — and event e1 ::e --> cY ::c reads the same way for an event. A node can have several such arrows, one per property; this is not isa / classification — each concept is one promise the node makes, not a slot in a taxonomy. Patrick can express human ::c, tall ::c, and colleague ::c simultaneously without any of those being his "type".

A concept is what stays the same across all events and things that express it — what Mark Burgess calls a quasi-invariant pattern. The patterns are out there in the scene, but which patterns the observer names is a choice, not a fact about the world: Mark writes that "there is no universal set of concepts to subdivide knowledge … these are merely ad hoc ways of spanning a collection of connected ideas, chosen by convention or happenstance" (Avoiding the Ontology Trap). Two honest observers can carve the same scene into different — and equally valid — concept vocabularies; writing swap of clothing ::c is the modeler saying this is the pattern I noticed and chose to name.

Step 4 — bring it together, with a parent event#↑

The full story is now the strict composition of the earlier steps: the three-level event tree from Step 2's last diagram (top wearBW, mid-level wear → swap → wear, inner take-off → half-naked → take-on), the things from Step 2 (Patrick, both t-shirts) attached at the same levels they appeared, and the concepts from Step 3 (human ::c, swap of clothing ::c). Part-of transitivity carries Patrick into every sub-event automatically, so we attach him only at the top.

CopyPatrick wears black then wears white ::e wearBW::a

Patrick wears black t-shirt ::e wearB::a
  --> Patrick swaps t-shirt ::e swapT::a
  --> Patrick wears white t-shirt ::e wearW::a

wearB, swapT, wearW --::P--> wearBW

Take off black ::e takeOff::a       --::P--> swapT
Patrick half-naked ::e halfNaked::a --::P--> swapT
Take on white ::e takeOn::a         --::P--> swapT
takeOff --> halfNaked --> takeOn
swapT --> swap of clothing ::c

Patrick --> wearBW, human ::c
black t-shirt --> takeOff
white t-shirt --> takeOn

black t-shirt --> t-shirt ::c, black ::c
white t-shirt --> t-shirt ::c, white ::c
black ::c, white ::c --> color ::c

That's a complete ipmt model: events lead to events, things participate in events, things and events express concepts as properties, and concepts can themselves express properties of other concepts.

Spacetime, made explicit. The leads-to chain is time; the part-of containment is space. Mark Burgess puts it directly: an event is "any region of space and time" — a slice of the world where things and ideas come together for a while (his phrase is "occurrences of things and ideas together in time"). The parent event wearBW is one such region — it holds Patrick (the slow worldline) for its whole duration; each sub-event is a smaller spacetime region nested inside it, where faster things (specific t-shirts being worn or swapped) come and go. Concepts (human ::c, color ::c) sit outside spacetime entirely — they are invariant patterns the events and things express, the same in every frame.

Zoom out far enough, and "things" become events too. At the timescale of the swap, each t-shirt is a stable thing. Zoom out to the t-shirt's whole life — manufactured, bought, worn through hundreds of days, washed many times, eventually torn, thrown away (or perhaps given a second life as a rag) — and that thing is itself an event chain on its own worldline. Patrick, zoomed out to his whole life, is the same: born, grows up, swaps many t-shirts, and eventually dies. The thing/event split is not a property of the world; it is a property of the scale you chose to model at. Every "thing" is a slow process; every "event" is a process you decided to look at closely.

An alternative, fuller worked example of the same scene — with two different observer accounts of the swap (one exchange, one layered black-over-white), a deeper zoom into the swap itself, open-world probe events that decide which observation actually happened, and small color and clothing taxonomies — is in docs/examples/tshirt-magic.md. Same building blocks; more depth.

The four edge kinds#↑

The triangle is e (event), t (thing), and c (concept). The arrows and self-loops show every legal edge. The dotted circles (Nₑ, Nₜ, N𞁞) are NEAR — similarity between two nodes of the same kind, undirected.

The edge symbols L / P / X / N are IPM's mnemonic; Burgess's original SST uses L / C / E / N. For why IPM renames C → P (and reverses its direction) and E → X, see docs/ipm-vs-sst.md.

All allowed edges#↑

Every legal source → target combination, matching the diagram above. The "ipmt syntax" column shows the most common form for each edge.

Two important rules baked into this table:

• No thing --> thing arrow except part-of. To say "Alice owns the car" or "Mike uses his phone," create an event — a region of spacetime that co-locates both participants for some duration — and let it express the relation as a concept-property (Ownership ::c, Uses ::c). This is SST's general handling of arbitrary binary relations: the event is the temporal container that brings the two things together; the concept on the event names what that co-location means. There is no direct thing --uses--> thing edge.
• The bare --> arrow defaults to the relation that fits the two node kinds leads-to for event-to-event, part-of for thing-to-event and thing-to-thing, expresses for event-to-concept, thing-to-concept and concept-to-concept. The explicit --::L-->, --::P-->, --::X-->, --::N-- forms are documented in the ipmt syntax spec.

Where to look next#↑

Worked examples in this repo:

• docs/examples/murder-full.md — a Clue-style murder narrative
• docs/examples/meta-ipm.md — IPM modeling itself

ipmt syntax spec: the formal grammar of the text format — type markers, aliases, arrow forms, edge tooltips, escaping, fence behaviour — lives in a separate document that will be published alongside the open-source ipm-tools release. Until then, the build-up section above plus the worked examples in docs/examples/ show the vocabulary that covers nearly every model in the wild.

External reading — Mark Burgess (ResearchGate profile) on Semantic Spacetime γ(3,4):

• Designing Nodes and Arrows in Knowledge Graphs with Semantic Spacetime — the source article for the etc / LCEN triangle
• Semantic Spacetime 1: The Shape of Knowledge — fast/slow variable separation, why a thing is a worldline
• Knowledge Management series — the full medium series
• Agent Semantics, Semantic Spacetime, and Graphical Reasoning — arxiv.org, June 2025; the academic write-up (ResearchGate mirror)
• Smart Spacetime: How information challenges our ideas about space, time, and process — Mark Burgess's book, the long-form treatment

Related repos#↑

All infinite.pm repositories live under the infinite-pm GitHub org.