A practical engineering guide to confirming custody, controlling dwell and improving pool availability, from physical tag performance to validated business events.
An RTI pool can own enough assets and still be operationally short. Pallets, totes, trays, roll cages, bins, drums, cylinders and containers may exist in the register but remain unavailable because custody is unconfirmed, dwell is excessive, returns are incomplete, or cleaning and repair delay reuse.
RFID provides durable identity and faster evidence at critical handoffs, but a read alone does not confirm that a dispatch, receipt or return occurred. EasyLogic’s ETT software platform filters raw RFID data, adds operational context and converts valid evidence into confirmed business events and actionable exceptions.
This paper combines Xerafy’s physical-layer expertise with EasyLogic’s ETT platform and integration experience. It provides an engineering method for RTI owners, pool operators, manufacturers and logistics providers designing a new RTI tracking system, correcting an underperforming deployment or evaluating an RFID pilot.
Key Takeaways
- Manage pool availability, not only the owned pool. Separate assets circulating productively from those ready for assignment at each location and those outside the expected cycle.
- Keep lifecycle state, custodian, readiness, exception and availability as separate data dimensions. An overdue flag is not a location or lifecycle state.
- Define the business event before selecting the read point. The design must specify what changed, which evidence confirms it and what action follows.
- Scale only after the full chain is proven: tag and attachment, read zone, event logic, enterprise transaction, exception ownership and measurable pool impact.
1. Why RTI Pools Become Operationally Short
RTI shortages are often circulation problems disguised as inventory problems. The pool appears large enough in aggregate, yet operations cannot access the right asset type, at the right location, in usable condition, when the next shipment or production cycle requires it.
Define availability for the operational decision being made.
- Total active pool
- Assets circulating within the expected cycle
- Assets ready and available for assignment at each location
- Assets delayed, held, under inspection or repair, missing, or otherwise outside the expected cycle
An RTI can be active and productively circulating without being immediately available for assignment at a particular site. Within each measure, use mutually exclusive states so that every RTI is counted once and unavailable assets are not subtracted repeatedly under several exception categories.
Four recurring mechanisms make owned assets unavailable:
- Unconfirmed handoffs: dispatch, receipt or return occurs without enough evidence to update custody reliably.
- Excessive dwell: the asset remains with a customer, carrier, depot or process longer than the operating rule allows.
- Delayed release: a returned asset is counted in inventory but is still awaiting cleaning, inspection, certification or repair.
- Pool imbalance: assets accumulate at one location while another location purchases, rents or expedites replacements.
Buying more RTIs may temporarily hide these problems while increasing the capital committed to the pool. A tracking project should first determine which mechanism creates the shortage and which decision is currently delayed.
Not every pool requires the same identification granularity. High-value assets, complex custody networks and workflows requiring item-level history may justify a unique identifier for every RTI. Very high-volume, lower-value pools may use aggregate counts or a hybrid model. The tracking level should match the decisions required, the consequences of loss or delay and the economics of capturing each movement.
Figure 1. RTI availability is lost when handoffs are unconfirmed, dwell exceeds the operating rule, returned assets wait for release, or inventory accumulates at the wrong location.
Define the operating rules first
Before technology selection, document the operating model, asset owner, permitted custodians, custody-transfer rules, expected dwell, return definition, readiness criteria and exception owners. If these rules are ambiguous, additional RFID reads will create more data without creating reliable availability.
2. Map Custody, Dwell and Availability Across the Return Loop
Once the sources of unavailability are clear, the next step is to define the data model that will control them. A single status field cannot represent an RTI accurately: “at customer,” “overdue,” “damaged” and “unavailable” answer different operational questions. Combining them obscures both the count and the action required.
Table 1. RTI State Record Model
| Dimension | Operational question | Example values |
|---|---|---|
| Lifecycle state | Where is the asset in the defined return loop? | At issuing site; allocated or staged; outbound transit; at external custodian; return transit; received at depot; retired. |
| Custodian | Who is responsible for the asset now? | Owner or depot; carrier; customer; service partner. |
| Readiness or condition | Can the asset enter the next productive cycle? | Ready; in use; awaiting cleaning; inspection; repair; quarantine. |
| Exception flag | What requires attention without changing the lifecycle count? | Overdue; missing; unexpected location; damaged; duplicate event. |
| Availability | Can the asset be assigned now? | Available or unavailable, with one primary reason for unavailability. |
The lifecycle state must be mutually exclusive at any point in time. The other dimensions add the information needed to manage the asset. For example, an RTI can be in the lifecycle state “received by customer,” have the customer as custodian, be marked “in use,” carry an “overdue” exception flag and remain unavailable for the next cycle.
The normal return loop
Available → Allocated → Dispatched → Received → Empty or awaiting return → Return dispatched → Returned → Released for reuse
Alternative paths must be explicit. A returned asset may move to inspection, cleaning, repair or quarantine before release. A missing asset may remain active while recovery is underway, then return to the loop or be retired through an approved write-off.
Define every handoff before the pilot
For each state-changing handoff, specify:
- Business event: what changed, dispatch, receipt, return, cleaning complete, inspection failed or release?
- Asset scope: which RTI types and identifiers are involved?
- Expected context: which shipment, route, customer, pool, order or work instruction should match?
- Read evidence: which portal, handheld, tunnel, gate, vehicle-mounted reader or operator confirmation supplies the evidence?
- Direction and time: how is movement direction determined, and what time window groups reads into one transaction?
- System of record: which application owns the resulting status, custody and availability?
- Exception rule: what happens when an asset is missing, unexpected, duplicated, overdue or in the wrong state?
- Action owner: who receives the task, and when does it escalate?
Practical test
Describe the event without using the word “scan.” “Scan at Dock 4” names a technology action. “Confirm custody transfer from Depot A to Carrier B for Shipment 126” defines the operational result the system must prove.
3. From RFID Read to Confirmed RTI State Change
Passive UHF RFID normally provides checkpoint evidence rather than continuous location. At a checkpoint, the same tag may be read many times, while nearby assets may also enter the RF field. ETT filters this device activity, applies shipment, location, direction and time context, and creates a business event only when the defined evidence is present.
Figure 2. A raw RFID read becomes operationally useful only after context and event rules confirm the handoff and update the correct RTI record.
Where identifiers or events must be shared across organizations, consider standards such as the GS1 Global Returnable Asset Identifier (GRAI) and EPCIS rather than creating a proprietary identification and event model by default.
Lessons from deployed asset-tracking workflows
In one truck-mounted deployment, EasyLogic combined RFID reads with GPS and event logic to distinguish a completed unload from an item placed briefly on the loading ramp. In an equipment-rental workflow, delivery and pickup scans were reconciled against expected assets, allowing missing items to be identified immediately. These principles apply directly to returnable asset tracking, where completed handoffs must be distinguished from incidental reads.
Table 2. RTI Event Model: Worked Examples
Handoff | Evidence and context | Required state update | Exception or action |
Dispatch | Portal or handheld read; expected shipment; direction; transaction window. | Allocated → dispatched; owner → carrier; outbound timestamp. | Missing or unexpected RTIs create a difference list; block or review the shipment as defined. |
Receipt | Destination read; expected shipment and location; receiver confirmation. | Carrier → receiver; received state; customer dwell clock starts. | Shortage, overage or wrong-state asset assigned for reconciliation. |
Return | Return portal or handheld; expected return set; direction and location. | Custody returns to owner or depot; customer dwell stops; readiness becomes inspection pending. | Missing expected assets remain overdue; unexpected assets are routed for identification. |
Release | Cleaning, inspection or repair result tied to the asset ID. | Readiness becomes ready; availability becomes available; next-cycle eligibility is recorded. | Failed asset moves to quarantine or repair with a named owner. |
The Xerafy–EasyLogic system boundary
- Xerafy: durable RFID identity, asset and environment assessment, tag and attachment selection, read-point constraints and physical validation.
- EasyLogic: read filtering, event context and rules, expected-versus-actual comparison, exception workflows, device monitoring and integration through ETT.
- Customer or integrator: operating rules, systems of record, master data, user permissions, transaction ownership and response to exceptions.
ETT can connect through REST APIs and, where appropriate, MQTT or database interfaces. Its operational tools can include device-health monitoring, heartbeat alerts, remote configuration and dashboards. The final architecture should define the interfaces, hosting model, monitoring and support responsibilities for the deployment.
Before building, settle five decisions: which system owns the current RTI state; what evidence confirms each handoff; how duplicates, delayed messages and offline readers are handled; which exceptions create immediate work; and who owns rule changes, monitoring and support.
4. Engineer the Tag and Read Point for the Actual RTI Workflow
Xerafy starts with the physical asset and the handoff that must be confirmed. A tag with a long laboratory read range can still fail in operation if the mounting position is shielded in a stack, exposed to fork impact, placed against metal, or readable from the wrong lane.
What Xerafy repeatedly checks first
- Material and contents: Plastic, wood and metal require different tag constructions, while liquids and high-moisture contents can substantially reduce performance. Test the loaded carrier, not only the empty asset.
- Protected mounting: the best RF position is not useful if the tag is scraped, crushed, removed during repair or blocks nesting.
- Real load geometry: validate empty, loaded, nested and stacked assets (not a single empty sample on a desk).
- Controlled read zone: the intended RTIs must be captured while adjacent pallets, cages or returned assets are excluded.
- Lifecycle durability: attachment, casing and visible identification must survive the same cleaning, handling, weather and reuse cycles as the asset.
Field perspective from Xerafy applications
Xerafy application testing: contents can dominate empty-container range. In tests on plastic food baskets using a 30 dBm handheld reader, nine tag samples reached 9.6–12.5 m on empty baskets. With meat in the basket, the observed range fell to 5.5–7 m; with fruit, it fell to 1.8–1.9 m. The practical lesson is that empty-asset range is a poor deployment proxy when high-water-content loads sit close to the tag. Tag choice, mounting position and acceptance criteria must be validated with representative contents.
Figure 3. In Xerafy application testing, high-moisture contents materially reduced observed read range. Tag choice, position and acceptance criteria must therefore be validated using representative loads. Nine tag samples; 30 dBm handheld reader; results are specific to the tested configuration and are not product specifications.
Returnable packaging tracking: In Xerafy’s published rooftop-farm application, reusable food containers move through harvesting, fulfillment, distribution, return and cleaning. The practical requirements were not limited to read distance: the tag needed to survive cleaning, avoid cross-reads and use a compact format that could be standardized across container types.
Global pallet flow: A home-appliance manufacturer uses Xerafy tags to identify pallets moving from one manufacturing base to five overseas warehouses. This illustrates a different design pressure: the identifier and mounting method must remain consistent across long logistics routes and multiple receiving environments.
Warehouse and intralogistics: Across reusable bins, totes, trays and pallets, Xerafy treats the physical container and the inventory record as separate objects. The tag identifies the carrier; the system must still associate the correct contents, location and transaction with that carrier.
These examples support three practical rules:
- Do not select an “RTI tag” by asset category alone. In one customer qualification, metal-framed automotive boxes and plastic bulk bins within the same returnable-asset program required different tag constructions. Select for the actual surface, geometry, environment, read point and lifecycle.
- Standardize the approved tag position and attachment method. Small placement differences can change protection, orientation and read-zone behavior across a large pool.
- Validate false reads as seriously as missed reads. A read from the wrong stack, lane or vehicle can create a false custody or inventory event.
Candidate starting points
- POD TRAK is the primary starting point for plastic and wood pallets, totes, crates, bins, trays and KLTs. Test the selected format in its normal loaded, nested and stacked configurations.
- TRAK and OUT families suit reusable assets needing more mechanical or outdoor protection. Metal containers, cages, trailers and yard assets require an on-metal construction such as Container OUT or Cargo OUT.
- Printable Metal Skin® or XSKIN formats fit workflows that also require barcodes, QR codes, human-readable identification or supplier-side encoding.
These are starting points, not substitutes for application testing. Xerafy’s selection decision is based on the complete operating envelope: asset, mounting, load, movement, read zone, environment and required service life.
Prove the physical layer before scale
Use production-representative assets and the intended reader configuration. Test normal variation, worst-case orientation, adjacent tagged assets, movement speed, cleaning and attachment wear. Reconcile every observed handoff against the resulting read and event record.
The acceptance criterion is not maximum range. It is a stable read zone that captures the intended RTIs, excludes assets outside the transaction and continues to do so after repeated handling.
5. Measure Pool Health and Deployment Value
Effective RTI pool management requires a short baseline tied to the reason the pool is operationally short—not a catalogue of generic RFID metrics.
Measure four things:
- Available pool: the share of active RTIs ready for the next productive cycle.
- Custody and dwell: the share of off-site assets with a confirmed custodian, and the age distribution beyond the agreed return window.
- Return-to-release time: the elapsed time from physical return through cleaning, inspection or repair to availability.
- Exceptions and loss: overdue, missing, unexpected and damaged assets by owner, age and resolution time.
Use thresholds that reflect the operating agreement. Averages alone hide the assets causing the shortage; segment dwell by customer, lane, location and RTI type.
Build the business case from observed leakage
The strongest cases usually combine several effects: fewer write-offs, recovery of overdue assets, less emergency pool expansion, shorter search and reconciliation time, and faster release of returned assets. Keep one-time recovery separate from recurring improvement.
The business case should include not only tags, readers and integration, but also process redesign, master-data preparation, training, support and the ongoing operational cost of resolving exceptions.
Do not assume faster counting is the main value. In returnable pools, the larger opportunity is often converting assets already owned (but held, delayed or unaccounted for) back into productive availability.
Is this a strong RTI pilot candidate?
Strong RTI pilot candidates usually have a defined asset population, a repeatable return loop, measurable loss or dwell, identifiable handoff points, an operational system that can receive events and an owner accountable for acting on exceptions.
6. Pilot-to-Scale Evidence Gate
Use a bounded pilot—not a technology demonstration—to prove that the designed RTI event occurs reliably, updates the right record and improves a baseline metric. Limit the scope to one high-value or high-friction RTI type, a small group of sites or partners, and two to four important handoffs. Run enough cycles to expose mixed loads, missing assets, overdue dwell, damaged tags, offline equipment, cleaning delays and real operator behavior.
Table 3. RTI Pilot-to-Scale Evidence Gate
Evidence area | What must be proven | Evidence source | Stop condition |
Physical identity and read zone | Tag and attachment survive the real RTI lifecycle. The designed zone captures required assets and excludes adjacent traffic. | Test logs; damaged-sample review; read and event reconciliation | Attachment, durability or zone control cannot meet the agreed operating requirement. |
Event accuracy | The system distinguishes the intended handoff, direction and transaction; duplicate and stray reads do not create false events. | Expected-versus-actual log; manually observed events | False state or custody changes exceed the agreed limit. |
Data and integration | The correct system-of-record update is idempotent, recoverable after offline or delayed messages, and auditable. | Transaction logs; interface and error logs | Duplicate or lost transactions, or unresolved ownership, corrupt the RTI state. |
Operational adoption | Operators and partners complete the workflow; exceptions are assigned, resolved and supported by named owners. | Work-queue data; task closure; user feedback | The exception backlog grows or no accountable owner responds. |
Value and scale readiness | Target pool KPIs improve against baseline; unit economics, support and standardization are repeatable. | KPI comparison; cost model; support plan | No material pool impact is demonstrated, or the cost and support case remains unsupported. |
Agree thresholds before the pilot begins. There is no universally acceptable read rate, event accuracy or ROI threshold; the limits must reflect the operational consequence of a missed asset, false custody change or delayed exception.
The scale decision should record the baseline, target, observed result, evidence source, owner and decision for every required KPI. Standardize the approved tag and attachment, read-point design, event definition, interface, exception workflow, dashboard and support owner before adding sites or asset types.
Conclusion
RTI tracking creates value when it returns more owned assets to productive use. That requires a controlled chain from durable identity and read evidence through a confirmed handoff, updated custody and availability, and an exception owned by someone who can act. Map that chain first, then validate it under real operating conditions before scaling.
Define Your RTI Pilot
Share one RTI type, the return loop it follows, the current loss, dwell or availability problem, the systems that must receive the event and the expected deployment scale. Xerafy and EasyLogic can help map the tag requirements, read points, event logic, exceptions, KPIs and evidence required for a bounded pilot.
Discuss Your RTI Pilot
Learn more about Xerafy RFID for logistics: https://xerafy.com/rfid-for-logistics/
Xerafy designs and manufactures industrial RAIN RFID tags, smart RAIN RFID labels, and application-specific tagging solutions for asset tracking, inventory management, and automation in demanding environments.
Its portfolio includes rugged RFID tags, printable on-metal labels, embedded RFID tags, and specialized RAIN RFID labels for demanding workflows, including manufacturing, logistics, healthcare, oil and gas, aerospace, data centers, and textiles.
Xerafy works with system integrators, technology partners, converters, and global enterprises to help digitize physical assets with reliable RAIN RFID performance in real-world conditions.
