Skip to the main content
Witnal
Sign in

How it works

See how Witnal records shop incidents and keeps a custody log. Browser capture needs the page open and a network connection.

A phone held in a hand in a dark room, showing an incident record in Witnal: Threat, opened 31 August 2026 at Northgate Convenience, Hyde Road.
An incident record, on the phone that made it. Demonstration shop.Photograph: Jakub Żerdzicki, Pexels. Screen: Witnal.

From recording to sealed evidence

Each stage adds an entry to the custody log. These timings come from the demonstration record.

  1. 00:00

    Captured

    One press starts video and sound together. Keep the browser open while recording.

  2. 00:00

    Hashed

    Each segment gets its SHA-256 hash on the device, the moment it is written. Change a single frame later and the number no longer matches.

    sha-256 242c6ceb9f9a5e53…c406c76a819aaaff

  3. 00:01

    Streamed

    While the browser stays open and connected, segments upload as recording continues. Received segments remain on the server if the phone is later lost or damaged.

  4. 01:42

    Verified

    On arrival, the server recomputes every hash. A mismatch quarantines the segment and says so; the quarantine is itself a line in the custody log.

    recomputed 242c6ceb… · matches the device hash

  5. 02:00

    Timestamped

    An independent timestamp authority signs the evidence hash under RFC 3161. Its token is kept with the evidence.

  6. 02:09

    Sealed

    The original is written once and never rewritten. From here, every action on it is one more line in a log that only grows.

    chained to segment 02 · retained until 26 Aug 2032

Figure 1. Segments hashed as they are written, each carrying the hash of the one before.00:00segment 01242c6ceb…819aaaff00:01segment 02797c2c09…c63446e500:03segment 035e535e5a…b1ba20e8recordingsha-256carries the previous hashcarries the previous hash02:09sealedindependent clock
Figure 1. Segments hashed as they are written, each carrying the hash of the one before.
Custody logdemonstration
  1. 00:00:01Capturedsegment 01 · video and sound
  2. 00:00:01Hashed242c6ceb…819aaaff
  3. 00:00:03Streamedwhile recording continues
  4. 00:01:42Receivedhash recomputed, matches
  5. 00:02:00TimestampedRFC 3161 authority
  6. 00:02:09Sealedoriginal never rewritten
SealedSHA-256 · RFC 3161
A record from the demonstration shop, written the way Witnal writes one.

Hash something yourself

Type anything. Your browser computes its SHA-256 here, on your device, the way the capture does. Seal it, then change one character and watch the number stop matching.

sha-256
Calculating the current hash…
Nothing you type leaves this page.

Threats, not faces

With the camera shown, the phone reads the picture for cues and writes each one into the record as unverified. A person decides what it was.

A blade or a bat in shot
A small detector runs on the phone, model and all. When it reads something as a possible weapon the screen says so and nothing more, because at that confidence the model cannot tell a bat from a blade. The class it guessed, the confidence and the time go into the record for whoever reviews it.
A sudden move
Frame-to-frame change across the picture. A lunge, a shove or a vault over the counter reads as a spike and is logged as a cue.
How many figures
People are counted as figures, never named. The count goes into the record with the cues.

Cues are suggestions. The incident record shows them beside the sealed frames as unverified, with one custody line that says the device raised them and when. Nothing here recognises anyone and no picture leaves the phone for it.

What you end up with

A record with its handling attached.

Each exhibit keeps its device hash, the server's matching recount, its place in the chain, the authority's token and the date its retention ends. None of that proves the camera saw the truth; no software can. What it proves is narrower: the file is the one sealed at capture and any change since would break its hash. Every action on the incident is one more line in the log.

The log is append-only. A mistake is corrected by a further entry, never by editing an old one.

The pipeline is built against the College of Policing's guidance on CCTV evidence and the Home Office procedure for digital images.

Exhibit 01Video · video/mp4Sealed
Device hash
242c6ceb9f9a…c76a819aaaff
Server hash
Recomputed on ingest, matches
Chain
First in the sequence
Timestamp
RFC 3161 token, held with the segment
Retained until
26 Aug 2032

Next

Police handover