> ## Documentation Index
> Fetch the complete documentation index at: https://docs.merchantops.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Versioning

> How products are versioned, why enrichment adds versions, and which one holds the richest data.

Products in MerchantOps are **versioned**. Instead of overwriting a product each
time it changes, the catalog keeps successive versions of it, so you can compare,
label, and roll forward without losing earlier data. This page explains how
versioning works and which version to trust. For the shared vocabulary, see
[Core concepts](/getting-started/concepts).

## Versions of a product

A product's `key` stays the same across every version, so all versions of a
product share one identity. Each version has an auto-incrementing version number
starting at 1 and, optionally, a note describing what changed and which version
it was created from — an audit trail of how the product evolved.

<ResponseField name="key" type="stable across versions">
  The identifier shared by every version. Records with the same key, in your
  organization, are versions of the same product.
</ResponseField>

<ResponseField name="version" type="auto-incrementing number">
  A number that increases with each new version, starting at 1.
</ResponseField>

## Enrichment adds versions, it doesn't overwrite

[Enrichment](/getting-started/concepts) — and edits generally — create a **new
version** rather than modifying the existing one in place. That means an
enrichment run never destroys the data you started with: the merchant-supplied
version remains, and the enriched result lands as a new version alongside it.

<Note>
  Enrichment merges data from several sources by priority — **brand site >
  lakehouse > merchant input > AI-generated** — and records the result as a
  new version.
</Note>

## The latest and production versions hold the richest data

Because each pass adds to what came before, the **latest** version is usually the
most complete. You can also mark one version as the **production** version with
the reserved `production` [label](/catalog/display-groups-labels) — that's the
canonical version, and only one version of a product may hold the label at a time.

<Tip>
  When you need a product's best data, read the latest or production-labeled
  version. Some fields — such as brand and identifiers — are populated during
  enrichment, so they may be present only on an enriched version and absent from an
  earlier merchant-input one.
</Tip>

<Warning>
  Because brand and identifier fields may only exist on enriched versions, don't
  assume an early or unenriched version carries them. If a value looks missing,
  check the latest or production version before concluding it was never set.
</Warning>

## How versions relate to publishing

Publishing is version-aware: what goes to a [publishing target](/getting-started/concepts)
is a specific version's content, and a product's publish status (draft / live /
changed) reflects whether its current content matches what was last published.
See [Products & variants](/catalog/products-variants) for the publish-status
summary.

<CardGroup cols={2}>
  <Card title="Display groups & labels" icon="layer-group" href="/catalog/display-groups-labels">
    How the production label marks the canonical version.
  </Card>

  <Card title="Products & variants" icon="box" href="/catalog/products-variants">
    What a product version holds and how variants relate.
  </Card>
</CardGroup>