PMC - Product Merchandising Control

PMC is the publishing control plane. It turns PVM product models into channel-specific, versioned product records that can be set online or offline. If PVM is the source of truth for what a product is, PMC is the system that decides what is live, where, and when.

PMC is built around the idea of immutable revisions. Every publish creates a new revision record. Exactly one revision can be online for a given product identity at any time, or none if the product is taken offline.

Service scope and boundaries

PMC owns publish-time state and online/offline control. It does not create product models (PVM does that) and it does not define org structure or sales channels (OFM does that). Its job is to turn valid PVM data into channel-ready, immutable publish records.

Implemented feature breakdown (what exists today)

• Publish runs: Publish a single variant or a broader set of products.
• Immutable revisions: Each publish creates a new revision with a required reason.
• Online pointer management: Set a revision online or clear it to take a product offline.
• Publishability profiles: Per-channel requirements for what data must exist to publish.
• Content packs: Immutable bundles of publish artifacts.
• Publish manifests: Structured records that describe what was published in a run.
• Search and list surfaces: Exact and partial-match queries for operational workflows.
• Auto-offline behavior: When upstream data becomes invalid, PMC clears the online pointer to prevent stale listings.

How the features are implemented (behavioral breakdown)

Publish run flow

1. A publish run is created with a reason and a target scope.
2. PMC evaluates publishability rules for each candidate product.
3. Eligible products receive new immutable revisions.
4. The online pointer is set to the new revision for each eligible product.
5. Skipped products are reported for follow-up.

Revision and online pointer management

• Revisions are immutable once created.
• Exactly one revision can be online at a time per product identity, or none.
• Operators can switch which revision is online or clear the online pointer entirely.

Publishability profiles

• Profiles define required attributes per channel.
• Missing required data causes a product to be skipped rather than blocking the entire run.

Content packs and manifests

• Content packs capture immutable artifacts tied to a publish.
• Manifests summarize the published outputs for audit and retrieval.

Search and list

• Search supports operational lookup by common product identifiers.
• Partial-match search exists for high-throughput workflows where exact matches are not enough.

Example use cases (extensive)

Channel launch: A retailer adds a new sales channel in OFM, defines publishability rules in PMC, and runs a publish. The run creates revisions and sets online pointers. Any products missing required data are reported and skipped until corrected.

Seasonal refresh: A merchandising team updates product data in PVM, then publishes a new seasonal revision. The old revision remains available for audit, while the online pointer shifts to the new revision.

Emergency offline: A supplier is suspended or a taxonomy category is deactivated in PVM. PMC detects the invalid state and clears the online pointer for affected products to prevent stale data from staying live.

Operational lookup: A support team uses search to locate a product by code, alias, or barcode, then checks which revision is currently online for a specific channel.

Selective republish: Only a subset of variants are republished after data fixes, leaving unrelated products untouched while new revisions are created for the corrected items.

Example scenarios and acceptance criteria

Scenario 1: Publish run with skipped variants

• A publish run targets a category with mixed eligibility.
• PMC publishes eligible variants and skips those missing required attributes.
• Acceptance: published variants get new revisions and online pointers; skipped items include reasons and do not block the run.

Scenario 2: Online pointer rollback

• A publish introduces an issue in a channel listing.
• An operator switches the online pointer back to the prior revision with a reason.
• Acceptance: exactly one revision is online; audit history preserves both publish and rollback reasons.

Scenario 3: Auto-offline on upstream invalidation

• A PVM category or supplier is deactivated.
• PMC clears online pointers for affected products within policy windows.
• Acceptance: products are offline, reasoned, and traceable to the upstream change.

Scenario 4: Content pack retrieval

• A publish run creates content packs and a manifest.
• A downstream system retrieves manifest parts for downstream processing.
• Acceptance: content packs are immutable, tied to the publish run, and retrievable by reference.

Scenario 5: Partial-match search for support

• Support searches by a partial code or alias to locate a listing.
• Results are scoped to the org and channel context.
• Acceptance: partial matches return only eligible products; data is consistent with online pointer state.

Constraints and invariants

• PMC is strict about revision integrity. A publish always creates a new immutable revision.
• Only one revision can be online at a time for a product identity.
• Every publish requires a reason to capture business intent.
• Publishability rules are enforced consistently; missing data causes a skip, not a failure of the run.
• Search and list surfaces are operational tools, not analytics group-by workloads.
• PMC supports bounded key aggregation via POST /pmc/product/group for known values (org-gated, online/offline filters). Rollup-backed counts are used for values[] where available; top buckets fall back to the search plane.

How PMC fits with other services

PMC consumes product snapshots from PVM and relies on OFM sales channel declarations to define product identity per channel. USM sessions and API keys provide authentication, and OFM membership governs authorization. MRS may be referenced for large publish artifacts through content packs and manifests.

Implemented vs planned

Implemented: immutable revisions, online pointers, publish runs, publishability profiles, content packs, publish manifests, and search/list surfaces.

Serving-grade group-by rollups remain bounded; use POST /pmc/product/group for key aggregations and the analytics backend for unbounded grouping.

For exact request and response shapes, see the PMC contract pages at https://doc.g3nretailstack.com/pmc/.