MESH-FI photo forensics · for carriers, TPAs & adjusters

Every claim photo, forensically checked in seconds.

ClaimProof flags photos that were edited, AI-generated or reused from another claim — and shows the evidence, with a reliability score, so your adjusters decide with their eyes open.

One REST call per photo. Multi-photo claims, ZIP ingestion, webhooks. Runs on Cloudflare's edge in the US.

Original, edited and detection panels for a claim photo
OriginalEditedDetection
Loading proof case…
—
Published proof cases, real engine output
—
Blind-mode tests (no original supplied)
mesh-fi/0.1
Engine version behind every verdict
10
Independent forensic signals fused per photo
The problem

Photos used to be the evidence. Now they're the attack surface.

Three ways a claim photo lies — and why a human eye on a screen is no longer enough.

Photoshop-era edits

A hail dent cloned across a hood. A water line nudged up a wall. Receipt totals retyped. Consumer editing tools make localized edits that look clean at full zoom but leave compression, noise and thumbnail inconsistencies behind.

Generative AI damage photos

Image generators can now produce a plausible storm-damaged roof, flooded kitchen or crumpled bumper from a sentence. The photo never existed. Industry fraud units report seeing these in real claim files; the question is no longer if but how often.

Recycled photos across claims

The same damage photo resubmitted under a different policy, a different date, a different address — sometimes by a contractor across many homeowners. Nothing about the single image is wrong; only the comparison against your other claims reveals it.

How MESH-FI works

Multi-Evidence Spatial History Forensics

No single test proves anything. MESH-FI runs ten independent signals, weighs each by how reliable it is for this specific image, and fuses them into one verdict with a confidence score and an honest inconclusive path.

01

Provenance

EXIF, XMP, ICC, C2PA manifests, editor history, AI generator markers, declared vs actual dimensions, embedded thumbnail vs image.

02

Camera physics

Sensor-noise consistency, JPEG quantisation history, 8×8 block-grid alignment, error-level analysis, double-compression periodicity.

03

Scene physics

Copy-move clone detection, frequency-spectrum generator fingerprints, and a vision-model pass on lighting, shadows, perspective and generative tell-tales.

04

Evidence fusion

Each signal's reliability is reduced by degradation (no EXIF, social resize, heavy JPEG). A noisy-OR fuses scores; one weak signal can never exceed 0.45 alone.

Proof gallery

Real engine output. Including the case it gets right by saying nothing.

Every card below is generated by running MESH-FI on composites we built from real photos. The numbers are the engine's own — not hand-written. The control case is an untouched photo, shown so you can see what "clean" looks like. These test images are 1–2 megapixels and are analysed at full resolution; photos above 6 MP go through the downscaled path described under "What ClaimProof cannot do", where the pixel signals carry less weight.

Loading proof cases…

Side-by-side testing on your own photos

Drop a JPEG into the live demo. It's analysed in memory and never stored. See the heat map, the regions, every signal.

Open the live demo
Signals

Ten signals, each with a stated limit.

Each signal reports a score and a reliability for the image in front of it. Here is what each one measures — and what it cannot see.

SignalWhat it measuresWhat it cannot do
metadataEXIF/XMP/IPTC/ICC containers, editor software tags, AI generator markers, C2PA manifest presence, date mismatches, social/generator dimensions.Metadata can be stripped or forged; absence is a degradation, not evidence. C2PA signatures are not cryptographically verified in v0.1.
thumbnailCompares the embedded EXIF thumbnail against the main image (perceptual hash + pixel diff). A mismatch means the image changed after the camera wrote it.Only works when a thumbnail survives. Re-exports that regenerate the thumbnail erase this signal.
quantJPEG quantisation tables: estimated quality, standard-library (software) tables vs camera tables, double-compression periodicity.Many phones re-encode on share; a software table alone is low-severity. Says nothing about PNG or WebP.
elaError-level analysis: how differently each cell re-compresses, normalised for texture. Pasted regions with a different compression history stand out.Weak after heavy recompression or resizing; strong edges and text can mimic anomalies, which is why it is texture-normalised and reliability-capped.
noiseSensor-noise residual per cell vs the texture-noise fit for the whole frame; chroma/luma ratio. Spliced content carries a different noise signature.Denoised or very dark/blown-out regions have little usable noise. Low-megapixel images halve its reliability.
grid8×8 JPEG block-grid phase per region. Pasted content usually lands off-grid.Only meaningful on JPEG below quality ~97 with a detectable global grid. Skipped for PNG and screenshots.
copymoveFinds duplicated blocks within the same image (clone-stamp) via quantised DCT hashing and clustered shift vectors.Natural repetition (shingles, tiles, brick) can match; clusters must be large and consistent. Does not detect material brought in from another image.
spectrumAzimuthal frequency-spectrum profile of the noise residual — periodic peaks and roll-off typical of generative upsamplers.Low reliability by design. Never drives an AI verdict alone; requires metadata or vision agreement.
visionA vision model reviews lighting direction, shadow consistency, perspective/scale, edge halos, melted text, repeated textures, screenshot/photo-of-screen.Capped at 0.5 reliability — models are confidently wrong sometimes. Skipped entirely in the public demo unless enabled.
contextClaim context vs metadata: captured before the loss date, far from the loss location, device mismatch, taken long after the loss.Depends on EXIF dates and GPS being present and honest. A missing date is inconclusive, not suspicious.
Multi-photo claims

The single image is half the story. The claim is the other half.

Upload a claim's photos — or the ZIP straight from your claims system — and ClaimProof analyses every photo, then checks them against each other and against every other claim in your tenant.

Claim pipeline: upload, unpack, per-photo analysis, cross-photo checks, claim risk report and webhook Upload photos[] or .zip Unpack Workflow · skip non-images Per-photo analysis queue · 10 signals each Cross-photo checks • duplicates within the claim • reuse across other claims (pHash) • device consistency • capture timeline vs loss date • GPS cluster vs loss location • verdict counts & top findings Claim risk report low · elevated · high fast_track → siu_referral + webhook claim.completed Up to 200 photos per claim · ZIP up to 50 MB · each photo keeps its own AnalysisResult
Integration

One endpoint to start. Three to run a claim.

Bearer key, multipart or JSON, synchronous results for single images, queued + webhook for claims. Full docs →

Single image — POST /v1/analyze

curl -X POST https://claimproof.wardtechsystems.com/v1/analyze \
  -H "Authorization: Bearer cp_live_…" \
  -F "image=@roof.jpg" \
  -F 'context={"lossDate":"2026-05-14","peril":"hail","lossLocation":{"lat":32.93,"lng":-96.9}}'

Claim + ZIP — POST /v1/claims → /zip

# 1. create the claim
curl -X POST https://claimproof.wardtechsystems.com/v1/claims \
  -H "Authorization: Bearer cp_live_…" -H "Content-Type: application/json" \
  -d '{"claimNumber":"HO-2026-48211","peril":"hail","lossDate":"2026-05-14",
       "lossLocation":{"lat":32.93,"lng":-96.9},"webhookUrl":"https://claims.example.com/hooks/claimproof"}'
# → 201 { "id": "clm_…", "uploadUrls": { "photos": "/v1/claims/clm_…/photos", "zip": "/v1/claims/clm_…/zip" } }

# 2. send the ZIP from your claims system
curl -X POST https://claimproof.wardtechsystems.com/v1/claims/clm_…/zip \
  -H "Authorization: Bearer cp_live_…" -H "Content-Type: application/zip" \
  --data-binary @HO-2026-48211.zip
# → 202 { "status": "unpacking", "workflowId": "…" }

# 3. poll, or wait for the claim.completed webhook
curl https://claimproof.wardtechsystems.com/v1/claims/clm_…/report?format=json \
  -H "Authorization: Bearer cp_live_…"
Pricing

Priced per image. Start free for 30 days.

Every plan includes all ten signals, multi-photo claims and the portal. Compare plans in detail →

Honesty clause

What ClaimProof cannot do

Forensics produces evidence, not certainty. We would rather you know the edges before the pilot than after.

Please read before you buy.
  • No certainty. A verdict is a weighted reading of evidence. edited_likely means "the evidence points this way with the stated confidence" — never "this is fraud". Every result is for adjuster review.
  • Degraded images degrade the answer. Screenshots, social-media downloads and heavily recompressed photos strip the signals we rely on. The engine says so (degradation: heavy) and leans to inconclusive rather than guessing.
  • A perfect composite can pass. A skilled editor who matches noise, compression and lighting, then re-shoots the result with a camera, defeats single-image forensics. Cross-claim reuse and context checks are the backstop, not a guarantee.
  • Large photos are downscaled before the pixel checks. Above 6 megapixels (most modern phone photos) the image is resized to about 5 MP before ELA, noise, grid and spectrum run, and those signals are then treated as weak evidence only (degradation: resized_for_analysis). Metadata, the embedded thumbnail, copy-move, claim context, cross-claim reuse and the vision model carry the verdict on those photos. A pixel-only splice in a 12 MP photo is more likely to read inconclusive than edited_likely in v0.1.
  • C2PA is read, not verified, in v0.1. We report Content Credentials manifests and their stated actions; we do not yet cryptographically validate the signing chain.
  • The vision model is an opinion. It is capped at half the reliability of the physical signals and is never allowed to carry a verdict alone.
FAQ

Questions carriers ask first

How long do you keep our photos?
90 days (originals and annotated renders), enforced by a storage lifecycle rule, or sooner when you delete the claim through the API. Shorter or zero retention can be arranged on Enterprise contracts. Public-demo uploads are analysed in memory and never written to storage. See the privacy policy.
Where does it run?
On Cloudflare Workers, with storage and database in Cloudflare's US region. There is no server you need to host. Enterprise plans can run on a dedicated Worker with region pinning or route the vision step to a private GPU cluster.
Do you support HEIC / iPhone photos?
JPEG, PNG and WebP are accepted everywhere. HEIC is transcoded to JPEG at ingestion when the image-transcoding binding is enabled for the tenant; otherwise the API returns 415 UNSUPPORTED_FORMAT. Transcoding is flagged as a degradation reason because it discards some camera-native evidence.
How accurate is it?
We publish real engine output on this page — including the control case and the degraded case — instead of an accuracy percentage. Accuracy depends heavily on image quality and the type of manipulation; a single number would mislead. During a pilot we run your own historical photos (known-good and known-bad) and report hit rate, false-positive rate and inconclusive rate on your data.
Are you SOC 2 certified?
Not yet. ClaimProof runs entirely on Cloudflare's audited infrastructure, and we can share our current security practices and sub-processor list today. A SOC 2 engagement is planned once the first carrier pilots conclude.
How long does integration take?
A first POST /v1/analyze takes minutes with the key we issue. Most carriers wire the claims + webhook flow into their claim system in one to two sprints. The portal works with no integration at all for SIU teams who want to start tomorrow.
How do webhooks work?
Set a webhookUrl per tenant or per claim. We POST signed events (claim.photo.analyzed, claim.completed, claim.failed) with an HMAC-SHA256 signature header and retry three times. Verification samples in Node and Python are in the docs.
Who can see the photos?
Only your tenant, through your API keys or portal sessions; file URLs are signed and expire after 7 days. The vision signal sends a downscaled copy to the model provider with a "deny data collection" routing preference (providers that log or train on inputs are excluded); it can be left disabled for your tenant on request. Ward Tech staff access production data only for support at your request.
Request a pilot

30 days, 300 images, your own claim photos.

Tell us a little about your book and we'll issue a pilot key and set up a portal tenant. We'll also run a blind test on historical photos you choose.