In the previous piece, I introduced the Data Layer: the foundation of a knowledge engine, where raw industry signals are captured and structured.
But capturing data is only half the problem. The harder half is connecting it.
In most industries: and the promotional products industry is a perfect example: data lives in silos. Supplier catalogs live in one system. Order management lives in another. Customer history lives in a CRM. Industry event calendars live in a spreadsheet. Compliance data lives in email threads.
The data exists. The signals exist. The problem is that they were never designed to talk to each other.
The Integration Layer is how you fix that.
What Integration Actually Means
Integration isn't just about moving data from one system to another. It's about creating a unified view of reality across systems that were built independently, by different vendors, for different purposes.
This requires three things: connectivity (the technical ability to pull data from each source), normalization (the translation of different data formats and schemas into a common language), and synchronization (the ongoing process of keeping those connections current as source systems change).
Most teams nail connectivity. They struggle with normalization. They rarely get synchronization right.
The Normalization Problem
Here's a concrete example. A supplier's catalog uses "item_number" as the product identifier. Your order management system uses "sku." Your CRM uses "product_code." These are the same thing: but the systems don't know that.
When you try to join these data sets, you get mismatches, nulls, and errors. The data is there. The connection isn't.
Normalization is the work of building a shared vocabulary across systems. It's unglamorous, time-consuming, and absolutely essential. Without it, every query that touches multiple systems is unreliable.
The Synchronization Problem
Even after you've normalized your data, you have a new problem: it goes stale.
Supplier catalogs update daily. Inventory levels change by the hour. Customer orders come in continuously. If your integration layer only syncs once a day: or worse, on demand: your "unified view" is actually a view of the past.
Real-time or near-real-time synchronization isn't just a technical nicety. It's the difference between a system that helps you make decisions and a system that gives you a false sense of confidence based on outdated information.
Why This Matters for Knowledge Engines
The Integration Layer is the foundation on which everything else is built. The Context Layer can only create meaningful relationships if the underlying data is connected and current. The Reasoning Layer can only detect real patterns if the signals it's analyzing are accurate and synchronized.
Get the Integration Layer wrong, and every layer above it inherits the problem: silently, invisibly, and at scale.
Get it right, and you've built something rare: a system where the whole is genuinely greater than the sum of its parts.
That's where Stewart's story gets interesting. And that's where we're headed next.
What this looked like in my work
The PromoStandards vendor integration framework I built at iPROMOTEu was the integration layer problem made concrete. Before the framework, each supplier integration was a custom engineering project: 3-6 months per vendor, no shared schema, no reusable components. I built the ingestion framework that normalized supplier data into a common format and automated the integration pipeline. The result: vendor onboarding time dropped from months to days, and the supplier network scaled from 75 to 200+ vendors without proportional engineering cost.
Read the full case study: PromoStandards Vendor Integration: iPROMOTEu
