{"slug": "only-inert-definitions-cross-the-boundary", "title": "Only Inert Definitions Cross the Boundary", "summary": "A developer building the MCP layer for XRefKit established a rule that only inert definitions cross the transport boundary between server and client. The server distributes judgment axes and skill definitions, while the client performs all execution and evaluation. This architecture splits the system into a server-side catalog and routing plane and a client-side execution plane, ensuring that executable guidance is delivered without performing the work itself.", "body_md": "In my previous two posts, I argued that MCP is more useful as a context distribution layer than as RPC, and that `AGENTS.md`\n\nshould be a bootloader, not a knowledge base.\n\nBoth posts described context as something delivered **in stages**.\n\nStartup context first.\n\nSkill catalog next.\n\nDomain rules when routed.\n\nAuthoritative documents when resolved.\n\nVolatile state only when needed.\n\nThat description answered one question:\n\nHow many stages are there?\n\nBut it quietly avoided a second question:\n\nOn which side of the boundary does each stage run?\n\nThis is the question that actually matters when you build the server.\n\nA stage is not just a point in time.\n\nIt is also a point in space.\n\nSome things happen on the MCP server.\n\nSome things happen on the client.\n\nAnd the line between them is not arbitrary.\n\nWhen I built the [MCP layer](https://github.com/synthaicode/XRefkit.MCP) for [XRefKit](https://github.com/synthaicode/XRefKit), I settled on one rule that decided almost everything else:\n\nOnly inert definitions cross the transport boundary.\n\nAn inert definition is executable guidance without execution.\n\nIt defines how work must be performed, but never performs the work itself.\n\nIt is not the result of doing the work.\n\nConcretely, what crosses the boundary is things like:\n\nWhat does **not** cross the boundary is the act of applying any of that.\n\nThe server can tell the client *what counts as a valid review*.\n\nThe server does not perform the review.\n\nThis splits the system into two planes.\n\n**Server-side plane: catalog and routing.**\n\nIt knows what skills exist, what each skill requires, and how to map a work intent to a skill definition.\n\n**Client-side plane: execution.**\n\nIt reads the actual code, walks the actual constraints, records the actual unknowns, and reaches the actual closure decision.\n\nThe server distributes judgment axes.\n\nThe client does the judging.\n\nAbstractions hide where the boundary really is. So here is a single request, traced end to end.\n\nA developer expresses an intent:\n\nValidate this change against known constraints.\n\n**Step 1 — client asks the server to route the intent.**\n\nThe client does not yet know which domain skill applies. It sends the intent to the catalog plane and asks for resolution.\n\nThis is semantic routing, not command routing. The client is not saying \"run tool X.\" It is saying \"this is the kind of work I am about to do.\"\n\n**Step 2 — server returns a skill definition. Inert.**\n\nThe server resolves the intent to a domain skill and returns its *definition*:\n\nNotice what did **not** come back: a validation result.\n\nThe server did not read the change. It did not check anything. It returned the *rules of checking*, not a check.\n\nThis is the whole point of \"inert.\" The payload is a contract, not an outcome.\n\n**Step 3 — client executes against the definition.**\n\nNow the execution plane does the work the definition describes:\n\nAll of this is local. None of it crossed the boundary.\n\n**Step 4 — closure is evaluated, not assumed.**\n\nThe closure contract came from the server. But the act of deciding whether closure is allowed happens on the client, against real findings.\n\nIf an unresolved unknown remains, closure is blocked.\n\nIf a forbidden assumption was required to proceed, the work halts and escalates.\n\nThe server defined the stop condition.\n\nThe client encountered it.\n\nIt would be easy to read the two planes as an engineering convenience. Keep the heavy catalog on a server, keep the runtime light on the client. True, but not the real reason.\n\nThe real reason is that the boundary lines up with something deeper.\n\nThe server can only distribute judgment that has already been **externalized**.\n\nA closure condition is distributable because someone wrote down what \"done\" means for this kind of work. A forbidden-assumption list is distributable because someone made the implicit rule explicit. An unknown-stop condition is distributable because someone decided, in advance, which gaps are not allowed to be papered over with fluent text.\n\nThese are externalized judgment axes. Inert. They cross.\n\nBut the act of judging against them at runtime — reading this specific code, weighing this specific risk, deciding whether this specific closure is honest — that does not become a transferable artifact just because the axes did.\n\nSo the boundary is really a test:\n\nIf a piece of judgment can be written as an inert definition, it belongs on the server.\n\nIf it cannot, it stays where the work happens.\n\nThe two-plane split is not a transport decision. It is a line drawn through judgment itself.\n\nHere is the part I could not write in the first two posts, because I had not located the boundary precisely enough.\n\nA domain skill distributes closure conditions, stop rules, and evidence requirements. That looks like it distributes judgment.\n\nBut distributing the *axis* of a judgment is not the same as distributing the *judgment*.\n\nWhen the server hands a client the closure contract, it is distributing the standardized part — the criteria that someone already coordinated, agreed on, and externalized. Applying those criteria to real findings is execution against a fixed axis. That part is delegable. It is, in the most precise sense, work that supports a decision.\n\nWhat does not cross is the last step: deciding, with stakeholders, that *this* closure is acceptable in *this* situation — and owning that decision. No contract removes that. The moment a case falls outside the externalized axis, the work stops and returns to a human, because the coordination that would resolve it was never externalized in the first place.\n\nBy coordination, I do not mean communication. I mean the process of reaching new shared judgment that has not yet been externalized.\n\nThat is why the inert boundary matters beyond performance.\n\nThe MCP boundary ends up sitting exactly where externalized judgment ends and live coordination begins.\n\nEverything that can be turned into a definition is distributable, and therefore delegable.\n\nEverything that still requires coordination stays on the human side, and never crosses.\n\nThe two-plane design did not impose that line. It revealed it.\n\nI built this on MCP, but the boundary is not an MCP property.\n\nThis principle is not specific to MCP. Any system that distributes domain knowledge eventually discovers the same boundary.\n\nTransport only distributes externalized judgment. Execution always remains local.\n\nMCP made the boundary easy to see, because it gives named entry points and a clean transport. But a team sharing a wiki, a platform shipping policy bundles, a company writing runbooks — all of them hit the same wall the moment they try to distribute not just *what is known* but *how to decide*. The part that can be written down travels. The part that still needs a human to coordinate a new judgment does not.\n\nThe protocol changes how far the inert part can travel. It does not move the line.\n\nAcross these three posts the question kept narrowing.\n\nFirst: is MCP RPC, or something else?\n\nThen: should the bootloader hold knowledge, or point to it?\n\nNow: where, physically, does judgment get distributed, and where does it refuse to?\n\nThe answer the implementation gave me is sharper than the one I started with.\n\nA skill can distribute judgment axes.\n\nIt cannot distribute the act of judging.\n\nThe transport boundary, if you draw it honestly, is just the second sentence made mechanical.\n\nOnly inert definitions cross.\n\nEverything that still needs coordination stays home.", "url": "https://wpnews.pro/news/only-inert-definitions-cross-the-boundary", "canonical_source": "https://dev.to/synthaicode_commander/only-inert-definitions-cross-the-boundary-1jdf", "published_at": "2026-06-26 13:57:32+00:00", "updated_at": "2026-06-26 14:04:20.062194+00:00", "lang": "en", "topics": ["developer-tools", "artificial-intelligence", "ai-agents", "ai-infrastructure", "large-language-models"], "entities": ["XRefKit", "MCP", "XRefkit.MCP"], "alternates": {"html": "https://wpnews.pro/news/only-inert-definitions-cross-the-boundary", "markdown": "https://wpnews.pro/news/only-inert-definitions-cross-the-boundary.md", "text": "https://wpnews.pro/news/only-inert-definitions-cross-the-boundary.txt", "jsonld": "https://wpnews.pro/news/only-inert-definitions-cross-the-boundary.jsonld"}}