What Changes When a Product Can Report Its Condition?

The system equation

A useful condition system can be expressed as:

item identity + sensor observation + time + measurement provenance + history + decision policy -> condition decision -> bounded action

The difference from a static product record is the word history.

A product specification might say that an item should be stored within a defined temperature range. A condition ledger can record what a particular item was measured to have experienced and when.

That creates different questions:

• Did this exact item cross a temperature threshold?
• Did it experience a shock event before a later fault?
• Is a warranty claim consistent with the available measured history?
• Should this unit be inspected before resale?
• Should this shipment be routed differently because of a recorded condition event?
• Did a cohort of products share the same exposure before later failures?

The decision is no longer based only on product class, model or declared state. It can become item-specific.

A condition ledger is more than a sensor reading

One reading is an observation. A useful condition ledger needs enough context to make that observation interpretable later.

At minimum, the history should preserve:

That is why the useful concept is a Condition Ledger, not simply “put a sensor on the product”.

The ledger can sit in an event platform, IoT system, service database or another governed store. It does not all have to be encoded in the physical carrier or published inside a Digital Product Passport.

EPCIS provides a standard event layer for sensor history

GS1 EPCIS 2.0.1 matters because the standard supports sensor information alongside events involving identified objects.

That creates a common substrate for joining what happened, when, where, business context and sensor-related information around the same product identity.

The standard does not itself sense temperature, calibrate a logger or decide a warranty claim. It gives applications a way to represent and exchange event history.

The deeper distinction between product master facts and event history belongs with what EPCIS events add to product master data. This page starts after that event layer exists and asks what measured condition changes.

A concrete production pattern: cold-chain condition history

Cold-chain monitoring shows the architecture in a form that is already operationally familiar.

A temperature logger or sensor travels with a product, container, shipment or other identified object. It samples local temperature through time. The history is then used to decide whether the object can continue through the process, needs inspection or should be treated as an exception.

The important change is not that “temperature data exists”. It is that the measurement can be associated with the identity and timeline of the object that the decision concerns.

A simple example looks like this:

Item A was identified at dispatch. Its logger recorded measurements during transit. A defined excursion appeared between two events. At receipt, the decision engine did not merely read the product's normal storage requirement. It compared the measured history with the applicable rule and routed Item A for review.

That is a real production class across cold-chain and industrial monitoring. The Lab evidence supports the technical and deployment class, but it does not provide a portable independent ROI figure that can be generalised across sectors. This article therefore does not manufacture one.

What condition history can change

Quality decisions can become item-specific

Without item-level history, a quality team may know that a shipment, batch or product class was exposed to risk but not which exact units crossed a threshold.

Where the measurement is genuinely bound to individual items, the response can become more selective. Units with relevant evidence can be inspected, quarantined or routed differently while others continue.

That does not mean item identity is always required. If all units share one logger and one exposure, batch or shipment-level identity may be enough. The separate guide on lot, serial and item operational identity owns the minimum-granularity decision.

Warranty can move from declaration to evidence

A warranty workflow can compare a claim with recorded condition history.

That sounds attractive, but it is also where measurement discipline becomes consequential. A noisy sensor, missing period or bad calibration should not silently become an automatic claim denial.

The stronger architecture is:

measured history + explicit policy + confidence/exception handling -> approve, escalate or inspect

A high-impact decision should remain contestable. The system should be able to show what measurement drove the result, what policy version applied and whether the sensor history was complete enough for the inference being made.

Service can become condition-led rather than calendar-led

A service system can use actual condition events to prioritise inspection or maintenance rather than relying only on age or scheduled intervals.

That can be as simple as “this unit experienced a shock above the inspection threshold” or as complex as a model combining multiple measurements and usage history.

The decision model still needs evidence of performance. A predictive-maintenance score is not made reliable simply because it is attached to a product identity.

Resale can include measured state, but not assume higher value

Condition history can give a resale or refurbishment workflow more evidence about an individual item.

That can help route the product to inspection, repair, resale or disposal. It does not mean adding condition history automatically increases price. The commercial effect depends on whether buyers trust the measurements, whether the history is sufficiently complete and how the market uses the information.

The existing guide on digital product identity and resale owns the broader resale question. Repair history across ownership owns the separate problem of persistent service records.

The measurement boundary travels with the history

A condition ledger becomes dangerous when downstream software sees a neat number but loses the limits that made the number meaningful.

Consider a temperature sensor fixed to one side of a package. It may accurately report the temperature at that sensor's location. That does not prove the same temperature existed at the product core during the entire period.

A shock sensor may record acceleration above a threshold. It does not automatically prove hidden damage or causation.

A tamper loop may change state. That can be useful evidence of seal interruption, but it does not automatically tell you who caused it or whether the product itself was altered.

A missing hour of data is not equivalent to an hour of normal condition.

These are not reasons to avoid sensing. They are reasons to keep scope, provenance and uncertainty attached to the measurement.

History also needs correction, not append-only mythology

Persistent history creates another design problem: what happens when an event is wrong?

Sensors can be replaced. Clocks can drift. Gateways can upload late. Calibration records can change. A measurement can be associated with the wrong item.

An operational condition ledger therefore needs correction and provenance rules rather than treating every historical entry as permanently true because it was written first.

EPCIS provides mechanisms for event history and correction semantics, but governance still determines whether errors are found, who may correct them and how dependent decisions are revisited.

That is especially important when condition evidence affects warranty, insurance, service or resale outcomes.

The five maturity questions should stay separate

The overall maturity is therefore NOW bounded.

The frontier is not whether a temperature sensor exists. It is whether different product ecosystems can carry condition history forward with enough identity, calibration, provenance and policy discipline for consequential decisions to trust it.

What this does not mean

A sensor reading is not whole-product truth. It describes the measurement actually taken at the sensor's scope and location.

No data is not normal data. Gaps have to remain visible.

A threshold crossing is not automatic causation. It may justify inspection without proving why a later failure occurred.

An item history is not automatically complete. Coverage depends on sensor power, sampling, network availability, handoffs and system integration.

Correct data does not create fair policy by itself. Warranty and insurance decisions still need proportionate rules and human escalation where consequences are significant.

A DPP is not automatically the sensor platform. Product publication, operational telemetry and event history can remain separate systems linked by identity.

Start with the decision that changes

The strongest condition use cases begin with a decision, not a sensor catalogue.

Ask:

1. What decision would be different if we knew the product's measured condition history?
2. At what identity level does that decision vary: model, batch, serial or item?
3. Which physical variable actually informs the decision?
4. How accurate, frequent and complete must the measurement be?
5. What uncertainty or missing data forces human review?
6. What action follows if the condition is outside the acceptable state?
7. How will we test whether the intervention improved the intended outcome?

That final question remains a separate measurement problem. Testing whether product information changes a business outcome and getting the denominator right are still required before a deployment can claim commercial effect.

What would change this answer

This page should be revisited when cross-sector implementations begin to make the following portable rather than bespoke:

• sensor identity and calibration provenance;
• explicit representation of gaps, clock drift and sensor replacement;
• correction propagation through shared condition histories;
• item-level condition evidence that survives lifecycle and ownership handoffs;
• independently reported decision outcomes such as inspection yield, false-denial rate, reduced failure or faster claim handling;
• standards or common profiles for contestable condition evidence in warranty, insurance or resale decisions.

Until then, the useful conclusion is already strong: persistent identity plus trustworthy sensor history can turn condition into an operational decision input today, but the evidence boundary must travel with every measurement.

Sources

Sources as at 4 September 2026.

• GS1: EPCIS 2.0.1. Used for identified event history, sensor elements and event-context capability.
• GS1: EPCIS and CBV overview, accessed 4 September 2026. Used for the wider visibility model covering product status, location, movement and sensor data.