A major new capability is being developed inside Mussel App.
Right now, it is learning quietly in the background. You will not see it in your account until next month, because before we release it, we need to test it against real farms, real operating limits and real user accounts. Weather warnings are too important to launch based only on laboratory testing and good-looking screens.
This article may sound scientific in places, but it is worth reading if you are an aquaculture farmer. Behind the forecasts, wave periods, pressure changes and alert thresholds is a very practical goal: helping you decide when to work, when to prepare and when conditions could put your crop, equipment or harvest plans at risk.
Mussel App was never intended to be another piece of software that simply collects your farm data. You have probably seen plenty of those already.
We are building Mussel App to use that data intelligently, warn you before problems become expensive and genuinely help protect the money you have invested in your farm.
This is what we have built, what we have learned and why the most important part of a weather warning system is often knowing when to stay quiet.
Every shellfish farmer already has access to a weather forecast.
They can see Saturday’s wind speed, Tuesday’s expected rainfall and the height of the next swell. Simply displaying the same numbers inside Mussel App would add little value.
The useful question is not:
What will the weather be?
It is:
What does that weather mean for this farm, this crop and the work planned for that day?
That distinction has shaped the weather warning system we have built for Mussel App. It turns forecast data into a small number of farm-specific operational warnings.
Most of the engineering, however, did not go into generating more alerts.
It went into deciding what the system should not say.
A forecast is not a warning
A standard weather application might tell a farmer: Wind gusts may reach 38 knots on Saturday.
A farm-specific warning should provide much more context: Gale conditions are forecast from 3:00 am to 2:00 pm on Farm 12. Your configured crop-handling limit is 34 knots. Secure loose equipment on Friday.
The forecast value has not changed. What changed is its relationship to the farm.
The same principle applies to rainfall:
48 mm of rain is forecast against the 20 mm trigger entered for this growing area. Thursday’s planned harvest falls within the operator’s expected closure window.
Or swell:
A 2.1 m swell at 13 seconds is forecast beam-on to the farm’s backbones. Long-period swell can load the full dropper column, backbone and mooring system.
A generic gale warning is information anyone can access for free.
A gale warning affecting near-harvest crop after an extended period of thermal stress is a farm-management decision.
That is the difference Mussel App is trying to deliver.
A forecast is not a warning
A standard weather application might tell a farmer: Wind gusts may reach 38 knots on Saturday.
A farm-specific warning should provide much more context: Gale conditions are forecast from 3:00 am to 2:00 pm on Farm 12. Your configured crop-handling limit is 34 knots. Secure loose equipment on Friday.
The forecast value has not changed. What changed is its relationship to the farm.
The same principle applies to rainfall:
48 mm of rain is forecast against the 20 mm trigger entered for this growing area. Thursday’s planned harvest falls within the operator’s expected closure window.
Or swell:
A 2.1 m swell at 13 seconds is forecast beam-on to the farm’s backbones. Long-period swell can load the full dropper column, backbone and mooring system.
A generic gale warning is information anyone can access for free.
A gale warning affecting near-harvest crop after an extended period of thermal stress is a farm-management decision.
That is the difference Mussel App is trying to deliver.
Sometimes the best alert is
good news
One of the most important outputs is not technically a warning at all.
It is a workable window.
For most farms, the recurring operational question is not whether a major storm is coming. It is which days are likely to remain inside the farm’s configured working limits.
A workable window can help teams plan:
- vessel movements
- crop assessments
- maintenance
- seeding
- harvesting
- staff and equipment allocation
It also helps prevent the notification channel from becoming a constant stream of bad news.
An alert system that only announces problems will eventually be ignored. Once users mute it, the warning that genuinely matters may never reach them.
Workable windows are deliberately worded carefully. Mussel App does not declare that conditions are safe. It reports that forecast conditions remain inside limits configured by the operator.
The final decision still belongs to the skipper and farm team.
Alert fatigue is an engineering problem
Alert fatigue is not something that can be fixed later with better colours or notification settings.
It has to be designed out of the warning engine itself.
Our target is:
- no more than one push notification per user per week during normal conditions
- no more than three during an active storm
- no more than ten standing warnings per user
Several mechanisms work together to keep notification volumes within those limits.
Conditions must persist
A threshold must normally be exceeded for several hours before it becomes a warning.
For example, with a forecast updated in three-hour intervals, a six-hour persistence rule requires two consecutive forecast points above the threshold.
This removes short-lived model spikes before they ever reach the user.
A candidate must survive two evaluations
Even when a forecast crosses a threshold, the warning remains pending until it appears in two consecutive evaluation runs.
A single unstable model run should not be enough to wake a farmer at 3:00 am.
Warnings do not immediately re-arm
Conditions must clear for two evaluation runs and fall meaningfully below the original threshold before a warning resolves.
Without this deadband, a forecast sitting close to the threshold can create an endless cycle:
Warning fired.
Warning cleared.
Warning fired again.
A warning must never re-arm at the same value that cleared it.
One storm should create one message
Warnings are also inhibited and grouped.
A severe pressure-fall warning can suppress lower-level wind and wave notifications covering the same period. A gale warning suppresses workable-window messages for the affected day.
When the same weather system affects twelve farms, the account manager should receive one message listing those farms, not twelve separate notifications.
We initially implemented grouping inside each individual farm’s notification process. The code technically grouped messages, but each farm had already become a separate delivery before the grouping occurred.
The requirement was implemented in a place where the architecture made it impossible to satisfy.
The evaluation process now gathers warning activity across the whole account and dispatches once per user.
“No warnings” must never mean “no data”
An empty warning list is a claim. It tells the user:
We checked the forecast, and there is nothing requiring your attention.
That is very different from:
We could not retrieve the forecast.
If a data feed fails and the system displays an empty list, it has effectively told the farmer that conditions are fine without having any information to support that conclusion.
Mussel App therefore treats No Data as a first-class state.
The weather provider can return:
- a successful forecast
- insufficient forecast coverage
- insufficient forecast reach
- partial data
- a complete feed failure
Existing warnings are not automatically resolved when the latest forecast is unavailable.
The interface shows the warnings it still has while clearly explaining which information could not be refreshed. It also directs the operator to the relevant national weather service.
This becomes especially important because atmospheric forecasts and wave forecasts often come from separate models.
If the wind forecast loads but the wave request fails, the result is not “calm seas”. It is a partial forecast.
Wind and rainfall rules can continue to evaluate, while the wave component reports that its data is unavailable.
What the system refuses to say
Weather can support operational decisions, but it cannot answer every question affecting a shellfish farm. Being explicit about those limits is essential. It does not declare a growing area open or closed.
Growing-area status is determined by regulators using management plans, laboratory testing, phytoplankton monitoring and other evidence.
Weather alone does not establish legal harvest status.
Rainfall warnings therefore compare forecast rainfall with a trigger entered by the operator. Mussel App does not display an “area will close” badge or attempt to replace the regulator.
The warning says: Rain against your trigger.
That is what the system actually knows. It does not say conditions are safe.
Mussel App does not use green ticks, thumbs-up icons or universal go/no-go decisions. Operating limits differ between vessels, farms, equipment, crews and company safety systems. A workable window means only that forecast conditions are expected to remain inside the limits configured for that farm. It does not invent probabilities
A single deterministic forecast model cannot honestly support statements such as “70% chance”. Instead, the system can report observable forecast behaviour: This condition appeared in the last four forecast runs.
Certainty is derived from factors such as run-to-run persistence, lead time and whether the expected onset is moving significantly between forecast updates. The interface can describe a forecast as likely, possible or unlikely. It will not describe anything in a forecast as observed. It does not rewrite official warnings
Official warnings from national weather authorities are presented separately, with the issuing organisation and issue time. They are not paraphrased, downgraded, suppressed or converted into Mussel App’s own severity scale.
Sometimes the honest answer is no number
Global forecast models commonly operate on grids far larger than the sheltered waterways where many shellfish farms operate. At approximately 41° south, a 0.25-degree model grid can represent an area roughly 21 km east-to-west and 28 km north-to-south.
A single cell can cover approximately 585 square kilometres. By comparison, parts of Pelorus Sound are only a few kilometres wide. Kenepuru Sound is narrower still.
Inside a global model, the channel, surrounding ridges and local wind funnelling may barely exist. Several farms spread across differently oriented waterways can collapse into the same forecast cell and receive identical model values.
Wave data can be even more problematic.
Some global wave models do not contain a valid water cell inside sheltered sounds. A returned value may be interpolated from open-strait or offshore swell that cannot physically propagate to the farm.
In those cases, Mussel App does not display a caveated or greyed-out wave height. It says: Wave forecast not available at this site.
The wave feature defaults to off until a usable source has been confirmed for the farm. An open-ocean wave height displayed inside a sheltered sound is not simply an imprecise value. It may describe a wave that cannot reach the site at all.
A smarter warning needs more than a threshold
Some risks cannot be captured by checking whether one number is above or below a fixed limit. Wave period changes the risk. Wave height alone is not enough.
Deep-water wavelength is approximately: 1.56 × period².
A 1.8 m swell with a 14-second period may place more load on a farm than a 2.5 m short-period wind sea.
Long-period swell produces motion deeper in the water column, loading droppers, backbones and moorings together. Where available, the system therefore examines the swell component rather than relying only on the combined sea state.
Pressure-fall thresholds depend on latitude. The pressure-drop threshold associated with explosive cyclogenesis is not a fixed global number. t changes with latitude: 24 × sin(|latitude|) ÷ sin(60°)
This produces different thresholds for Coromandel, Marlborough and Stewart Island. It is a small calculation, but it allows the warning to reflect the physical location of each farm instead of applying one generic rule everywhere.
Farm geometry changes loading. Mainline length can also interact with wavelength.
Certain relationships between backbone length and wavelength can increase windward mooring load. Because Mussel App already stores farm geometry, the engine can calculate these relationships for individual lines rather than treating every farm layout as identical.
Why we deliberately deferred biological warnings
Published biological thresholds do not transfer cleanly between species. Research for New Zealand green-lipped mussels cannot automatically be applied to blue mussels, Chilean mussels, oysters or kelp.
The consequence of using the wrong threshold may not simply be a false warning. It may be false reassurance.
For that reason, the first phase focuses on operational warnings that can be connected to farm and vessel limits:
- wind
- gusts
- waves
- pressure changes
- workable windows
- rainfall against operator-entered triggers
Thermal and biological warnings require a separate evidence review for each species.
The system already contains the framework for compound risks, such as heat-weakened attachment meeting an approaching gale. Those rules remain switched off until they can be validated against species-specific research and operators’ own damage records.
Shipping less is sometimes the more responsible engineering decision.
Testing whether the system should be released
The warning evaluator was built as a pure, replayable component. It does not depend directly on the database or the current system clock. Historical weather can be passed through the same engine used for future forecasts.
Our backtesting process walks through stored data, simulates forecast evaluations and applies the same pending, deduplication and warning-lifecycle rules used by the live system.
It then compares the projected notification volume with the alert budget. If the volume is too high, the command fails with a clear result: Volume budget breached — do not ship these thresholds.
That failure is intentional.
A launch gate is only useful when it can stop a launch.
Farm-scoped is not the same as person-scoped
Every warning is calculated for an individual farm, using that farm’s coordinates, timezone, limits and forecast data. But isolating the calculation is only half the problem. The people receiving and managing warnings also need to be correctly scoped.
During review, we found three important risks:
- A crew member without an explicit farm assignment could inherit access to every farm in the account.
- A user could potentially change another farm’s warning configuration by supplying its identifier.
- Snoozing or acknowledging a warning could silence it for the entire team.
Those behaviours may be tolerable in some low-risk areas of a management platform. They are not acceptable for warnings. Membership now fails closed, warning configuration is restricted to authorised roles, and acknowledgements or snoozes are stored per user. A storm that becomes materially worse also reopens a dismissed warning, because changed evidence is a new fact.
The calculations were isolated by farm from the beginning.
The humans needed to be isolated too.
What we built
The first phase of the Mussel App weather warning system includes five operational warning types, with nine additional categories scoped and deliberately deferred. Across the supporting services and interfaces, the build currently includes:
- approximately 16,000 lines across three repositories
- 363 backend tests
- verification against 212 live NOAA alerts
- complete geometry resolution for the alerts used in testing
- a launch gate that fails when projected notification volume exceeds the budget
The most important result is not the number of warnings the system can generate. It is the number it prevents from reaching the user.
A useful warning engine must identify real operational risks, understand the limitations of its data and remain quiet when the evidence is not strong enough. That is how it earns the right to interrupt a farmer.
