A UHF RFID reader can return several values from one tag. The Electronic Product Code (EPC), Tag Identifier (TID) and optional User memory are not interchangeable names for the same identifier. A project must decide which value is being read, what that value means, whether it can change and how the application maps it to an asset or transaction.
This guide uses an editorial maintenance scenario to make that decision concrete. It describes GS1 Gen2 concepts and third-party tag documentation; it does not promise that an AIDC GO reader supports every memory operation, lock state, password feature or tag design.
Name the business identifier before choosing a memory bank
Start with the value the business needs: an asset number, serialized trade item, reusable-container ID, work-order reference or another controlled key. Decide who assigns it, its format, whether it can change and which system is authoritative. Only then decide whether the tag should carry that value directly or whether the application should map another read value to the business record.
The RFID tag commissioning article covers encoding, readback and binding as one controlled workflow. This article focuses on the earlier design decision: which memory value the application should rely on and why.
Distinguish Reserved, EPC, TID and User memory
The current GS1 Gen2 UHF RFID standard defines separate logical memory banks and operations. The GS1 EPC Tag Data Standard explains how GS1 identification keys and related data are encoded in the EPC memory bank. Those standards provide the protocol and encoding framework; they do not make every tag's capacity, permanence or access policy identical.
Reserved memory is associated with access and kill passwords when implemented. EPC memory carries protocol-control information and the EPC/UII value used in inventory. TID identifies tag or chip information according to the applicable tag design. User memory is optional and its size and organization depend on the chip and implementation. Request the exact tag-chip data sheet before designing around a bank or address range.
Decide whether identity is direct or mapped
An EPC can be encoded to represent a controlled business identifier. A TID can help distinguish physical tag chips, but it should not automatically replace the asset identity. User memory can hold project data on a suitable tag, yet the application still needs a format, version and access rule.
In a mapped design, the application reads a stable observed value and looks it up in an authoritative table. The damaged-tag replacement guide explains why the relationship between an old tag, a new tag and the asset record must be approved and verified rather than assumed from one successful read.
Compare what each value can prove
| Read value | Useful role in a workflow | Limit that still needs a project decision |
|---|---|---|
| EPC or UII bank value | Inventory selection and a business identifier encoded under the chosen scheme | Whether the value is authoritative, correctly encoded and protected from unintended change |
| TID bank value | Distinguishing the observed tag or chip according to the implemented TID structure | Whether the application maps that tag to the intended asset and whether all required TID bits are available |
| User-memory value | Holding optional project data on a tag with the required capacity and access behavior | The data format, address range, write/lock policy and reader support for the exact tag |
| Application database key | Maintaining business ownership, history, status and relationships outside the tag | Which tag value resolves to the key and how replacement, duplication and exceptions are controlled |
Do not treat a longer value as automatically more trustworthy. Trust comes from assignment, control, read conditions, validation and the mapping to the correct business record.
Walk one maintenance example through the choices
Consider an editorial fleet of reusable tools. The business record uses asset ID TOOL-00482. The tag's EPC is encoded from an approved project scheme and is the normal inventory value. The application also reads the tag's TID during commissioning and stores it as supporting physical-tag evidence. User memory is not required for the workflow.
During a later inspection, a worker reads the expected EPC but the TID differs from the commissioning record. The application does not silently accept or reject the asset. It creates an exception for investigation: perhaps the tag was replaced through an authorized process, perhaps the mapping is wrong, or perhaps a duplicate EPC was encoded. This example illustrates a control decision; it is not a customer deployment or a promise that a particular device returns both banks in one operation.
The RFID inventory scope article covers selection filters and expected populations. Memory-bank identity should be settled before filters are treated as business scope.
Verify read, write and protection behavior separately
List every operation the application needs: inventory EPC values, read TID, read or write User memory, write EPC, lock a region, use an access password or only perform read-only checks. The RAIN Alliance item numbering and tag data technical note illustrates the four-bank memory map and the separation between item numbering and other tag data.
Test the exact tag chip, memory size, bank address, data length, password state and reader/SDK version. A successful EPC inventory does not establish User-memory access. A successful write does not establish that the value was locked, that the application read it back correctly or that another device can use the same configuration.
Use the RFID mobile-computer category and RFID sled category to identify candidate form factors, but request the exact model documentation for required bank and protection operations.
Send a complete identity and memory specification
Provide the deployment country, candidate reader and SDK version, exact tag chip and inlay or finished-label part number, required business identifier, encoding scheme, expected EPC/TID/User data, bank addresses and lengths, read/write/lock operations, password states, duplicate and replacement rules, sample tags and acceptance records. State which system owns the mapping and what the operator sees when values disagree.
Send that specification to Integration Support or Contact for review of the documentation available for the shortlisted configuration. The project owner remains responsible for identifier governance, encoding authority, access credentials, application mapping and acceptance of the complete workflow.