How to Scope a Cold Chain Monitoring Pilot: Six Decisions Before Scale
This article describes how Eelink scopes hardware pilots with cold chain platform brands and OEM customers. It is not legal or regulatory advice. Eelink supplies sensing hardware and firmware. It does not operate quality systems, validate shipping lanes on a customer’s behalf, or certify compliance. Regulatory interpretation belongs to the shipper and its quality function.
Before Touching the Hardware
Most cold chain hardware pilots stop one question short. They confirm that the device reports, that runtime covers the trip, and that data reaches a dashboard. All of that matters. None of it settles what the record has to show. Then the programme scales, and a year later a claim arrives against a sensor that was measuring the wrong thing in the wrong place. The device was rarely the risk. The unclosed decisions were.
So this runbook starts before the hardware does. Five items belong on paper before the first device is provisioned:
- The evidence requirement, written down. What must the record be able to answer when a shipment is disputed? One paragraph, agreed with the quality function.
- The lane, named. The actual route with its real coverage gaps, transfer points and thermal profile. Not a representative route. The route.
- The market list. Which countries the device will operate in at scale. Radio configuration and market-access credentials both hang on this, and both vary by SKU.
- A provisional measurement point. Enclosure air, return air or product core — chosen against the evidence requirement, to be confirmed in Stage One.
- A named platform owner. Where the data lands, in what format, and who owns retention and retrieval.
A pilot tests whether a defined record, produced on a defined lane, meets documented acceptance criteria and stays interpretable when reviewed later. It is not only a hardware test. Beyond device function it closes six decisions — lane, measurement point, reporting policy, markets, integration and validation — before volume makes them expensive to reverse.
An evaluation asks whether a device works, and ends when it performs to datasheet. A pilot asks whether a specific record still reads clearly when someone disputes a shipment a year later, and ends when the team closes six open questions in writing. Everything below is staged toward that signature.
Stage One: Fix the Measurement Point
Teams usually start with the threshold, because the limit comes from the product specification and feels like the settled part. Nothing settles until you name the measurement point. A threshold means little until you know what it applies to: the same limit at a different location describes a different event. The same load, monitored three ways, produces three different records of one trip — and each supports a different claim.
| Measurement point | What it establishes | What it cannot establish | Typical fit |
|---|---|---|---|
| Enclosure air (on-device sensor) | Conditions around the device and the exposure trend across the trip | What the product itself experienced, especially in a dense or insulated load | Ambient condition monitoring; homogeneous loads; exposure and handling context |
| Return air (probe at the return duct) | Temperature at the return duct, which supports assessment of refrigeration performance when read alongside setpoint and controller records | Unit performance on its own, or whether an individual pallet went out of specification | Reefer performance disputes; carrier equipment accountability |
| Product core (external PT1000 probe) | Temperature reported by the probe at a defined installation point | Conditions elsewhere in the load, or product core temperature unless the placement has been validated | Regulated product where the claim concerns the product itself |
Two architectures, not two quality grades
Vendors market an on-device temperature and humidity sensor and an external IEC 60751 platinum probe as good and better. They are neither. They are two measurement architectures answering two different questions. The on-device sensor reads the air the device sits in. The external probe reports the temperature at its sensing element — and how closely that reading represents product core temperature depends on placement, contact, thermal coupling, response time and validation in the intended product configuration. A probe becomes necessary when the claim concerns the product rather than the environment around it, and its placement is a pilot decision, not a datasheet decision. A programme that needs product-level evidence and buys ambient-only hardware has not bought a lower grade. It has bought a record that cannot answer its own question.
Acceptance standard for Stage One. Name the measurement point in writing and match it against the evidence requirement. For probe configurations, document the installation point and validate it in the intended product configuration. Reversing a measurement-point decision after deployment is not a firmware update. It changes what every historical record means: a year of data captured against enclosure air will not answer a question about product core temperature. The stage only completes when someone signs the choice.
Stage Two: Configure for the Lane, Not the Bench
Reporting profile is where pilots quietly go wrong. The default configuration works in testing, because testing happens near an office with good coverage. The lane is not the office. Reporting interval, positioning method and alarm behaviour are lane decisions, not product decisions. A dense urban route, a long highway leg and an ocean crossing each demand a different mix of GNSS, Wi-Fi and Cell-ID, across LTE-M, NB-IoT or 2G fallback. One global configuration defers the decision rather than making it.
Validate coverage and reporting together
Positioning method and network availability are coupled. A GNSS fix inside a steel container behaves differently from a fix on an open dock. Wi-Fi scanning helps in urban density and does nothing mid-ocean. LTE-M and NB-IoT coverage varies by market and operator, and 2G fallback is retiring on different timelines by country. Pilots that skip the target lane produce a configuration that works everywhere except where it ships.
Sampling, logging, alarm-evaluation and uplink intervals can be separate settings, though some devices couple them. If a lane needed fifteen-minute sampling and the pilot ran at sixty, the gaps are permanent. No downstream analysis recovers a measurement nobody took. Runtime follows the same logic: it is a function of the reporting profile, and the profile belongs to the lane. This is why Eelink publishes battery capacity and measures runtime against the customer’s actual configuration during the pilot, rather than publishing a single runtime figure.
Alarm behaviour is a policy question
Every alarm carries a cost. Too sensitive and the receiving team stops reading them; too loose and the record misses the event that mattered. The workable threshold depends on the product, the lane, the measurement point and who acts on the alert.
Acceptance standard for Stage Two. Validate interval, positioning mix, alarm thresholds and uplink triggers on the target lane, not the bench. Map the coverage gaps and accept them, or change the profile until you can. The configuration of record names the radio configuration for each market on the list, and the file that passes becomes that record.
Stage Three: Run the Trips and Test the Record
With the measurement point fixed and the profile validated, the trips themselves answer a narrower question: does the record hold up when someone reads it against the evidence requirement? Trip count is not the exit criterion. A domestic route with stable conditions may close its questions in three or four shipments; a multi-modal international lane with seasonal variation needs considerably more. The exit criterion is closed decisions, not elapsed time.
A device capturing light exposure, motion, temperature, humidity, barometric pressure and position against one time base produces something a single-channel logger cannot: a sequence. Light changes, handling follows, temperature responds, all on the same clock. A reviewer reads one event instead of assembling it from three files. Separate devices timestamp against separate clocks. Where the records carry a common reference event, a synchronisation trace or documented clock-performance limits, an analyst may bound the offset; without that evidence the relative interval may stay indeterminate. Even a valid bound may be wider than the interval a dispute turns on.
That is a genuine improvement, and a narrower claim than this category usually makes. Correlated signals narrow an investigation. They do not on their own prove root cause, liability or compliance. Those need a quality system, documented procedures and a platform that retains and retrieves records on demand. The boundary is real, and it is the correct one: hardware supplies evidence inputs, and any vendor claiming a device supplies compliance is overstating what a device does.
In practice this stage runs on the customer’s own platform. Eelink supplies the sensing endpoint and the firmware behind it, configured to the customer’s lane and integrated into the customer’s API. The GPT45-M cold chain cargo tracker is the current reference device, with on-device temperature, humidity, light, motion and pressure sensing plus an optional external PT1000 probe. The brand on the device and the relationship with the end customer belong to the platform. Eelink does not operate a mandatory cloud, write a customer’s SOPs, or tell them what their regulator will accept.
Where the regulatory clock sits
In the United States, the FDA Food Traceability Rule under FSMA Section 204 now carries a compliance date of July 20, 2028. The mechanism is worth noting precisely. FDA proposed a 30-month extension from the original January 20, 2026 date, and Congress subsequently directed the agency not to enforce the rule before July 20, 2028. In the European Union, Chapter 9 of the Good Distribution Practice guidelines (2013/C 343/01) requires that required storage conditions are maintained during transport and that deviations are documented. Neither framework specifies a device. Both assume a record exists and that someone can produce it. That is the gap a pilot closes.
Acceptance standard for Stage Three. The person who will defend the record — not the person who configured the device — reviews the completed trip set the test plan defined, retrieved from the customer’s own platform endpoint, against the written evidence requirement. Gaps found here loop back to Stage One or Two; they do not carry into scale.
The Acceptance Record: Six Decisions, Signed
A pilot is not only a test of the device. It is a test of the decisions you are about to make permanent — and the cheapest place to find out that one of them is wrong.
A pilot ends with a document, not a feeling. The acceptance record lists six decisions, each with an owner, a date and a pointer to the evidence that closed it:
- Lane. The validated route, with its mapped coverage gaps, transfer points and thermal profile.
- Measurement point. The Stage One choice — enclosure air, return air or product core — matched in writing against the evidence requirement set in the preconditions.
- Markets. Which countries the device operates in — driving radio configuration and market-access credentials, both of which vary by SKU and get confirmed per programme rather than assumed.
- Reporting policy. The configuration of record from Stage Two: interval, positioning mix, alarm thresholds, uplink triggers.
- Integration endpoint. Where data arrives, in what format, and who owns retention and retrieval.
- Validation method. How the programme confirms the record does what it claims, and how often it rechecks.
These six have dependencies; they are not independent workstreams. The lane shapes the reporting policy, the evidence requirement shapes the measurement point, and the markets shape the radio configuration. Teams that settle them independently find the contradiction late, and late is expensive.
The sign-off has three honest outcomes. All six closed: scale, and the acceptance record becomes the baseline every future dispute is read against. Some open, none contradictory: extend the pilot rather than scale on open questions. A decision that cannot close on this hardware or this lane: stop, and treat the pilot as having done exactly its job. A pilot that closes all six is ready to scale. A pilot that closes four becomes a deployment someone has to unwind.
