WARDEN
A callout, minute by minute

03:12. Structure fire.
Persons reported.

The clearest way to understand Warden is to watch one incident run. Here is the same fire with drone overwatch in the loop — and, alongside each beat, the line it writes to the tamper-evident record.

Incident Structure fire · persons reported Overwatch Thermal DFR Status Synthetic · concept
Read this first

This is an illustrative, synthetic scenario — no real incident, address or person. It's written to show how the pieces fit in time: the flight, the picture, the human decisions, and the record each one leaves. Every timestamp and hazard here is invented to make the sequence legible.

01 The incident, in real time

Watch the record form on the right of every decision.

03:12:04

The 999 call lands

Control categorises it: structure fire, persons reported. An incident is opened and the record begins — before anything flies, before anyone commits.

Record #01 · INCIDENT OPENED
03:12:40

A human authorises the flight

The partner's aircraft is ready to launch. A named commander — not the software — authorises overwatch, and the necessity and proportionality of that decision are captured with it.

Record #02 · FLIGHT AUTHORISED · ◆ human
03:13:30

Eyes on, before the crew

The drone reaches the scene ahead of the appliances. Thermal overwatch is live: two heat signatures on the first floor, a hotspot building at the rear. Live-only — nothing is stored.

Record #03 · OVERWATCH FEED LIVE
03:14:10

A hazard, called early

The commander spots a gas cylinder at the rear and flags it to the incident commander — before a single firefighter is anywhere near it.

Record #04 · HAZARD FLAGGED
03:16:00

The first appliance arrives to a picture

Not a blank street in the dark. Where the people are, where the fire is travelling, and where not to send a crew — minutes of situational awareness that simply didn't exist before.

03:41:00

Stand down, and sanitise

Incident closed. The live feed is already gone; any footage a deployment opted to retain is purged on its schedule — and the deletion is itself written to the record.

Record #05 · MEDIA PURGED
03:45:00

The record is sealed

Closed and immutable. If this deployment is ever reviewed — by the service, the ICO or a court — the account of who authorised what, and why, answers for itself.

Record #06 · RECORD SEALED · ✓ verified

02 What changed

Same fire. A different first ten minutes.

Before A blank street

Crews arrive without knowing where the people or the hazards are. The picture is built on the ground, in smoke, under time pressure — and no one can later prove exactly what was decided, or when.

After A scene already read

Thermal overwatch hands the commander the layout before the first boots are down — lawfully, with no facial recognition, nothing stored by default, and every decision on a record that can't be quietly rewritten.

03 The whole system, on one picture

What the drone sends in, what the commander controls, and how every decision becomes a signed, sealed entry no one can quietly rewrite.

WARDEN operational flow Four phases from callout to sealed record: ingest and air safety (one-way feed), live command and privacy (live-only), the cryptographic ledger (HMAC append-only chain), and purge and seal (seal-guard plus governed, logged deletion), with the ledger lifecycle from incident opened to record sealed. WARDEN — operational flow From emergency callout to a permanently sealed, independently verifiable record. PHASE 1 Ingest & Air Safety Thermal + telemetry stream in via MediaMTX and a MAVLink→WS bridge. one-way — can't fly the drone → reassures the engineer PHASE 2 Live Command & Privacy Commander watches live, role-gated. Imagery is live-only — nothing stored. live-only — nothing stored → reassures the DPO PHASE 3 Cryptographic Ledger Every action signed server-side into an append-only hash chain. HMAC-signed · append-only → reassures the auditor PHASE 4 Purge & Seal Record hard-locked; any retained media purged — and the purge is logged. seal-guard · governed purge → reassures the commander THE RECORD · LEDGER LIFECYCLE #01 INCIDENT OPENED #02 FLIGHT AUTHORISED #03 OVERWATCH FEED LIVE #04 HAZARD FLAGGED #05 MEDIA PURGED #06 RECORD SEALED content = SHA-256(seq · ts · event · meta · actor)    chain_hash = HMAC(secret, prev :: content) Tamper-evident, not “unbreakable” — any change is detectable by recomputing the chain.
Flight liability

One-way by design

Warden sits downstream of the ground station and physically cannot send flight commands. Adding it introduces no airworthiness or liability surface to the operator’s aircraft.

Downstream of the GCS · no control link
Privacy & the DPO

Live-only by default

By default the thermal feed is live-only — no imagery is stored. Any opt-in recording is retention-bound, and its deletion is itself written to the record as a signed event.

Data minimisation · Art 5(1)(e)
Tamper resistance

Provably unaltered

Every action is signed into an append-only HMAC hash chain. Edits, deletes and un-seals are rejected at the database, and anyone can recompute the chain to prove it was never altered.

HMAC-SHA256 · append-only · independently verifiable

Diagram illustrates a design concept — not a deployed system.

See it for yourself

The console runs this exact sequence — the feed, the human authorisation, the ledger forming and a live tamper test. Open the live demo →