Status & roadmap · updated 7 November 2026

Where we
actually are.

Most companies publish a roadmap. Fewer publish the gaps. If Warden is going to ask a fire service to trust a record it can't see inside, the least we can do is state plainly what is built, what isn't, and what is still wrong. Some of it you can check today, some of it you cannot yet, and some of it is uncomfortable.

Stage Pre-production Entity Not yet registered Live deployments None Real records sealed Zero

Why this page exists

Warden's entire proposition is that a record should be verifiable rather than taken on trust. That principle is worthless if the people describing Warden get a free pass. So this page is written to the same standard as the verification page: no green ticks that haven't been earned.

01 At a glance

LivePublic site & governance modelPublished and readable by anyone

LiveInteractive console demoSynthetic data, runs in your browser

LiveVerification page & toolingAlgorithm, the signing key's fingerprint and both verifier scripts published; an export of a record can be checked against that fingerprint without any Warden secret

BuiltBackend: schema, row-level security (RLS), append-only ledgerProvisioned in Ireland (eu-west-1); the ledger is hash-chained with keyless SHA-256 and signed with Ed25519 — see 03

LiveEd25519 signing (ledger v2)Switched on: every ledger event is signed under key warden-2026-10, whose fingerprint is published on the verification page. The old keyed-HMAC secret is deleted

LiveExternal anchoring (RFC 3161 time-stamp through FreeTSA)Started: the first anchor was made on 1 November 2026 and its token checked with openssl. Events up to the cutoff of the latest anchor whose token verifies and whose time-stamp is minutes after that cutoff cannot be altered undetected after that time-stamp. Newer events are not covered until the next anchor. An anchor is attempted once a day; on a day when that attempt fails, the scheduled run writes no anchor. The second sink, a receipt to the fire service's data protection officer, is written but not switched on: there is no fire service to send it to — see 04

NoUK limited companyNot yet a registered company

NoCustomer, partner or pilot projectNone. The route to fire services is through suppliers they already use

NoReal flight, real recordNo real incident has ever been recorded or sealed; any record in the ledger is a labelled synthetic test

NoCyber Essentials · pen test · insuranceNot started

02 Live system feed

The heartbeat — or the honest silence.

Public cryptographic events only; incident and flight records are not public and never appear here. More about this feed →

03 What is genuinely built

Working code, not slideware. The verifier scripts and the console demo can be inspected; the backend code is not public.

Done The governance layer

Role-based command console, a commander's flight-authorisation entry on the record (one per incident; it records the decision and cannot stop a launch), append-only event ledger with database triggers that reject UPDATE and DELETE, a seal guard that refuses to reopen a closed incident, and a governed purge that writes its own deletion onto the record (its schedule is designed but not yet switched on).

Done Verification anyone can run

Every ledger event is hash-chained with SHA-256, which needs no key, and signed with Ed25519 under key warden-2026-10, whose fingerprint is published on the verification page. Anyone with an export of a record can check every link and signature against that pinned fingerprint without any Warden secret, and each chain is bound to its incident. The old keyed-HMAC secret is deleted. Both verifier scripts are downloadable and readable, and refuse to establish authorship without a pinned fingerprint. Tamper-evident and independently verifiable from an export — no known issues within the reviewed scope. Events up to the latest time-stamped anchor also carry an outside RFC 3161 time-stamp, checkable with openssl; the newest are not covered until the next anchor: see 04.

Done The data-protection groundwork

A pre-reasoned starter DPIA (data protection impact assessment, under Article 35 of the UK General Data Protection Regulation) for the fire service's own data protection officer to complete and own, a proposed lawful basis (public task) that is the service's to decide, a no-facial-recognition red line and a live-only-by-default posture — all published rather than promised.

Built Ingestion that sends no command

Video and telemetry in. Warden's software sends no command to the aircraft: it contains no function that sends anything to it. Two limits: the receive-only set-up of the telemetry tap (a third-party gateway that can send) is not yet built or tested, and the feeds have been tested only against ArduPilot's simulator and a test video stream. No real aircraft has been connected, and there is no DJI or dock integration yet.

04 What is wrong or missing

The list we would rather you heard from us.

GapData residency is Ireland, not the UKThe backend sits in eu-west-1. Whether it moves to a UK region is not yet decided, and no real incident data will be accepted until that is settled and stated here.

GapSigning keys are not in a hardware security module (HSM)The private key lives in a server-side secret that the backend's own functions can read, and so can anything with the right to deploy code to that backend; it is not in dedicated key-management hardware. Anchoring bounds the damage a compromise could do, because events an anchor already covers cannot be altered undetected after its time-stamp; it does not eliminate it, because events newer than the latest anchor could still be forged or altered, and the limits in the next row apply.

GapNo independent security assessmentNo penetration test and no Cyber Essentials certification yet. The cryptography has been tested by us, which is not the same as being tested by someone else.

GapNo entity, insurance or processor contractNo UK LTD, no professional indemnity cover, and no Article 28 data-processing agreement drafted. All three are prerequisites for any real use, not optional extras.

GapThe newest events are not time-stamped yetAnchors cover events up to their cutoff. Events written after the latest anchor's cutoff, including any incident opened since, are not covered until the next one; until then whoever holds the signing key could alter or remove them undetected. An anchor is attempted once a day, with no retry, so the newest events usually wait up to about a day to be covered, and longer after a day with no anchor. Before anything is written, our anchor function checks that FreeTSA granted a token over this exact digest, stamped within 15 minutes after the cutoff. It does not check FreeTSA's signature: openssl is that check. FreeTSA is a free service with no service guarantee: on a day when it does not answer, or its token fails that check, the scheduled run writes no anchor. Tying a record to an anchor takes both verifiers, a comparison of the record and ledger exports (up to the cutoff, the same events, none missing, each with the same chain_hash and ts), and openssl: see the verification page, sections 04 and 05. And someone with owner rights over the backend could still rebuild the ledger and anchor it again from scratch; that shows only against a copy of an earlier anchor kept outside Warden, which is why the anchor log is world-readable.

GapNo export buttonAn export of a record means someone signed in to the console with a staff role reading the records out of the ledger (in a deployment, the service's own staff); the console has no export function yet, so an outside checker depends on whoever holds the record to hand one over. The public access key this site uses cannot read the ledger at all, by design. The anchor check needs an export of the whole ledger, which has the same limit.

GapReceive-only telemetry set-up not builtWarden's software has no function that sends anything to the aircraft, but the telemetry tap is a third-party gateway that can send, and its receive-only set-up has not been built or tested. Until it is, the only claim we make is that Warden sends no command.

GapNothing has been proven in the fieldEvery record on this site is synthetic. No aircraft has flown into this system and no commander has ever used it at an incident. Telemetry has been tested only against ArduPilot's simulator and video only as a test stream, and there is no DJI or dock integration.

05 What happens next, in order

Sequenced by what blocks what — not by what is most fun to build.

Next Exports and hosting

Decide how an export, including the whole-ledger export the anchor check needs, reaches an outside checker, and settle where the backend is hosted.

Then A route in through existing suppliers

UK fire and rescue services typically fly their own drones, bought, trained and supported through suppliers they already work with. So Warden's route to a service is inside an existing supplier's offering, a framework, or a market-engagement notice the fire authority itself publishes, not a direct approach to the service. What that involves →

Then Independent assurance

Cyber Essentials, a penetration test against the deployed system, and professional indemnity cover — the things that let a public body run supplier due diligence without stopping.

Later Procurement readiness

Article 28 processing agreement, a published commercial model, and a place in the supplier offerings and frameworks fire services already buy through.

06 Holding us to this

A status page nobody checks is just marketing with worse formatting.

If something here is out of date, wrong, or reads as more flattering than the evidence supports, tell us and we will correct it. The technical claims are the ones to test first: the algorithm, the signing key's fingerprint and the tooling are published so you can check an export of a record rather than believe this page, and the verification page says what that check does not prove.

Check the verification design → · Report a problem →