Enterprise Integration Is Structurally a Mesh-Cognition Problem

Near two decades of this and the diagnosis is not the hard part. I can name what goes wrong on a programme before it starts. So can most people who have run a few. Naming it has never once been enough to stop it — and after the third or fourth time, you stop blaming the execution and start suspecting the shape.

What has never been named is the shape. The canonical model, the consolidated platform, the workshop with every owner booked into it — each one quietly requires a vantage point: somewhere the whole picture resolves, in one model, one architect’s head, one meeting. Across enough lines of business that vantage point cannot be occupied. Not understaffed, not undocumented — unoccupiable. The knowledge is distributed and stays distributed. Programmes are still planned as though it can be gathered into one place, and they stall at the same point every time.

Nobody holds the whole map

Ask who in your organization knows how data gets from a source system to another line of business’s report.

There is no such person. Not because nobody wrote it down — because nobody could hold it.

The team that runs the source knows what the data means. The team that owns the ingest knows what it accepts and how a schema may change. The lake team knows the partitioning, the catalog rules and the retention. The consuming line of business knows what it needs and what it will join on. Each information architect owns the model for their own line of business. The organization-wide model exists only where those models meet. Nobody authors the whole of it.

Follow one feed and it gets concrete. Your data sits in systems your team runs on premise. It has to reach a lake in the cloud so other lines of business can report on it. The service that ingests it and writes to object storage belongs to another team, with its own accepted formats, its own rule for how a schema may change, its own onboarding approval. The lake belongs to a third team, with partitioning conventions, catalog registration and retention rules. Four owners stand between the data and the person who asked for it. None of them owns the path.

Not all of this is about meaning, either. Does a retry double-post? Does a failed record have a replay path? Does a partial failure leave two systems disagreeing? Each answer sits with a different owner. The work stops until those owners are in the same conversation.

Those are engineering questions, not semantic ones, and they stall for the identical reason: the answer is distributed across owners and no vantage point holds it. That is the shape the two share. Meaning is the sharpest case of it, not the whole of it.

Each holds something the others need and cannot supply. That is why integration at this scale runs for years, costs a fortune, and often never finishes.

Scale creates this problem

Two systems inside one department, one team at each end — one person can hold that map. Writing it down as a specification works perfectly well. Plenty of integration is like that, and it should be done that way.

The change comes when the number of owners passes what one mind can hold. Past that point the centralized approach does not get harder. It stops being available.

The map is knowledge, not documentation

A column called cust_ref tells you nothing. Is it a customer, an account, or a contract? Is the identifier unique across the organization, unique per branch, or reused after an account closes? Does status 07 mean the same as the other side’sSUSPENDED? Does their code list include the values they stopped issuing but still hold? Is the amount in minor units? Is that field a date or a datetime, and in whose timezone?

These are the questions that pass testing and fail in production. None of the answers is in the database. They are in the head of the person who has run that system for fifteen years. And the person who knows the source is not the person who knows the target.

Why the usual fixes fail

Serious organizations know all this. Their answer is the global data model: information architects define a canonical target, and every line of business maps into it.

Look at how that model actually gets built. Each architect owns the model for their own line of business. The organization-wide model exists only where those sub-models meet — usually in the lake everyone reports from. Nobody authors the whole of it. The standard answer to “no one holds the map” turns out to have the same shape as the problem.

That is also where the quiet failure lives. The lake serves organization-wide reporting. Your line of business’s “customer” and another line’s “customer” have to mean the same thing once they land. If they do not, the numbers are wrong — not visibly wrong, silently wrong. And no single line of business can catch it, because each one only ever sees its own side.

A bigger platform cannot author the map either: there is no central place holding the knowledge to put into it. A smarter model can guess what cust_ref means. It cannot know, in a system it has never run. Copying everything into a lake copies the data, never the meaning.

And there is no single meaning to copy. What a field means depends on what you are trying to do with it. The same column is the answer for one consumer and noise for another. So “store the meaning centrally” has no well-defined target. There is no one meaning to store.

Centralizing was not a mistake, though. It was forced. Passive systems cannot reason about what they hold, so meaning had to be worked out by people, in one place. That constraint has lifted, because endpoints can now reason. But an architecture built on that constraint does not shed it by adding AI. AI applied to a centralizing architecture makes centralizing faster. It does not make it possible. You can make a hub a great deal smarter. You cannot make it hold what no one holds.

The unit is the cognition node

If the knowledge lives in pieces, the map has to be built in pieces — one owned slice at a time, where it already sits. That slice, bound to its owner, is a cognition node: the person who knows what their fields mean, or their grounded agent, joined to the mesh. No one owns the whole. Everyone owns a slice. Two nodes couple, each bringing what the other lacks, until they reach an understanding neither held alone.

None of that is a hunch about architecture. We test it. Our mesh protocol is published in the open as a specification anyone can read and implement, and the admission behaviour underneath it is measured against predictions registered before we look — including what result would tell us we were wrong. Small owned slices are not a compromise forced on us by the org chart.

We publish the failures on the same terms. More than once, our own claims did not survive their controls, and they came off our pages rather than being quietly rescoped. A vendor who only ever shows you results that worked is selling you something, and you already know what that is worth on a programme like this one.

A node is not only a person. A team is a node. So is a line of business. The unit repeats at every scale. That is why the chain from a field, to a line of business’s model, to the organization’s model is a mesh of meshes rather than a hierarchy. Each level owns its slice. None owns the whole, including the top.

That is what xMesh does. Each expert’s knowledge becomes a node — one grounded in the source, its counterpart in the target. They propose across the boundary, cross-check each other, and flag what they cannot settle instead of guessing. Nothing enters the map until its owner approves it, with a trail back to who said what it means.

Where the two cannot reconcile, that is not the method failing. That is the finding. A disagreement between the person who owns the source and the person who owns the target is exactly what a central specification papers over. Someone picks one reading, writes it down, and the conflict surfaces years later as numbers that do not add up. Surfacing it while both owners are still in the conversation is worth more than a confident answer that was never theirs.

And it never becomes one document. Nothing is pooled: no shared memory, no central store. Each party keeps its own knowledge, and only what they choose to share crosses. The map ends up existing the way the knowledge does — distributed, each owner holding their slice and whatever they have accepted from others.

What this changes

Here is what I want out of this, having watched the alternative fail from the inside. A multi-year programme has to survive every budget cut and every reorganization before it delivers anything. The map assembles incrementally instead, one owned and signed-off field at a time. It pays off before the next reset. The knowledge stays with the people who hold it, rather than in a document that gets scattered at the next re-plan. Each initiative should leave the next one easier: the meanings settled for this piece of work are still there, still owned, when the following piece needs them.

Related: Agentic integration starts where the pipeline breaks · You can’t org-chart a mind.

— Hongwei Xu, Founder, SYM.BOT