The architecture behind scalable product data transformation — and why most brands are solving it the hard way
Mohamed Amer, CEO & Co-Founder, BridgeCommAI | April 14, 2026
I. The Retail Data Problem Nobody Talks About
You’ve landed meetings with Target, Walmart, and Amazon. Your product is great. Your brand story is compelling. Then someone on your ops team opens the retailer portals and reality sets in.
Each of those retailers wants the same core product information — what the product is, how much it weighs, what it costs, what it looks like — but they want it expressed in completely different systems, formats, and structures. Not different spreadsheet columns. Different submission paradigms.
Walmart
Walmart migrated all sellers to Item Spec 5.0 (OmniSpec) in August 2025 — a full taxonomy overhaul, not an incremental update. Required fields now include a 500–1,000-word long description, manufacturer name and part number, a minimum of 4 product images (6 recommended at 2,000 × 2,000px), and a structured attribute schema that varies by product category. The old short description limit was retired. The new model emphasizes structured attributes over free-form text. Every item needs to match Walmart’s current OmniSpec attribute model or it won’t pass validation.
Amazon
Amazon uses category-specific flat files submitted through Vendor Central or Seller Central. The file format and required fields change by product category — grocery, health & beauty, and household each have their own template. Title rules tightened in January 2025: special characters are now prohibited, and word repetition within titles triggers automatic rejection. Backend keyword fields (up to 250 bytes) are separate from all listing fields, invisible to shoppers but critical for search indexing — many brands don’t know they exist. Amazon can also auto-update listings using AI if sellers don’t act on its suggested changes within 14 days; brands need to monitor their listings post-submission.
Target
Target’s item setup process is fundamentally different from the other two. Brands do not self-submit product data through a portal form. Setup flows through Partners Online (POL), then through LaunchPad and IMN — internal tools that vendors access only after being aligned by a Target buyer. Brands have 48 hours to begin setup after Vendor Alignment. Product attribute data is submitted in a structured XML format. Target’s own Item Data Specialists then write the final product title on Target.com from those vendor-provided attributes — the vendor does not control the final listing title. Some items require additional approvals — Import, Hazmat, or Scale Label — before they can go live; these need to be identified and flagged before submission, not discovered after rejection.
If you’re managing this by hand, you’re not solving the same problem three times. You’re solving three structurally different problems, each with its own workflow, its own file format, its own validation logic, and its own timeline. And every time any one of those retailers updates their requirements — which all three did in 2024 and 2025 — every brand in every pipeline is affected independently. And the architecture you choose to solve it with determines not just how fast you get into Target — it determines whether your products are findable when consumers stop searching and start asking AI agents to shop for them. We’ll come back to that.
“If you have 10 brands and 5 retailers, the brute-force approach requires 50 custom data workflows. Add one more retailer, and you’re not adding one workflow — you’re adding 10. The complexity explodes.”
II. The N×M Complexity Problem
Here’s a useful way to think about what’s actually happening. Call the number of brands N and the number of retailers M.
In the traditional approach, consultants, spreadsheet specialists, or in-house operations handle each brand–retailer combination separately, with its own custom data transformation. Brand A’s data goes through one process for Target and a different process for Walmart. Brand B goes through the same two processes, plus a third for Amazon. Every time a retailer changes a requirement (and they do, frequently), every affected pipeline breaks independently.
Traditional approach:
N brands × M retailers = N×M pipelines
Example: 10 brands × 5 retailers = 50 custom workflows
Add 1 new retailer = +10 new pipelines
Retailer updates Item Spec = update N pipelines
The problem scales quadratically. Every new retailer multiplies the operational burden by the total number of brands. Every new brand multiplies it by the number of retailers. At any meaningful scale, this is unsustainable. This is why most CPG brands stay stuck at one or two retail channels long past the point where their products could win in a third. The barrier isn’t product quality or buyer relationships. It’s the operational cost of managing product data across multiple, structurally incompatible systems.
III. The Architectural Solution: A Universal Translator
The fix is a design pattern that engineers in other domains discovered decades ago: instead of connecting every source directly to every destination, route everything through a common intermediate format.
In our case, that means creating a single, comprehensive product data structure — a universal schema — that captures everything needed to describe a product completely. Every brand’s data gets transformed into this format once. Then, retailer-specific outputs are generated from that single representation.
N+M architecture:
Step 1: Brand data → Universal schema (1 transformation per brand)
Step 2: Universal schema → Retailer format (1 transformation per retailer)
10 brands + 5 retailers = 15 total transformations
(vs. 50 in the N×M approach)
Add 1 new retailer = +1 transformation, not +10
Retailer updates their spec = update 1 adapter, not N pipelines
The math now scales linearly. Adding a new retailer means building one new output adapter that works for all brands. Adding a new brand means building one input transformation that feeds all retailers automatically. The work grows as N plus M, not N times M. This architecture has a name in software engineering: the hub-and-spoke model. Think of an airport hub: flights don’t connect every city to every other city directly. They connect each city to a hub, and the hub connects to everywhere else. What looks like a complicated web of connections becomes a simple, manageable structure.
IV. The Three-Layer Architecture
The universal translator pattern has three distinct components. Each solves a different problem.
Layer 1: Source Adapters (Brand → Universal Schema)
When a brand submits their product data — typically a CSV or spreadsheet export from their internal systems or a prior retailer relationship — a source adapter handles the translation into the universal schema format.
This is where the messiness of real-world data gets resolved: inconsistent column names, different unit conventions, missing fields that need to be inferred, and brand-specific formatting quirks. AI does a lot of the heavy lifting here — it maps columns automatically, normalizes units, and fills in missing fields where the data provides enough context. A human expert reviews anything the AI flags as uncertain. We’ll cover the AI workflow in more detail in Blog Post 4.
Layer 2: The Universal Schema (The Hub)
This is the central data structure that everything passes through. It’s organized into logical groups covering product identity, descriptive content, commercial information, physical specifications, media assets, compliance data, and data quality metadata.
The schema is retailer-agnostic by design. Nothing in it reflects how Walmart structures its Item Spec 5.0 attribute model, how Amazon organizes its flat file templates, or how Target’s LaunchPad expects product data to be formatted. Those retailer-specific details live entirely in the target adapters. The hub itself stays clean and stable regardless of what any individual retailer requires or changes.
The schema is also designed to carry contextual meaning — the attributes that describe what a product means to a consumer, not just what it physically is. That layer becomes important later in this post.
Layer 3: Target Adapters (Universal Schema → Retailer Format)
Target adapters are the translation layer between the universal schema and each retailer’s specific requirements. For Walmart, that means producing output aligned with Item Spec 5.0’s attribute schema — including the new long description format, correct image count, and structured attribute fields. For Amazon, it means generating the right category-specific flat file with current title rules and properly formatted backend keyword fields. For Target, it means producing the structured attribute data that flows into Partners Online, with items requiring special approvals already flagged. Because adapters are configuration-driven rather than custom code, adding a new retailer doesn’t require a software development sprint. It requires building the configuration that maps the universal schema to the new retailer’s requirements. When Walmart migrated to Item Spec 5.0 in August 2025, the change required updating one adapter — not rebuilding every brand’s workflow independently.
V. Why This Matters in Practice
The architectural benefits compound over time in ways that aren’t obvious at first.
Benefit 1: Linear Scaling
When a brand adds a fourth retailer, it’s not four times the work of adding the first retailer. The universal schema for that brand already exists. The new retailer’s adapter already exists. What remains is validation — confirming that the brand’s data satisfies the new retailer’s specific requirements and addressing any gaps.
Benefit 2: Quality Improvements Apply to Everyone
In a direct-pipeline model, fixing a data issue for Brand A doesn’t help Brand B. In a hub model, improvements to the universal schema, validation logic, and AI enrichment benefit every brand simultaneously. When Walmart’s Item Spec 5.0 added the long description requirement, the update to the Walmart adapter applied across all brands in the system at once.
Benefit 3: AI Cost Efficiency
AI enrichment is computationally expensive. In a direct-pipeline model, every brand–retailer combination would require its own enrichment pass. In a hub model, AI enrichment happens once — at the source adapter stage, when data enters the universal schema. That enriched data then generates output for any number of retailers at essentially no additional AI cost.
Benefit 4: The Same Architecture That Handles Today’s Changes Handles Tomorrow’s
All three major retailers updated their requirements materially between 2024 and 2025. Walmart restructured its entire attribute taxonomy. Amazon tightened title and keyword rules. Target replaced its costing tools. In a direct-pipeline model, each of those changes breaks every affected brand–retailer pipeline independently. In a hub model, each change updates one adapter — every brand benefits automatically. The extensibility that protected brands through Walmart’s Item Spec 5.0 overhaul is the same extensibility that positions them for AI-mediated commerce: a channel that’s already reshaping how consumers discover products.
VI. How the Approaches Compare
| Metric | Traditional (N×M) | Hub-and-Spoke (N+M) |
| Onboarding time | 60–90 days per retailer | 30 days for first 3 retailers |
| Cost structure | $30–50K per retailer | $20K for first 3, ~$5K per additional |
| Scaling model | Quadratic (each retailer = N new pipelines) | Linear (each retailer = 1 new adapter) |
| Retailer spec change | Update N pipelines per retailer | Update 1 adapter per retailer |
| Error correction | Fix once per brand–retailer pair | Fix once, applies to all brands |
| AI enrichment cost | Per brand × per retailer | Per SKU, once — reused across all retailers |
| New retailer setup | Build N new pipelines | Build 1 adapter |
VII. The Broader Picture: Where This Architecture Is Heading
The architecture we’re describing isn’t just optimized for today’s retail submission problem. It’s designed to support a fundamentally different future — one that was already visible in the thread we’ve been pulling on since Section I.
AI shopping agents are already changing how consumers discover products. Platforms like Perplexity, ChatGPT, and browser-embedded agents are beginning to mediate the path between a consumer’s intent and a product recommendation. Walmart’s own Sparky AI assistant is already surfacing products based on how well their structured data matches consumer queries. These agents don’t read product pages the way search engines do. They read structured product data, reason about attributes, and make recommendations based on how well a product’s data answers the consumer’s actual question.
A product catalog built on a rich, well-structured universal schema is exactly the foundation that makes a brand’s products discoverable in that environment. The physical attributes that retailers require today — dimensions, weight, certifications, ingredient lists — are a starting point. Contextual attributes — usage occasions, lifestyle contexts, the meaning of the product to the consumer — are what differentiate products in an AI-mediated discovery landscape. This is the layer the schema was designed to carry all along.
Brands that build their product data infrastructure now, on an architecture designed for richness and extensibility, are building a durable competitive advantage. The brands that don’t will find themselves retroactively adding structure to flat, inconsistent catalogs — the same problem that’s slowing down retail onboarding today.
Conclusion
The N×M problem in retail product data isn’t a data entry problem. It’s an architectural one. The solution — a universal intermediate schema with source adapters on one side and retailer-specific adapters on the other — is straightforward in concept, but the details matter: how the schema is organized, how AI enrichment is integrated, how retailer-specific requirements are managed without contaminating the central data structure, and how the system evolves as requirements change.
BridgeCommAI built Compass, our Phase 1 service, on this architecture. We work with small and mid-sized CPG brands to transform their product data for submission to Target, Walmart, Amazon, and other major retailers in 30 days instead of 90 — at a fraction of the consultant cost.
The next post in this series goes deeper into schema design: how a well-designed product data structure borrows from the same principles that made TCP/IP work for every application on every network. That’s coming later this month.
If you’re a CPG brand building toward multi-retailer distribution, or a retail technology engineer thinking through product data infrastructure, we’d welcome the conversation. Visit bridgecomm.ai or reach out directly to discuss how this applies to your specific situation.