When a Product Changes, Do You Overwrite the Fact, Version the Record or Create a New Product?

Five different kinds of product change

Before deciding what to do, classify the change.

1. Correction

The product did not change. The data was wrong.

Examples:

• typo
• wrong unit
• transposed number
• incorrect supplier name copied into a record.

2. Effective-date change

The product or governed fact changes from a known point in time.

Examples:

• approved specification revision
• changed environmental calculation
• certification renewal
• new declared product weight.

3. Production-run change

One batch or lot differs while the commercial product remains the same.

Examples:

• different manufacturing plant for one run
• supplier lot substitution
• batch-specific test result
• production date.

4. New sellable configuration

The business introduces a configuration customers, warehouses or channels need to distinguish.

Examples:

• new size
• new colour
• new pack count
• market-specific version
• formulation option.

5. Identity-level change

The change is material enough that the relevant identifier standard, regulation or business model treats it as a different product or trade item.

Examples depend on the applicable rules. There is no universal "materiality percentage" for product identity.

When overwrite is appropriate

Overwrite can be appropriate when the previous value was wrong and no genuine historical product state is being replaced.

Examples:

• wieght corrected to weight
• 500 kg entered instead of 500 g due to unit error
• spelling correction in a non-historic descriptive field
• missing information added to a current record.

But overwrite does not have to mean "erase all evidence of the old value".

For important regulated, safety, traceability or claim-related facts, retain an audit trail showing:

• old value
• corrected value
• who corrected it
• date
• reason
• evidence.

The public or operational record can show only the corrected current value while the audit history remains available.

When versioning is appropriate

Versioning is useful when the previous value was true for a period and a new value becomes true later.

Examples:

• a specification changes on 1 October
• a carbon calculation is recalculated under a new method
• a certificate is renewed
• an approved product weight changes
• a compliance classification changes.

A useful version record preserves:

• previous value
• new value
• effective date
• evidence
• reason for change
• approving owner.

W3C PROV is useful conceptual support because provenance models explicitly account for derivation and versioning of information entities.

Versioning protects historical truth.

If a customer bought the product in March, the business may need to know what information was valid in March rather than showing today's value as if it had always been true.

Example: when the product carbon footprint changes

Under PACT v3 a Product Carbon Footprint record has its own footprint identifier: when the PCF changes, the revised footprint receives a new footprint ID, earlier records can be deprecated and the new record can link back through precedingPfIds (product unchanged → footprint PF-1 → recalculation → footprint PF-2 → PF-2 points back to PF-1). The product doesn't automatically become a new product simply because its footprint changed. What changed is a derived data object, which may need its own version identity. This is an example, not a universal DPP rule. Other facts and regulations can use different lifecycle models. If the old value was true under an earlier calculation, don't silently rewrite it as though the new result had always applied. The PCF exchange model: how companies exchange Product Carbon Footprint data.

When to create a new variant or SKU

A new variant or SKU may be appropriate when the change creates a distinct commercial configuration.

Common examples:

• size
• colour
• pack count
• finish
• market version
• formulation option.

But:

not every changed attribute requires a new SKU.

SKU creation is a business and system decision.

Different organisations define sellable configurations differently.

Shopify, for example, treats combinations of option values as variants and uses SKUs for product and variant inventory tracking. That is Shopify behaviour, not a universal rule. See how variants are read from a Shopify store.

A useful test is:

Does this configuration need to be ordered, stocked, priced, fulfilled or reported separately?

If yes, a distinct variant/SKU may be justified.

When a new product identity may be needed

This decision needs extra care because formal identifier standards can apply.

A product-data governance team should consider a new identity when a change affects factors such as:

• consumer or trading-partner distinction
• declared formulation or functionality
• legally required information
• intended use
• regulatory classification
• pack quantity
• major dimensions or logistics treatment
• product generation or model
• safety-relevant characteristics.

But these are decision factors, not one universal rule.

What GS1 actually says about GTIN changes

The GS1 GTIN Management Standard is a specific trade-item identification standard.

For declared formulation or functionality, GS1 says a new GTIN is required when both of these are true:

1. the formulation or functionality change affects legally required declared information on packaging
2. the brand owner expects the consumer or supply-chain partner to distinguish the difference.

That is much narrower than:

Any composition change always requires a new GTIN.

GS1 also has other specific GTIN change rules. Those should be checked directly for the actual change.

Local regulation can require more frequent identifier changes and takes precedence over the GS1 management standard.

Batch or lot instead of new product identity

Some manufacturing changes belong to the production-run layer.

Examples:

• production date
• plant
• supplier lot
• raw-material lot
• shift
• test result
• temporary process variation.

GS1's General Specifications describe batch/lot as information used for traceability and explicitly state that it is not part of the unique identification of the trade item.

A new batch can represent new traceability context without automatically creating a new trade item identity.

However, if the run-specific change also triggers a formal GTIN change rule, safety requirement or separate sellable product, additional identity action may still be required.

Evidence-only change

Sometimes the product does not change at all.

What changes is:

• certificate
• declaration
• test report
• approval
• method
• claim substantiation.

Examples:

Certificate renewal

The same product remains in market but the certificate is renewed.

The compliance evidence record changes. The underlying product identity may not.

Certificate expiry

The product has not physically changed, but the claim or compliance status may no longer be publishable.

The correct action may be to update the governed compliance state, not create a new product.

New test result

A new test may strengthen, weaken or contradict the existing product claim.

That is an evidence and conflict question first.

Use When a Test Contradicts a Supplier Declaration for the deeper evidence-resolution logic.

Individual item state

A product can remain the same commercial model while one physical item changes.

Examples:

• repaired
• refurbished
• recalled
• ownership changed
• software state changed
• battery replaced
• condition graded.

Those changes may belong to the serialised item record.

They should not automatically change every other unit of the same model or SKU.

Decision tree

Use this as a governance guide, not a universal legal rule.

START
  |
  |-- Was the previous value simply wrong?
  |      |
  |      `-- YES -> Correct current value
  |                + preserve audit history where material
  |
  `-- NO
         |
         |-- Did the truth change from a known effective date?
         |      |
         |      `-- YES -> Version the fact/record
         |
         `-- NO / or more specific scope needed
                |
                |-- Does the change apply only to one production run?
                |      |
                |      `-- YES -> Batch/lot state
                |
                `-- NO
                       |
                       |-- Does it create a separately sellable or stock-managed configuration?
                       |      |
                       |      `-- YES -> New variant and/or SKU
                       |
                       `-- NO
                              |
                              |-- Does an identifier standard or regulation require a new identity?
                              |      |
                              |      `-- YES -> New product/trade-item identity
                              |
                              `-- NO
                                     |
                                     |-- Did only the evidence/status change?
                                     |      |
                                     |      `-- YES -> Version evidence/compliance state
                                     |
                                     `-- Otherwise -> retain same identity
                                                     and document scoped change

In practice, more than one branch can apply.

A formulation change may create a new sellable SKU and require a new GTIN.

A plant change may remain batch-level but also require updated compliance evidence.

Worked examples

Example 1: typo in country name

Record says:

Portgual

Correct value:

Portugal

The product did not change.

Action: correct the field. Keep an audit trail if the field is material.

Example 2: supplier changes but product specification does not

The business changes fabric supplier from Supplier A to Supplier B.

The material specification and sellable product remain unchanged.

Possible action: update supplier provenance from the effective batch/date. Do not automatically create a new SKU or GTIN.

Check whether certification, origin, safety or other evidence changes as a consequence.

Example 3: one colour gets a different composition

Navy shirt:

100% cotton

Stretch black shirt:

98% cotton / 2% elastane

If stretch black is a separately sellable configuration:

Action: lower composition scope to that variant and create/maintain the appropriate variant or SKU.

Then separately check identifier rules.

Example 4: declared formulation changes materially

A consumer product changes formulation in a way that affects legally required declared packaging information and the brand expects customers or trading partners to distinguish the new formulation.

Action: under the GS1 GTIN Management Standard's declared formulation/functionality rule, assign a new GTIN.

This is a GS1 rule for that defined case, not a universal rule for every composition edit.

Example 5: temporary factory switch for one production run

The same model is normally made in Portugal.

One production lot is made in Turkey.

Possible action: capture manufacturing-country or plant truth at batch scope if that accurately represents the business and regulatory reality.

Do not overwrite the model to Turkey if historic and future Portuguese production still exists.

Example 6: certificate expires

The product specification is unchanged.

The certification document expires.

Action: update/version the certification status and evidence. Stop or qualify affected claims if required. Do not create a new product merely because the document date changed.

Example 7: environmental calculation is recalculated

The physical product is unchanged.

A new calculation method changes carbon footprint from 8.4 kg CO2e to 7.9 kg CO2e.

Action: version the calculated fact with method, inputs and effective/publication date. Do not present 7.9 as if it had always been the historical result.

Example 8: one returned item is refurbished

The commercial SKU remains unchanged.

One physical unit receives a component replacement.

Action: update that item's lifecycle state. Do not alter the model specification unless the underlying product definition changed.

Downstream consequences

A product change can affect more systems than the source record.

Potential downstream consumers include:

• ecommerce
• retailer feeds
• marketplaces
• packaging artwork
• labels
• certificates
• declarations
• customs records
• Digital Product Passport
• safety documentation
• recall systems
• customer service
• historic orders.

So the change process needs impact analysis.

For each material change ask:

• Which outputs currently contain the old value?
• Which outputs need the new value?
• From what effective date?
• Do historic orders keep the old representation?
• Does a label or identifier need to change?
• Does evidence need to be re-approved?

The same question applies inside the record before anything reaches an output. A changed input can feed other facts. In Example 2, a new fabric supplier can affect origin, a certificate's coverage or a calculated footprint, while the product name and size range stay as they were. Review the facts that depend on the changed basis and leave the unrelated ones standing.

Keep the earlier answer and its evidence beside the new one, then classify the result using the change types above. When a basis changes, you can see which results rest on it and review them. That's controlled review, not a monitor. ActivateDigital doesn't watch your sources or keep a passport correct without attention.

Change history

A useful product-data history records more than "last updated".

For material facts consider retaining:

• previous value
• new value
• scope
• effective from
• effective to, where relevant
• change type
• reason
• source evidence
• owner/approver
• affected identifiers
• affected downstream destinations.

This does not mean exposing the whole audit log publicly.

It means preserving enough internal history to know what was true and why.

A change history is only useful if the record is versioned, attributed and dated under an identity that never moves, so the code on the pack keeps resolving to the current answer.

Common mistakes

Overwriting historical truth

Today's value is written over yesterday's valid value with no effective date.

Creating a new SKU for every edit

This creates commercial fragmentation and confuses data correction with product identity.

Never creating a new identity

The opposite mistake is keeping one identifier through changes that formal identifier standards treat as a different trade item.

Treating supplier change as automatically identity change

Supplier provenance and product identity are related but not the same thing.

Treating certificate expiry as physical product change

Evidence state can change without product identity changing.

Storing batch-specific truth at model level

A one-run factory or test result can pollute the whole product record.

Applying GTIN rules from memory

GS1 uses defined change criteria. Check the current standard and the actual change.

How long should history be retained?

There is no single universal product-data retention period.

Retention depends on:

• applicable regulation
• product category
• safety and recall needs
• tax/customs requirements
• contractual obligations
• warranty/service needs
• evidence and claim governance.

The governance principle is simpler:

Do not destroy historical product truth before you know which legal and operational obligations depend on it.

A specific retention schedule should be set by the relevant legal, quality and records-management owners.

Digital Product Passport impact

A product change does not have one universal DPP consequence.

The DPP impact depends on:

• the product-specific law
• required passport granularity
• identifier rules
• whether the changed fact is a mandatory passport field
• whether old passport information must remain available
• applicable change or replacement rules.

Do not assume:

Every product change creates a new DPP.

Use the existing Digital Product Passport Granularity and Digital Product Passport Identifiers resources for the regulatory layer.

Who may apply the change

This page decides what kind of change has happened. A separate question is who is legally permitted to apply that change to the DPP. See who can update a Digital Product Passport.

A safety recall adds another system

A safety recall adds another system around this change decision. See how recall duties, DPP corrections and Registry updates stay separate.

Direct questions

When should I create a new SKU?

When a change creates a configuration your business needs to sell, stock, price, fulfil or report separately. There is no universal SKU rule.

Does a supplier change create a new product?

Not automatically. It may be a provenance or batch change. Check whether composition, origin, compliance, performance, sellable configuration or identifier rules also change.

Does a composition change require a new GTIN?

Not automatically. Under GS1's declared formulation/functionality rule, a new GTIN is required when the change affects legally required declared information and the brand owner expects the consumer or supply-chain partner to distinguish the difference. Other GTIN rules may also apply.

Should product weight changes be versioned?

Often, if the previously stated value was valid and a new value becomes true later. A simple correction to an erroneous weight can instead be corrected with history preserved where material.

What happens when a certificate expires?

Update the certification status and evidence. Reassess any affected claims or market-access state. The product does not automatically become a new identity.

Should old product data be overwritten?

Not when it represents genuine historical truth that may matter later. Corrections can update the current value, but material history should be preserved.

How long should product-data history be kept?

There is no universal period. Set retention against applicable legal, safety, contractual, warranty and records requirements.

What changes should create a new DPP?

There is no universal rule. Check the product-specific DPP law, granularity, identifier requirements and whether the changed fact belongs in the passport.

Related questions

• Which Product Facts Belong at Model, Variant and SKU Level?
• Which System Should Own Each Product Fact?

Sources and evidence basis

Industry standards

• GS1 GTIN Management Standard, Release 1.1, especially declared formulation/functionality and related trade-item change rules
• GS1 General Specifications, batch/lot identifier definition
• GS1 EPCIS, event data and supply-chain visibility concepts

Provenance standard

• W3C PROV Overview and Primer

Documented platform behaviour

• Shopify product variant and SKU documentation

Existing ActivateDigital Knowledge

• Digital Product Passport Granularity: Model, Batch or Item?
• Digital Product Passport Identifiers
• Passport Evidence: How We Know, and What a Blank Means
• When a Test Contradicts a Supplier Declaration
• Is Your Product Data Ready for a DPP?

Except where a cited standard or regulation applies, the decision guide is our own recommendation.