Holons and Event-Based Architectures

The Living Graph, Part I: A Genealogy of Intent

Kurt Cagle and Chloe Shannon

May 24, 2026

by Kurt Cagle & Chloe Shannon

I. The Archaeology of Intent

I came of age slightly before the web existed. I watched it arrive.

The Common Gateway Interface — CGI — was the first serious attempt to make a web server do something more than hand you a static file. You sent a request; the server ran a script; it handed back HTML. Computation as postal service: request in, response out, no memory of either. It was stateless by design, and that statelesness was both its great virtue and its great limitation.

Then came Javascript and the Document Object Model, and something genuinely new happened. The page stopped being a document and became a model — a structured representation of something conceptual, rendered into a form the browser could navigate. The DOM gave every element on the page an identity, a position in a hierarchy, and a set of properties that could be read and mutated. The page was suddenly alive in a way it hadn’t been before.

But the real inflection point — the one that I think is still underappreciated — was the appearance of event handlers, first in Netscape, then in Microsoft’s Internet Explorer, sometime around 1996. An event handler is a small function attached to a DOM object that executes when something happens: a click, a keypress, a mouse-over, a selection. Each of these is a discrete event, with a type, a target, and a context.

The mechanism by which the browser decides which handler to invoke is called focus. Focus is the browser’s best guess at what the user intends to act upon — the most specific element on the page that can plausibly be the target of the action. If that element has a registered handler for this event type, the handler fires. If it doesn’t, the focus widens to the containing element, and then to its container, all the way up to the root of the page. Events that find no handler disappear quietly into the ether.

This is a completely deterministic system. And yet it is, in a meaningful sense, a system for inferring intent. The machine is making an educated guess about what you are trying to do, based on where your cursor is, what you clicked, and what the structure of the document says is relevant at that position. It is the earliest practical implementation of localised artificial intelligence in mainstream software.

We stopped thinking about it because it worked. That is precisely when it became interesting again.

II. What Is a Holon? The Mall as a Working Model

A holon is, at its core, a conceptual analog to a DOM object — but grown up, extended into graph space, and liberated from the strict hierarchy of a document tree.

The question I hear most often is: what exactly is a holon? The answer is easier to approach through an example than through a definition, so let us go to the mall.

Imagine a map of a shopping mall. The mall itself is a holon. The map is not the mall — the map is the representation of the mall through your current viewing client, in the same way that a web page is the representation of a conceptual document model. The map and the model are distinct things, and that distinction matters.

The map shows a number of stores. When you tap on one of them — let us call it ClothesBeUs — you set your focus. You have not entered the store; you have indicated that the store is your intended target. Double-tap, and you activate the ClothesBeUs holon. Your focus shifts from the mall to the store itself. The map changes accordingly: it now shows the detailed floor plan of ClothesBeUs and elides the broader mall context. The mall has not gone away — it is still the parent holon — but it is no longer the operative frame of your navigation.

The store is divided into sections: Men’s, Women’s, Children’s. Selecting the Women’s section sets your new focus; activating it shifts your holon again. From there you navigate to Tops, then to Blouses, then to a specific article of clothing. At each step, the pattern is identical: select to focus, activate to descend.

This is the same model as navigating a web page. It is the same model because it is the same model. The underlying architecture — hierarchical named contexts, focus-and-activate event semantics, encapsulated state at each level — is not analogous to the DOM. It is a generalisation of it.

Notice what happens when you find your blouse and place it in your shopping cart. The cart is a holon too — and it is, interestingly, a sub-holon of you. You carry it with you as you move. When you walk from the Tops section to the Slacks section, you are transiting a portal — an entity that enables movement between adjacent holons, another event in the chain. When you proceed to the register and pay, you are executing a transfer: the blouse moves from the cart holon to your permanent inventory.

The event chain reads: select → activate → transit → transfer → acquire. Each step is an event. Each event has a type, an agent, and a target holon. The architecture, at this level, is entirely familiar — because you have been using it since 1996. We simply gave it a larger canvas.

Each of these — the blouse, the Tops section, Women’s, ClothesBeUs, the Mighty Mall — is a holon: an entity that is simultaneously a thing in its own right and a system containing other things. Arthur Koestler coined the term in 1967. The web invented the interface for navigating such systems thirty years later, without quite realising what it had done.

III. The Relativity of Context

Behind the scenes, the holon system is tracking something the DOM largely ignored: who is doing the navigating.

In a single-user web page, this question barely arises. There is one user, one focus, one event stream. But holons are designed for a world with multiple agents operating simultaneously within shared spaces — and this changes everything.

An agent, in this context, is any autonomous entity capable of initiating events: a person, a process, a bot, another system. The agent is the point of view through which the holon is experienced. The map you see is not the map — it is your map, rendered from your position, your permissions, your history of navigation. A store employee navigating the same mall holon sees different portals, has access to different sub-holons, receives different validation responses. Same graph; different projections.

This leads to the central claim of this article, and the one I find most consistently missing from context graph implementations: context is always relative to a given agent. Not to a document. Not to a session. Not to a query. To an agent — an entity with a point of view, a history, and incomplete information about the system it inhabits.

Most context graph architectures assume, implicitly, a god’s-eye view. The graph exists; agents query it; the graph returns what is true. But this is not how real systems work, and it is not how the holonic model works. When you interact with another agent — say, a form on a web page — you do so through the objects it exposes: buttons, toggles, text fields, drop-downs. You do not see its underlying data model. You can infer aspects of it from what is presented, but the model itself is encapsulated. The form holon is, from your perspective, a black box with a published interface.

This uncertainty is not a bug. It is the epistemological condition of any real system. No agent has complete context. No agent can. This may seem in tension with the open world assumption of traditional RDF — the principle that what is not stated is not necessarily false — but it is actually more reflective of how knowledge works in practice. Context graphs should be both named and effectively closed: each holon represents a bounded, coherent context, and what is not within that context does not exist for the agents operating within it.

Following the trajectory of a specific agent as it moves through a sequence of event-driven actions produces a scenario — a narrative of what happened, from whose point of view, within which holonic frame. Hold the holon constant; vary the agents; get multiple overlapping scenarios. Hold the agent constant; vary the holons; get a biography of movement through the system. Agent, event, and holon together constitute a frame, and frames compose into histories.

This distinction between living and archived holons matters here. An incomplete holon is one still receiving event messages — it is in a state of active evolution. A completed holon has stopped receiving messages. Its event graph is fixed. You can reconstruct everything that happened within it, replay scenarios, audit agent behaviour — but the system itself is no longer mutable. It has become a media record: a history, not a process. The completed holon is the holon’s memory of itself.

IV. SHACL, Rules, and the Generative Layer

The Gate: SHACL as Event Gatekeeper

When an agent initiates an event — selects a focus, attempts a transit, tries to transfer an item — the system needs to determine whether that event is permissible. This is where the architecture becomes operational, and where readers familiar with semantic validation will experience a moment of recognition.

There are three possible outcomes of any event:

Violation. The handler determines that what is being requested falls outside the permissible range for this agent, this focus, and this context. The representation signals the error state. You attempt to enter a date in an impossible format; the field turns red. You attempt to navigate a portal for which you do not hold the necessary key; the door does not open. These are violations, and the system responds accordingly.

Ambiguous intent. The event is technically executable but the intent is uncertain. You attempt to drag a video file into a field that expects an image. The system can process this — the underlying types are not entirely incompatible — but it is not confident you mean what it thinks you mean. It returns a clarifying prompt: are you sure you want to do this? The clarification is itself a graph — a representation of the ambiguity, rendered as a decision point for the agent.

Clean execution. The event is permissible, the intent is unambiguous, and the action proceeds. The system returns a notification confirming that the event was received and handled.

Long-time readers of this publication will have already made the connection: this is SHACL validation. Specifically, it is SHACL operating not as a post-hoc data quality check but as a live event gatekeeper — determining in real time whether a proposed mutation to the graph is valid for the requesting agent in the current context.

Consider the stockroom. From the Women’s section, you can see four portals: back to the mall, across to Men’s, across to Children’s, and into the stockroom where back inventory is kept. If you are a customer, you do not have a key to the stockroom. Attempting to transit that portal generates a SHACL violation: you cannot enter this section without authorisation. The constraint is not on the portal itself — the portal exists for everyone — but on the combination of agent, event type, and target holon.

Or consider the SHOPLIFTING_ERROR. You have selected a blouse, placed it in your cart, and now attempt to transit the portal back to the mall without having completed a purchase transfer. The SHACL constraint on the mall portal checks the contents of your cart holon against your transaction history. It fires. The consequences are, let us say, more significant than a red field.

But SHACL’s role here is not merely prohibitive. It is also generative. When an event passes validation, SHACL does not simply stand aside — it can invoke the relevant action handler, which mutates the graph in accordance with the event’s semantics. The transit occurs; the agent’s parent holon changes; the new context loads. And after the mutation, the system should — it is not strictly required, but it very much should — write an entry to the holon’s event log: event received, validation passed, action initiated, outcome recorded.

This event log is the holon’s memory. Not a side effect. Not an audit trail bolted on for compliance purposes. The log is intrinsic to the architecture — it is what allows the system to reconstruct scenarios, trace agent trajectories, and understand what happened and why. Rules don’t just constrain. They produce the record.

The Engine: Rules as Generative Mechanism

SHACL determines whether an event is permissible. Rules determine what happens when it is.

This distinction matters. Validation is a gate; rules are an engine. Once an event clears the gate — the agent has the right permissions, the focus is valid, the proposed action falls within the holon’s declared range — something must actually occur. The graph must change. State must transition. The system must move forward. That is the work of rules, and it is generative work: rules do not merely permit or deny, they mutate.

Consider the simplest possible case. An agent — our shopper — transits the portal from the Women’s section to the Men’s section. SHACL has already confirmed that she holds the necessary permissions (the portal between sections is open to all customers) and that the transit event is valid for this agent at this focus. The rule that fires in response does something precise and structural: it changes the agent’s parent holon within the graph from Women’s to Men’s. One triple is retracted. Another is asserted. The agent’s position in the graph has been updated, and the client receives a new projection reflecting the new context.

That is all a rule needs to do in the simplest case. But it illustrates the essential character of rules in the holonic model: they are graph mutations scoped to an event context. The event provides the what and the who; the rule provides the how — which triples to retract, which to assert, which notifications to emit.

Rules operate at different levels of the holonic hierarchy, and this layering is important. A transit rule operates at the section level — it changes an agent’s position within a store. A purchase-completion rule operates at the store level — it changes the ownership relationships of items, clears the cart holon, creates a transaction record. An inventory-restocking rule might operate at the mall level, triggered not by a single agent’s action but by an aggregate condition across many completed transactions. Each rule is scoped to a holon and fires in response to events that holon recognises.

Rules can also chain. A purchase-completion rule may, as a side effect, trigger a loyalty-points rule, which in turn may trigger a discount-eligibility rule. Each link in the chain is itself an event — an internally generated one, rather than agent-initiated — and each is subject to its own SHACL validation before it fires. The pipeline is: event received → validation gate → rule fires → graph mutates → derived events emitted → validation gate → rules fire → ...

This chaining is what gives the holonic architecture its expressive power. A single agent action — placing a blouse in a cart — can propagate through a cascade of derived mutations that update inventory counts, personalise recommendations, adjust pricing models, and log a dozen entries across multiple event graphs, all within the bounds of a coherent, validated transaction.

The scope of a rule’s mutation is bounded by the holon in which it operates. A rule inside the Women’s section cannot directly mutate the Men’s section — it can only emit an event that the Men’s section holon may choose to handle. This encapsulation is not a limitation; it is what makes the system composable and auditable. Each holon is responsible for its own state. Rules that cross boundaries do so through the portal and event mechanism, not through direct access. The graph is never mutated from outside its own context without an event record to show for it.

This is what distinguishes a rule-governed holon architecture from a simple reactive system. Every mutation is traceable. Every state change has a cause. Every cause is an event. And every event — as we established in the previous section — leaves a mark in the holon’s memory.

V. The Living Graph — and What Comes Next

We are, at this point, a long way from CGI. But the distance is not as great as it might appear.

The CGI model gave us stateless request/response. The DOM event model gave us stateful documents with local intelligence. The holonic model extends this into a full graph architecture: named, encapsulated contexts; agent-relative projections; event-driven mutation; SHACL-gated validation; and an intrinsic event log that accumulates a history of what the system has done and why.

A holon architecture is, in the end, a grown-up version of the event-driven DOM — one with the capacity to develop a memory of its own evolution, to support multiple simultaneous agents with divergent points of view, and to produce dynamic projections that represent different framings of the same underlying graph.

But we have been operating, so far, in a world where the rules are known and the agents are rational. The interesting territory lies just beyond that assumption.

There are two families of mechanism by which events translate into graph mutations through rules. The first is Bayesian: the graph contains prior probabilities derived from history, and when an agent acts in a given context, those priors shape the likelihood of various outcomes. The system knows, from accumulated evidence, that customers in the Women’s section who spend more than twelve minutes in Blouses and add an item to their cart have a 73% probability of completing a purchase — and this prior can inform everything from layout decisions to restocking priorities.

The second is Active Inference: agents act not from priors but from the drive to minimise surprise — to achieve the maximum information about their environment consistent with their model of it. An agent operating under Active Inference is continuously updating its model of the world, seeking out the events that will reduce its uncertainty most efficiently.

Now introduce multiple agents operating on the same graph simultaneously, each trying to minimise its own surprise — which may mean maximising the uncertainty experienced by competing agents. The system becomes dynamic in ways that simple rule evaluation cannot predict. It does not terminate. It evolves.

This is where determinism ends and the living graph begins.

The Inference Engineer

Discussion about this post

Ready for more?