RFID and blockchain are usually presented as a pair because both are said to remove trust from a process. They remove different kinds of trust, and the value of the combination depends entirely on how the two are joined. RFID makes a physical event observable. A chain makes a sequence of records expensive to rewrite. Neither, alone, proves that the right pallet was on the right truck.

That is not a reason to dismiss the combination. It is a reason to be precise about the question it answers: not what is true, but what was asserted, by whom, and in what order. Those questions matter most when the parties do not share an ERP and the disagreement will be settled by a third party.

Two ledgers and two different trust models

The physical ledger is noisy, local and ephemeral. The digital ledger is sparse, global and permanent. Treating them as the same object is where most projects go wrong.

The RFID ledger records observations: tag, antenna, time, signal, and the quality of the read.
The chain records assertions: a party claims that this serial left this site, in this shipment, at this time.
RFID trust rests on the installation: antenna placement, read rate, tamper resistance of the tag.
Chain trust rests on governance: who may write, how writers are identified, and what happens when they disagree.
An immutable record of a wrong observation is still wrong. Immutability multiplies confidence; it does not create it.

What an RFID read can and cannot prove

Being explicit about evidential strength is the foundation of a credible design.

It can prove that a tag with a given identity was energised at a given antenna within a known time window, with a recorded confidence.
It cannot prove that the tag was attached to the correct item, that the carton contained what the manifest says, or that a human did not swap labels.
It cannot prove absence. A missed read is a missed read; the item may still be on the pallet.
Cloning is real. EPC values are trivially copied; use tags with a unique TID, cryptographic authentication, or both, when the value at stake justifies it.
Document the confidence level alongside the event. An auditor who understands the limits trusts the system more, not less.

Where a chain earns its cost

A distributed ledger costs more than a database in operation, integration and governance. It pays back only under specific conditions.

Multiple parties that do not share a system of record, and will not accept one party's database as neutral.
High consequence of a dispute: pharmaceuticals under serialisation rules, food provenance, luxury goods, safety-critical automotive parts.
Audit questions about history rather than the present: what did the record say on the day of shipment, before the recall.
A regulator or customs authority that needs read access without being given write access.
It is a poor fit for internal warehouse picking. A normal database with an append-only audit log is cheaper, faster and just as auditable.

Anchoring: coupling the physical event to the record

The coupling is a hash, and the engineering is in what goes into it and when it is written.

Serialise the event into a canonical payload: EPCIS 2.0 fields, tag TID, reader and site identifiers, event time with source, and the raw read identifiers behind it.
Hash the canonical payload with a stable algorithm, and never rely on JSON key ordering in the hash input.
Batch events per shipment or per time window, and write a single Merkle root instead of one transaction per tag.
Keep the full payload off-chain; the chain stores the hash root, the pointer and the writer identity.
Do not block the dock on confirmation. Commit locally first, anchor asynchronously, and reconcile within a defined service level.

The on-chain data model should be boring

The most successful projects put almost nothing in the contract. The ledger is an evidence store, not an application server.

Register assets by GTIN and serial, with an aggregation tree for pallet, carton and item.
Model a small set of event classes: commission, aggregation, shipping, receiving, decommission.
Validate state transitions in the contract, and keep pricing, routing and optimisation outside it.
Assign write permissions per event class and per party, so a carrier cannot commission serials and a retailer cannot alter dispatch records.
Version the schema on-chain. An evidence store that cannot evolve will be abandoned within two years.

Privacy and commercial confidentiality

A shared ledger is a shared surface. Everything written is visible to everyone on the channel unless you design otherwise.

Use a permissioned platform with channels when partners are competitors, and disclose only the events each party needs.
Keep personal data off-chain. Hash references, not names; if a hash can be reversed by brute force, salt it.
A right to erasure cannot delete an immutable record. Design so that personal data is never on-chain in the first place.
Treat volumes, prices and routes as commercial secrets. Commit to the hash and disclose the payload to an auditor under contract.
Key management is the operational weak point: rotate keys, separate roles, and plan for a compromised partner node.

Exceptions are where the value is proven

A chain that only records success is an expensive press release. The disputes are in the exceptions.

Missing read at receipt: raise an exception event, and have both parties sign the same record.
Chain-of-custody gaps: a carrier with no scan between two sites creates a window that must be flagged, not hidden.
Smart contracts cannot judge physical damage, partial delivery or a mislabelled carton. Keep arbitration human and contractual.
Assemble an evidence package: event hashes, raw reads, photos and the reader configuration at the time.
Set a service level for anchoring, typically fifteen minutes, and escalate when it is missed.

A staged adoption path

Most failures come from starting at stage four. Start where the audit pain already exists.

Stage one: an internal append-only log using the EPCIS schema you would put on-chain later. This alone solves most traceability questions.
Stage two: anchor hashes to a permissioned ledger with two or three partners, on one product line.
Stage three: extend to carriers and customers with selective disclosure, and measure dispute resolution time.
Stage four: give auditors and regulators a read-only node, and integrate recall workflows.
Track three numbers: disputes resolved per month, time to complete a recall, and cost per anchored event. If the third rises and the first does not fall, stop.

The combination works when the physical event is trustworthy enough to be worth anchoring, and the ledger is used for the narrow set of assertions that no single party should own. Everything else is a database, and calling it a chain does not make it one.