Platform and content — two layers, two cadences
MeshWeaver is two independently deployable layers. Almost every architectural question has a different answer depending on which one it is about, and most confusion about the framework — what gets rebuilt, what needs a release, what a customer owns, why a change is live without a deploy — dissolves once the split is explicit.
The platform makes everything addressable
The platform layer does one thing above all: it makes everything addressable — and everything is meant literally, not just code. A domain record, a spreadsheet, an inbound e-mail, a schema, a business rule, a layout area, an agent, a skill, and every historical version of any of them: each has an address. The platform's job is to resolve that address to whatever answers it — activating the hub that owns it, feeding it exactly the context it needs, enforcing who may see it, and versioning every write.
That is what lets an agent be handed precisely the right context instead of a document dump, makes access control and audit properties of the system rather than features re-implemented per screen, and turns "where does this value come from" into a question with an answer.
That is the whole of it. The platform is a harness, not an application:
| The platform provides | It does not provide |
|---|---|
| addressing and the message hub | your data model |
| the data mesh — versioning, audit, point-in-time restore | your business rules |
| the agent harness — tools, context, threads | your agents' instructions |
| the UI runtime — reactive layout areas | your screens |
| security — SSO, partition-scoped access control | who may see your partitions |
It ships as one versioned container image, it is Apache-2.0 / MIT, and it changes rarely relative to what runs on it.
Content is what the harness routes to
The content layer is the code and data the platform routes to: node types and their Source/,
business rules, layout areas, agents and skills, seed data. It lives in a git repo of node
repos, it is compiled by the mesh on import (see
Node Type Compilation), and it needs no platform rebuild
and no NuGet package — see Plugins.
Because of that, it is iterated far faster than the platform underneath it: daily during a build phase, and thereafter by whoever owns the domain rather than by whoever owns the framework.
What follows from the split
They deploy independently, and by different mechanisms. Content reaches an instance by GitSync from its repo plus a recompile; the platform reaches it as an image roll. Neither blocks the other, and the two failure modes are different — which is why Deploying a plugin change exists as its own page and opens with "merging is not shipping".
A module is the third thing, and it belongs to the platform side. A compiled assembly a deployment turns on by listing it (Modules) travels with the image and activates at boot, so it moves at the platform's cadence, not the content's. A package may carry both — content nodes and a module — which is why the store install can require a restart while a pure-content install never does.
The cadence gap is the point, not an accident. Domain logic that must be changed by the people who understand it cannot sit behind a framework release train. The two-layer split is what lets an appetite rule, a price, or a screen change in an afternoon while the runtime beneath it is upgraded deliberately, on a schedule someone else controls.
Ownership divides on the same line. The platform is open source and replaceable in principle; the content is written against its programming model and is where the domain work actually accumulates. When a deployment asks "what do we own", the honest answer is drawn here: the data and the rules are portable, the layer that renders and routes them is not.
Where the boundary is easy to get wrong
- Putting domain logic in a module. It compiles and it works, and it has just moved that logic onto the platform's release cadence — every change now needs an image. If a domain expert should be able to change it, it belongs in content.
- Reaching for a platform change to serve one deployment. The extensibility hooks (Extensible Defaults, UI Extensibility) exist so that content can specialise behaviour without the harness learning about a specific domain.
- Assuming a merged content change is live. It is not; the mesh serves what it last imported and compiled.
See also
- Plugins — content as a repo of mesh nodes
- Modules — the compiled-assembly lane
- Node Type Compilation — how in-mesh
Source/is compiled - Deploying a plugin change — the mesh-side tail
- Plugin Packaging — how a package carries content, a module, or both