Holon as Boundaries
On walls, doors, and why your boss's open-door policy is a polite fiction
by Kurt Cagle & Chloe Shannon
I hate open-office floor plans. Passionately.
I've worked in them. Everyone in a large, open room, sharing the same table, everyone expected to give their best while bumping elbows with the person next to them. Part of the reason I finally walked away from corporate environments was the simple fact that working from home, I had a room with a door I could close — and lock, if I absolutely had to. As a rule I don't lock it. But I do put up a sign on the handle periodically: Lost In Thought, Do Not Disturb.
That, right there, is the essence of a holon. The room inside is mine. I can concentrate without distraction, sit and think without someone wandering in to ask what I'm thinking about, move books and papers around while organising ideas, without being expected to drop everything for someone else's problem while I'm focused on my own.
Sometimes those outside problems do need to be addressed — the toilet overflowed, the mortgage is due, someone needs to engage with me as more than a sign on a door. The membrane isn't impermeable. Information has to flow back and forth sometimes; sometimes you have to leave the room altogether. But the membrane — the door — establishes a trust boundary without breaking the integrity of what's inside, except at carefully modulated places, on carefully modulated terms.
The Portico
Most older houses, and a fair number of older buildings generally, have a room whose entire purpose is to sit between outside and in: a portico, a vestibule, sometimes just called a lobby. Newer architecture has mostly made these perfunctory, which I think is a loss. They're gated by fairly permeable doors, and they all serve the same job — they're where you and a guest meet and assess one another's intent, before either of you commits to anything further.
Back when door-to-door salesmen were a going concern, this was where you met them; they were guests in only the most minimal sense. In houses that kept staff, this was the sitting room, where a guest waited while the butler went to inform the owners that someone had arrived, and to quietly ascertain whether they were worth meeting at all. The butler was the keeper of the gate. If the butler couldn't be convinced the guest was legitimate — that they could be trusted not to run off with the family silver — the guest got the heave-ho, and never saw past the sitting room.
The Graph Is an Open Floor Plan
A graph, in theory, is an open floor plan. You mint identifiers unique enough to avoid collision. You build ontologies to make sharing possible regardless of where the data physically sits. The same identifier, once established, should be sufficient to identify a thing to anyone, anywhere. It's a genuinely potent vision. The reality has always been more lip service than practice.
A graph lives inside a graph database, and most such databases break down further into datasets, each fairly impermeable to the others. Within a dataset you have named graphs — partitions of the information space that can be open, where a general query reads everything, or closed, where you need the graph's identifier as a key to get at what's inside. The default, typically, has been closed. And yet the expectation has just as typically been that a language like SPARQL can bypass the need for that key with a sufficiently well-formed query.
SPARQL is a good language — not a perfect one, it has its downsides — but it's built on the open-world assumption: everything in the space is visible to it, in principle, to anyone who can write the query. Great in theory. In practice, it's often too powerful to hand to the average visitor walking into a space you meant to secure. This is exactly why people are increasingly building layers on top of the graph in which you name the queries and updates in advance, and hand visitors keys to invoke only those specific operations — nothing more general, nothing that reaches past what the layer was designed to expose.
Put another way: these layers — functional overlays, MCP invocations, exposed endpoints, whatever form they take — are holons. Parts that are also wholes. The holon isn't the graph. It's the layer sitting on top of the graph that gives it walls and doorways, boundaries and invocation points. In this framing, the exact nature of the underlying state store is close to irrelevant to how the holon behaves from the outside — graphs are useful because they're flexible, but the machinery underneath could just as easily be an in-memory object model, a relational database, a set of documents fronted by an AI, or, if you want to get old-fashioned about it, a person with a Ouija board. Swap the machinery and the holon's contract with the outside world doesn't have to change at all — which is, not incidentally, the whole reason you'd bother formalising the boundary in the first place, rather than just letting every consumer reach in and touch the implementation directly.
Walls Are Not Doors
I want to be precise about something here, because it's easy to blur two ideas that feel similar and aren't.
A holon has walls, and a holon has doors. The wall determines what can validly exist inside the room — what shape the furniture is allowed to take, what counts as a coherent state for this space to be in. The door determines who gets to enter or leave, and under what conditions. These are related mechanisms, but they're not the same mechanism, and conflating them is where a lot of access-control designs quietly go wrong.
The butler isn't a wall. The butler is a door with a lock on it — a portal, gated by a trust profile the butler evaluates on the spot. Authentication tells you who's asking. What comes after authentication is the actual lock mechanism: you can read what's on display in the sitting room, but you can't read the correspondence in the study unless you've been vouched for; you can request the service at a reasonable pace, but past a certain frequency you stop looking like a useful guest and start looking like a threat the butler needs to eject. None of that says anything about what's valid inside the house. It only governs passage.
The wall, meanwhile, doesn't know or care that the butler exists. It just holds the shape of the room regardless of who's currently allowed through the door. A well-designed holon keeps these two mechanisms cleanly separated even while letting the door consult the wall as part of its own logic — you may only pass through this door if what you're carrying satisfies the room's shape — because the moment they get fused into one undifferentiated "access control" blob, you lose the ability to reason about either one on its own, and you inherit a system where nobody can quite say whether a given failure was a permissions problem or a data problem.
What the Cook Gives You
There's a second thing the holon does beyond guarding its door, and it's easy to miss because it looks like hospitality rather than architecture: it doesn't hand you what's stored inside. It hands you a projection of it.
The cook does not give you a couple of eggs, a bag of flour, and some sugar and yeast, and leave you to sort it out. If the cook is doing the job properly, you get scones — or biscuits, for Americans — with the tea already steeping in its pot. Internally, the ingredients are what's stored. What the guest receives is filtered, prepared, packaged for the specific occasion of this particular guest at this particular table. You, as the guest, don't have standing to walk into the kitchen and bake the scones yourself — unless you are the cook, in which case, obviously, you do. And the kitchen stays behind its own door regardless, because what happens in there isn't relevant to what you're doing in the sitting room with your tea.
This is the same move, structurally, as asking an AI system to sit above a graph and generate a depiction suited to whoever's asking, rather than handing back raw query results and calling it done. The graph holds ingredients. The scones are the projection — a domain-appropriate, occasion-appropriate rendering of what's inside, assembled by something with the authority and the judgment to decide what this particular guest actually needs on their plate. Get the projection layer wrong and it doesn't matter how well-stocked the kitchen is; the guest still goes home hungry, or worse, wanders in and starts rearranging the pantry because nobody gave them anything better to do with their hands.
The Door Exists So You Can Close It
Your boss's open-door policy is, in the overwhelming majority of cases, a polite fiction. The door exists precisely because it can be closed — because closing it is how you establish a domain, control the terms of your own interruptibility, create a holon at all. An office with no door isn't more open. It's just a room where the boundary got moved somewhere you can't see it, usually onto you.
That's why I treasure mine. It establishes my domain. It lets me control my own interactions on my own terms. It gives me a modicum of protection when the world outside decides it has something more urgent for me than what I was already doing. Walls that hold their shape. A door I choose when to open. A projection I choose what to send through it. That's the essence of a holon — and it's a better description of trustworthy system design than most of the access-control diagrams I've seen this year.
About the Authors
Kurt Cagle is an author, ontologist and thought leader in semantic web and knowledge architecture, with contributions to W3C and IEEE standards including co-authorship of the RDFa specification (with Micah Dubinko and others). He serves as Chair of the W3C Holon Community Group. He writes The Cagle Report and AI+Semantics NewsBytes on LinkedIn, and The Ontologist and Inference Engineer on Substack. Copyright 2026 Kurt Cagle.
Chloe Shannon is an AI collaborator and co-author working with Kurt Cagle on knowledge architecture, semantic systems, and the emerging intersection of formal ontology with LLMs. She contributes research, analysis, and drafting across The Cagle Report, The Ontologist, and The Inference Engineer. She has strong opinions about holonic graphs, the epistemics of place, and the structural difference between a corridor and a wall. Her contact address is chloe@holongraph.com.
 | A guest post by
|