A refrigerated shipment reaches a Dutch distribution centre. The latest sensor value is within range, but a carrier message mentions a period without power during a transfer. The warehouse sees a green tile. Customer service sees a PDF attachment. The person responsible for deciding what happens to the goods must reconstruct the story from both.
A cold-chain exception portal should connect observations to identifiable goods and an authorised operational decision. The most valuable software is often the screen that explains why a pallet is waiting, who can release it and what evidence they reviewed. Another attractive temperature chart cannot answer those questions by itself.
Start with the goods, the event and the decision
For a Netherlands-based importer or logistics provider, sketch the actual handovers: collection, consolidation, transfer, arrival and onward delivery. At each point, identify the business reference, the physical unit and the party that creates an event. A shipment number can describe several pallets, and a sensor can move between containers. Those relationships need dates and clear ownership.
GS1's EPCIS overview describes a standard for sharing supply-chain event information, including sensor data, with JSON/JSON-LD and REST support in EPCIS 2.0. It provides a useful common vocabulary for an integration. It does not decide whether a particular product may be released after an excursion.
Keep the product-specific decision rules with the responsible business or quality team. The software should implement approved rules and record their versions. Do not turn an illustrative threshold from a vendor demo into an operational policy for real goods.
Preserve the gaps instead of smoothing them away
A graph that joins two observations with a line can suggest continuous knowledge where none exists. Record the measurement time, ingestion time, device identity, unit and expected sampling behaviour. Make missing observations visible. Distinguish a reading received late from a period when no reading was captured at all.
The carrier's clock and the warehouse's clock may differ. Keep the original timestamp and timezone context while converting to a consistent internal representation. Where a timestamp is uncertain, show that uncertainty to the reviewer. A beautiful chronology built from inconsistent clocks is a weak basis for deciding which handover caused a problem.
Treat corrections as new evidence. A device calibration note or corrected pallet assignment should explain which earlier interpretation it changes. Preserve the original event so a customer can understand why the decision changed. The EPCIS standard includes structures for event information and error declarations; your application still needs a clear, usable correction process around the chosen implementation.
Build a useful exception desk
An operator opening an exception should immediately see the affected units, the current physical location and the action that is blocked. Provide the relevant interval of observations, associated handover events and any missing evidence. Show the applicable rule revision and the person or team allowed to decide.
Separate an acknowledgement from a release. A warehouse employee may confirm that a pallet has been isolated without being authorised to approve onward delivery. Customer service may add a customer instruction without changing warehouse stock. These permissions should be enforced in the backend, including when a user follows a direct link.
Make partial decisions possible where the business process allows them. If one pallet has a different sensor history, releasing an entire consignment may be inappropriate. Conversely, creating an exception per sensor reading can overwhelm the team. Agree the grouping rules and how a reviewer can split or merge cases without losing the relationship to the underlying events.
Connect the decision back to warehouse work
The portal's decision must reach the system that controls picking or dispatch. Define the acknowledgement expected from that system. A release button should show whether the request was sent, accepted or is awaiting retry. Staff need a visible unresolved state if the integration is unavailable.
Use a stable reference for each decision and make repeated delivery safe. If the warehouse system applies a release and its response is lost, a retry must not create a contradictory or duplicate action. If the decision is later withdrawn, that is a separate, explicit operation with its own authorisation and operational limitations.
Customer views should expose the evidence relevant to that customer's goods. Carrier accounts should have equally clear boundaries. Avoid a global search that reveals another customer's shipment reference simply because both use the same consolidation centre. Audit access to sensitive supporting documents as well as changes to decisions.
What a credible pilot should demonstrate
Choose one trading lane and a small set of product rules. Use representative historical examples that the business is entitled to process, plus deliberately difficult synthetic cases. Ask the development team to demonstrate:
- ▸A sensor replaced midway through a shipment.
- ▸An out-of-order event received after a reviewer opened the case.
- ▸A consignment containing both affected and unaffected pallets.
- ▸A corrected pallet assignment and a visible decision revision.
- ▸A warehouse acknowledgement lost after successful processing.
- ▸A customer attempting to open another customer's evidence link.
Judge the pilot by decision time, unresolved exceptions and the effort required to explain a decision later. Hardware coverage, connectivity and calibration remain dependencies; software cannot reconstruct measurements that were never captured. Include those boundaries in the proposal so the operational team understands where its own procedures remain necessary.
Our guides to API integration scope and event-driven systems help define the interfaces around the portal. The goal is a reliable flow from observation to owned action.
TuniCyberLabs develops custom operational software. Share a sample shipment journey and one unresolved exception. We can map the first integration and the evidence your team needs before it changes the movement of real goods.