Why catch forecasting breaks down on incomplete data
Catch forecasting breaks down not on the algorithm, but on the input. Three data streams about the same fishing operation — vessel reports, satellite monitoring, and oceanographic layers — diverge in frequency, accuracy, and latency.
Until they are brought to a common scale, the model sees not the ocean, but a mosaic of incomplete fisheries data.
Fishery reports are filled in manually, often upon return to port rather than at the moment of fishing.
Catch, bycatch, and trawling time are reconstructed from memory and the ship's log, so gaps in vessel reports are the norm, not a failure: some trips arrive with weeks of delay, some with coordinates rounded to the nearest whole degree.
Satellite monitoring provides vessel position and speed every few hours, but says nothing about catch: the track shows where the fleet worked, but not how much it took.
Oceanographic layers — surface temperature, chlorophyll, currents — arrive as separate datasets with their own time step and spatial grid, and there is nothing to align them with the tracks.
Hence the desynchronization of sources: hourly tracks, daily reports, and ten-day fields live on different time axes.
On such a sample, the model substitutes the area average in places with gaps, and catch forecasting error grows exactly where the decision is most expensive — at the boundary of fishing aggregations. The fleet goes to squares where "the fish should bite", burns fuel, and loses days.
We explain how this is closed: by bringing streams to common spatiotemporal cells, reconstructing gaps from indirect signs, and honest uncertainty estimation — so the forecast shows not only where to look, but also how much it can be trusted.
What changes in fishing operations after model deployment
Before the model, the decision to set gear relied on the captain's experience and correspondence with neighboring vessels.
The oceanographic picture arrived with a one-day delay, fleet positions were analyzed after the trip, and CPUE was calculated from actual catch and had no real-time effect.
The price of such a scheme is empty transits of 6–10 hours and a severalfold spread in successful sets between vessels in the same group.
The model brings oceanography from Copernicus, vessel positions from vessel monitoring, and accumulated CPUE into a single time scale and provides an estimate for each square for the next day.
The share of successful sets in target squares rises from 40–45% to 65–70%, empty transits are reduced by about a third: the vessel less often goes "just in case" to where the front has already shifted.
On the bridge, this is a single summary for the area, updated on schedule and after each set.
The time from summary to captain's decision is measured in minutes — no need to cross-check three sources and call neighboring vessels, and the order of traversing squares is visible immediately.
A separate class of failures is closed — "there is a forecast, but no data under it": before output, the estimate undergoes a completeness check of input fields and satellite slice freshness.
If coverage is patchy, the square is honestly marked as unforecastable instead of a low-confidence number. Owing to this, fishery forecast accuracy does not sag during transitions between seasons, and fleet downtime is reduced — fewer hours on transits without setting gear.
Comparison of approaches: statistics, physical model, machine learning
The approach is chosen not by degree of modernity, but by available data and fishery stability. While vessels operate in familiar squares, statistical catch models based on previous seasons' reporting maintain acceptable accuracy. Their limitation is non-transferability to a shifted stock: the series lags by a season or two.
Oceanographic data — surface temperature, currents, sea level height — describe the environment but not fish distribution.
Therefore, training on combined layers links the environment with catch and fishing effort, while satellite series from Copernicus fill gaps where in-situ observations are scarce.
| Approach | When it fits | Limitations |
|---|---|---|
| Reporting from past seasons | Stable area, long series, even fishing effort | Does not transfer to new squares, lags behind stock shifts |
| Physical water transport model | Few fishery observations, need current and transport mechanics | Requires calibration, does not directly provide a fishery forecast |
| Machine learning on combined layers | Both oceanographic series and vessel monitoring data are available | Sensitive to gaps and leakage between training and validation samples |
| Hybrid scheme | Need a forecast where the stock shifts | More expensive to maintain: requires both competencies and regular recalibration |
Pure options almost never occur: physics sets the boundaries of the possible, statistics and machine learning refine within them. Next — how it is verified that the model maintains accuracy in a new season.
Work order: data audit, schema, configuration, validation
We start not with the model, but with the data: without analyzing sources, any demo accuracy will not survive the first real season. Below are six stages that go from fishery data audit to handover of maintenance regulations.
- Fishery data audit. We consolidate ship logs, CPUE by species, VMS tracks, and oceanographic fields, and check completeness by seasons and fishing squares.
- Data schema. A single storage with "vessel — day — square" granularity, coordinate reference, and explicitly marked gaps, so interpolation does not pass itself off as fact.
- Feature engineering. Thermal fronts, seasonal shifts, history for a specific vessel and area — only what is actually related to catch.
- Model configuration. Training on fishing seasons with time-based, not random, sample splitting: otherwise accuracy will be inflated and will drop on new data.
- Forecast validation. Testing on seasons the model has not seen: comparison with actual CPUE, error separately by areas and by rare species.
- Handover. Schema, configurations, retraining regulations, and monitoring metrics — the team will be able to update the forecast on its own.
Each stage ends with an artifact that can be checked: a list of sources with a completeness assessment, a storage schema, an error report for past seasons.
What the customer receives: models, schemas, regulations
A catch forecasting model is valuable together with its supporting framework: without a description of assumptions, a flow schema, and an update regulation, it cannot be maintained or defended before a regulator.
Therefore, we hand over the project as a set of artifacts — from the parameters of the trained model to the procedure for analyzing discrepancies with actual catch.
- Trained model with a model card: target variable (CPUE by fishing zones), forecast horizon, assumptions, applicability boundaries, and behavior on rare scenarios.
- Data flow schema: sources of oceanographic fields and vessel positions (VMS), arrival frequency, aggregation windows, quality control points, and gap-filling rules.
- Access rules: roles for fleet, analysts, and dispatchers, differentiation by zones and vessels, and a log of forecast requests.
- Update regulation: retraining frequency, triggers for accuracy degradation, and the threshold after which a version is taken out of service.
- Operating instructions: starting calculations, checking data freshness, actions when a source is unavailable, rollback to a previous version.
- Procedure for analyzing discrepancies: how actual catch is recorded, how error is calculated, and who resolves a systematic deviation and within what time frame.
- Acceptance protocol: control periods on which the customer reproduces metrics independently, without our assistance.
Model documentation lives in the customer's environment and is updated together with the code — when the contractor or team composition changes, the solution remains operational.
Fishery case: accuracy and downtime before and after deployment
Two fishing seasons of the same group of vessels are the basis for comparison.
In the first, the forecast was built on historical ship logs and captains' summaries: aggregations were sought "by experience", transits took up to half of fishing time, and the discrepancy between forecast and actual catch was analyzed already on shore.
Before model configuration
The share of successful days remained around 40%: on the remaining days, the fleet worked on weak aggregations or returned to proven squares. The average transit to a fishing point was 45 nautical miles, and some trips went into blind search.
Every fourth summary was disputed: the vessel and the shore had different data for the same squares.
After deployment
The model brings oceanographic fields from Copernicus Marine, vessel positions from the monitoring system, and catch per unit effort into a single picture and updates the aggregation forecast several days ahead.
The share of successful days grew from 40% to 68%, the average transit length decreased to 25 miles — the freed-up time went into fishing. Disputed summaries decreased threefold: the discrepancy is visible in advance, not after the fact.
The forecast is retrained on data from each trip: fresh catches are returned to the sample, so seasonal shifts in temperature and forage base do not "age" the model.
Captains receive one summary instead of several contradictory ones, and disputed squares are marked directly on the map.
How catch forecasting differs from effort reports
An effort report describes the past: catch per unit of fishing effort (CPUE) in a square over a period. The metric is correct retrospectively, but carries built-in bias — effort is allocated to where fish have already been found.
Squares that vessels did not visit are simply absent from the data. This does not mean they are empty: no one went there. A model trained on such material reproduces fleet routes, not resource distribution, and behaves uncertainly in new areas.
The forecast is formulated differently. The target variable is a density estimate at each point of the water area, including unused areas. Predictors are oceanographic fields: surface and depth temperature, salinity, gradients, position of fronts and eddies. They are measured regardless of whether the fleet worked there.
Hence the boundary between methods. Accounting evaluates fleet performance and depends on its behavior. Forecasting evaluates the environment and its suitability for the species, so it transfers to areas without fishing.
Satellite vessel position monitoring (VMS) and effort data remain in the system, but as context and quality control, not as a source of the answer.
We verify this on time windows: training on past periods, validation on future ones, not on a random sample of rows — observations adjacent in time almost always correlate.
Separately, we make sure that a feature is not assembled from information about vessel trips: such leakage from the target variable produces a beautiful but useless metric.
The output is a probability map with a horizon, used to plan the fishing area. The difference is not in the precision of the numbers: accounting answers about the past, forecasting — about a place where a vessel has not yet been.
Technical concerns: data, accuracy, model updates
Engineers' concerns usually relate not to the model itself, but to the input: what to feed it if logs are kept manually and some data arrives with delay. Below are objections that come up at every review and how they are addressed.
Everything is in paper logs and inconsistent
A manual fishing log is not an obstacle: it remains a control source, and the forecast is built on the combination of "catch per unit effort (CPUE) + oceanography".
We do not hide discrepancies between the log and vessel monitoring — they themselves become a feature (a gap in the track, a recording error), and they show which rows to trust.
The season will change — the model will become outdated
The forecast is trained not on the annual average, but on a sliding window within the season and fishing area: when the fishing season changes or the area boundary shifts, its own segment works, not extrapolation.
Rebuilding happens on schedule and on signal — a discrepancy between fact and forecast above the threshold triggers it off-schedule.
We already have vessel monitoring deployed
We connect vessel monitoring (VMS) as a separate stream without rewriting the existing one: position frequency and access to historical exports are important.
On board, the communication channel breaks — the calculation goes to shore and is pulled in after restoration, so the crew is not left without output. Open oceanographic sources come with an explicit snapshot date: if the data lags, it is visible directly in the forecast card.
Let's discuss the task: data composition and work plan
An estimate for such a task rests on two things: completeness of historical data and forecast horizon. The fewer gaps in vessel reports and the more regularly monitoring coordinates arrive, the more stable the features for the model.
To discuss the task, the list below is enough — preliminary cleaning is not needed, we will sort it out ourselves.
- Export of vessel reports for two or three seasons: gear setting and hauling time, coordinates, species, catch mass — CSV, as provided by the accounting system.
- Access to vessel monitoring data: coordinates with polling interval and vessel identifiers — as a file or export on request.
- Oceanographic layers for the same period: surface temperature, currents, chlorophyll content, depths for the required areas.
- List of fishing areas and seasons for which the forecast is built, with boundaries in coordinates.
- Expected forecast horizon: day, week, or ten-day period — the feature set and acceptable data latency depend on it.
- Quality metric you trust: CPUE per effort, hit in the area, or the "fishing / not fishing" fact.
- Who on your side accepts the result — the person confirming the composition of fields and model acceptance.
Based on this data, we will assemble a work plan: which features we calculate from oceanography, which from monitoring, where we place placeholders for gaps, and how we validate the model on held-out seasons. Describe the task — we will return with an estimate and a plan.
