Which System Should Own Each Product Fact?

Why one master system is not the whole answer

Product information is created for different reasons.

Engineering creates technical specifications.

Suppliers provide declarations.

Laboratories produce test results.

ERP manages commercial and operational records.

PIM manages structured product content.

DAM manages media assets.

Commerce platforms manage sellable listings.

Compliance systems manage regulatory status and evidence.

WMS manages stock and movement.

Trying to make one of these systems the original authority for every field usually confuses two different jobs:

• where the organisation wants to publish a controlled value
• where the truth for that value originates

A governed product layer can still be extremely useful. The mistake is assuming that the layer itself proves every fact inside it.

System of record

A system of record is the governed place where the organisation maintains the approved value for a defined purpose.

Examples might include:

• ERP for legal entity or commercial master data
• PLM for an approved product specification
• PIM for controlled product content
• compliance system for certificate status
• DAM for approved product imagery
• WMS or ERP for stock.

These are examples, not universal assignments.

The right system depends on the organisation, process and fact.

Source of evidence

A source of evidence is what establishes why a factual claim should be trusted.

That can be different from the system of record.

Example:

recycled_content = 35%

The PIM may store and distribute the value.

But the PIM does not itself prove the 35%.

Evidence may be:

• supplier certificate
• chain-of-custody record
• bill of materials
• test result
• approved calculation
• regulatory declaration.

This distinction is central.

A database can store a claim. Evidence is what supports the claim.

W3C's PROV model is useful background here because it treats provenance as information about the entities, activities and agents involved in producing data. It supports the general discipline of retaining origins, derivations and versions.

Business owner

Systems do not resolve every ambiguity by themselves.

An important fact should normally have an accountable owner or owning function.

That does not mean adding a committee to every field.

For a material fact, the minimum useful ownership might be:

• accountable function
• approved system of record
• evidence source
• escalation route when evidence conflicts.

Examples:

• composition: product development or technical/compliance
• price: commercial or finance
• inventory: supply chain
• certification status: compliance or quality
• product imagery: brand/content operations.

The function names will differ by organisation.

Publication destination

The same governed fact may be sent to several destinations:

• ecommerce
• marketplace
• retailer feed
• printed label
• product specification
• customs or trade process
• compliance system
• Digital Product Passport
• customer service
• internal analytics.

A destination is not automatically the authority.

If a marketplace has the wrong weight, the marketplace should not become authoritative merely because customers can see it.

The organisation needs a controlled published representation generated from the approved fact.

A practical authority matrix

This is an example framework, not a universal architecture.

One "single source of truth" can still be useful

The phrase is useful when it means:

Everyone consuming product data receives one governed current representation.

It becomes misleading when it means:

One application is the original authority and proof for every attribute.

A good pattern is:

distributed authority at source → governed product-information layer → controlled outputs

For example:

• PLM owns approved dimensions
• compliance system owns certificate status
• ERP owns legal entity record
• DAM owns approved images
• PIM assembles the controlled sellable product representation
• channels consume the approved output.

The PIM can therefore be central without pretending that every fact originated there.

What happens when systems disagree?

Suppose:

• ERP weight: 510 g
• PIM weight: 495 g
• supplier portal: 500 g.

Do not choose the answer by system rank alone.

Use a conflict process.

1. Confirm the fact definition

Are all three values measuring the same thing?

• net product weight
• packaged weight
• nominal specification
• measured sample?

A large share of "conflicts" are actually different facts with similar names.

2. Confirm scope

Are the values for:

• model
• one SKU
• one market
• one batch?

A correct batch value can look like a conflict with a correct model value.

3. Check evidence

What supports each value?

A recent controlled measurement may be stronger for actual net weight than an old supplier spreadsheet.

For another fact, an approved engineering specification may be the appropriate authority.

4. Check freshness and effective date

A value can be historically correct and currently obsolete.

5. Check nominated authority

The organisation should define which function can approve the resolved value for that fact type.

6. Preserve the conflict and resolution

For important facts, keep:

• conflicting values
• sources
• decision
• approver
• date
• reason.

Do not silently delete the losing evidence.

This aligns with the existing ActivateDigital resource When a Test Contradicts a Supplier Declaration, which should remain the deeper canonical destination for evidence conflicts.

Authority is fact-specific

The strongest source depends on the question.

A supplier declaration may be authoritative evidence for a supplied material specification.

A laboratory result may be stronger evidence for a measured chemical or physical property.

A PLM record may be authoritative for the approved design.

An ERP record may be authoritative for the legal entity used in trade.

A DAM may be authoritative for the latest approved image.

There is no defensible universal rule such as:

Always trust ERP.

or:

PIM should own all product data.

The system should encode the authority policy by fact class.

Evidence scope has to match fact scope

A certificate may cover:

• one model
• one factory
• one supplier
• one material
• one period.

It should not be stretched to prove a broader claim.

The same applies to tests, declarations and calculations.

If a supplier declaration proves composition for one variant, copying that value to all variants because they share a style ID is not a system integration problem. It is a governance error.

This is why Which Product Facts Belong at Model, Variant and SKU Level? comes before system ownership.

Designing a governed product-information layer

A practical governed layer does not need to centralise every raw document.

It needs enough structure to answer five questions for important facts.

What is the fact?

Use a controlled definition.

Where is it true?

Model, variant, SKU, batch, item or another defined scope.

What is the approved value?

The representation that downstream systems can use.

Why should we trust it?

Evidence, provenance and authority.

What happens when it changes?

Version, correction, new variant, batch event or new identity.

A useful minimum data contract might include:

• fact name
• value
• unit
• scope type
• scope identifier
• system of record
• source evidence reference
• owner
• effective date
• status
• last reviewed
• publication destinations.

This is an ActivateDigital governance recommendation, not a universal standard.

PIM, ERP, PLM, DAM and compliance systems: useful boundaries

ERP

Often strong for:

• commercial master data
• legal entities
• inventory and operational records
• purchasing
• finance-linked data.

Not automatically the best home for rich product content or evidence.

PIM

Often strong for:

• structured product attributes
• channel-ready content
• inherited product data
• enrichment
• controlled syndication.

Not automatically proof of a claim.

PLM

Often strong for:

• product specification
• design
• engineering or development data
• BOM and approved technical changes.

DAM

Often strong for:

• images
• video
• approved media versions
• rights and renditions.

Compliance or QMS

Often strong for:

• certificates
• conformity status
• test evidence
• approval state
• regulatory scope.

Ecommerce platform

Often strong for:

• channel listing
• merchandising
• channel price
• sellability state.

It is usually a publication destination for many facts rather than the original evidence source.

DPP platform

A Digital Product Passport platform can assemble and publish regulated product information.

It should not automatically become the master product database merely because it exposes product information.

The correct role depends on architecture and the applicable regulation.

Common mistakes

Choosing one master system before defining the facts

You cannot decide authority well if "weight", "supplier" and "composition" are not precisely defined.

Treating evidence documents as master data

A PDF certificate is evidence, not necessarily the controlled current product record.

Treating the PIM as proof

The PIM can publish a claim without proving it.

Letting the latest integration overwrite authority

A recently synced value is not automatically more trustworthy.

Ignoring scope

A correct SKU value can conflict with an incorrectly inherited model value.

No owner for conflicts

If no function can approve a resolution, duplicate systems become competing truths.

Publishing before resolving material conflict

If the value matters to safety, compliance, claims or traceability, unresolved conflict should be visible internally rather than silently flattened.

Direct questions

Should ERP or PIM be the source of truth?

Not for everything. Assign authority by fact. ERP may be authoritative for some commercial or master data while PIM is the governed representation for structured product content.

What is a system of record?

The governed system in which an approved value is maintained for a defined purpose.

Can a PIM prove a product claim?

Not by itself. It can store and distribute the claim. Proof comes from the underlying evidence and controlled process.

Who owns product composition?

There is no universal function. Product technical, compliance, sourcing or another accountable team may own it. The key is to nominate the owner and evidence route.

What if ERP and PIM disagree?

First confirm definition and scope, then compare evidence, freshness and nominated authority. Resolve deliberately and preserve the decision.

Should compliance data live in the PIM?

Some controlled compliance attributes can be published through a PIM. Detailed evidence may remain in a compliance or document system. The architecture should connect them.

Does every product fact need one owner?

Not every trivial field needs bureaucracy. Material product facts should have a clear accountable function and resolution route.

Should DPP software become the master product database?

Not automatically. A DPP platform may be a regulated publication layer while authoritative facts continue to originate in ERP, PIM, PLM, compliance, supplier or evidence systems.

Next question

Once fact scope and authority are defined, the next decision is:

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

For a small business

What this looks like in a small business

You do not need a PIM team to separate system of record, evidence source, business owner and publication destination.

The examples are operating patterns, not universal assignments. The correct owner remains fact-specific.

A spreadsheet can be a controlled system of record if identifiers, definitions, ownership and change rules are explicit. A shared drive can hold evidence without becoming the system of record for the product fact. Shopify can be a publication destination without becoming the evidential owner.

Suggested onward links

• How to Organise Product Data Without a PIM
• Digital Product Passport Readiness for Small Businesses
• Which Product Facts Can a Small Business Verify Itself?

Sources and evidence basis

Standards / authoritative references

• W3C PROV Overview and PROV Primer: provenance, entities, activities, agents, derivation and versioning
• GS1 EPCIS: distinction between master data and visibility event data and the use of event information for product movement/status
• GS1 standards for identifiers and traceability

Documented system behaviour

• Shopify Help Centre: variants, SKUs, barcodes and variant-level attributes

Existing ActivateDigital Knowledge

• Passport Evidence: How We Know, and What a Blank Means
• When a Test Contradicts a Supplier Declaration
• What You May Publish When You Do Not Know
• Which Product Attributes Are Worth Fixing Once
• Is Your Product Data Ready for a DPP?

The system ownership model in this article is an ActivateDigital governance recommendation and synthesis. It is not a mandated PIM/ERP architecture.