What "One Source of Truth" Actually Means for Product Data

"One source of truth" gets used as a description of intent, we'd like our data to be consistent, when it's actually an architecture decision with specific requirements. A dashboard that pulls numbers from three platforms and displays them together isn't a source of truth. It's a reporting layer, and it inherits whatever inconsistencies already exist in the systems underneath it.

The first real requirement is SKU mapping, and it's the least glamorous part of the whole project. Amazon, Shopify, and WooCommerce each let a seller structure product identifiers differently, and a product that's genuinely the same item can have three different SKUs, three different titles, and three different variant structures across platforms. Before any syncing logic can work, something has to map "these three listings are the same product" reliably, including when a supplier changes a SKU format or a platform's own ID rules change.

The second requirement is deciding which system owns which field, not just where data lives, but which platform's value wins when two disagree. Price might be centrally managed and pushed out identically everywhere; product description might be allowed to vary by channel for SEO reasons; stock count has to be centrally owned or the entire premise falls apart. Without explicit ownership rules per field, "sync" just means "the last system to write wins," which produces exactly the kind of silent data drift a source of truth is supposed to prevent.

The third requirement is conflict resolution for the cases ownership rules don't cleanly cover: a product edited directly on Shopify by someone who didn't know it was centrally managed, or an Amazon-specific compliance edit that has to survive the next sync instead of getting silently overwritten. A real source-of-truth system needs an explicit answer for what happens here, flag it for review, always defer to the central system, or something else, chosen on purpose rather than by whichever code path happened to run last.

The fourth requirement, and the one that actually separates a source of truth from a fancy dashboard, is owning writes, not just reads. A system that only aggregates data from three platforms for reporting can tell you your numbers disagree. A system that's the actual source of truth is where you make the change once and it propagates outward; the platforms become synced channels, not independently editable copies.

This is what "product information management" is really describing when vendors use the term: a central system with mapped identifiers, explicit field ownership, defined conflict resolution, and outbound write authority to every connected channel. Without all four pieces, you have a partial version that looks consistent until the day two channels disagree and nobody can say with confidence which one is right.

Getting this right is mostly a sequencing problem, not a technical one. We typically start with the fields causing the most damage when they drift, stock and price almost always come first, get those centrally owned and synced correctly, then expand field ownership outward as trust in the system builds. Trying to centralize every attribute of every product on day one is how these projects stall before they deliver anything.

The payoff, once it's actually built this way, isn't just fewer reconciliation headaches. It's that adding a new sales channel becomes a mapping exercise against a system that already knows what's true, instead of another independent copy of your catalog to keep in sync by hand.