The questions that get asked

In appraisal and litigation, digital evidence draws scrutiny that a claim file rarely anticipates. Was this the condition at the time? Has this file changed since it was captured? Who produced it, and on what?

A folder of photographs and a scope in Xactimate cannot answer any of those. This page describes exactly what Estimatics can — and is deliberate about the limits, because an overstated evidentiary claim is worse than no claim at all.

What the server records, on every plan

Estimatics splits the record in two: what the device reports, and what the server can observe independently. Both are kept; only the second is used to verify the first.

Recorded	What it means
Server-side SHA-256	The hash the server computes by re-reading the bytes it actually received — not the value the uploader sent
Client-declared SHA-256	What the device claimed. Preserved, never trusted alone
Verification status	The comparison between the two
Clock offset	The gap between the device clock and the server's at upload
Location permission	Whether GPS was granted, denied, or unavailable at capture
Capture origin	Team member, or an outside FIELD Lite invitation
Device provenance	Device identifier, model, OS and version, timezone, and the app version that produced the file

Events are recorded append-only — added, never edited or removed.

The five verification states

Pending · Match · Mismatch · Unverifiable · Unreadable

Unverifiable is not Match, and the distinction carries weight. The server's own hash is the one that doesn't depend on the word of whoever uploaded — but without a client declaration to compare against, you lose the ability to detect a corrupted upload or a client misreporting what it sent. Which state is sufficient is a judgment for whoever reads the file.

What this does not prove

Not that the damage is real, or caused by the loss. Integrity is about the file, not the interpretation.
Not that anyone was physically present. It records whether the device reported a location and whether permission was granted. A device can be wrong; permission can be denied.
Not the moment of capture. It records the device's timestamp and how far that device's clock sat from the server's. That is evidence about the timestamp, not a guarantee of it.
Not admissibility. A court decides that under its own rules.
Not a digital signature or a notarization. No third party attests to anything.
Not liability or coverage.

What it supports is narrower and more defensible: the file in the record is byte-for-byte the file the server received, and here is everything the server could independently observe about how it got there.

ℹ Note

There is no evidence-log screen in the web app today. The record is captured and retained on every account and is available on request — email support@aiestimatics.com with the job.

Completeness, separately from integrity

Whether a file is intact and whether it is complete are different questions. The evidence completeness check reviews the documentation area by area — missing coverage, thin areas, findings without linked photographs — and reports green, amber, or red. It's the pass to run before a file faces adversarial review.

Cause & Origin, on CERTIFY

CERTIFY adds an AI cause-and-origin assessment written from the confirmed findings — three to five sentences that state uncertainty explicitly where the evidence doesn't carry a conclusion. It composes into the Damage, Analysis, and Complete reports for a CERTIFY seat, and only on insurance-claim jobs.

It is an analytical aid, not expert testimony, and it does not assign liability.

→ What Cause & Origin claims, and what it refuses to

How firms use it

Most property attorneys receive the file from a PA or contractor working in Estimatics. Firms that run their own field inspections can onboard directly.

Contact our team to discuss how this fits your litigation workflow.

The Property Attorney's Guide to Estimatics