How Can Product Presence Become a Business Event Without a Manual Scan?

The useful chain is observation to decision, not sensor to truth

The same basic point holds across RFID, condition sensing and connected logistics even when the technologies differ. A read or measurement only becomes worth recording once it's tied to the right object, put in context and checked against a business rule. Failed or conflicting observations need somewhere to go rather than being silently turned into clean history.

So the phrase “the product created an event” can be misleading. A self-powered connected product may originate telemetry, but in many deployed architectures the product does not decide the business meaning. Readers, gateways, capture applications and business rules do that work around it.

The design question is not “Can the product transmit something?” It is “What has to be true before software is allowed to treat that observation as evidence that a business event occurred?”

What deployed scan-free systems actually prove

Several production systems already remove a manual scan from part of the process. They are useful because each proves a bounded composition rather than a universal architecture.

The common pattern is controlled context. A reader at a known exit, a logistics checkpoint or a monitored reefer has a clearer business interpretation than a radio sighting with no reliable zone or process context.

Better radio hardware does not remove the governance problem either. More observations can improve coverage, but they also create more duplicates, edge cases and data to interpret.

Where EPCIS fits, and where raw telemetry belongs

EPCIS is useful once the business has decided that an event exists and wants to represent or exchange it in a consistent way. The existing EPCIS owner explains the event classes, event-vs-master-data boundary and the role of business context. This page covers the step immediately upstream: how an automatic observation earns promotion into that event layer.

GS1's System Architecture explicitly separates capture infrastructure from the downstream applications that use captured data. It describes raw sensor data being parsed, validated, translated and augmented with higher-level business context before it reaches business applications or becomes an appropriate EPCIS output.

EPCIS 2.0.1 can carry sensor information through sensorElement and sensorReport, including references to raw data and information about processing. EPCIS is not intended to become a dump of every raw sensor reading. Business-oriented aggregation and contextualised sensor information are normally more useful than a stream of uninterpreted telemetry.

That gives a practical split:

• keep high-volume raw telemetry where the sensing system can manage it efficiently;
• preserve enough provenance to explain how the observation was processed;
• promote only the business-relevant result into the event layer;
• keep a reference to raw evidence where the use case needs later inspection.

A well-formed EPCIS event still does not prove the underlying observation was true. The standard can structure the event and its context. It cannot independently establish that the antenna saw the intended physical object, that a sensor was calibrated correctly or that a carrier was not moved to a different item.

What can fool the observation-to-event pipeline

Automatic capture removes one kind of human action. It introduces other failure modes that have to be designed for.

Duplicate and missed reads

An RFID reader may see the same tag repeatedly while it sits in range, or fail to see it when orientation, material, interference or tag placement is poor. A sensor may send the same state after a retry or miss a reporting interval during a connectivity failure.

So the business rule needs to decide what counts as one event. “We received ten reads” and “ten products crossed the door” are not equivalent statements.

Ghost and wrong-zone association

Radio does not respect a painted line on the floor. A reader installed for one doorway may pick up an item just outside the intended zone, or an adjacent antenna may see the same object. Zone design, antenna configuration and timing windows are part of the event logic, not just installation detail.

The same principle applies to location and condition sensors. If the system cannot reliably associate the measurement with the intended product or containment level, a precise measurement can still produce the wrong business conclusion.

Weak physical binding

The digital identifier may be perfectly valid while the tag, carrier or sensor is attached to the wrong physical object. Automatic capture cannot solve that by itself.

If the decision depends on one exact unit, the required identity level and the continuity of that identity matter. The guide to when lifecycle data needs item-level identity covers that granularity decision.

Clock, calibration and configuration drift

Time, threshold, firmware, sensor calibration and reader configuration can all change the meaning of an observation. A temperature excursion is only useful if the threshold and measurement context are known. A location event is only useful if the zone definition is still the one the business rule assumes.

Connectivity and retry behaviour

Gateways go offline. Messages arrive late or out of order. Systems retry. If the event pipeline does not preserve identifiers and deduplication logic, a temporary network problem can become a false sequence of business events.

The evidence discipline is similar to a manual scan: the observation tells you something, but not everything. The separate page on what a scan actually tells you covers the broader evidence boundary around scan observations.

Receiver coverage is the limiting dependency

An ambient product system is only as good as the observation environment it creates.

For RAIN RFID, that means engineering the antenna field and accounting for the physical environment. For BLE, it means deciding which gateways, phones or platform devices are expected to hear the beacon and how often.

The false shortcut is to treat the tag as if it were independently connected to the event system.

One question settles it:

If this receiver disappeared, would the product still create the event?

For a passive RAIN RFID tag, the answer is no. For a BLE beacon, the radio advertisement may still exist locally, but no business event reaches the application unless a receiver detects and processes it.

So plan and cost the receivers as part of the product system, not as a footnote.

What an automatic event does not prove

An automatic event can be operationally useful without carrying more certainty than the observation supports.

It does not automatically prove:

• that the physical object is authentic;
• that the identifier has never been cloned or moved;
• that the observer saw the intended object rather than an adjacent one;
• that a sensor was correctly calibrated;
• that the party creating the event owned the product or had legal authority over it;
• that an EPCIS-conformant event is factually true;
• that every earlier or later event in the history is trustworthy.

Useful systems are often built by composing several partial forms of evidence. Physical binding, issuer trust, event history and observation quality can reinforce each other. None should be silently promoted into proof of all the others.

Once governed events accumulate, they can support anomaly signals from identity, event history, time and location. That is a further inference layer. A strange sequence can justify investigation, but an anomaly is still not proof of counterfeit or diversion.

Privacy is part of the architecture, not a later policy layer

Automatic observation is most defensible in controlled environments where the item has a clear operational role: inventory, tools, logistics assets, equipment or owned infrastructure.

The risk changes after sale or when items travel with people. A product-event history can become a proxy for a person's movements.

A responsible design should prefer:

• purpose-limited observation zones;
• rotating or privacy-preserving identifiers where the protocol supports them;
• minimal retention of raw location or receiver data;
• clear separation between product operations and people monitoring;
• controls against covert consumer tracking;
• explicit security around who can query item histories.

The technical ability to generate more events is not a reason to collect every event.

The economics sits in the assurance and exception path

The reader or sensor is only one part of the operating cost.

A production system may also need tags or serialisation, fixed infrastructure, gateways, connectivity, commissioning, reader-zone engineering, sensor calibration, master-data joins, event filtering, integration, monitoring and people who can resolve exceptions when the automation is uncertain.

The deployment examples above show those burdens exist. They do not provide a defensible universal return-on-investment figure across sectors, technologies and use cases.

A better business case starts with the event, not the hardware. Ask:

• Which manual action or delayed decision are we trying to remove?
• What is the cost of a missed event?
• What is the cost of a false event?
• Can the observation happen in a controlled enough zone or context?
• What exception rate can the operation absorb?
• Does the next action need item-level identity, or would batch, container or location state be enough?

A system that automates a high-value, well-bounded event can justify substantial infrastructure. A system that creates thousands of low-value observations and a large manual exception queue may simply move the work somewhere else.

What to build first

For a first implementation, choose one event with a clear physical boundary and a clear downstream consequence.

Name it in business terms: “Received at warehouse A” is better than “RFID read detected”. Decide what happens when observations conflict or arrive late before you automate, and measure missed and false events in the real environment before you add more locations, sensor types or trading partners.

This is implementation guidance, not a GS1 requirement. The point is to make the business meaning explicit before the infrastructure starts generating large volumes of data.

Maturity: deployed vertically, composable horizontally

The evidence supports different maturity levels for different parts of the system.

The COMPOSABLE rating is the important one here. The technical pieces exist. The design work is deciding how much assurance a particular business event needs and which failure modes the operation can tolerate.

Treat a sensor signal as one piece of evidence, not as proof of authenticity, ownership or permission. That stops a convenient signal from quietly becoming more authoritative than the evidence allows.

What would change this page

This answer should be revisited if:

• GS1 materially changes the capture, sensor or business-event boundary in its System Architecture, EPCIS or CBV specifications;
• a neutral cross-industry standard establishes a broadly adopted observer-assurance profile for automatic product observations;
• repeated multi-enterprise deployments demonstrate the same cross-technology observation-to-event architecture without heavy bespoke governance;
• independent deployment evidence materially changes what is known about false events, missed events or the operating economics of automatic capture.

Sources as at 6 September 2026.

Sources

• GS1 System Architecture v12.0.0, October 2024. Used for the separation between capture infrastructure, processing/business context and downstream applications. It is architecture evidence, not proof of a particular deployment.
• GS1 EPCIS Standard 2.0.1, July 2025. Used for EPCIS event and sensor semantics and the boundary between business-oriented event data and raw sensing. A standard does not establish adoption or event truth.
• GS1 EPCIS and CBV Implementation Guideline. Used for practical sensor-information and aggregation guidance. It is guidance, not deployment evidence.
• Decathlon, Product traceability and RFID technology. Used as first-party evidence of large-scale item-level RFID infrastructure. It does not establish EPCIS use or error-free capture.
• Amazon, Just Walk Out RFID technology. Used as a bounded retail example in which automatic item reads are coupled to a checkout flow.
• UPS, RFID sensing technology, 14 April 2026. Used as company-reported evidence of automatic RFID capture at logistics scale in the US network.
• Maersk, Captain Peter services. Used as a production example of continuous condition/location sensing, alerts and downstream integration. The example is container-level rather than item-level.