Evidence
Chain.
A cryptographic chain-of-custody built for parking disputes, theft investigations, and premises-liability claims. It supports authentication under FRE 901/902 and follows ISO/IEC 27037 and SWGDE digital-evidence practice. Below: exactly what we sign, when, and how a third party checks it.
Every frame hashed at capture.
The moment a frame is written, the Sitinel device computes a SHA-256 hash over the frame bytes, timestamp, and camera ID and stores it alongside the video. Tampering with even a single pixel later breaks the hash.
Hourly Merkle root signed with the device key.
Every 60 minutes the device folds all per-frame hashes into a Merkle root and signs it with a hardware-bound key (secure element where available, ed25519 elsewhere). Forging history would require breaking the key on every device simultaneously.
Pushed to an append-only log.
Signed roots are published to a public, append-only transparency log (~5 KB per day per camera). There is no rewind, no deletion, no silent edit. The log is the receipt, and anyone can audit it.
Insurers and courts verify without seeing other footage.
Send a clip with its Merkle proof. The third party recomputes the hash, walks the proof, and confirms against the signed root in the public log. They learn the clip is authentic, and nothing else leaves your device.
vs. the record-and-hope camera world.
How a third party verifies
- You export a clip. The export bundles the frame bytes, the per-frame hashes, and the Merkle proof linking those hashes to a signed hourly root.
- The third party recomputes the hashes locally from the clip bytes.
- They walk the Merkle proof to reconstruct the root.
- They fetch the same signed root from Sitinel's public transparency log.
- If the signatures match and the root is present in the log, the clip is authentic and has not been edited since capture.
No trust in Sitinel required. No access to any other footage required. The math does the work.
What this is designed to prevent
- Silent edits. Clipping out a frame, adjusting a timestamp, or swapping a license plate all change the hash, and the signed root no longer matches.
- After-the-fact fabrication. A new clip can't be retroactively signed because the hourly roots already published to the log don't contain it.
- Deletion cover-ups. Even if a clip is deleted from the device, its hash is still in the signed roots, so absence can be detected.
- Chain-of-custody disputes. Every clip carries a cryptographic receipt no paper custody form can match.
Frequently asked, by insurers
What leaves the site by default?
The signed hash roots (about 5 KB per day per camera) stream to the transparency log, and every sealed incident clip replicates to durable off-site storage so a stolen or failed recorder cannot erase your evidence. The full continuous record stays on-site unless you turn on the cloud retention tier. Inference always stays on the edge.
Who holds the signing keys?
Each device generates and holds its own key on first boot. Sitinel cannot sign on a device's behalf, and keys never leave the hardware.
What happens if a device is destroyed?
Historical signed roots are still in the public log, and any already-exported clips remain verifiable. Future captures after the incident obviously stop, but that itself is evidence.
Is this aligned with any existing standard?
The design follows the transparency-log and Merkle-proof patterns used by Certificate Transparency (TLS) and the software supply-chain log sigstore, and it is built to support authentication under FRE 902(13)/(14) via a written certification, aligned with ISO/IEC 27037 and SWGDE. It is a pedigree, not a promise of admissibility, which is always the court's call.
We'll get you a print-ready one-pager you can forward to carriers and counsel. Email insurers@sitinel.ai and we'll send it over.
Start a pilot →Last updated · July 1, 2026