PIM Core, explained

As a catalogue admin, I keep one category tree so every product has exactly one home.

A root split into Physical and Digital, then category, subcategory and leaf category. Names in English and Arabic.

• Admin creates, renames, deactivates and reorders nodes.
• Deactivating a node hides it from the seller upload. Existing products stay.
• A node with active products cannot be deleted. Reassign the products first.
• Every schema change is logged with the admin and the time.

As a seller, I see exactly the fields my category needs, and I cannot submit without the mandatory ones.

Each leaf category carries its attribute set: global, per type (physical or digital) and per category. Each attribute is Mandatory, Optional or Hidden, with a type and a validation rule.

• Rules set on a category inherit to everything below it. A child can override, and the override is visible.
• Hidden attributes are stored but never shown to sellers or buyers.
• A schema change applies to new listings at once. Existing listings are flagged for review, not invalidated.
• In the code today, attributes live only on leaf categories, as text, number or enum, each with a required flag.

As a catalogue admin, I decide which attributes split a product into versions, so sellers compete on the right thing.

Up to five attributes per category are variant axes, for example Storage and Colour on Smartphones. Region is the third axis on Smartphones: UAE, International, US.

• An axis can be pinned to an allowed values list. Values outside it are rejected.
• Only a catalogue admin creates an axis. Custom axes stay off for Smartphones and Electronics.
• An axis is live only when every existing variant in the category carries a value for it.
• Model number does not define identity for Smartphones. Regional units stay one product.
• Whether every axis combination is generated up front or only the ones sellers enter.OPEN

As a seller, when I list something Merit already carries, I attach my offer to it instead of creating a duplicate.

Before anything is created, the upload is matched against the catalogue. Exact match runs on the product and its full set of axis values. AI matching adds a scored match for what exact match misses.

• An exact match on a variant creates an offer only.
• AI matching runs in shadow mode first: Ops sees the score and accepts or rejects every match.
• LiveOps later sets how much is automatic, per category.
• In the code today, exact match compares the title, then the full option set of the variant.

As a seller, I can add the cellular iPad when Merit only carries the Wi-Fi one.

A seller adds a new version of an existing product, or a new product with its first version. A version that cannot be told apart from an existing one stops and becomes a request to the catalogue admin.

• A variant is the product plus its complete set of axis values, unique inside the product.
• A collision follows the ladder in section 04, never a new offer on an existing variant.
• A seller can never create a variant axis.

As a member, when I pick the blue one, I see the blue one.

Each variant can carry its own images. The seller submits candidates, Ops approves the canonical set in PIM, and nothing reaches a client until it is approved.

• Display falls back from variant image to product image to a placeholder.
• Bulk image upload is keyed on the variant SKU, with a per-row error report.
• A per-client switch reverts to product-level images within 60 seconds.
• The Online Catalogue payload for variant images is not yet agreed.OPEN

As a seller with 2,000 products, I upload one file instead of 2,000 forms.

The seller downloads a template for a category, fills it, and uploads it. Columns come from that category effective schema.

• Each row is validated against the schema. The result file carries an error code per row.
• Valid rows go ahead. Invalid rows wait for the seller to fix them.
• A row with an existing SKU updates that product. A new SKU creates a new one.
• Maximum 10 MB and 5,000 rows per file.

As Merit Ops, I trust that a barcode on a product is a real one.

Where a category makes the barcode mandatory, EAN-13, UPC-A and GTIN-14 are checked by checksum.

• Each category sets the barcode as Mandatory, Optional or Not applicable.
• A barcode already used on another product raises a warning for admin review, not a hard block.

As Merit Ops, I can refer to any variant by one id that no seller controls.

Every variant gets a Merit SKU. The SKU the seller submitted is kept alongside it.

• Format merit_variant_sku_ plus ten digits.
• The seller SKU is kept in the variant metadata.

As a member in Riyadh, I read the product in Arabic.

A brand dictionary links brands to products. Product and category content carries English and Arabic, including attribute labels and terms and conditions.

• English is the default. Arabic is stored alongside it, per product and per category.
• Languages beyond English and Arabic.OPEN

As Merit Ops, a product a seller lists in the New World can still be sold by an Old World client.

The live bridge between the two stacks. Product and stock go out by signed webhook to the Online Catalogue, which syncs on to MGC. An Old World order takes stock off the New World offer.

• Physical merchandise only. Gift cards, codes and vouchers are excluded.
• The sync stops on error. A supplier SKU conflict halts it.
• For the Al Fursan move, PIM replaces the Online Catalogue, and sellers upload their catalogue again.

As Merit Ops, I control which products each client store can sell.

Rules decide which products are sellable in which channel. The draft specification orders them: SKU blacklist, then brand denial, then category exclusion, then the channel allow list.

• The Catalog Distribution Service is a draft specification, not a built service.OPEN
• Client catalogue allocation moves to LiveOps.