Proving What a Cold Chain Tracker Was When It Took the Reading
This article is about record design and production release control, written from a hardware manufacturer’s side of the problem. It describes engineering practice and buyer evidence requirements. It states no legal obligation for any shipment, and makes no compliance claim for any Eelink product. Illustrative figures are labelled as such.
On early machine-to-machine data plans, a cellular sensor message could cost real money by the byte, and one design followed from that. Send the reading and the serial number. Keep everything else on a server. Units, scale factor, sensor channel, alarm thresholds, firmware version — all of it sat in a table keyed by that serial, and the device never repeated what the server already knew.
Fleets still run that table. Where it holds one row per device and overwrites that row on every change, it answers what a cold chain tracker is. Software that now acts on temperature data asks something else, months after the fact: what was that device when the reading was taken? This article walks through the binding between a reading and its configuration: what it costs in airtime, the four ways teams resolve it, and where in the build it is created.
The lookup a minimal telemetry payload depends on
Take the minimal version of a cold chain tracker’s uplink. A two-byte integer. A timestamp. An identifier. In that design, everything that turns those bytes into a temperature on a named channel, judged against a named alarm rule, sits somewhere else. A payload can carry units, scale and a configuration reference instead. The question is which one yours is.
Configuration identity, defined. The facts that decide how a reading should be interpreted: firmware image, measurement settings and scale factors, sensor channel assignment, calibration reference, alarm rule set, and payload schema. A reading carries a value. Configuration identity says which quantity that value represents.
The WHO Guideline on data integrity, Annex 4 of Technical Report Series No. 1033 (2021), makes the point with a smaller example. It defines metadata as “data that provide the contextual information required to understand other data”. It then observes that “in the measurement of weight, the number 8 is meaningless without metadata, such as, the unit, milligram, gram, kilogram, and so on”. The same guideline asks that data be “attributable, thus being traceable to an individual and where relevant, the measurement system”.
That is pharmaceutical GxP data-integrity guidance, not food law, and it is quoted here as a model for building reconstructable records rather than as a rule that binds a food shipment. What binds any given consignment depends on the product, the jurisdiction and the contract. The MHRA’s ‘GXP’ Data Integrity Guidance and Definitions (Revision 1, March 2018) puts the design requirement in one line: “Raw data must permit full reconstruction of the activities.” The engineering problem is older than either document.
What changed when software started acting on its own
Route optimisation has read telemetry for years. The newer capability is optimisation that executes — reallocating a slot, reassigning a vehicle, resequencing drops, with no planner approving each move. Refrigerated Transporter’s coverage of one such launch, published on 11 September 2026, describes dynamic slot optimisation, learned stop durations and continuous replanning.
Read that account and something is absent rather than present. It does not describe temperature, reefer telemetry, door events or cargo thermal state as inputs. An absence in a published article establishes nothing about what the deployed product accepts, or what any customer has integrated. It does mark where the interesting question sits.
A planner who reroutes a load leaves a person in the chain who can be asked what they saw. An automated action leaves a record instead, alongside whatever policy and deployment history sits around it. And a record is worth whatever interpretation you can still attach to it later.
Sourcing note — in-transit monitoring. A buyer specifying a real-time shipment temperature tracker for automated workflows has three questions to add. What does each uplink carry besides the reading? How is a past configuration resolved after a firmware update? How long does the archive keep that history? Reporting interval and battery life answer none of them.
Do the extra bytes cost you the battery?
That objection comes up early in battery-powered cold chain tracker work, and it deserves arithmetic rather than rhetoric. Take a device reporting every five minutes for sixty days. That is 17,280 reports. Add 32 bytes of binding to each one, riding inside transactions the device was already going to make.
Thirty-two extra bytes per report, at a five-minute cadence over sixty days, adds roughly 553 kB of payload. Assume an illustrative 0.3 W active radio, a 10 to 100 kbit/s effective uplink, and bytes carried inside transactions already scheduled. That is about 0.004 to 0.04 Wh, well under one percent of a 10 Wh pack.
That is a linear sensitivity case, not a modem measurement. It assumes the bytes ride in an already scheduled transaction and that the quoted rate and power describe one operating state. It excludes attach, control signalling, repetitions, handshakes and failed attempts. Nominal pack energy is also not usable energy at cold-chain temperatures. Settling it for a real product takes a modem measurement with and without the extra bytes.
Where the byte count does still bite
Two regimes change the answer. Under deep coverage enhancement the effective uplink rate falls and repetitions rise, so payload length stops being negligible. And on a constrained LPWA link the case above does not transfer at all. A standard Sigfox uplink carries at most 12 bytes of application payload, so 32 extra bytes is not a cost but several more messages. LoRaWAN application payload limits vary by region and data rate, from around a dozen bytes at the most constrained settings up to a couple of hundred at the least. Either link needs its own calculation.
So in the worked case, the marginal payload term is small. Whether it is the smallest term in a given product is a measurement question, not one this arithmetic settles. What the arithmetic does settle is that the constraint worth designing around here is not measured in joules. Every field you leave off the record becomes a dependency on history. Somebody has to keep that history resolvable for as long as the record must stand up, which is typically far longer than one shipment. Fleets turn over, get refurbished and take firmware updates in that time.
Four ways to resolve a reading’s configuration
Teams do not choose between fat records and thin ones. They choose how the binding gets resolved. The four patterns below differ in what has to survive for resolution to work, and a system can combine several. What matters is which one carries the weight when a record is challenged.
| Resolution pattern | What it costs | What breaks it |
|---|---|---|
| Self-contained bundle | Larger exports; context duplicated on every record | Missing calibration material, unresolved references or an ambiguous schema — self-contained is not the same as complete |
| Immutable version reference | A few bytes per record, plus an archive that is never rewritten | Deleting or overwriting a referenced manifest; a reference whose target was never retained |
| Effective-dated lookup | Versioned state history, with valid-from and valid-to on every change | Changes applied without an effective date; corrections that overwrite rather than supersede |
| Current-state lookup | Little to build, and a frequent default | Any change to relevant state, over-the-air or otherwise, once prior state is not recoverable elsewhere |
Why the fourth is not a fourth option
The fourth is not a cheaper option on the same axis as the other three. Once relevant state has changed and the prior value is not recoverable elsewhere, it cannot answer the question at all, and no weighting of cost against completeness rescues it. It sits in the table because it tends to be a default rather than a deliberate choice.
What a configuration hash can and cannot settle
Sending a hash on every record is a compact way to reference a configuration, and a good pattern. Three limits travel with it. Without defined contents and a canonical encoding, two builds of one configuration may hash differently; hashing an exact binary artefact avoids that, since the bytes are the definition. A hash over settings alone says nothing about the firmware image. And it is not authentication — the device reports the hash it believes applies. A reference also works only while its target is retained.
The snapshot the acting system has to keep
Reconstructing the device is the tractable half. The harder question, six months later, is what the system knew when it decided — and a complete device history does not answer that one.
A flawlessly reconstructed configuration does not rescue a decision made on a three-hour-old reading from a probe nobody can now tie to that pallet. The challenge lands on the action, and the action used whatever evidence had arrived by then.
Decision-time snapshot, defined. What the acting system recorded as it acted. The readings it consumed and the age of each. The probe and consignment they were bound to. The configuration identifiers in force, the policy or model version applied, and the action selected. And the inputs that were absent, stale or unbound.
Absences matter as much as values. A record showing the system acted with no fresh product-probe reading can be examined on its merits. One that silently omits the gap cannot — though recording it is not the same as showing the action was right. And unless the reconstruction preserves what had arrived by decision time, it can pull in a reading that landed afterwards, which makes the outcome look better informed than it was. Buffering and retransmission are what make late arrival routine, and we covered those mechanics in an earlier piece.
One thing does not come free with provenance. A tracker reports what its sensor saw. Air near a door, case surface and product core are different quantities with different lag. Which one a threshold refers to is a definitional question we have taken apart separately. Perfect metadata on the wrong measurement point is still the wrong measurement point.
WHAT TRAVELS WITH A READING · AND WHAT HAS TO BE RESOLVED LATER
Three bands, and only the middle one is a design choice.
BAND A · THE SAMPLE
Raw value
The integer the sensor path produced.
Acquisition time
When the sample was taken, not when it arrived.
Device identity
Which unit produced it.
BAND B · THE BINDING
Schema version
How to decode the payload at all.
Configuration generation
Which settings were in force at acquisition.
Sensor channel
Internal, external probe, or which of several.
Omit this band and you have not saved a record. You have created a dependency on somebody else keeping history.
BAND C · RESOLVED LATER, OR NOT AT ALL
Firmware image identity
What was actually loaded and verified.
Calibration reference
Tied to the unit, where the design has one.
Alarm rule set
The thresholds the record was judged against.
These resolve only if the historical content was preserved somewhere — an immutable manifest, an event log or a temporal table.
Illustrative record structure. Field names and byte counts vary by product; no specific payload format is implied.
Where configuration identity is actually created
Firmware reports the version it believes it is running and stamps that onto records. Production can evidence what was loaded onto a serial number and when, if the verification and the record binding are good enough. Reading back a version label is not the same as verifying a complete image. Neither side substitutes for the other. A work order saying “flash image X” states intent, not result. The evidence worth having is the outcome: image identity confirmed after flashing, the configuration written, the test program version that checked it, and the disposition of anything reworked.
There is a loose analogy one layer up. GS1’s EPCIS and Core Business Vocabulary exist, GS1 writes, so that “all parties who exchange EPCIS data using the CBV will have a common understanding of the semantic meaning of that data”. That concerns semantics between trading partners, not firmware verification or release records. The analogy is narrow: both try to stop one identifier meaning different things to different readers.
What a second site does and does not change
Owning both factories is not evidence that their release records mean the same thing. Two owned sites can drift apart, and a contract manufacturer can run rigorous release control. The question is worth putting to any IoT device contract manufacturing partner, ODM or CM/EMS, in China, Vietnam or anywhere else. Ask for a demonstration rather than an assurance. Two units prove a retrieval capability, not process equivalence — but a partner who cannot do it for two cannot do it for a batch:
Take one serial from each site. Same SKU, same configuration revision. One unit built in China, one in Vietnam.
Read what each unit reports. Firmware image identity and configuration identifier, from the device itself.
Retrieve the matching release record. From each site’s archive, against that serial, as recorded at build time. Approved build package, verification result, release disposition. Check the field definitions mean the same thing at both sites.
Where we sit on that test
For what it is worth on our side. Eelink’s Shenzhen operation is an R&D centre with no factory attached, and it holds design and release authority. Eelink’s manufacturing site in Yibin, Sichuan runs five SMT lines and 28 assembly lines across a 101,000 m² manufacturing base. The site in Haiphong, Vietnam runs the same process sequence. Both consume released build packages rather than defining their own, which is a statement about change authority rather than a claim that any two units are measurably identical. Current production output: approximately 300,000 devices per month across Eelink’s manufacturing operations in China and Vietnam. Management systems are certified to ISO 9001, ISO 14001 and IATF 16949. Product-level market-access credentials — FCC authorization, CE marking, PTCRB certification — vary by SKU and configuration. That same separation between design control and finished-device behaviour is one we have written about for radiated performance.
Frequently Asked Questions
What is configuration traceability on an IoT device?
It establishes which firmware, settings, sensor channel assignment and alarm rules were in force on a specific serial number at a specific past moment. A registry that keeps only current state cannot provide it. Once the row is overwritten, the value that applied at acquisition time is gone unless something else retained it.
Does adding metadata to every reading hurt battery life on a cellular tracker?
On a cellular link, under the assumptions used here, not materially. At a five-minute cadence over sixty days, 32 extra bytes per report adds roughly 553 kB, on the order of hundredths of a watt-hour against a 10 Wh pack — provided the bytes ride inside transactions the device was already making. Which term actually dominates a given design is a measurement question. On constrained LPWA links this does not transfer at all: a standard Sigfox uplink carries at most 12 bytes of application payload.
Is a configuration hash on each record enough?
It is a compact reference rather than a proof. Without defined contents and a canonical encoding, identical configurations may hash differently. A hash over settings alone says nothing about the firmware image. Because the device reports it, a hash identifies what the device believes it runs. And the reference is only useful while whatever it points at is still retained.
What should an automated decision record, beyond the readings it used?
The age of each reading, the probe and consignment they were bound to, the configuration identifiers in force, the policy or model version applied, and the action selected. Also any input that was missing, stale or unbound. Absences are the field we see omitted, and without them a later reconstruction can import data that only arrived after the decision.
What can a buyer ask a contract manufacturer to demonstrate?
Take one serial built at each site. Read the firmware image identity and configuration identifier the unit reports, then retrieve each site’s build-time release record for that serial — build package, verification result and release disposition. Two units show a retrieval capability, not process equivalence. Owning the factories is not by itself evidence of either.
What should I ask a supplier when sourcing a real-time shipment temperature tracker?
Beyond interval and battery life, ask what each uplink carries besides the reading. Ask how the platform resolves a configuration that has since been updated over the air. Ask how long the release archive retains build-time records. For an IoT device contract manufacturing programme across two countries, ask whether both sites return release evidence in the same form.
Key Takeaways
A reading is interpreted, not self-explaining. The value means nothing without the measurement system and settings that produced it.
On cellular, binding metadata is a small energy term. Under the assumptions in the worked example, at least. The constraint that survives is resolvability over the retention period, which is an archiving decision rather than a payload one.
A current-state registry answers the wrong question. It describes what a device is. A challenge asks what it was at acquisition time.
Reconstructing the device is not reconstructing the action. Persist the decision-time snapshot, including inputs that were missing or stale, not only a rebuildable device history.
A demonstration beats an assurance. One serial per site, read the device, retrieve both release records. It proves less than process equivalence and more than a claim.
