# Manage the whole product catalog, not a sample of it.
> Catalog Foundation is the CommerceClarity area that builds the product records every other area reads from. Six agents run here: Data Enrichment, Matching, Variant Grouping, ERP Codification, Catalog Migrator and Product Image Generation. They read the supplier feed, the PIM, the ERP and the DAM without replacing any of them, hold every value to the retailer’s own attribute model, and write the finished record back to the system of record.
Agents that build the product records everything else reads from. SEO, translation and marketplace work all pull from the same fields, so this is where the work starts.
## The catalog is the constraint
A product record starts life in three or four systems at once. An ERP with codes and no copy. Supplier files in whatever shape the supplier felt like sending. A PIM built to hold specifications rather than to sell them. A spreadsheet holding the hand-offs together, maintained by the one person who understands it.
None of that is wrong, and replacing it is not the job. The problem is narrower: the fields that decide whether a product is found and bought, fit, material, dimensions, the variant it belongs to, the category it sits in, are the fields no system owns. So they get typed in by hand, once per channel and once per market, by the team that is already the constraint.
The cost shows up in assortment. Every channel and every market that needs the same fields retyped is a channel that opens later, with less of the catalog on it. Everything above this layer reads from the same records, so fixing the record once is what makes the other seven areas cheap.
## The jobs on the record
A few of the ones that run here. Each is a single workflow with its own output and its own numbers, and a job you do not see named is usually a variant of one that is. Run one, or run the set.
### Data Enrichment
Auto-enrich product pages from your own or supplier data, recovering missing specs online.
Builds publishable product pages from your own data or your suppliers, and recovers the specs they left out from sources online.
time per product
Continuous
### Data Sourcing
Find the product data you do not have, from outside sources, with the evidence behind every value.
Goes outside your own systems for the values nobody can fill in, reads the manufacturer and the named sources, arbitrates where they disagree, and returns each attribute with its evidence and a confidence.
attributes left blank
Continuous
### Matching
Match products across catalogs and marketplaces: offers to canonical, SKUs to listings, dedup.
Decides whether an incoming record is a product you already carry, links it to the canonical entry, flags duplicates.
duplicate rate
Continuous
### Variant Grouping
Turn flat SKUs into parent products with their variants linked.
Turns a flat SKU list into a family: one parent with the shared content, the children linked to it.
PDPs per product
Continuous
### ERP Codification
Codify new supplier products into your ERP automatically.
Produces the codification your ERP needs before a supplier product reaches the PIM: code, dimensions, weight, packaging.
days to sellable
Continuous
### Catalog Migrator
Migrate your catalog to a new platform, Magento to Shopify and similar.
Maps an existing catalog onto a new platform schema, and surfaces the gaps that need a merchant decision.
weeks of replatforming
One-shot
## A supplier file in, a sellable product out
*Product onboarding*
Twenty suppliers, twenty formats: an XML feed, a CSV dropped on SFTP, an API, a spreadsheet somebody maintains by hand. Every field is mapped onto your own attribute model and normalized on the way in: currency on price, category paths flattened, image URLs rewritten, and a field with no home is flagged rather than quietly dropped. The specs the supplier left blank, fit, material, compatibility, get read off the datasheet and the supplier’s own text, then recovered from sources online and cross-checked. Every value carries where it came from.
## What retailers ask us
### What is product catalog management?
Keeping every product record complete, consistent and current, on every channel that reads it. In a small catalog it is a job one person finishes. Past a few thousand SKUs, with suppliers sending twenty different formats, nobody finishes it. That is where it stops being data entry and becomes an operation.
### Who runs the agents, us or you?
We do, on your data, category by category, and we stay on the account after go-live. What you are buying is the outcome on your catalog, not a licence and a manual.
### Do we have to replace our PIM or ERP?
No. The agents read your PIM, ERP and DAM and write back to them. We sit on top of the stack you already run, and mapping how data enters and leaves is the first thing we do.
### What if the agent we need does not exist yet?
Most of these already run for another retailer and adapt to your catalog, and that adaptation is part of the service. Where a workflow is not covered, we design the agent with you and scope it separately.
### How do you know the output is right?
The KPI, agreed before any build, says whether the business moved on the real catalog. Underneath it we score the work itself against your rules on a sample of your catalog, and that score re-runs on every change.
### Whose data is it?
Yours. The corrections your team makes are what the agents learn from, and both the data and the corrections stay exportable at any point.
## Related areas
## Proven by
## Every correction makes the next run better
*The feedback loop*
Your team judges the output. A value is right, or it is wrong and gets fixed once. Each verdict changes the next run: the score on your own sample moves, and the agent starts from what the last one learned. So the share of values that need a person keeps falling, measured on your catalog and your rules rather than on an average of everybody else.
## Live on your catalog in weeks, not months
*How we work*
We run all four phases with your team, on the stack you already have, and each one ends with a number you agreed in advance.
- Design · We map how your data comes in and how the result goes back out, then agree the business KPI the agent has to move.
- Implement · We build the agent and test it on a sample of your own catalog, agreed with you. Every change is scored against that sample, so the tuning runs on numbers.
- Prove · Done means the KPI reached target on the full catalog, and you have seen the numbers yourself.
- Evolve · We stay on the account. Your corrections keep improving the agent, the KPI holds where you need it, and the next use case starts from the context this one already built.
## Enterprise, on a catalog you cannot break
- It runs on the stack you have · It reads your PIM, ERP and DAM through their APIs and writes the result back to them.
- Nothing uncertain reaches a channel · Every value is checked against your rules, and anything uncertain goes to review before it reaches a channel.
- Your data stays yours · Your own isolated workspace. It is never pooled into shared models, and you can export it at any point.
- Every run is logged · Each value carries its source, its run and its score, so you can see why a wrong one went wrong.
## Start with one use case
One use case, run end to end on your own catalog. That is enough to see what it moves and what it costs per product, before you commit the rest.
## Entities
## Sources
---
Canonical: https://commerceclarity.com/solutions/catalog-foundation
Every page of this site is available as markdown: append `.md` to its path. Index: /llms.txt
](https://cdn.sanity.io/images/xd4hrbt2/production/e447fd9addb331c4f03a57faaa79e6fcae3f6c98-1774x887.jpg?auto=format){kind=link}
](https://cdn.sanity.io/images/xd4hrbt2/production/30815d23ee4d132352d037d84d401a32a7b48eec-2880x1620.webp?auto=format){kind=link}
](https://cdn.sanity.io/images/xd4hrbt2/production/251441053d31b02d7111cf86ee1083ac6fd8f061-1600x1000.jpg?auto=format){kind=link}