Harbormaster ensures reliable maritime anomaly alerts on AWS
Harbormaster: Evidence-Gated, Replay-Safe Maritime Anomaly Detection on AWS
Cryptography and Security
Summary
Ships broadcast their positions, but sometimes these messages are wrong or missing, which can cause problems. The authors created Harbormaster, a system that checks each ship report for obvious errors before analyzing it. Their system carefully manages data updates on AWS so alerts are accurate, reviewable, and can recover from failures. They tested it with realistic data bursts and showed it handles them efficiently while keeping data consistent.
What this means in practice
- •For maritime operations teams: Detect and investigate suspicious ship movements with reliable alerts that remain consistent and recoverable after system failures.
- •For cloud infrastructure engineers: Implement fault-tolerant, replay-safe event processing pipelines on AWS ensuring data correctness and controlled model rollout.
Authors
Arun Sharma
Abstract
Ships broadcast their positions through the Automatic Identification System (AIS), and those reports can be false or missing. An operator who acts on an anomaly alert needs that alert to be attributable, reviewable, and recoverable after a failure. This paper describes Harbormaster, a production-shaped system on AWS that follows three rules. Physics checks run on every report before any learned model runs. The DynamoDB read store is an idempotent projection of PostgreSQL, and a guard on the log sequence number (LSN) of each change protects every write to it. A candidate model must pass a holdout gate and a shadow comparison before a canary gives it traffic, and a burn-rate check guards each canary step. The paper proves that replaying any prefix or suffix of the change log leaves each projected key at the value of its highest applied LSN. It also notes effects this result does not cover, such as repeated cache invalidations and repeated audit rows. In a bounded AWS window, a one-hour soak returned 35,999 HTTP 200 responses to 36,000 requests, with a 95th-percentile (p95) client latency of 142.751 ms. In a separate bounded AWS run of 900 s, the stream path received a burst of 400 records/s, and its consumer lag later drained to zero. Every number in the paper carries a label that says where it was measured, and the paper lists the parts of the design that were never built.