Must the object be connected continuously?

No. A label can link to records without continuous connectivity.

Does the memory need sensors?

No. People and business systems can also contribute information.

Is it automatically a digital twin?

No. A history store need not include a simulation or continuously updated model of behavior.

AI Glossary / Graphs and symbolic AI / Advanced

Digital object memory

Definition

A digital object memory is an organized collection of digital information associated with an individual physical object over time. It can record that item's properties, events, usage, and changes, linking a real-world object to information about its history. The information may reside on an attached device, in external systems, or across several connected stores.

What it means

The focus is a particular object instance, such as one numbered instrument, rather than only its product model. Two items made to the same specification can accumulate different histories after manufacture. Keeping their records distinct helps applications answer questions about the item actually being inspected.
The word memory is metaphorical. The object does not need human-like recollection, intelligence, or even its own processor. An identifier can connect it to externally maintained records. AI may later analyze those records, but the presence of a digital object memory does not itself imply prediction, learning, or autonomous behavior.

How it works

An identification mechanism connects the physical item with its records. Depending on the application, this might involve a printed code, an RFID or NFC tag, or a connected sensor device.
Applications add records and retrieve relevant information. Useful records distinguish the event, its time, its source, and its association with the object. Some content can be stored locally, while other content is reached through links. Access to a linked record depends on the availability and permissions of the system holding it.
The historical Object Memory Model described in a 2011 W3C Incubator Group Report organizes content using blocks with metadata and payloads or links. It is an example of a proposed representation, not a requirement that every object memory use the same format. That report is not a W3C Recommendation or an endorsement of a deployed product.

Three practical examples

Equipment history: A workshop links an individually numbered tool to inspection notes, recorded operating hours, and replacement events. Staff can inspect the history of that particular unit. Missing observations remain gaps rather than evidence that nothing happened.
Reusable containers: A logistics team associates each container with recorded dispatches, returns, and condition observations. The history can help investigate discrepancies, provided identifiers remain attached to the correct containers and events are recorded consistently.
Museum interpretation: An exhibit label connects a specific artifact to descriptions, photographs, and accounts of its use. Different accounts may need attribution, and a linked narrative is not automatically a verified historical fact.

Think of it this way

Think of a service notebook that follows one physical item through its life. A digital object memory can make that notebook accessible to several authorized applications and connect it to other records. Its usefulness still depends on whose notes were added, what was omitted, and whether the notebook is attached to the right item.

Worked example

Consider two fictional demonstration devices of the same model, identified as P17 and P18. The project uses an invented administrative review rule: flag a device when recorded operating time since its last review reaches 200 hours. This is a toy rule, not a maintenance recommendation.
P17's memory contains three non-overlapping operating intervals of 80, 90, and 70 hours after its last review. Its total is 80 + 90 + 70 = 240 hours, so the application flags P17 under the stated rule.
P18's memory contains intervals of 60, 50, and 70 hours, totaling 180 hours. The same rule does not yet flag P18. The model-wide total, 420 hours, cannot be assigned to either individual device. Nor does dividing by two and assigning 210 hours to each preserve their separate histories.
Now suppose P17's 70-hour event is imported twice with the same event identifier. Blindly summing records would produce 310 hours. A defined duplicate-handling rule can recognize the repeated event and retain the correct recorded total of 240 hours. This requires suitable event identification; simply deleting records with equal values could remove genuinely different events.
Finally, imagine that an unrecorded operating interval exists. The digital history would then be incomplete even if every stored sum were correct. The application should distinguish “recorded time” from an assertion that all actual operating time has been captured.

Illustrative case study

Fictional Cedar Equipment introduces digital histories for a pool of reusable demonstration units. Its first import groups records by model name, making several units appear to share one history. Reviewers identify conflicting locations and repeated event records.
The team changes the import to use instance identifiers, records the origin of each event, and defines how corrections and duplicates are handled. It tests label replacement and ownership transfer so that records remain associated with the intended item. Staff can see when information is missing or inaccessible.
Adding a tag alone would not have resolved the record-quality problems.

Common misconceptions and mistakes

“A tag contains the entire object's history.” It may contain only an identifier or link.
“Every item of one model shares one memory.” Individual instances can have different histories.
“A digital record proves the event happened.” The reliability of its source and capture process matters.
“No recorded event means no event occurred.” Coverage may be incomplete.
“Digital object memory means computer RAM or the webpage DOM.” These are different concepts despite overlapping terminology.

Business use

Start with the decisions that require an individual item's history. Define identification, event meaning, correction rules, and responsibilities for keeping the records available. Check whether required information can still be accessed when an item moves between organizations or systems.
Evaluate record quality before building analytics on top. An AI model trained on merged identities or duplicated events can learn misleading patterns. Clear provenance and missing-data indicators help reviewers distinguish observed history from assumptions or derived predictions.

Check your understanding

Which device meets the invented review threshold?

Answer: P17, with 240 recorded hours.

Why is assigning 210 hours to each device wrong?

Answer: It replaces distinct instance histories with a model-wide average.

Why retain an event identifier?

Answer: It can help distinguish a duplicate import from a separate event with the same value.

Related terms

Internet of Things
object identifier
RFID
NFC
provenance
event log
asset history
digital twin

Learn next

Design a small record structure for two individually identified objects. Include event identifiers, timestamps, sources, and correction handling, then test duplicate imports, missing events, and a replacement label.

Sources

W3C Object Memory Modeling Incubator Group Report, historical model and use cases: https://www.w3.org/2005/Incubator/omm/XGR-omm-20111026/ Barthel, Kröner and Haupert, Mobile interactions with digital object memories, author-hosted abstract: https://www.dfki.de/en/web/research/projects-and-publications/publication/6330 Haupert, DOMeMan architecture research, author-hosted overview: https://www.dfki.de/en/web/research/projects-and-publications/publication/6839

Previous: Digital image Next: Digital obsolescence