Drone-response C2

The Drone-response C2 example demonstrates Scrydon's command-and-control pattern: sensor detections arrive via webhook, a process-flow instance opens automatically, and an air-picture operator classifies the contact on a live tactical map before an AI duty analyst produces a threat advisory and a duty commander issues a response decision.

The entire loop — detect → triage → assess → decide → respond — is driven by a single OSINT Intelligence pack installed from a Git pack source. No bespoke code.

What the pack provisions

Prerequisites

• A Scrydon deployment with the agentic, ontology, and analytics surfaces enabled.
• An LLM integration configured (required by the ASSESS stage's AI threat-advisory agent).
• A Git pack source pointed at https://github.com/scrydon/packs (or a mirror); ref main; catalog path scrydon.yaml.

Step 1 — Install the OSINT Intelligence pack

Step 2 — Deploy the detection ingest workflow

Step 3 — Send a detection (the Marimo notebook)

The pack ships a Marimo notebook driver for the demo. From the pack source root:

marimo run src/osint-intelligence/_notebooks/drone-detection-driver.py

Paste your webhook URL and set a Track ID (default DRONE-TEST-001). Two buttons:

After the first POST, watch Process Flows — an instance "Drone response — DRONE-TEST-001" appears. Repeated POSTs with the same trackId update the same instance rather than spawning duplicates. Track and TrackObservation rows accumulate in the OSINT ontology tables.

You can also POST the detection payload directly with curl:

curl -X POST "<your-webhook-url>" \
  -H "Content-Type: application/json" \
  -d '{
    "trackId": "DRONE-TEST-001",
    "source": "webhook-demo",
    "lat": 54.30,
    "lng": 23.10,
    "altitudeMeters": 180,
    "headingDeg": 215,
    "speedMps": 22,
    "observedAt": "2026-07-03T12:00:00Z"
  }'

Step 4 — TRIAGE: classify the airspace picture

Open the Drone response — DRONE-TEST-001 instance. The first task is Classify the airspace picture, assigned to the Air Picture Operator persona.

The task renders a live tactical map with two geo layers:

The fleet-context layer is the DroneObservation object type (the telemetry observations carry the coordinates), not the Drone fleet registry — the registry binding maps only identity and airframe metadata, so it can never produce map features.

The detected Track contact is pre-selected (highlighted on load) because the ingest workflow seeds the instance context with trackRef.

Select a classification:

• Friendly — known asset.
• Hostile — declare threat.
• Unknown — insufficient data; the AI assessment will flag missing information.

Add notes (e.g. "Heading 215° at 22 m/s, approaching NATO base corridor") and click Submit.

On submit, the platform writes the classification to the live track row via a governed api-table upsert (the write-through). If the upsert fails — for example, because the analytics surface is not reachable — the action stays open with a Retry button; your notes and classification are never lost.

Step 5 — ASSESS: AI threat advisory

On TRIAGE completion, the inline threat-assessment workflow fires automatically. The AI duty analyst reads the operator's classification and notes and produces a structured advisory:

THREAT LEVEL: LOW | MEDIUM | HIGH

RATIONALE:
<2–5 sentences grounded in the triage evidence>

MISSING INFO:
- <gap 1>  OR  none

Ask-back loop. If the advisory flags items under MISSING INFO:

1. The advisory appears as a banner above the next map action in DECIDE.
2. The operator can click Revise and re-run on the ASSESS action, add detail to the triage classification notes, and re-submit.
3. The agent re-runs on the updated classification. Iterate until the advisory is actionable.

If your LLM integration is not yet configured, the action fails with LLM_NOT_CONFIGURED. Configure an LLM integration under Settings → Integrations and click Retry.

Step 6 — DECIDE: commander map decision

The Command decision task is assigned to the Duty Commander persona. It renders the same focused Track contact from the track table — but now with the AI advisory banner at the top of the card.

Four options:

Add commander's notes for the audit trail, then submit.

Step 7 — RESPOND: auto-dispatched tasking

The respond-tasking workflow fires automatically on DECIDE completion. No manual trigger needed.

• Dismiss → a "dismissed" note is written to the response block output.
• Recon → a task "Recon tasking — scramble F-16" appears in the instance task list.
• Engage → a task "Engage tasking — weapons authorization" appears.

Re-triage does not complete DECIDE, so this stage never fires for it.

Open the instance task list and verify the created task matches the commander's decision.

Simulating an incursion

Run Simulate incursion in the notebook to post 20 detections over 40 seconds. Each detection upserts the Track row (updating last position) and appends a TrackObservation row (full position history). The process-flow instance is deduplicated — the same trackId always resolves to the same open instance, so the operator can classify as contacts evolve rather than dealing with 20 separate instances.

After the incursion completes, the ontology map shows the Track contact's final position; the Instances graph links the Track to each of its TrackObservation records via the TrackedBy link type.

Production hardening checklist

Related

• Map actions — full reference for the map action type, writeTarget, returnToStage, and the advisory banner.
• Webhooks — how the Detect block composes into the ingest pipeline; token auth; replay-safety.
• Ontology geo query — how the map layers resolve coordinates and link types.
• Service accounts — production ingest identity.