Putting a new UHF RFID tag on an asset is not complete when a reader first sees it. The project still has to identify the physical tag, write only the approved data, read it back, bind it to the intended business record and prevent the same identifier from being commissioned twice.
This guide follows an editorial first-time asset-tagging example. It differs from Replacing a Damaged RFID Tag, which starts with an existing identity and a failed tag, and from UHF RFID Inventory Scope, which defines which commissioned tags belong in an inventory. It does not claim that an AIDC GO model can write a tag unless the approved model and SDK materials say so.
Define the identifier before opening a write screen
An RFID project may use a GS1 EPC, another structured identifier or an enterprise-specific value. Decide which scheme is authoritative, who allocates it, how uniqueness is checked and which business record it should represent before a worker approaches the tag.
The GS1 EPC Tag Data Standard defines EPC encoding schemes and data carried in EPC-encoded RAIN RFID tags, including EPC, control and tag-manufacture information. The GS1 System Architecture Document places those encodings in the wider identification and capture architecture. The standards distinguish the EPC from other data that may use User Memory or supported EPC/UII encodings; they do not make an arbitrary string a valid enterprise identifier.
Do not treat the tag's TID as a replacement for the business EPC. TID can help distinguish the physical tag during a controlled access operation, while the application still needs an approved relationship between the encoded identifier and the asset record.
Select one physical tag before writing
Consider an editorial asset PUMP-204 and two blank tags on a commissioning bench. The intended EPC has been allocated for that asset, but both tags are within read range. An unrestricted write operation could affect the wrong tag or more than one tag.
Use a controlled fixture, one-tag presentation or a supported selection/filter method for the exact reader and software. Zebra's RFID SDK for Android 2.0.5.292 write-access tutorial is one bounded API example: it describes write operations on a specific tag or tags matching an access filter, a chosen memory bank, offset, data length and access password. That is documentation for the named SDK, not an AIDC GO capability statement.
Before writing, record the candidate tag's observed EPC or blank state, its TID when the approved workflow uses it, the reader identity, antenna or fixture, software version and proposed target value. Remove neighboring tags or prove the selection rule with controlled samples.
Write the approved bank and verify the result
The commissioning application must name the target memory bank, offset, encoded data and access conditions. A generic “write tag” button is insufficient evidence because EPC, User and Reserved memory have different purposes, and tag implementations can differ.
After the write call returns, read back the intended field from the same selected physical tag. Compare the returned value with the approved encoded value, not only with a success message. Zebra's named tutorial exposes operation status and number of words written, including the possibility of partial writes; the project still needs an independent readback and business comparison.
If the readback differs, quarantine the tag and transaction. Do not allocate another asset record automatically, and do not keep retrying without knowing whether a partial value now exists. Preserve the attempted value, returned status and observed memory content for review.
For tags that will be rewritten during reuse, distinguish planned business updates from actual writes and retries to each memory location; see the reusable UHF RFID tag endurance and retention guide.
Bind the encoded tag to the correct asset
In the editorial example, the application approves EPC urn:epc:id:grai:0614141.12345.400 for asset PUMP-204. The operator scans or selects the asset record, writes the encoded EPC to the isolated tag, reads it back and then submits a mapping that includes the asset ID, approved EPC, observed TID, tag part and commissioning transaction ID.
The application should reject a mapping if the EPC is already active on another asset, the asset already has a different active tag without an approved replacement path, or the physical tag readback does not match the proposed value. These are business controls, not automatic properties of the RFID air interface.
The article on RFID Tag and Reader Basics explains the general identifier layers. For a later replacement, use the damaged-tag workflow so the old and new relationships remain explicit rather than overwriting history.
Compare evidence for every commissioning state
| Commissioning state | Evidence to retain | What remains unproven without another check |
|---|---|---|
| Identifier allocated | Scheme, source system, proposed value and uniqueness result | Allocation does not establish that any physical tag contains the value. |
| Physical tag selected | Fixture or filter, observed EPC/TID and reader context | Selection does not establish that the intended memory bank was written. |
| Write reported | Target bank, offset, length, status and software version | A success status alone does not establish complete readback. |
| Readback matched | Independently read value from the selected physical tag | Matching bytes do not establish that the correct asset record was updated. |
| Asset mapping accepted | Asset ID, EPC, tag evidence, transaction ID and application response | A database row alone does not establish that the mounted tag remains readable in service. |
Keep the commissioning record separate from later mounting and read-zone acceptance. RFID Tag Attachment on Metal Assets covers the mounted assembly, while UHF RFID Read Range covers representative read conditions.
Test duplicate, partial and wrong-tag branches
Use controlled tags and non-production asset records. Test an already-allocated EPC, a tag outside the approved part list, two tags in the field, a rejected access password, a reported partial write if the SDK can represent it, a readback mismatch and a duplicate asset mapping. Confirm that none is silently recorded as commissioned.
Then mount one correctly commissioned tag using the approved assembly and verify that the application reads the same identifier at the intended work position. A successful bench write does not prove installed readability, and an installed read does not prove that the business mapping is correct.
Record whether the application can resume safely after interruption. The transaction should distinguish “identifier allocated,” “write attempted,” “readback matched” and “mapping committed” so an operator does not create a second identity while recovering.
Bring the commissioning contract to the purchase discussion
Provide the tag manufacturer and exact part, memory requirements, encoding scheme, sample asset records, regional deployment, mounting method, expected batch size, access-control policy, application and SDK versions, selection method and audit fields. Separate bench commissioning from installed read acceptance.
Ask the tag and software suppliers to confirm memory layout, supported access operations, password and lock behavior, error reporting and limits for the exact parts and versions. Ask AIDC GO to confirm whether the proposed RFID Mobile Computer or RFID Sled configuration exposes the required read/write path; do not infer it from UHF inventory capability alone.
Use RFID Inventory & Asset Tracking to connect commissioning to the wider asset workflow, then Integration & Support and Contact AIDC GO to present the exact tag, reader, application and evidence needs. Commissioning is complete only when the selected physical tag, approved encoded value and authoritative asset record agree.