03:12. Structure fire.
Persons reported.
The clearest way to understand Warden is to watch one incident run. Here it is with drone overwatch in the loop — and, alongside each beat, the line it writes to the hash-chained record.
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. It assumes the service launches its own drone from a dock, which is one way a service might fly. No dock connection is built yet: Warden has been tested only against a flight simulator and a test video stream, never a real aircraft. It has no DJI integration and no 999 or computer-aided dispatch (CAD) feed, so the incident below is opened in the console.
01 The incident, in real time
Under each decision, the line it writes to the record.
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 OPENEDA human authorises the flight
The service's own aircraft is ready to launch. A named commander — not the software — authorises overwatch. The entry carries the same fixed note every time; the necessity and proportionality reasoning itself is the service's to record.
Record #02 · FLIGHT AUTHORISED · ◆ humanEyes 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 LIVEA hazard, called early
The officer on the console 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 FLAGGEDThe 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 — from the service's own drone, on the commander's screen, with each decision around it on the record.
Stand down, and sanitise
Incident closed and the live feed is gone. If a deployment keeps footage, the retention job is designed to delete it on schedule and write the deletion to the record as #05. That schedule is not yet switched on.
Record #05 · MEDIA PURGEDThe record is sealed
Closed and sealed: the database refuses to un-seal it. If this deployment is ever reviewed, by the service or the Information Commissioner's Office (ICO), the account of who authorised what, and when, is there to read, and anyone holding an export can check it against Warden's published key without Warden, and, once the next anchor covers it, against an outside RFC 3161 time-stamp too.
Record #06 · RECORD SEALED02 What changed
Same fire, same drone. A different record.
Before A picture, no record
The drone flies and the picture is good, but the decisions around it — who authorised the launch, on what grounds, what was kept — can end up spread across radio logs, notebooks and memory, and be hard to show afterwards.
After The same picture, on the record
Same aircraft, same picture. A named person's authorisation goes on the record before launch, with no facial recognition, no imagery stored by default, and every later decision chained into the same record.
03 The whole system, on one picture
What the drone sends in, what the commander controls, and how every decision becomes a sealed, hash-chained entry.
One-way by design
Warden sits downstream of the ground station, and its software has no function that sends anything to 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 and the service’s own permissions stay as they are.
Live-only by default
By default the thermal feed is live-only — no imagery is stored. Any opt-in recording is designed to be retention-bound, with its deletion written to the record as a chained event; that scheduled deletion is not yet switched on.
Append-only, signed hash chain
Every action is chained into an append-only hash chain with SHA-256, which needs no key, and each link is signed with Ed25519; edits or deletes of entries, and un-seals, are rejected at the database. Anyone holding an export can check it against Warden's published key fingerprint, without Warden. Events up to the latest time-stamped anchor (one whose token verifies) are also time-stamped externally (RFC 3161), so they cannot be altered undetected after that time-stamp; newer events are not covered until the next anchor, and the verification page lists the other limits.
Diagram shows the design of pre-production software — not deployed at any fire & rescue service.
The demo console runs this sequence on synthetic data — the feed, the human authorisation, the ledger forming and a tamper test. Open the demo →