Comprehension Over Connection

By Aaron Gammon · Founder, Inferrex · June 2026

I spent eighteen years selling integration and data tooling into large enterprises before I built any of it myself. I sat in the rooms where the integration backlog got discussed, watched the consultants get hired, and signed off on the renewals when the thing we'd connected last year broke because a provider changed a field name. So when I say the industry has been solving the wrong problem, I'm not throwing stones from outside. I sold the wrong problem for the better part of two decades.

This piece is the argument I wish someone had made to me earlier. It's a thesis, not a spec — where I'm making a claim about how Inferrex works, I keep it to what it produces, not how it's built. Live platform figures are always at inferrex.com/claims; I don't hardcode them into essays because they change.

If the argument is wrong, the most useful thing you can do is tell me where.

Every integration platform ever built rests on a single unspoken assumption: that integration is connection. That the job is to run a wire from system A to system B, and that doing more integration means running more wires.

It sounds so obvious it isn't worth saying. That's exactly why it's dangerous. The assumptions you never say out loud are the ones you never test.

Look at how the entire category describes itself. Connectors. Integrations. Pipes. The vocabulary is plumbing. A connector is a pre-built wire to one provider. A platform's strength is measured by how many connectors it ships — MuleSoft, Boomi, and Workato all compete on catalogue size, thousands of pre-built connectors each. The implicit promise is: we have already run the wire to the system you need, so you don't have to.

And for the systems on the list, on the day you buy, that promise holds. The trouble is everything that happens after that day.

A connector is a snapshot. Someone, at some point, looked at a provider's API, decided what each field meant, and wired it to a destination. That mapping is frozen at the moment it was made.

APIs are not frozen. They change constantly — fields renamed, deprecated, restructured, new auth, new pagination. Every one of those changes is a small earthquake under a mapping that was built assuming the ground would stay still. The wire doesn't adapt. It snaps. And because the mapping was hand-built by someone who has probably moved on, fixing it means a human re-learning what the original human knew, then re-wiring by hand.

This is the part the catalogue-size number on the slide never shows you. Every connector you own is a maintenance liability with a half-life. The catalogue isn't an asset that sits there appreciating; it's a fleet of snapshots quietly going out of date, each one waiting for the provider to move so it can break and page someone at 11pm.

A mapping tool can only ever be as current as its last manual update. That's not a flaw in any particular product. It's the ceiling of the entire approach.

Here is the distinction the whole argument turns on.

Connection asks: which field do I wire to which field? It's an answer about two specific endpoints, true only until one of them changes.

Comprehension asks: what does this field mean? It's an answer about the field itself — its business meaning, independent of what it's currently wired to or what the provider happens to call it this week.

Once you understand that a field is a customer's email address — not because someone labelled it customer_email, but because the system comprehends what it is — a rename stops being a catastrophe. The provider can call it email, emailAddr, contact_email, or rename it overnight, and a system that understands meaning recognises the same thing wearing a different name. It's a variation, not a breakage.

That's the move. Stop treating integration as the act of joining two things, and start treating it as the act of understanding each thing well enough that joining becomes trivial and re-joining becomes automatic. Inferrex points at any API, reads its schema, and classifies every field by what it means — so the mapping is a consequence of understanding, not a thing a human wires by hand.

Connection is a fact about a pair. Comprehension is knowledge about a thing. One of those goes stale the moment the world moves. The other doesn't.

Now the part that turns a philosophical distinction into a business one.

Connection scales linearly with the wrong number. Each provider you support is one more snapshot to build and maintain. N providers means N connectors to keep alive — and that's the optimistic version, because the value people actually want isn't connectors, it's integrations between systems, and the number of possible pairs among N systems is on the order of N². The demand grows quadratically; the connector-building effort grows linearly behind it; and the gap between the two is precisely where the integration backlog lives. It's why there's always a "we don't support that one yet," and always will be.

Comprehension breaks the geometry. Understand a provider once — what its fields mean, in the canonical language every other provider is also understood in — and it can reach every other comprehended system through that shared understanding. You map each provider to the canonical meaning a single time; any system reaches any other through the hub. That's N acts of comprehension instead of N² hand-built wires. And because comprehension is knowledge rather than a snapshot, the same understanding that connects A to B already connects A to C the moment C is understood too.

So one model spends linear effort to chase quadratic demand and never catches up. The other spends linear effort to understand and gets the quadratic web of connections as a consequence. That isn't a better version of the same product. It's a different shape of cost — and over any real time horizon, the two curves aren't close.

I make the maths visceral in a companion piece on the N×N problem; this is the short version. The point to hold onto: the incumbents aren't behind because they execute badly. They're behind because they're running linear effort at a quadratic problem, and no amount of execution fixes the wrong exponent.

Spell out what disappears when you stop wiring and start understanding.

The integration backlog disappears, because there's no queue of connectors to hand-build — point at the API and it's comprehended. The 11pm breakage page disappears, because a provider changing a field is a variation the system recognises, not a snapped wire. The consultant disappears, because there's no field-mapping exercise to bill for. The slow erosion of a connector catalogue disappears, because understanding doesn't rot the way a snapshot does — it gets better as corrections feed back in.

This is also why "everyone can stay different" is possible rather than a slogan — most platforms force every system to conform to one schema, and conformity is the thing that breaks; a comprehension layer adapts to difference instead of demanding it away. I make that case in full in a separate piece.

If you're buying integration tooling, the question to ask isn't "how many connectors do you have." That's the catalogue-size trap — it measures snapshots, and snapshots decay. The question is: "what happens when a provider changes?" Because that's not a rare event you can wave away; it's the steady-state weather of running integrations, and the answer to that one question tells you whether you're buying a fleet of wires to maintain or a layer that understands.

The integration industry got very good, over twenty years, at connecting things. I helped sell that competence. But competence at the wrong problem is still the wrong problem. Connection was never the job. Comprehension was — it's just that, until recently, no one could build a system that actually understood what it was looking at.

Now you can. That's the whole thing.

See it in practice on Functionality, or browse what's been comprehended so far in the Corpus.