Product data governance: a framework for AI-ready catalogs
Build product data governance that assigns ownership, evidence, approvals, and publishing rules to every important product field.
Product data governance is where a company decides who may change a product field and what evidence makes a change publishable. Without those decisions, the same SKU drifts between the PIM, ERP, storefront, marketplace, and feed.
The fix is a field-level policy. This guide defines the decision rights behind five representative fields, shows how channel standards constrain the output, and explains where Catalog fits once those rules exist.
Product data governance is decision rights
Product data governance is the policy layer that assigns accountability for product facts. It sets the meaning of a field, names its authoritative source, limits who may edit it, defines the approval trigger, and decides what happens when systems disagree.
A field policy should answer these questions:
- Definition: What does the field mean, and which products or markets does it cover?
- Owner: Which role is accountable for the rule and the outcome?
- Authoritative source: Which system or document wins when values conflict?
- Permitted editors: Which people or services may write the value?
- Accepted values or evidence: Which vocabulary, units, identifiers, or proof make a value valid?
- Approval trigger: Which events require review before the value changes?
- Destination rule: How does the approved value map to each channel?
- Publish gate: What must pass before the value reaches a destination?
- Exception path: Who decides when the value is missing, disputed, expired, or rejected?
This is narrower than a catalog policy that says “keep product data accurate.” It gives a steward a decision to make and a publisher a rule to enforce.
Keep governance separate from adjacent work
Governance is often used as a label for every activity around product data. The boundary matters because each activity has a different owner and output.
| Discipline | What it decides or does | What it does not replace |
|---|---|---|
| Governance | Defines ownership, authority, edit rights, approvals, destination policy, and exceptions | Quality measurement or channel delivery |
| Quality | Measures whether a record is complete, accurate, consistent, current, valid, and useful | The decision about who may correct it |
| Validation | Runs tests against a schema, value list, identifier, relationship, or freshness rule | The policy that defines the test and its owner |
| Lineage | Records source, transformation, timestamp, and change history | The decision about which source should win |
| Syndication | Delivers approved records to retailers, marketplaces, feeds, and partners | Ownership of the canonical field |
| PIM or product data management | Stores product content and supports enrichment or workflow | Decision rights across every system and destination |
Catalog’s product data quality guide, product data integration guide, and product data syndication guide cover those adjacent operating jobs. This page stays on the policy that tells each job what it is allowed to do.
Use a field policy, not a blanket policy
A single rule for “product data” is too broad. Price changes hourly. A GTIN should remain stable for the life of a trade item. A material value may need a supplier specification and a category vocabulary. A marketing claim may expire when its evidence or regulation changes.
Write one policy per field or tightly related field group. Version it with an effective date and a scope, such as category, market, seller, or destination. Keep the policy readable by people and precise enough to implement through permissions, workflows, mappings, and publish gates.
The matrix below is a practical starting point. Adapt the roles and systems to your organization, while preserving the decision-rights columns.
Field-governance matrix
| Field | Owner | Authoritative source | Permitted editors | Accepted values or evidence | Approval trigger | Destination rule | Publish gate | Exception path |
|---|---|---|---|---|---|---|---|---|
gtin | Master data lead | GS1-issued identifier and approved brand master | Master-data steward; manufacturer through controlled intake | Valid GTIN with correct length and check digit; one trade item per ID | New item, pack-level trade-item change, or identifier correction | Preserve the same ID; map to each channel’s identifier field; never substitute an internal SKU | Unique, valid, assigned to the right variant, and free of duplicate ownership | Quarantine record; route to master data and the manufacturer |
material | Product engineering or category owner | Manufacturer specification or approved technical sheet | Category steward; engineering; supplier through controlled intake | Controlled material vocabulary plus a specification, test, or safety document | New specification, source change, or new material claim | Normalize terms and units per destination; retain the source value and evidence | Evidence is current, category-required fields are present, and no approved claim conflicts | Route to product steward; send safety or claim conflicts to compliance |
price | Pricing or commerce operations | Effective ERP or commerce price book | Pricing service; approved promotion manager for sale price | Numeric amount, ISO 4217 currency, market, effective interval, and promotion terms | Price-list, promotion, market, or currency change | Map price and sale price to the channel schema; match product page and checkout | Fresh effective value, correct currency, and landing-page and checkout match | Hold the update and route to pricing operations |
availability | Inventory operations | Designated OMS, WMS, ERP, or commerce inventory service | Inventory service only; no editorial or channel copy editor | Approved availability enum plus timestamp, quantity, or fulfillment state | Stock event, reservation, discontinuation, or fulfillment change | Map status to each destination’s values and market rules | Fresh timestamp, successful reconciliation, and no stale offer | Route to inventory operations; suppress the offer when freshness fails |
claims | Compliance lead, with the brand or product owner | Approved substantiation repository, manufacturer evidence, or regulatory record | Compliance, legal, and approved product marketing | Exact claim wording tied to a current test, certification, specification, or legal basis | New claim, wording edit, evidence expiry, or regulation change | Publish only to approved markets and destinations; do not infer stronger wording | Evidence is current, wording is approved, and restricted-claim checks pass | Remove or hold the claim; route to compliance review |
The point of the matrix is control, not bureaucracy. A supplier can contribute a material value without becoming the owner of your customer-facing claim. A marketplace can require a category attribute without becoming the source of truth for it. A channel transformation changes representation, not ownership.
Standards constrain the output, not the owner
Destination specifications make the policy concrete. They do not decide who owns the underlying fact.
- Google Merchant Center: Google’s product data specification defines required and applicable attributes, accepted values, and destination requirements. Its attribute rules can transform primary or supplemental data, test draft rules, and apply changes. Governance should keep those transformations downstream. For example, Google’s
idmust remain stable for an item, whilegtin,item_group_id,price,availability, and variant attributes need explicit mappings. - Amazon: Amazon’s Product Type Definitions API returns a JSON Schema for the attributes and conditional requirements of a product type in a marketplace. Treat that schema as a destination contract. Assign the owner and source before mapping a field such as
material,color, orsizeinto Amazon’s product type. - GS1: The GS1 Global Data Model separates product attributes into Global Core, Global Category, Regional Category, and Country/Local layers. Use the same shape for governance: set a stable core policy, then add category and market rules where the product or destination needs them.
A channel template can change. The field policy should change only through its own approval trigger. That separation prevents a new Google attribute rule or Amazon product-type version from silently changing the meaning of your canonical product record.
Put decision rights into operation
A field policy becomes useful when it changes how work is performed. Use this sequence for a focused rollout:
- Choose the risky fields. Start with fields that cause channel rejection, wrong offers, compliance exposure, or variant confusion. List the destinations that consume each field.
- Name the accountable owner. Assign one owner per field. Record the authoritative source, permitted editors, evidence standard, and exception path. Contributors and downstream consumers can be listed separately.
- Version the policy. Give the rule a scope, effective date, and change reason. Require approval when the definition, source priority, edit rights, or destination mapping changes.
- Enforce at the boundary. Set permissions at the source, use workflows for approval-triggering changes, and keep channel mappings downstream. A destination editor should not be able to rewrite the canonical field.
- Review exceptions as decisions. Every exception needs a reason, owner, temporary or permanent disposition, and next action. If the same exception repeats, change the policy or the source instead of collecting another manual workaround.
Keep quality scores, validation reports, lineage records, and syndication diagnostics attached to the policy they serve. Those artifacts show whether the decision rights work. They do not replace the decisions.
Where Catalog fits in the policy layer
Your organization decides who owns a field and which source is authoritative. Catalog carries those decisions through the product data layer. It preserves approved source data and provenance, keeps live fields synchronized, maps records for destinations, and exposes typed product objects to AI shopping surfaces.
That boundary is deliberate. Your ERP, inventory service, PIM, DAM, pricing system, or compliance repository remains authoritative for the fields it owns. Catalog makes the policy executable at the boundary, keeping live, normalized product data aligned with those decisions without replacing every source system.
For the supplier-versus-product boundary, use our vendor data management guide. For system boundaries and product records, see product data management software. Once the policy is defined, Catalog can help you put it into a live, machine-readable product surface. Talk with Catalog.
