Barcode, Passport or Digital Twin: How Much Digital State Does a Physical Product Need?

The six levels of useful digital state

1. Identity only

At the first level, software can answer:

Which product or product class are we talking about?

That may be a model, lot, serialised asset or individual item, depending on the use case.

Identity by itself can support surprisingly useful decisions. It can distinguish one product class from another, scope a lot, attach a record to a serialised item or provide the join key into another system.

It cannot tell you what happened to the product, where it is now, what condition it is in or who owns it.

The choice between lot, serial and item identity is its own architecture question. Use lot, serial or item: which identity level does an operational use case need? rather than treating item-level identity as the default for every product.

Use identity only when: the decision depends on knowing the subject, not its changing history or current state.

2. Resolvable identity

At the second level, the product has a stable identity that software can use to reach current information or services.

The question becomes:

Given this identity, where is the current resource I need?

GS1 Digital Link and the GS1-Conformant Resolver Standard provide current standards-level infrastructure for using product identifiers as Web-addressable identities and resolving them to multiple linked resources.

This is enough for many product-service journeys.

A care guide, manual, accessibility resource, current recycling instruction or post-sale service page may change over time while the physical code remains the same. The product does not need a sensor or event history simply to reach the right current resource.

That is why a product code can support useful after-sale services without the product becoming a live digital model of itself.

Use resolvable identity when: the decision is "where should this product identity take me now?" rather than "what has happened to this exact item?"

3. Event history

At the third level, the system remembers events linked to the product through time.

The question becomes:

What happened to this product, where, when and in what business context?

GS1 EPCIS 2.0.1 provides a mature event model for what, when, where, why and how. Events can describe observations, transformations, transactions, associations and other lifecycle activity.

History matters when the sequence of events changes the decision.

Examples include:

• whether a serialised item passed through a particular service event;
• whether a product has a recorded repair history;
• whether a lot or item was observed in a relevant facility or market;
• whether a transfer or intervention happened before a later outcome.

An event store is not the same thing as product master data. What EPCIS events add to product master data owns that distinction.

An event history is also not automatically a digital twin. It may be a chronological record without a maintained current-state model, predictive behaviour or simulation.

Use event history when: the decision depends on what happened, not merely what the product is.

4. Current derived state

At the fourth level, software turns history and current inputs into a state that can be used directly in a decision.

The question becomes:

Given everything we currently know, what state is the product in now?

That state might be:

• warranty eligible / not eligible / needs review;
• service due / not due;
• recalled / not in affected scope / unresolved;
• repair complete / open / awaiting evidence;
• inventory available / reserved / unavailable;
• inspection required / not required.

The state may be derived from multiple events rather than stored as a permanent fact.

This is a useful architectural step because many operational systems do not want to replay an entire event history every time a decision is needed. They maintain a current representation that can be recalculated or updated as new events arrive.

The danger is stale state. A derived status is only as reliable as the event coverage, rules and update process that produced it.

Use current derived state when: the decision repeatedly needs a concise, governed answer about the product's present operational status.

5. Sensed state

At the fifth level, the product or its environment contributes direct measurements.

The question becomes:

What has been physically measured about this item or its environment?

EPCIS 2.0.1 supports sensor elements alongside product events, allowing condition observations such as temperature or other sensor data to be associated with lifecycle events.

Sensing can make previously invisible decisions possible, especially when the condition of the individual item changes what should happen next.

Examples include temperature excursions, shock, humidity, tamper, usage telemetry or other measured conditions.

But a sensor does not create universal truth. Placement, calibration, sample frequency, missing data and physical attachment all constrain what can be inferred. A temperature sensor on packaging may not prove the temperature of every component inside it. A missing reading may mean "not observed", not "nothing happened".

The deeper architecture for condition-aware products belongs to what changes when a product can report its condition.

Use sensed state when: a decision depends on a physical condition that cannot be established reliably from identity, history or external context alone.

6. Dynamic digital twin

At the sixth level, software maintains a dynamic representation of the product that is updated from events, telemetry or both and is used for prediction, optimisation or action.

The question becomes:

What is the product's current modelled state, what is likely to happen next and what should the system do about it?

"Digital twin" is used differently across industries. For this decision framework, the useful boundary is not the label. It is whether the system maintains a product-specific dynamic model that is refreshed from the physical or operational world and used for decisions beyond simple lookup or event replay.

A twin may combine:

• persistent product identity;
• configuration and relationships;
• event history;
• current derived state;
• telemetry;
• models of degradation, performance or remaining life;
• predicted outcomes;
• optimisation or action logic.

This can be justified for complex, long-lived or high-value assets where the model changes a consequential decision often enough to justify the burden.

It is usually excessive for a product whose only requirement is to resolve a manual, expose a recycling route or confirm a static product fact.

Use a dynamic twin when: prediction, simulation, optimisation or state-dependent control needs a maintained model richer than ordinary product data, events or sensor readings.

A DPP is not automatically a digital twin

A Digital Product Passport can be rich and still not be a twin.

A DPP may provide persistent product identity, governed product data, evidence and links to lifecycle information. Depending on the product rules and implementation, it may also expose changing information.

That does not automatically mean it maintains a continuously or periodically refreshed state model of the physical product, receives telemetry or predicts future behaviour.

The same is true in reverse. A company can have an industrial digital twin that is not the public or regulatory DPP.

The two can share identity and data where useful, but they have different jobs.

Treating every DPP as a twin creates unnecessary architecture and can blur access boundaries. Public or role-based passport information does not need to expose every operational state, telemetry stream or proprietary model used inside a business.

An EPCIS history is not automatically a digital twin either

EPCIS can provide a powerful memory layer.

It can record what happened, when, where, why and how. It can include sensor data and support cross-organisation event exchange.

That still does not make an EPCIS repository a twin by default.

A history can exist without a maintained current-state model. A current state can exist without predictive behaviour. A twin can consume EPCIS events without making EPCIS itself the twin.

This distinction matters because event capture and state modelling solve different problems.

If you only need to know whether a repair occurred, store the repair event. If you need to know the current service state, derive it. If you need to predict failure based on service, usage and telemetry, a richer model may be justified.

Do not jump from "we have events" to "we need a twin" without naming the additional decision the twin would support.

Which decisions need which level?

The simplest way to choose state is to work backwards from the outcome.

The resale example is particularly useful because it shows that richer outcomes do not always require richer internal state. A product's history can change what it is worth by joining item history to external market data. That is a context problem, not necessarily a twin problem.

What changes as state gets richer?

Each level adds capability. It also adds obligations.

More identity granularity

Moving from model to lot to serial or item identity can improve operational precision, but creates more records and can increase lifecycle governance requirements.

Use when lifecycle data needs to follow the individual product to decide whether item identity is genuinely necessary.

More history

Events improve traceability and learning, but only if capture coverage is understood. A system that records some repair channels should not describe silence as proof that no repair occurred.

More current state

Derived state simplifies decisions, but it needs explicit update rules, versioning and exception handling. A stale "serviceable" flag can be worse than no flag if downstream software trusts it blindly.

More sensing

Sensors create physical evidence, but add hardware, power, calibration, connectivity, security and retention decisions.

More modelling

A twin can predict or optimise, but the model itself becomes a governed asset. It needs a definition of state, update frequency, confidence, failure behaviour and a way to show when the model is outside its validated scope.

The key trade-off is therefore not simply data volume. It is decision value versus state burden.

Five example architectures

Static service routing: stop at Resolve

A garment, appliance or packaged product needs to route a user to the current manual, care information or repair entry point.

Architecture:

identity → resolver → current resource

No event history, sensor or twin is required unless the service itself needs them.

Recall scoping: add only the history needed

A business needs to determine whether a unit is in an affected model, lot or serial range and whether there is relevant evidence about where it was supplied.

Architecture:

identity → affected scope → relevant distribution/event evidence → recall action

The precise identity level matters. A twin usually does not.

Repair continuity: use item identity + events

A repair history has to follow a product after resale.

Architecture:

item identity → governed service events → access/write policy → next-owner/service view

That is enough to support persistent history. Repair history across ownership owns the portability, privacy and write-governance problem.

Condition-aware warranty: add sensing and policy

A warranty workflow needs to know whether an individual item experienced a measured condition relevant to the claim.

Architecture:

item identity → sensor/history evidence → policy threshold → approve / inspect / escalate

This requires strong evidence discipline. The sensor must be suitable for the decision and noisy or incomplete data should not be treated as automatic grounds for a high-impact denial.

Predictive maintenance: justify a twin when the prediction earns its keep

A complex asset needs maintenance before failure based on usage, telemetry, service history and modelled degradation.

Architecture:

identity → configuration + events + telemetry → current modelled state → prediction → maintenance decision → action

This is where a dynamic twin can be justified. The twin exists because prediction and optimisation need a maintained model, not because "digital twin" sounds like the most advanced architecture.

When is a digital twin justified?

A twin becomes more defensible when several conditions are true at the same time:

• the asset is long-lived or sufficiently valuable;
• its state changes materially through use or environment;
• events and telemetry can be captured with useful reliability;
• current configuration or relationships affect outcomes;
• a model can predict or optimise something operationally important;
• the prediction changes a real decision;
• the action can be measured against failure, cost, downtime, safety or another explicit outcome;
• the organisation can maintain the integrations, security and model governance over the asset's life.

If those conditions are absent, a smaller state architecture is often stronger.

A twin that is not kept current is not automatically more useful than a resolvable identity and a good event history. It may simply be a more expensive stale model.

When is a twin over-engineering?

A digital twin is probably excessive when the requirement can be satisfied by one of these simpler statements:

• "I only need to know which product this is."
• "I only need to find the current information or service."
• "I only need to know whether a specific event happened."
• "I only need a current eligibility/status result derived from governed events."
• "I only need a single measured condition at the decision point."

It is also excessive when telemetry is collected without a named decision.

More data does not create value by itself. Telemetry with no operational use becomes data exhaust, while still creating cost, access, cybersecurity and retention obligations.

The correct design question is therefore:

What decision becomes possible at the next state level that cannot be made reliably at the current one?

If the answer is unclear, do not move up the ladder yet.

What this means for a connected-product roadmap

Start with the decision, not the technology label.

For every proposed connected-product use case, write down:

1. the decision or action;
2. the identity granularity required;
3. whether a current resource is enough;
4. whether history changes the answer;
5. whether a derived current state is needed;
6. whether direct sensing is necessary;
7. whether prediction or optimisation genuinely requires a dynamic model.

Then stop at the lowest defensible level.

That approach also makes later evolution easier. A product can begin with resolvable identity, add event history when service continuity requires it, add sensing where condition matters and add a dynamic twin only for the subset of products where prediction changes the economics or risk.

The architecture does not need to jump from barcode to digital twin in one step.

Maturity as at 4 September 2026

• NOW: stable identifiers, resolvers, event stores, APIs, sensor-linked events and state models all exist as production technologies.
• NOW, bounded: item-level histories, condition-aware systems and digital twins are deployed in sectors where asset value and operational decisions justify them.
• EMERGING: broader connected-product architectures that reuse identity across passport, event, sensing, context and action layers without forcing them into one monolithic record.
• POSSIBLE: increasingly interoperable cross-brand state models where product identity, events, telemetry and machine actions can move between organisations with shared semantics.
• NOT SUPPORTED: every DPP is a digital twin, every EPCIS history is a digital twin, every product needs item-level sensing or richer digital state is automatically more valuable.

What would change this answer?

Recheck the framework if product-specific regulation begins to require persistent item-level telemetry or state models in major categories, if cross-brand digital-twin semantics become broadly interoperable or if low-cost sensing materially changes the economics for currently static products.

The principle is unlikely to change: use the minimum digital state needed for the decision. What may change is which level becomes economical for a given product category.

Primary sources

• GS1 Digital Link URI Syntax 1.7.0: current infrastructure for persistent, Web-addressable product identity.
  Standards body
• GS1-Conformant Resolver Standard 1.2.1: current mechanism for resolving stable product identity to changing resources and services.
  Standards body
• GS1 EPCIS 2.0.1: mature event model for what, when, where, why and how, including sensor elements that can support condition histories.
• GS1 EPCIS and CBV overview: overview of event, location, movement, chain-of-custody and sensor-data capabilities across organisations.