A chain-of-custody log has one job: to let someone, months later and under questioning, show where an item was and who was responsible for it at every moment. The value of the log is not in what it contains. It is in the absence of unexplained gaps.
What every entry has to carry
- Who: a named individual with their own login, never a shared account or a station name.
- What: a stable identifier for the item, ideally one that travels with it physically, such as a QR label.
- When: a timestamp assigned by the server, not typed in or taken from the device.
- Where: the location or handover point, as specific as the workflow allows.
- Why: a reason code, so ‘moved’ always has a meaning.
- To whom: a handover names both the giver and the receiver.
What the system must make impossible
Good design is often a list of things that cannot happen. A custody system should not allow any of the following, even to administrators acting in good faith:
- Editing or deleting an existing entry. Corrections are new entries that point at what they correct.
- Back-dating an entry. Time comes from the server.
- An item with no responsible custodian. ‘In transit’ still has a named person.
- A one-sided handover. The receiver acknowledges, or the transfer is incomplete and visible as such.
Gaps are the signal
Once entries are append-only and attributable, the most useful report is the one that finds absence: items whose last handover is unacknowledged, items with no movement for longer than expected, entries made at a location that conflicts with the previous one. These are questions a paper register cannot answer cheaply.
Access follows responsibility
Not everyone should see every item. Role and station should determine what a user can view or act on, and those permissions should be enforced on the server. Hiding a button is not access control.