A product is a SKU in an ERP, a spec in a PLM, a line item on an order, a carton in a WMS, a listing on a resale platform. Each is a useful projection of the product from one system's point of view. Each describes part of the product, within the boundaries of the system built to manage it. No single projection follows the physical object through its entire life.
Those boundaries matter. The order closes. The carton is broken down at the dock. The spec is superseded. The SKU is retired. The listing is delisted. The physical object keeps going — changing hands, being repaired and resold, and eventually being recovered or taken apart, long after many of the systems that first described it have moved on.
Each projection is a snapshot. None provides a continuous record of the physical object and how it changes over time.
PLM and PIM describe what a product was designed to be. ERP knows what was ordered and produced. Factory and traceability systems know something about materials and transformation. Warehouses know movement. Certification platforms know claims and evidence. Retail and commerce systems know transactions. Service, authentication and resale platforms create entirely new information later in the product's life.
Each system answers the question it was built to answer. None sees the entire physical context.
When the object crosses a boundary, whether between systems, between companies, or between lifecycle stages, its continuity is often lost, recreated or reduced to whatever identifier and data model the next system understands. Every downstream question becomes a reconciliation exercise.
That was tolerable when a product's data life effectively ended at the first sale, and most business processes only needed a product to be understood within a particular transaction or operational stage.
It stops working when the questions that matter come after it. It stops working when value extends beyond the first transaction. Brands increasingly want to authenticate, service, engage, resell and recover products throughout their lives, while using the resulting data to inform business decisions. The product is no longer simply the subject of a transaction. It becomes a persistent business asset.
Was this specific unit made from a compliant material? Which finished goods are affected by a change to a material or certification? Can this item be authenticated for resale? What was repaired? Who owns it now? What can be recovered from it at the end of its life? What value has this product generated across its lifecycle?
Answering any of these means joining projections created by different organizations, in different systems, under different schemas, at different times. What's missing is continuity around the physical object itself.
A data model for the physical world
Persistent identity creates continuity. A durable identity gives a physical object a reference that isn't confined to any one enterprise system, transaction or lifecycle stage.
That identity becomes an anchor for connected context. EON connects the data that describes an object, the relationships that provide context, and the lifecycle events that record what happened to it over time
Identity doesn't have to stop at the finished product. Products, product batches, serialized items, materials, material batches and other traceable objects can have persistent identities of their own. Suppliers, facilities, certifications and other entities can then be connected through explicit relationships, allowing data to be managed at the level where it actually exists rather than flattened into a single SKU or product record.
A product isn't one flat record with everything stored inside it. It's part of a connected model of independently identifiable objects and the relationships between them.
That distinction matters.
A material batch may contribute to many product batches. A facility may produce many products. A certification may apply to a material, facility, product or defined scope. A component may become part of one product and later be replaced by another. Those relationships provide context without requiring every entity to be duplicated inside every product record.
Persistent identity gives that information a durable reference point. Data can describe an object directly, connect it to other objects, record what happened to it over time, or combine all three.
Composition is a good example. A product might state that it is 80% cotton and 20% polyester. EON can preserve that composition as provided by product data. When the underlying traceability information exists, the product can also be connected to the actual materials, quantities and units of measure that make up that composition.
The first tells you the answer. The second gives you the context behind it.
Certifications work similarly. A certification might appear as an attribute for a particular application while also being represented as a connected entity with its own issuer, scope, evidence, status and validity.
The goal isn't to force product information into rigid buckets. It's to preserve the information businesses already have while adding the identity, relationships and context needed to understand what it means.
Granularity changes what you can know
Identity becomes more powerful when it exists at the level where the question needs to be answered.
At the product level, identity provides a durable reference for what the product is designed to be. A batch identity can connect that design to a specific production run. A serialized identity can preserve the history of an individual physical item. Material and material-batch identities can connect finished goods back to the inputs from which they were made.
Together, those identities and relationships make questions possible that flat product data cannot answer.
If a material lot is found to be noncompliant, which product batches contain it? Which serialized items came from those batches? If a certification expires, which materials, products or production runs are affected? If a component is replaced during repair, what does that specific item contain now?
The more precisely identity and relationships reflect the physical world, the more precisely software can understand it.
Composition changes. Identity doesn't.
A bill of materials describes what a product is designed to contain. The physical object can tell a more complicated story.
Which material lot actually went into a production batch? Which component was substituted when the original was unavailable? Which part was replaced during a repair three years after the sale?
Those changes matter because the product that exists in the physical world may no longer perfectly match the product described at design time.
EON can preserve declared composition while also connecting it to underlying materials, components, quantities and units of measure when that information exists. As those relationships change, persistent identity provides continuity.
A component can be replaced without creating a new identity for the product. A repair can become part of its lifecycle history while the relationship between the product and its components changes. Software can understand not only what the product was designed to contain, but what is known about the specific physical object over time.
Transformation is different. When materials or components become inputs into something new, the resulting object can receive its own identity while retaining relationships to the identities it came from.
Provenance can therefore travel forward with the material. A second-life product doesn't have to simply claim recycled content; where the underlying information is available, it can connect back to the products, components or materials from which that content originated.
The source identities remain part of the lineage rather than disappearing at the point of transformation.
The compliance case makes the difference concrete. If a unit is repaired with a component sourced outside the original chain, the design BOM may still indicate compliance even though the composition of the physical item has changed. A system reading only the design document can return an incomplete or incorrect answer because it has no record of the replacement..
What already exists, and what's missing
Serialized identity isn't a new idea, and we aren't claiming to have invented it.
GS1 identifiers provide standardized ways to identify products and serialized trade items. EPCIS provides a standardized way to capture and share visibility events across supply chains. PLM and PIM systems are highly effective at managing product specifications and product information. ERP systems manage transactions and production. Track-and-trace platforms capture movement, custody and provenance.
Each is strong inside its own boundary.
The missing layer is continuity across those boundaries: a persistent identity and connected context that can span systems, organizations and lifecycle stages while allowing data to remain at the level where it actually exists.
A compliance question, a repair question and a resale question may require very different information, but they can still refer to the same physical object and the same connected context around it.
That's the layer EON was built to provide.
One identity, many identifiers
EON is schema-flexible by design. Supply chains run on different systems, formats and vocabularies, and they are never going to converge on one data model. Asking them to is how these projects fail. The same applies to identifiers: we don't require the industry to standardize on one.
A persistent identity is not another identifier competing with the ones our partners already use. A GS1 SGTIN, supplier part number, brand article code, certifier reference or other identifier can be associated with the same traceable object, allowing each system to continue using the identifier it understands.
Data carriers play a related but different role.
The identity is what persists. Identifiers are how systems refer to it. Data carriers are how the physical product connects to it.
QR codes, NFC tags, RFID and other carrier technologies can provide a physical route to an identity or its digital resources. A product can have multiple carriers for different purposes without creating multiple product identities. The carrier can change. The identifier a particular system uses can change. The underlying identity doesn't have to.
Addressable, the way the web is
Digital documents existed long before the web. One of the web's foundational capabilities was addressability: a resource could be independently located and could reference another resource without sharing the same database, application or owner.
That made it possible to build a connected network across otherwise independent systems.
Persistent identity makes the physical world addressable in a similar way.
Once an object has a durable digital identity, a supplier can contribute provenance, a certification body can verify a claim, a repair provider can record service, and a resale platform can contribute another lifecycle event.
None of them has to own the entire record. None has to abandon the identifiers or systems it already uses.
They need a reliable way to refer to the same thing.
That is what addressability makes possible: independent systems contributing to and acting on connected context around the same physical object.
Why this matters now
Fragmented product data used to be primarily a human interface problem. Someone opened five systems, exported a spreadsheet, reconciled identifiers by hand, and eventually reached an answer. The ambiguity was expensive, but humans could compensate for it.
That becomes a much harder constraint when software is expected to reason and act across the same data. An agent cannot reliably establish provenance when the same physical object is represented differently across every system it touches, without a durable way to establish that those representations refer to the same thing. It should not have to infer that five similar projections probably describe the same object, or reconstruct relationships buried across PDFs, spreadsheets and system-specific schemas before it can answer a question.
Reliable machine reasoning starts with explicit entities. Give the product an addressable identity, make its relationships traversable, and connect data, claims and lifecycle events to the entities they actually describe. An agent can then follow provenance rather than infer it, determine which projections refer to the same thing rather than guess, and act on product data with a much stronger basis for confidence.
As product data shifts from information humans search to infrastructure machines reason over,persistent, explicit identity becomes foundational.
From a transaction to a lifetime
Most enterprise systems are optimized around transactions and operational stages. A product is designed, manufactured, shipped, sold, and the systems involved move on to the next transaction.
The physical product keeps going.It can be authenticated, repaired, resold, recovered, remade and passed between owners, sometimes over decades. Each of those moments can create information and economic value, but only if the product can still be identified and understood.
Persistent identity provides continuity beyond the systems and transactions that originally created the product. An order can close. A SKU can be retired. An enterprise platform can be replaced. The physical product can still retain a durable digital reference around which new lifecycle information can be connected.
And when a product is eventually taken apart, materials and components that carry identities of their own can remain connected to where they came from, allowing provenance to travel forward into what they become next.
Customer relationship software helps businesses recognize that the value of a customer isn't limited to the first transaction; it accumulates across the relationship.
Products can be understood in a similar way.
Product Lifetime Value is the cumulative economic value a product can generate across its lifecycle — through initial sale, service, engagement, authentication, resale, recovery and other interactions. Persistent identity is what makes those interactions connectable to the same physical object over time.
For decades, software has built increasingly sophisticated infrastructure around customers, transactions, documents and digital assets.
The next foundational entity is the physical product itself.
And the timeframe it has to be built for isn't a transaction, a season or a quarter.
It's the life of the object.
