Fisheries VMS Domain · Lesson 9 of ∞ · ← Lesson 8
Capstone
Eight lessons of vocabulary and world practice are only useful if they change how you read the actual compliance matrix. This is that test, using the real requirement groups from docs/compliance/README.md.
The e-Boat ToR's 172 requirements are grouped into 11 blocks. For each one below, work out — before opening the answer — which MCS pillar (Monitoring / Control / Surveillance) it mainly belongs to, and which lesson in this series would help you explain it to someone unfamiliar with the domain. Then check yourself.
ToR §5.1–5.5 · C-009..C-039 · 31 requirements
Monitoring objects, map, tracks, geofences
Monitoring, with a heavy Control component in the geofence definitions themselves. The largest single group in the ToR — a signal that this is the load-bearing capability, not one feature among many. See Lesson 5.
ToR §5.6–5.7 · C-040..C-051 · 12 requirements
Event type catalogue, event capture
Monitoring — the broad "things that happened" stream, deliberately wider than violations. See Lesson 2 for why this is a separate group from the next one.
ToR §5.8–5.9 · C-052..C-065 · 14 requirements
Violations: catalogue, capture, history
Surveillance — events checked against Control rules, with the subset that breaks a rule promoted to a violation. See Lesson 2.
ToR §5.10–5.11 · C-066..C-076 · 11 requirements
Documents, notifications
Surveillance follow-through — the evidentiary and communication layer that makes a detected violation actionable (an inspector needs a document trail, an operator needs an alert). Not covered by its own lesson yet — a candidate for a future one if this area gets non-obvious in practice.
ToR §5.12 · C-077..C-087 · 11 requirements
Tracker device management
Monitoring infrastructure — not position data itself, but the health and lifecycle of the hardware that produces it. See Lesson 4, including why ITrackerAdapter is intentionally unimplemented right now.
ToR §5.13 · C-088..C-098 · 11 requirements
User management
Cross-cutting, not a pillar itself — but note the connection to Lesson 8: user identity here is federated Keycloak + Дія.Підпис/QES, part of what e-Boat brings itself rather than inherits from the registry platform.
ToR §6 · C-099..C-126 · 28 requirements
Non-functional requirements
Not a pillar — but every number in this block is worth running through the Lesson 3 question: which legal obligation is this NFR actually serving? The 30s device-to-map latency target traces back to UNFSA's "investigate promptly" duty, not arbitrary UX taste.
ToR §7 · C-127..C-133 · 7 requirements
Integrations
Where e-Boat's boundary with the outside world is drawn explicitly — eFish (Lesson 6) and the registry platform's Keycloak federation (Lesson 8) both live here.
The pattern across all nine entries: a ToR requirement group is almost never self-explanatory from its title alone. "Documents, notifications" sounds administrative until you connect it to evidentiary chain-of-custody for a violation. "User management" sounds generic until you connect it to the platform-integration decision in Lesson 8. The habit worth keeping is asking, for any requirement: which MCS pillar, which world-practice concept, and which real system on either side of e-Boat's boundary does this actually touch? That's the whole method this workspace has been teaching — the vocabulary was never the point, the ability to place a requirement in the world was.
This closes the first pass across the mission's breadth — terminology, world practice, the legal "why," the technical pipeline, and e-Boat's actual boundaries. A second pass (lessons 10–13) goes deeper on four things flagged here as gaps: ERS mechanics, the Black Sea/Azov Sea "why now" context, documents/notifications as chain-of-custody, and the six NFR numbers decoded one by one.
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.