Inspiration

An unusual underwater sound leaves harbor officers with a difficult choice: escalate without enough evidence, or wait and risk missing something important. We wanted to make the next step clearer.

Harbor Handoff connects detection, inspection, and human judgment. We also see potential for the same workflow to support efforts against overfishing by helping teams investigate suspicious vessel activity.

What it does

Harbor Handoff turns unusual underwater activity into an understandable event that an officer can review.

Our workflow has four stages:

  1. Listen: Establish normal harbor sound patterns and flag unusual acoustic events.
  2. Locate and cross-check: Estimate the source area and compare nearby vessel tracks from AIS.
  3. Inspect: Request an inspection boat to gather sonar and camera evidence.
  4. Hand off: Present the evidence so an officer can choose confirmed intrusion, false alarm, or nothing found.

The prototype demonstrates this workflow through a simulated harbor scenario. It brings acoustic alerts, vessel context, and inspection status into one interface while keeping the final decision with a person.

Its two intended applications are port security and fisheries monitoring. For overfishing, it could help prioritize suspicious activity for investigation; sound alone cannot establish that a fishing violation occurred.

How we built it

We organized the prototype around an acoustic-analysis view and a 3D harbor situation view.

The acoustic view displays sound frequencies over time, an anomaly score, adjustable sensitivity, and a persistence requirement before raising an alert. The harbor view places the event in context, showing nearby vessels, sensor information, and a simulated inspection boat.

The interface follows the officer’s decision process: what changed, where to investigate, what evidence is available, and what to do next. Recorded and simulated inputs make the demonstration repeatable without requiring a live harbor deployment.

Challenges we ran into

The main challenge was making an unusual sound useful to someone who is not an acoustics specialist. An anomaly score alone does not explain what happened or justify a response.

We also had to balance sensitivity with false alerts. Requiring an unusual pattern to persist can reduce brief triggers, but it can also delay detection.

Another challenge was communicating uncertainty. An estimated location is not a confirmed position, a nearby AIS vessel is not proof of the sound’s source, and an unsuccessful inspection does not necessarily mean nothing was there.

Accomplishments that we're proud of

We created a visual prototype that connects underwater sensing to an officer’s next decision.

We made the alert understandable through a spectrogram, event history, and harbor view. We also designed distinct outcomes for confirmed intrusion, false alarm, and nothing found, preserving the difference between disproving a concern and lacking enough evidence.

Most importantly, we kept human review at the center of the workflow.

What we learned

Detection is only the beginning. A useful system must help people interpret an alert, gather evidence, and choose a proportionate response.

We learned that uncertainty should be visible throughout the interface. We also learned that a convincing simulation demonstrates a workflow, but real-world performance requires independent testing.

The same evidence-gathering approach could support both port security and fisheries monitoring, although each application needs its own data, operating rules, and validation.

What's next for Harbour Handoff

Our next step is to test the detector on previously unseen, labeled underwater recordings and measure false alerts, missed events, and detection delay.

We then want to validate location estimates, connect live vessel information, and test inspection handoffs with port operators and marine researchers.

For the overfishing application, we would work with fisheries specialists to determine which acoustic and vessel-activity patterns are useful and what additional evidence is required.

We will build responsibly through human approval, access controls, and recorded decisions. An anomaly should prompt investigation—not automatically identify wrongdoing or trigger enforcement.

Built With

Share this project:

Updates

Submission history