WARDEN
For suppliers to UK fire & rescue

You keep the service flying.
We keep the record.

UK fire and rescue services typically fly their own drones, bought, trained and supported through suppliers they already work with. Warden is a governance and audit layer designed to travel inside that relationship: a named person's authorisation on the record before launch, and a hash-chained log of each decision. Its software only reads the feeds and has no function that sends a command to the aircraft, so it records the decision to launch; it cannot stop one.

For drone, dock, training & assurance suppliers Integration a read-only data feed Commands sent none Status Pre-production Looking for a conversation
Read this first

Warden is pre-production. This page describes an intended way of working with suppliers, not an existing commercial relationship, and nothing here implies a partnership with, or endorsement by, any company or fire and rescue service. To be plain about the rest: Warden is not yet a registered company and has no customer. No real aircraft has been connected to it; its video and telemetry feeds have been tested only with a test stream and a simulated aircraft. There is no DJI or dock integration yet, and its record can be checked from an export against a published key and, up to its latest time-stamped anchor (one whose token verifies), against an outside RFC 3161 time-stamp; the newest events are not covered until the next anchor (Verify).

01 Where the line sits

One rule defines the whole system: data flows one way.

Warden sits downstream of the ground station or dock. Thermal video and telemetry flow in. Warden's software has no function that sends anything back out, so it never arms, steers or lands the aircraft. In an installation, the connection it reads from would also be set to receive only; that set-up is not built or tested yet. The aircraft, the pilots, airworthiness and the service's Civil Aviation Authority (CAA) permissions stay exactly where they are today.

Unchanged The aircraft & the flight

The airframe, the camera, the autopilot, the radio link or dock, the remote pilots and the service's permission to fly. Warden never touches any of it.

Added The authorisation & the record

A named person's sign-off before launch, the incident commander's live picture, and a hash-chained record of each decision. The governance, not the flying.

02 Why the record matters to your customer

The aircraft is only half the question. The other half is whether a data protection officer can sign off how it is used.

A thermal camera over a street is personal-data processing under UK GDPR (the UK General Data Protection Regulation). For every flight, someone has to be able to answer, on the record: what is the lawful basis, who authorised this flight, is footage stored, and can anyone show the record wasn't altered?

Warden is designed to help answer those questions: a proposed lawful basis (public task) for the service's data protection officer to confirm, no facial recognition, live-only imagery by default, bounded retention, and a hash-chained ledger of each decision, signed under Warden's published key so anyone holding an export can check it without Warden. One part is not finished: scheduled deletion is not yet switched on. And one limit stays: the ledger's external time-stamps cover it only up to the latest anchor, so the newest events are not covered until the next one (Verify). What a data protection officer gets today is a head start on their assessment, not a finished sign-off.

You bring The kit & the know-how

Aircraft, docks, training, servicing and support that the service already relies on, through a relationship it already has.

Warden adds The governance groundwork

The authorisation step, a starter data protection impact assessment (DPIA) that the service's data protection officer completes and owns, and the record the service will be asked for.

03 How it plugs in

Integration is a data feed, not a redesign.

The ground station or dock already produces the two streams Warden needs. Warden reads a copy of each into its own console. Nothing changes on the aircraft, the autopilot, the radio link or the flight software.

WARDEN — where it plugs into the drone Read-only. It reads the feeds the ground station or dock already produces, and sends nothing back to the aircraft. THE FLIGHT SIDE · UNTOUCHED WARDEN · READ-ONLY GOVERNANCE ONE-WAY Drone or dock thermal camera · autopilot radio link Ground station / cloud the pilot flies, as today already streams video + telemetry tap · copy of the feeds ✕ Warden sends no command back WARDEN ingest MediaMTX (video) MAVLink → WS bridge Commander’s console a separate screen WHAT “THE OVERLAY” IS drone’s thermal feed, unchanged + DFR // INCIDENT 120m · 87% · AUTO ● LIVE · not recorded NO FR + WARDEN overlay (HUD · governance) The overlay is drawn in Warden’s own viewer, over a copy of the feed; the drone’s view and the pilot’s screen are never touched. EVERY DECISION → THE RECORD Commander decides Server chains it append-only ledger Open · authorise · flag · seal: each is hash-chained into a record designed to show a later change. One-way: video + telemetry in · no flight command out. The tap would run on a computer at the ground station; a cloud-connected dock needs an adapter not built yet. Illustrative: the exact tap (stream, encoder or vendor cloud interface) is confirmed per platform. No integration with, or endorsement from, any drone or dock maker.
Where Warden taps in, and what it never touches.

01 Point the feeds at the bridge

Thermal video over RTSP → WHEP (Real-Time Streaming Protocol in, converted by MediaMTX to WebRTC-HTTP Egress Protocol for the browser); telemetry over a small MAVLink → WebSocket bridge. Each is a read-only copy of a feed that already exists. Docks and closed platforms would connect through the vendor's cloud interface instead (see 04).

02 The commander takes the picture

A named commander signs in to the role-based console and watches the live thermal and telemetry. Only a commander or an administrator can authorise a flight or seal a record. A person decides; Warden records the decision.

03 Every decision is written into the record

Open, authorise, flag and seal are each written server-side into an append-only ledger, every entry chained to the one before it with SHA-256, which needs no key, and signed with Ed25519 under a key whose fingerprint is published; any purge of imagery is logged there too. Anyone holding an export can check the chain and its signatures without Warden, and events up to the latest time-stamped anchor also carry an outside RFC 3161 time-stamp. Verify sets out what that proves and what it does not.

04 What it pairs with

Platform-agnostic by design, because Warden never controls the aircraft.

It is designed to work with any drone or dock that can hand it two things: a video stream and a telemetry stream. That is the whole compatibility test. How much glue it takes depends on how open the platform is.

Native Open-stack (MAVLink)

Autopilots running ArduPilot or PX4 speak MAVLink, the open protocol Warden's telemetry bridge reads. So far the bridge has been run only against ArduPilot's simulated multicopter, and video only as a test RTSP feed. No real aircraft has been connected, and PX4 flight modes would still need mapping.

Adapter Vendor clouds & docks

Many UK fire services fly DJI. DJI's docks send their livestream and telemetry through DJI's own cloud interface, so they would connect through a per-vendor adapter onto the same contract, alongside DJI's own platform rather than replacing it. That adapter is not built yet.

Worked example A remote-launch dock

A dock on a station roof launches the drone while the pilot flies it from a control room miles away. Nobody is standing next to the aircraft, so the answer to who authorised this launch? only exists if something records it. Warden would read the dock's livestream and telemetry through the vendor's cloud interface, record a named person's authorisation before launch, and log the take-off and each decision after it, with no change to the dock, the aircraft or the flight software.

Illustrative. Warden has no integration with, partnership with or endorsement from any drone or dock maker, and the adapter this example needs is not built yet.

05 What's in it for you

You stay the expert on the kit. Warden carries the governance.

Hand-over The answer to who authorised the flight

When the service's data protection officer asks who authorised each flight, the aim is for the answer to come with your kit, not months later.

One relationship Reached through you

Warden is designed to be offered as part of what you already supply, so the service can reach it through a relationship it already has. Whether it fits a particular contract or framework, and the service's approval of Warden as a processor of its data, would still need to be confirmed.

Assurance Evidence for the safety case

If you help services with their specific operations risk assessment (SORA) or safety assurance, each authorised flight leaves a record the service can point to.

If challenged A record of who authorised what

If a deployment is ever challenged, the service would have a hash-chained record of who authorised each flight and when, which it could choose to share with you. Whoever receives an export can check it against Warden's published key without asking Warden and, for events an anchor covers, against its outside RFC 3161 time-stamp; the newest events are not covered until the next anchor.

You'd rather own the kit and the training than the paperwork. Warden is designed so the paperwork is already on the record.

Who we're looking for

A small number of companies that already supply drones, docks, pilot training or safety assurance to UK fire and rescue services, and would rather carry the governance answer than build it themselves. Nothing commercial is fixed yet: no price and no contract model. The first step is a short conversation and, if useful, a walkthrough of the console on synthetic data. If that's you: joe@wardendfr.com.