Why "we have it on camera" is not always enough
A recording becomes useful in a dispute, an insurance claim or a proceeding only if somebody can answer, credibly, a short list of questions: where did this come from, when was it captured, has it been altered, and who has handled it since. A file on a hard drive answers none of those on its own.
Most video systems are built to store video. Fewer are built so that the stored video can be trusted later. That gap is a design choice, not an accident.
Provenance — where did this come from?
Every clip should carry, as data rather than as folder convention, which camera produced it, which stream or profile, and the source's operating mode at the time. That last one matters more than it sounds. A system that can replay recorded footage through its own pipeline can, if carelessly built, produce an "alert" from replayed video that is indistinguishable from a live one.
The safeguard is to make live and playback structurally different: only live acquisition may create evidence and dispatch alerts, and every record carries the mode it was captured in. A replayed test clip must never be able to present as a real operational event.
Time — the most commonly broken link
Timestamps are where evidence quietly falls apart. Cameras ship with wrong clocks, drift, reset on power loss, and disagree with the recorder. If a clip says 02:14 and the door log says 02:47, the footage stops corroborating anything and starts raising questions.
- Synchronise cameras and recorders to the same time source, and monitor for drift rather than assuming it away. Clock skew is worth surfacing as a health signal.
- Record the timezone and whether the clock is local or UTC. "14:30" is not a timestamp.
- Be explicit about which clock a timestamp came from — camera, recorder, or the software that wrote the file.
Integrity — has this been altered?
The practical measure is a cryptographic hash computed when the artifact is written, stored alongside it. Anyone can recompute it later and confirm the bytes are unchanged. This is cheap to do and disproportionately valuable, because it converts "trust us" into something checkable.
Two related habits: keep the original file rather than only a re-encoded or watermarked derivative, and make exports additive — an export should never be the only remaining copy.
The evidence a system did not keep
The most common failure is not tampering. It is that the footage is simply gone — deleted by a retention policy that treated it as routine, or never written because a disk was full or a recorder had silently stopped.
Three design consequences follow:
- Footage attached to an alert should be retained on a different schedule from routine continuous recording. See retention and storage planning — deleting by age alone will eventually delete the incident.
- There must be a way to lock material for an investigation so that no automatic policy can reclaim it, at any disk pressure.
- A recorder that has stopped writing must raise an alarm. A system that quietly records nothing looks identical to a quiet night, and the gap is discovered when someone asks for the footage — which is the worst possible moment.
Capture the context, not just the moment
An alert that arrives with a single still frame is weak evidence and, in practice, weak operationally too — a person mid-stride tells you very little. What makes a clip useful is the seconds before the trigger, which is only possible if the system was already buffering video before it decided anything had happened. A few seconds of pre-roll is the difference between "something was detected" and "here is what happened."
Handling — who has touched it?
Chain of custody in the formal sense is a record of everyone who accessed or copied an artifact. For most commercial deployments the proportionate version is: access to evidence requires authentication, access is logged, exports are recorded, and permissions are role-based rather than a single shared login. A shared password on a recorder is the point at which "who viewed this" stops being answerable.
A checklist worth applying to any system
- Can I tell which camera and which stream a clip came from, from the file itself?
- Can I prove the bytes have not changed since capture?
- Are clocks synchronised, and would I know if one drifted?
- Is footage attached to an incident protected from routine deletion?
- Would I be told if recording silently stopped?
- Is there a per-user access record, or one shared login?
- Does the clip include the seconds before the event?
Where ManasaView fits
ManasaView attaches a clip to every alert including pre-event context, stamps records with provenance and a redacted source identifier, retains evidence on a separate schedule from routine footage, and reports when recording is not actually producing video. Evidence stays on the device; access requires a login.
Frequently asked questions
What makes video admissible as evidence?
Requirements vary by jurisdiction and this is not legal advice, but the recurring themes are provenance (which camera, when), integrity (proof the recording has not been altered), accurate and synchronised time, and a record of who has handled it. A system that cannot answer those questions weakens otherwise good footage.
Do I need to hash video files?
It is inexpensive and disproportionately useful. A hash computed when the file is written, and stored with it, lets anyone later confirm the bytes are unchanged. Without it, integrity rests on assertion rather than something checkable.
Why do timestamps matter so much?
Because evidence usually has to line up with other records — access logs, transactions, witness accounts. Camera clocks drift, reset on power loss and disagree with recorders, so an unsynchronised clock can make footage stop corroborating anything. Timezone should be recorded explicitly.
How long should I keep video evidence?
Routine footage is typically retained for days or weeks, but material attached to an incident should be kept far longer and protected from automatic deletion. Any applicable legal or regulatory retention requirement takes precedence over storage convenience.
Is a snapshot enough, or do I need a clip?
A single frame rarely establishes what happened. A clip that includes several seconds before the trigger is substantially more useful, both for an operator deciding how to respond and for anyone reviewing the incident later. Capturing pre-event context requires the system to buffer video continuously.
← Back to Knowledge