Field guide · Data and integration
RFID Data Quality: Turn Reads Into Trusted Business Events
Reader output becomes operational evidence only after identity, time, location, business context, and exceptions are reconciled.
A Read Is Not Yet a Fact
A reader reports that it observed an identifier under particular radio conditions. Inventory, custody, shipment, and process state are business conclusions built from that observation. Treating every raw read as truth creates duplicate events, stray reads from adjacent zones, and false confidence when expected items are absent.
The integration layer must decide which observations belong together, which read zone and time window define an event, and how the resulting event compares with what the enterprise system expected.
Reconcile Expected and Observed
The useful control is often a comparison. A shipment system expects a set of serialized items. RFID observes another set. The application identifies matches, missing expected items, unexpected items, and identifiers that cannot be resolved. Each class needs a defined response.
The GS1 US Claims Compliance Implementation Guideline describes this expected versus observed pattern and the use of exception handling. Its apparel context should not be generalized without care, but the control structure is broadly useful.
A previous GS1 US and Auburn RFID Lab study reported substantial order accuracy improvement in its participating retail supply chains. Those figures describe that study and reconciliation process; they are not a universal RFID read accuracy guarantee.
Use a Shared Event Model
EPCIS 2.0 is a GS1 standard for visibility event data. It provides a way to express what objects or quantities were involved, when and where an event occurred, why it occurred in business terms, and additional context including sensor information. It can support exchange across systems and trading partners without forcing every participant to expose its internal application model.
Using EPCIS does not fix poor master data or ambiguous business steps. An identifier still has to resolve correctly, locations need stable definitions, clocks need sensible handling, and partners must agree what an event means. The standard is a common grammar, not a substitute for governance.
Measure Data Quality Where It Matters
Track unmatched identifiers, missed expected items, duplicates after filtering, late events, unresolved master data, manual interventions, and reversals. Segment the measures by read zone, product class, packaging state, and partner. A single fleet wide percentage can hide a failing workflow.
Preserve lineage. A business event should be traceable to the observations and rules that produced it, especially when the event triggers payment, recall handling, regulatory records, or custody claims. Corrections should not erase the original evidence.
Design observability before launch. Teams should be able to inspect reader health, event latency, filtering decisions, master data failures, and the queue of unresolved exceptions without entering each vendor console. Alert thresholds should correspond to a threatened business process, not ordinary radio noise. Version changes to filtering and event rules so that a sudden improvement in a dashboard can be explained and audited.
Ownership must follow the data path. Assign accountable teams for device availability, edge filtering, identity resolution, event delivery, and business exceptions. A service level stated only for reader uptime is incomplete when an unreadable identifier or stalled interface can stop the same workflow.
Integration Questions
- What expected record is each read population compared with?
- Where are duplicate and stray reads filtered, and can the rules be audited?
- How are unknown, missing, and conflicting identifiers handled?
- Is the event interface documented and portable, such as EPCIS, or proprietary?
- Who owns master data quality across organizational boundaries?
- Can a corrected event be traced to the original observations and decision?
- Which business outcome, not merely read count, is monitored after launch?
Limitations
Benchmarks from apparel and retail are valuable but context dependent. Product materials, process controls, partner maturity, and software design alter results. Data quality improves when the system makes uncertainty visible and operationally manageable, not when it hides exceptions behind an impressive aggregate read figure.