Catch reporting: the half of MCS e-Boat deliberately doesn't own

Position and catch are two separate reporting obligations. Ukraine already built the catch half. Knowing where that line sits is what keeps e-Boat's scope honest.

Lesson 1 drew the VMS/ERS distinction in the abstract: VMS reports where a vessel is, ERS (Electronic Reporting System) — the electronic descendant of the paper catch logbook — reports what it caught. This lesson makes that concrete with the actual system on the other side of e-Boat's integration boundary.

eFish: Ukraine's ERS/licensing system

eFish is Ukraine's Unified State Electronic Fisheries Management System, operated by Держрибагентство (the State Agency of Fisheries), live since July 2024. It replaced a paper-based permitting process inherited from Soviet-era rules — reporting at the time framed it explicitly as a transparency and anti-corruption reform, alongside integration pressure from EU accession. It covers:

Fishing opportunities and authorisations (who is licensed to fish what, where)
Logbooks (the ERS half — what was caught)
Landing declarations (what was actually brought ashore)
The vessel register itself (which boats exist and who owns them)

Source: Development and Implementation of a Fisheries Information System in the State Agency of Fisheries of Ukraine.

Why e-Boat doesn't rebuild this

This is the practical reason e-Boat's README lists e-fish as an external REST consumer rather than a module e-Boat implements. eFish already discharges the ERS/licensing side of MCS. Building it again inside e-Boat would duplicate a live production system for no benefit — the efficient boundary is exactly where the two reporting obligations (position vs. catch) were always going to split anyway.

What crosses the boundary, and which direction

Concretely, in ToR terms, this integration surface is its own requirement group — C-127..C-133, "Integrations" — separate from all the monitoring/violation groups covered so far. Two things are worth being precise about:

e-Boat is the consumer of eFish's vessel/licence data, not the source of truth for it — a vessel's authorisation status is eFish's answer to give, not e-Boat's.Getting this backwards would mean e-Boat second-guessing licence data it doesn't own.
A violation e-Boat detects (e.g. fishing in a closed area) is a fact about a vessel's behaviour — it doesn't need eFish to exist, but cross-referencing it against eFish's catch declarations is what turns "vessel was somewhere it shouldn't be" into "and here's evidence the catch report doesn't match."This is the Unreported failure mode from Lesson 2, made operational.

Trembita: the plumbing option, not a requirement

One more piece worth knowing by name even though it isn't decided yet: Trembita (Трембіта) is Ukraine's national system-interoperability bus — the standard plumbing state systems use to exchange data with non-repudiation and audit guarantees. It's a real option for the e-Boat↔eFish integration, but per the tender's own analysis it is a proposed best practice, not a ToR mandate — direct bilateral REST/SOAP is explicitly sufficient, and which specific endpoints (if any) route through Trembita is a decision still owed at project Inception, once the full eFish API catalogue is available. Lesson 8 covers Trembita's broader role in more depth.

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.