Fisheries VMS Domain · Lesson 14 of ∞ · Second pass · ← Lesson 13
Second pass · reading maturity, not just requirements
Lesson 12 asked why C-066..C-076 matters legally. This lesson asks how it actually moves — and reads e-Boat's own code to find two very different answers hiding under one requirement group.
ToR §5.10–5.11 (C-066..C-076, 11 requirements) bundles "documents" and "notifications" together, and the compliance matrix gives nothing beyond that one line — no narrative, no per-requirement breakdown. That's worth naming as a real documentation gap before going further, not something to paper over: this lesson had to be built by reading the code directly rather than any written spec.
A "notification" in fisheries MCS isn't one thing — it's at least three different flows depending on who's on the receiving end:
| Audience | Purpose | Example |
|---|---|---|
| Regulator / inspector | Dispatch attention to a detected violation | An internal alert routing a geofence breach to the officer on duty |
| Vessel / master | Preventive — warn before a violation happens | Parks Australia/AFMA's real-time alert service, live since 2014, which messages a vessel master and licence holder the moment they enter a marine park where their gear is prohibited |
| Public | Let anyone report a suspected violation | NOAA's 24/7 Enforcement Hotline for reporting a federal marine resource violation |
Sources: NOAA Fisheries — Report a Violation; the AFMA alert service is referenced via "Preventing noncompliance in marine protected areas using a real-time alert system".
The vessel-facing (preventive) case is the interesting one against everything covered so far: it means a "notification" can fire before a violation exists, aimed at stopping it, not just documenting it after the fact. Worth checking, when reading e-Boat's own notification requirements, which of these three audiences a given requirement actually targets — the ToR table doesn't say, and the answer changes what "success" looks like for that requirement entirely.
Unlike the tracker-adapter case in Lesson 4 — where a genuinely open external fact (the vendor list) blocks implementation — EBoat.Notifications shows a different kind of "not done": a deliberately designed seam with nothing plugged into it yet, wired into the app but turned off.
Concretely, from the code itself:
Read together, this is a team that has already made several real decisions (severity tiers, throughput budget, channel list, the SPI shape) without yet writing the delivery code — a "designed, not built" state, distinct from both "intentionally deferred pending an external fact" (Lesson 4) and "not started."
A background service draining a queue and fanning out across independent channel implementations — rather than the rule engine calling SendEmail() directly — is standard notification-system design for exactly the reasons general practice describes: channels fail independently, need independent retry/backoff, and a stuck SMS provider shouldn't block an in-app inbox message from arriving. Worth knowing the vocabulary even though none of it is implemented yet in this codebase: idempotency keys (so a retried delivery doesn't double-send), dead-letter queues (so a failure is captured, not silently dropped), and fallback channels (so a failed SMS can escalate to a phone call or email instead of just failing).
Source: SuprSend — Notification Retry and Fallback Design.
The "documents" side of this requirement group is a genuinely different story — not a designed-but-unbuilt skeleton, just an unused configuration block. appsettings.json defines a Storage section (MinIO endpoint, bucket eboat-documents, 5MB max file size, allowed extensions .pdf/.jpg/.jpeg) — and nothing in the codebase reads it. No Documents controller, no entity, no upload endpoint. The root README mentions "documents" as one of the fragment types htmx is meant to own, but no view backs that mention either.
World practice offers two genuinely different things this could eventually become, and it's worth distinguishing them rather than assuming either:
The EU's new digital CATCH system — replacing paper catch certificates, compulsory for EU operators and authorities from 10 January 2026 — is the concrete world-practice example of the second category: a document that certifies a shipment's legal origin to a trading partner, not evidence for a domestic prosecution. Given the 5MB/pdf-jpg-jpeg config already sitting in e-Boat's settings, the evidentiary category (scanned inspection material) looks like the closer fit — but this is a real open question, not something resolvable from the repo as it stands today.
Source: IUU Watch — The Catch Certificate Scheme, SeafoodSource — new digital CATCH certificate.
A ToR checklist has one column: done or not done. Reading the actual code surfaces at least three distinct stories that column can't tell apart — and the difference changes what question to ask next.
| Pattern | Example | Right next question |
|---|---|---|
| Intentionally deferred, documented | ITrackerAdapter (Lesson 4) — blocked on the Customer's vendor list | "When does the blocking fact resolve?" |
| Designed, not yet built | EBoat.Notifications — SPI + severity tiers + throughput budget exist; channel classes and dispatch logic don't | "What's the build sequencing, and why is it still switched off?" |
| Not yet started | Documents — an unused config block, no consuming code | "Has anyone decided which real-world document category this even is?" |
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.