Can we start linear and move to parallel later?

Yes, and most catalogs should. The migration is not painful if your validation rules were written as named, independent checks rather than as one monolithic "ready to publish" flag. Write them separately from the start and converting to per-destination gates is mostly a matter of grouping rules you already have.

What if a product qualifies for the website but not for a marketplace?

It publishes to the website and waits for the marketplace. Parallel gates exist for exactly this case. Holding a product off your own site because a third-party channel wants a compliance document is a self-inflicted revenue delay.

Where should the validation rules physically live?

As close to the destination's requirements as you can manage while still being visible to the people who fix data. Rules buried in an integration script are correct and useless, because the merchant who has to act on the failure never sees them. If they must live in the pipeline, surface the results back into the PIM.

How do we stop a workflow from becoming a bottleneck?

Measure how long records sit in each step, not just how many are in each step. Queue depth tells you volume; dwell time tells you which gate is stuck and whether it is waiting on data, on a person, or on a rule nobody can satisfy.

Does this replace QA before a site release?

No. These gates validate data. Release QA validates code and configuration. A record can be perfectly valid and still render badly because a template changed, which is what regression testing is for.

Should validation run staging-to-production or in parallel workflow steps?

If products publish to a single live environment, a linear staging-to-production gate is enough and anything more is overhead. If products publish to several systems with different requirements, a linear gate forces the strictest destination's rules onto every record and holds the whole catalog to the pace of its slowest channel. That case needs per-destination gatekeepers evaluating in parallel, each publishing its channel the moment a record qualifies.

What validation is for

Validation exists to answer one question at one moment: is this record good enough to be seen by this audience. Staging environments, workflow engines and approval queues are all mechanics in service of that question.

The mistake that produces most of the pain is treating “good enough” as a single global standard. It never is. A product can be complete enough for your own site, insufficient for a marketplace that demands three images and a compliance sheet, and irrelevant to your warehouse system, which needs dimensions and cares nothing for copy. One standard applied to all three either blocks everything on the strictest requirement or lets bad records through to the pickiest destination.

Option 1: linear staging to production

The linear model is simple and, for a large number of catalogs, correct. Records are built and reviewed in a staging state, a validation gate checks that everything required for the live environment exists, and approved records move to production.

This suits you when:

You publish to one storefront, or to one storefront plus feeds that accept whatever the storefront has.
Your channels have the same requirements in practice.
The volume is low enough that a queue of records waiting on one gate does not build up.

The gate here should be complete rather than nominally present. Everything the front end needs to function: classification, pricing, inventory linkage, imagery, the attribute set the category requires, and any configuration that the template depends on. A record that reaches production and renders a blank spec table has passed a gate that was not checking anything useful.

The linear model fails by staying in place three years after the business became multi-channel. The symptom is a large, permanent backlog of records that are ready for something but not ready for everything.

Option 2: parallel workflow gatekeepers

Once records go to several systems with different requirements, validation needs to become plural. Each destination gets its own gatekeeper: a named set of conditions that, when satisfied, publishes to that destination and, when not, states exactly what is missing.

The essential property is independence. Gates evaluate in parallel and do not block one another. A record that satisfies the website gate publishes to the website today even though the marketplace gate is still waiting on a safety data sheet. Speed-to-market becomes per-channel rather than lowest-common-denominator.

A workable gatekeeper has four parts:

A destination. One system or channel, named. Not “external partners”.
Conditions. The specific attributes, assets, relationships and states that destination requires, expressed as checks that can pass or fail individually.
An action on pass. Publish, queue for the next feed run, or mark eligible.
A legible failure. “Missing: hero image, primary material, country of origin”, attributed to a person or team who can act. “Validation failed” tells nobody anything.

Teams skip the fourth part, and then the workflow documents problems without reducing them. A failure message that names the gap turns validation from a wall into a task list.

Rule of thumb. If your validation failures are counted but not itemized, you have built a report. If each failure names the missing field and the person who owns it, you have built a process.

Where the rules should be written

There is a real architectural choice here, and it is usually made by accident.

Rules written in the integration layer sit closest to the destination and get updated whenever the destination changes. They also fail the organization, because merchants never see them and cannot serve themselves. Rules written in the PIM are visible and actionable but drift out of sync with what the destination actually requires, particularly for third-party channels that change requirements without notice.

The arrangement that holds up: define the rules once in a versioned, human-readable form, execute them wherever execution belongs, and surface the results back into the interface where the person who can fix the data already works. A merchant should never have to open a ticket to find out why a product did not publish.

Two things a gate should never do

Never publish partially. A record that publishes with a name and price but no imagery because the image check was advisory is worse than one that did not publish. It is live, wrong, indexable, and nobody is alerted, because from the system’s perspective it succeeded.

Never fail silently on the way back. Destinations reject records after accepting the transmission. A marketplace queues the item and rejects it hours later. A commerce platform accepts the payload, then drops the record on an internal constraint. If those rejections are not read back into your workflow, your PIM believes it has published thousands of products that do not exist anywhere. Reconciling counts by destination on a schedule catches this, and it belongs in your defect reporting rather than being invented separately.

Choosing

Count your destinations, then count the ones with materially different requirements. One, or several that are near-identical: stay linear, and put your effort into making that single gate thorough. Two or more with real differences: go parallel, even if you start with just two gates.

The migration cost is low if your rules were written as discrete, named checks. It is high if “ready to publish” is one opaque boolean computed somewhere nobody remembers. Write them discretely from the start, whichever model you begin with.

Both models depend on the record being structurally sound before it gets here, which is the job of governance at SKU creation. And in either model, the question of whether a record is ready is better expressed as a score than a boolean. See completeness scoring.