Wide-area search finds it. Hi-res confirms it.

The classic ISR tip-and-cue loop, automated: a wide-field FMV stream runs continuous YOLO-E detection; when a target class of interest appears, the service raises a re-image request that tasks a higher-resolution SAR or EO collect over the detection footprint - with a human-in-the-loop approval gate so the operator signs off before the asset is committed. The detection-tipped, sensor-cued workflow that turns a wide search into a confirmed identification.

FMV YOLO-E detectionSAR / EO re-imageApproval gate Rule-drivenPersistent rules

The loop

Detect → request → approve → task → confirm

Tip-and-cue closes the gap between a wide-area sensor that covers ground fast (but at low resolution) and a narrow-field sensor that confirms detail (but can't search widely). The platform automates the handoff.

Detect - the continuous-detection host runs YOLO-E over the FMV frames; a detection of a rule-matched class (e.g. "vessel", "vehicle") in a rule-matched area raises a tip.
Request - the service creates a pending re-image request carrying the detection footprint, the cueing sensor (SAR or EO), and the rule that fired.
Approve - the operator reviews the pending request and approves or rejects it. Nothing tasks without sign-off.
Task - on approval, an imagery-order request is filed (commercial EO via the ordering pipeline, or a SAR tasking).
Confirm - when the cued collect arrives and is registered, the operator compares it against the tip that started the loop.

/api/tipandcue

# a rule: detect vessels in the AOI → cue SAR
POST /api/tipandcue/rules
{
  "name": "vessel-sar-cue",
  "detectionClass": "vessel",
  "aoi": { "rings": [[…]] },
  "cueSensor": "SAR",
  "minConfidence": 0.7
}

# pending requests awaiting approval
GET  /api/tipandcue/requests?status=pending
→ [{ "id":"req-9f",
     "rule":"vessel-sar-cue",
     "footprint":[-76.5,37.0,…],
     "confidence":0.84 }]

# operator signs off → tasks the cue
POST /api/tipandcue/requests/{id}/approve

Why it matters

The force-multiplier an analyst can't do manually

A wide-area FMV feed produces more frames than a human can watch. Continuous AI detection watches all of it; the approval gate keeps the human in command of the expensive part - the hi-res tasking.

🔍

Always watching

The detection host runs over every sampled frame, 24/7. A human sees alerts, not raw video. The wide search never blinks.

⚖️

Human in the loop

No sensor is tasked without explicit approval. The gate is the difference between a force-multiplier and an autonomous weapon - and it's the right design for every legal/ROE framework.

📐

Footprint-accurate

The cueing request carries the detection's ground footprint (derived from the FMV's frame-corner metadata), so the hi-res collect is pointed at the right patch of earth.

Rules persist at <dataDir>/tipandcue/rules.json; pending requests are ephemeral. The service hooks FmvContinuousDetectionHost.DetectionPublished - the same event stream that drives the CoT detection pipeline.