Picture a Tuesday morning and a call from the hospital pharmacy: a box is missing on one of the wards. According to the plan, it was delivered on Friday. Was it really? Now the search begins, and it has a fundamental problem: it can only find what was recorded on Friday. Nothing more.
Whatever can be said about a delivery later must therefore have been recorded at the moment it happened. Sounds trivial. It is. And yet this is exactly where most proofs fail.
The search happens afterwards. It only finds what was recorded beforehand.
Why the search always starts too late
The missing box is not a special case. Whether pharmaceuticals, a lab sample or a sterile goods container: that they have to arrive is obvious. But at some point, often only weeks later, someone wants to know: when was the shipment where? Who handed it over? What happened along the way? These questions do not come on the same day. They come with a complaint, in an audit, or when something is missing.
Then someone sits in front of the system, questioning a past that can no longer answer. Physics knows the principle from thermodynamics: you can scramble an egg, but you cannot unscramble it. Information is no different. What nobody measured at the time, nobody can measure later. No analysis, however clever, brings it back.
Three words to keep apart
In a first-year physics lab you learn a rule that sounds so simple it seems superfluous: write down what you measured. Not what you think you measured. For proof in logistics, it is the most important rule of all. Because behind every piece of information lies one of three things.
- Event
- is measured. A scan, a position, a completed stop.
- State
- is derived. “The shipment is in the vehicle.”
- Decision
- is made, by a person, with a name and a time. “The tour leaves despite the finding.”
- Most common mistake
- treating a derived state as if someone had measured it
Why does this matter so much? Because a state can be wrong without a single event being wrong. An example: in many systems a shipment counts as being in the vehicle as soon as it is firmly planned on a tour. That is a state, derived from the plan. Only the scan at loading tells whether the box was actually loaded. That is an event. Anyone who lumps the two together ends up proving something nobody saw.
The lab notebook
Science has long known how to do this properly. In the lab you keep a lab notebook, and by strict rules: bound pages, numbered consecutively. You write in ink, and every entry gets a date. A mistake is not erased but struck through with a single line, so that the wrong entry stays legible. The correction goes next to it, with date and initials. No correction fluid. Ever.
That seems pedantic. There is a good reason for it, though: a lab notebook should show not only what came out in the end, but also how one got there, wrong turns included. Patent disputes have been decided by such notebooks.
At heart, that is exactly what lies behind the fine word “audit-proof” that turns up so readily in tenders. The term comes from archiving and means that entries stay complete, unaltered and retrievable for the whole retention period. That asks for more than software. Whether a procedure is audit-proof also depends on retention, access rights and organisation. For the software, it first means only what every lab notebook does: a change does not silently overwrite what applied before, but is recorded with person and time. We decide together in the project which retention and which mandatory information an operation needs beyond that.
What NUNAV writes into the lab notebook
NUNAV keeps part of this lab notebook itself during operations:
- Scans: Shipments and individual pieces can be scanned at sorting, loading and unloading, at delivery or as not delivered. This produces a timeline per shipment.
- Stops: Every completed stop is reported with its time and the position from the driver app.
- Changes: Records have a change history that shows who changed what and when. A change can also be reverted there.
- Releases: Every attempt to release a tour is recorded with its check findings, acknowledgements and reasoned overrides.
- Promises: Which arrival time was promised, corrected or withdrawn, and when, is kept together with the actual arrival. How such promises come about is described in the article Arrival forecasts.
A timestamp is honest, but silent
A timestamp says: at 9:52 something happened. It does not say why. And for evaluation, the why is often worth more than any clock time. “Truck full”, “breakdown”, “receiving not staffed”: only such reasons show where something in the process can be changed. A reason nobody wrote down, however, is as lost as the scrambled egg.
NUNAV shows why an order could not be scheduled, and it requires a reason when a blocking check is overridden at release. Dispatch can add notes to every tour. A fixed catalogue of deviation reasons, mandatory fields per shipment movement or a scan obligation before a stop is closed can be defined in the project and implemented in a connected scanner or telematics system.
The last metre: the handover
At the end of every delivery comes a moment that cannot be repeated: the handover. Where an electronic proof of delivery with signature, name or photo is required, we connect it in the project through the interfaces. A rule of thumb applies: the proof belongs with tour, stop and shipment. A proof that sits alone in yet another system is like a page torn out of the lab notebook. It may be right, but nobody can show any more where it belongs.
The decisive question
For traceability, it therefore matters less how much data a system stores. Storage is cheap. The more important question is: is what will be asked later recorded along the way?
How we support you
What has to be recorded follows from the questions that will be asked later. So, quite scientifically, you start with the question and not with the data:
- Taking stock: Which questions must be answerable later, internally, towards clients and in an audit?
- Definition: Together we decide which events, reasons and mandatory information belong to which shipment movement.
- Connection: Scanners, telematics, proof of delivery and existing systems are connected to NUNAV through the interfaces.
