Design a vessel-of-interest fusion pipeline for a maritime common operating picture
Fuse AIS, coastal radar and satellite detections into one picture, and flag the vessels that go dark.
- Cross-agency sharing
- CUI marking
- PIA
- Human in the loop
IllustrativeA composite built from public information. It does not describe a specific OCEANS engagement, customer system or solicitation, and every figure on this page is an assumption for the exercise.
Practice mode
45:00
Hides the write-up and starts the clock. Built for rehearsing an orals technical challenge.
01 · The prompt
“Four agencies watch the same stretch of coastline with different sensors, and none of them sees the whole picture. Design a system that fuses AIS, coastal radar and satellite detections into one common operating picture, flags vessels of interest, and shares the result with partners who are each allowed to see different things.”
02 · Ask these first
Each of these changes the design. Ask them before drawing a single box.
- Q1 Which decisions does the watch floor make from this picture, and how fast does it need to make them?
- Q2 Who are the partners, and what is each one allowed to see? Does any feed sit above CUI, and could the fused picture itself be classified by compilation?
- Q3 Who defines a vessel of interest: policy, the analysts, or us?
- Q4 What happens today when two sensors disagree about a track?
- Q5 Does the picture have to keep working when the satellite or partner feeds drop?
- Q6 How long do we keep the data, and under which records schedule?
Write-up hidden
Your turn. Requirements, sizing, architecture, trade-offs.
Work it on a whiteboard. When the clock runs out, or you're done, reveal ours and compare.
Time. Pens down.
03 · Requirements
What it has to do
- Ingest terrestrial AIS, satellite AIS, coastal radar tracks and satellite SAR detections, each through its own adapter.
- Correlate reports from different sources into one fused track per vessel, and keep the source tracks behind it.
- Detect dark gaps, AIS identity changes, loitering and ship-to-ship rendezvous.
- Score vessels of interest with reasons an analyst can read, and route them to a review queue.
- Serve the picture to the watch floor, and a filtered feed to each partner under its own agreement.
- Record every analyst decision and every release to a partner.
How well it has to do it
| Measure | Threshold | Objective |
|---|---|---|
| Sensor report to picture (p95) | ≤ 10 s | ≤ 3 s |
| Dark-gap alert after AIS goes silent | ≤ 15 min | ≤ 5 min |
| Watch-floor picture availability | 99.5% | 99.9% |
| Fused-track mis-association rate | ≤ 2% | ≤ 0.5% |
| Releases to the wrong partner or with the wrong fields | 0 | 0, with audit proof |
Exercise values, invented for this problem. Not a recommendation for any program.
04 · Sizing
~15,000
Vessels in view at peak
One regional area of responsibility, port approaches included
~2,500/s
AIS reports
15,000 vessels at about one report every 6 s
~2,000/s
Radar track updates
20 coastal radars, ~400 tracks each, 4 s scan
~45 GB/day
Normalized storage
~390M records a day at ~120 bytes each
~4 TB
Hot store
90 days online; older data moves to the archive tier
Binding constraint
~150/hr
Flags the watch can review
6 analysts × ~25 reviews an hour. This is the number that bounds the design.
The machines are the easy part. 4,500 messages a second is modest for any modern stream. The real ceiling is six people on a watch, so the scorer is designed to stay under their review rate, not the hardware's.
05 · Architecture
Scroll sideways to see the full diagram
Source tracks are never thrown away: every fused track points back to the reports that formed it. The release gateway sits in its own authorization boundary, and every analyst decision and partner release lands in the audit ledger.
06 · Trade-offs
Decision 01
One fused track, or keep the source tracks?
When an analyst asks why the system thinks two contacts are one ship, the answer has to be on screen. A fused track that has thrown its inputs away can't defend itself, and it can't be split when the association turns out to be wrong.
Decision 02
Where does correlation run?
Cross-sensor association needs every source in one place. Partitioning the stream by cell keeps each correlator small, and neighbouring cells hand off tracks that cross the line.
Decision 03
Rules or a model for vessel-of-interest scoring?
A referral has to state its reasons. Rules give readable reasons on day one, and every accept or dismiss an analyst records becomes training data for the model that comes later.
Decision 04
Partner sharing: one feed, or one per agreement?
If the filtering happens on the partner's side, the data has already left. The gateway applies each agreement's field rules, stamps the marking and logs the release.
Decision 05
Stream every detector, or batch some?
A dark-gap alert is worth minutes. Pattern-of-life analysis is worth hours, and running it continuously costs far more than it returns.
07 · The federal layer
The part commercial interview prep skips. On a federal program it decides whether the system ships.
Draw the ATO boundary on purpose
The release gateway sits in its own system boundary, so a partner agreement can change without reopening the core system's authorization.
PIA before the first byte
Vessel ownership records and crew lists carry personal information. The Privacy Impact Assessment decides which fields the system may hold and for how long, and that shapes the schema.
An ISA and an MOA for every feed
Each partner connection needs an Interconnection Security Agreement and a Memorandum of Agreement. Budget weeks for each, and build adapters so a new feed is configuration, not code.
Markings travel with the record
Each record carries its CUI categories and dissemination controls from ingest. A fused track carries all of them, because CUI categories are not ranked: its marking is the sum of its inputs, and it can be released only where every input allows. Check the program's classification guide too, since a fused picture can reveal coverage or patterns that are classified by compilation.
Retention is a requirement
How long data lives comes from the agency's records schedule, not from storage cost. The 90-day hot tier and the archive rules both trace to it.
Section 508 covers the watch floor
The picture has to work from a keyboard, and alert states can't rely on color alone.
08 · How it fails in month 12
- Alert fatigue Flags outrun analyst capacity and the queue gets ignored. Hold flag volume under the 150-an-hour budget and watch dismissal rates every week.
- Spoofed AIS taken as truth AIS is self-reported. Cross-check identity against radar and SAR, and treat AIS-only contacts as lower confidence.
- Clock drift between sources A few seconds of skew makes one ship look like two. Timestamp at the sensor, and correct or reject reports that arrive outside tolerance.
- A partner agreement changes quietly The MOA is amended and nobody updates the gateway. Version the release rules, tie each version to the signed agreement, and test releases against it.
More on this pattern: What kills programs in month 12.
09 · How we'd test it
| Type | Measure | How it gets measured |
|---|---|---|
| MOE | Lead time on a vessel of interest before it reaches the port approach (threshold ≥ 30 min, objective ≥ 2 h) | A red team runs dark-vessel scenarios the watch has not seen during a live exercise. A white team runs the event and scores each run against an analysis plan written beforehand. |
| MOE | Time from flag to analyst decision (threshold ≤ 10 min, objective ≤ 3 min) | Instrument the review queue during an operational assessment with real watch-standers. |
| MOP | Sensor-to-picture latency, p95 | Synthetic load at twice peak, timestamped at the sensor, the stream and the display. Feeds the lead-time MOE. |
| MOP | Dark-gap alert latency | Cut AIS from chosen vessels in replayed traffic while radar or SAR still holds them, then confirm with cooperative vessels in the exercise. Time each alert against the 15-minute threshold. |
| MOP | Track mis-association rate, scored by vessel class | Replay recorded traffic against ground truth from a cooperative-vessel test. |
| MOP | Watch-floor picture availability | Logged over a 30-day operational assessment, with maintenance windows declared in advance. |
| MOP | Release correctness | Automated tests for every agreement version. One wrong field fails the build. |
MOE and MOP are defined in the Mission Glossary.