From Product Record to Product Memory

coil_voltage = 24 V is a record. It cannot tell you which datasheet it came from, what it read last quarter or who approved the change. The moment any of those questions matters, a record is not enough.

The thin record

A conventional catalog stores the winning value and nothing else. A flat field cannot answer the questions that actually come up in operations: where did this come from, was it ever different, and can we trust the system that changed it? When a supplier revises a spec, the old value is simply overwritten and gone. When a figure is wrong, there is nothing to revert to. The record is a snapshot with amnesia.

Product memory

Promote that field into a product memory and the value carries its own context.

Same value, but now it knows where it came from, when it was observed, what it replaced, how certain the system is and who signed off. A record tells a system what is true now. Product memory tells it why, since when and based on what evidence.

History and decisions belong in the canonical record

The instinct is to push history off into a separate audit log. That is a mistake: the moment history lives somewhere else, it stops informing the value. A canonical product record should retain its own lineage (prior values, the sources behind each, and the human decisions that resolved ambiguity) so the record itself is the memory, not a pointer to one. This is the data provenance principle applied over time.

Record versus memory

What memory unlocks

• Rollback. Revert to the last well-sourced value instead of guessing what it used to be.
• Drift detection. When a supplier quietly changes a spec, the memory shows the before and after, and flags it for review.
• Trustworthy agents. An agent can say not just “100–250 V AC/DC” but “per the manufacturer datasheet, observed September, confirmed by the catalog team.”
• Defensible disputes. A supplier or customer disagreement is settled against the cited source.

How to start

You do not need to rebuild your PIM. Start with the fields that cause the most rework or risk (dimensions, electrical ratings, compliance values) and add four things to each: a source reference, an observation date, the previous value and a confidence or review state. The workflow is laid out in fill missing attributes with provenance, and the reasoning in why source matters more than another extracted attribute.

Memory is what makes the Product Identity & Evidence Graph compound rather than merely store. It is the same reason matching should produce knowledge, not just a score: a value that remembers is a value you can build on.

Related

FAQ

What is product memory? +

Product memory is a product record that retains its own history and evidence: each value carries its source, observation date, previous value, confidence and approver, so the record can say why a value is what it is and since when.

How is product memory different from an audit log? +

An audit log is a separate record of changes. Product memory keeps history, sources and decisions inside the canonical record, so they inform the value itself and can be used to roll back, detect drift and answer agent queries.

What is drift detection in product data? +

Drift detection notices when a supplier changes a specification and compares the new observation with the stored memory. The before and after are shown and the change is flagged for review instead of silently overwriting the old value.

Do I need to rebuild my PIM to get product memory? +

No. Start with the fields that carry the most risk and add a source reference, observation date, previous value and confidence or review state to each. The memory can be written back alongside the value.