Documents and notifications: a violation record is evidence, not a log line

A detected violation that can't survive a defence lawyer's questions about how it was captured isn't a violation — it's an unusable data point. This is the discipline that connects.

Everything covered so far — geofence intersections, event capture, violation detection — describes how e-Boat notices something. ToR group C-066..C-076 ("Documents, notifications") governs what happens next: turning a detection into something that can actually be acted on, up to and including a prosecution or licence sanction. That's a different discipline from detection, and it has its own rules, borrowed from digital forensics generally.

Chain of custody, in plain terms

Chain of custody is the documented, unbroken record of who handled a piece of evidence, when, and what (if anything) was done to it, from the moment it was captured to the moment it's presented. The core reasoning: evidence is only as trustworthy as the record of what happened to it — if a violation record could plausibly have been altered between detection and presentation, with no way to prove otherwise, the record's evidentiary value collapses regardless of whether it was actually altered.

Sources: American Military University — Maintaining Chain of Custody for Digital Forensic Evidence, Eclipse Forensics — Chain of Custody in Digital Forensics.

Fisheries-specific version

A dedicated Evidence Collection Manual for Fisheries Enforcement, published to support Port State Measures Agreement implementation, exists specifically because generic chain-of-custody practice doesn't automatically cover fisheries evidence types (position tracks, catch photos, inspection forms). Its central point, in short: correct chain-of-custody procedure has to be followed or the case is weakened — this isn't a nice-to-have on top of detection, it's a precondition for detection to matter legally.

What this requires of a system, not just a process

Translated into system requirements, chain of custody generally demands:

Immutable capture — once a violation record exists, it can't be silently edited; any change is itself a new, timestamped, attributed recordThe same "no silent edits" principle Lesson 10 found in ERS's End-of-Fishing message.
Attributable access — every read/download of evidentiary material, not just every write, is logged with who and when
Retention that outlasts the case — evidence has to survive as long as it might still be needed, which is often years, not until the next deploy
Integrity verification — a way to prove a file hasn't been tampered with since capture, typically a checksum/hash recorded at capture time

Where this shows up concretely in e-Boat

The tender's own assumptions register grounds this in specific numbers rather than leaving it abstract: scanned document attachments (inspection photos, signed forms) are capped at 5MB, run through antivirus scanning (ClamAV) on upload, and held for a 7-year retention period specifically for evidentiary attachments — a duration set by the evidentiary need, not by ordinary application-log retention norms. That retention number is itself a tell: 7 years is far longer than any operational reason (debugging, analytics) would justify, and matches typical statute-of-limitations and appeal-window horizons for administrative/legal proceedings instead.

Check your recall

Something unclear, or want to go deeper on any term here? Ask the agent that built this lesson — it's your teacher for this workspace, not just a lesson generator.