How OvrSee evidence works

Specialist short-term-rental insurance, OTA damage protection, and deposit schemes differ in their wording, but the burden they place on the claimant converges on three requirements:

1. That the damage occurred during a specific guest's stay.

   Cover applies to damage caused by a guest during their booking. A claimant who cannot tie the damage to a particular occupancy window — rather than to general use, a previous guest, or gradual deterioration — has a weak claim regardless of how clear the damage itself is.

2. That the damage was not pre-existing, and is not wear and tear.

   Policies routinely deduct for wear and tear and exclude anything that arose before the booking began. Without evidence of the property's condition prior to the stay, a claimant cannot rebut the assertion that the damage was already there. This is the most common reason otherwise-valid claims are reduced or refused.

3. That the evidence is authentic and unaltered.

   “Legitimate and verifiable” evidence is the standard. An adjudicator has to be able to trust that a photograph is what it claims to be — taken where and when it says, and not edited after the fact.

OvrSee maps directly onto these three. The sections below show how each is discharged.

Every turnover produces a timestamped, GPS-verified record tied to a specific booking window. The evidence captured after a guest checks out is bound to that guest's stay; the evidence captured at the previous turnover establishes the condition the guest was handed.

When damage is flagged, OvrSee pairs the two: the state of the property at the start of the booking and at the end of it. The comparison is anchored to the booking, not to the calendar, so the claim asserts what the policy requires — that the damage occurred during this stay — rather than leaving the adjudicator to infer it.

Each piece of evidence carries the time it was captured, the device GPS location, and the EXIF metadata written by the camera at the moment of capture. Two independent location sources — device GPS and camera EXIF GPS — agreeing on the same property makes the “where and when” difficult to dispute.

OvrSee establishes prior condition in two ways.

The property baseline: when a property is onboarded, a full walkthrough is captured and locked as the property's ground-truth condition. This is the reference against which the first guest's stay — and every disputed claim where no earlier turnover exists — is measured.

The previous turnover: from the second turnover onward, the condition at the end of the previous clean is on file. A damage claim is supported by the most recent prior record of the same room, the same surface, the same item — captured before the guest in question arrived.

Either way, when a claim is assembled, OvrSee can show the property's condition before the booking alongside its condition after. That before-state is what rebuts a wear-and-tear deduction or a pre-existing-damage challenge. Where no baseline or prior turnover exists for a property, OvrSee flags the gap rather than presenting an incomplete chain as if it were complete.

This is the forensic core, engineered to a deliberately high bar.

• Cryptographic hashing. Every photo is hashed with SHA-256 on the device, at the moment of capture, before it is uploaded anywhere. The hash is computed from the raw file bytes. If a single byte of the file is ever changed, the hash no longer matches. The hash is stored permanently alongside the file — the chain of custody. Anyone can verify the file presented is byte-for-byte the file that was captured.
• Metadata preservation. Camera EXIF metadata is never stripped or compressed. The original file is stored unmodified. Capture timestamp, camera GPS coordinates, device make and model, and the image's unique identifier are all preserved.
• Dual-source location. Device GPS and EXIF GPS are captured independently. Two sources agreeing on the property location is materially harder to fabricate than either alone.
• Immutable storage. Evidence is written once and never modified. There is no edit path and no delete path in normal operation — records are append-only. Files live in private storage, accessible only through short-lived signed links, never public URLs.
• Capture, not upload. Photos are taken inside the OvrSee app and never pass through the device camera roll, removing the most common route by which an image could be substituted or edited between capture and submission.

The three requirements above are met by three independent layers, captured at every turnover. Each stands on its own; together they corroborate each other.

• Layer 1 — The operative's contemporaneous statement. At the start of every walkthrough, the operative records a short self-identifying voice declaration, and can record voice notes describing anything they see, as they see it. A contemporaneous witness account from a named individual who was physically present — evidence that, unlike an automated flag, can be attested to and stood behind.
• Layer 2 — Automated corroboration on flagged damage. When the operative flags damage, OvrSee's server-side analysis compares the current walkthrough against the prior reference and produces a structured before-and-after summary for the claim. This corroborates the operative's account; it does not replace it. The analysis is clearly labelled as analysis of the evidence, not as evidence itself.
• Layer 3 — The hashed forensic archive. The full walkthrough video and all photos are hashed, metadata-preserved, location-tagged, and archived immutably — whether or not a claim is ever made. Evidence assembled after a dispute begins is weak; evidence captured routinely, before anyone knew it would be needed, is strong.

A note on sequence, because it matters for evidentiary weight: the human declares first, the automated analysis corroborates second. The system never shows the operative an automated flag and asks them to confirm it — that would contaminate an independent witness account. The operative is the primary record; the analysis backs it up.

Evidence is retained for 0 months by default, covering the claim-filing window for the routes property managers use and aligning with common insurance documentation requirements. Storage is tiered: full resolution for the first 0 days, then downscaled — still clearly showing the relevant detail — while the original cryptographic hash is preserved alongside the downscaled copy so integrity verification remains possible. After 0 months, evidence is deleted under a defined retention policy. Evidence attached to an open claim is exempt from automatic deletion until the claim closes.

OvrSee surfaces anomalies in the evidence chain rather than waiting for them to be discovered during a dispute: clock-skew checks flag captures whose device time is inconsistent; metadata-presence checks flag any capture missing expected EXIF data; hash verification confirms stored files match their originals; coverage enforcement during the walkthrough requires each room to be adequately captured; and sampling audits review a proportion of no-damage turnovers as a check against systematic under-reporting.

Being straight about the current state: some elements of OvrSee's roadmap are not yet live. Streaming hash computation for designated high-value properties, expanded anomaly detection, and formal insurer-recognised evidence formats are planned, not shipped. We'd rather state that plainly than imply a more complete system than exists. The forensic core — client-side hashing, metadata preservation, dual-source location, immutable storage, and the three-layer capture model — is built and running.

If you're assessing OvrSee's evidence for use in claims adjudication, or considering how an OvrSee evidence pack would sit alongside your own claims process, we'll provide the technical detail your evidence-standards team needs — chain-of-custody documentation, the structure of a sample claim pack, and the integrity-verification method. The fastest route is the contact form; mark it for partnerships and it reaches a founder directly.