Detect Later Edits to a Job Photo | JobProof

The short answer

JobProof keeps the captured original immutable inside the app and computes local SHA-256 hashes for the image and for the canonical manifest, so a change made after capture is detectable. The honest scope of that: it verifies file consistency — the bytes are the ones that were there — and it does not prove identity, capture time, legal ownership, or third-party certification. Retakes keep the original with a recorded replacement relationship, notes and markup are stored without touching the source photo, and a correction to a report you already delivered becomes a new version rather than a quiet replacement. All of it happens on your device: no account, no app-managed cloud sync, and a report leaves only when you pick a share destination.

Why you are looking for this

The dispute is rarely about whether the work was done. It is about whether the photo could have been changed afterwards. And because nobody neutral is holding the file, whoever has it can change it — including, accidentally, the crew member who grabbed the wrong file from the camera roll, or the phone that re-encoded the image when it was sent through a messaging app.

Detecting later edits turns out to matter for two opposite reasons:

• In your favour: a customer disputes the timeline, a subcontractor's insurer asks what was documented when, or a scope conversation turns into an argument about what was covered. A record that the file has not moved since capture is something you can point at.
• Against a careless mistake: a markup tool overwrote the original, an editor stripped everything while "tidying up", a re-compression changed the bytes. Without a reference, none of those are ever noticed.

It also frames what "edit" means in field work, which is less dramatic than the phrase suggests. The usual mutations are the mundane ones: cropping or annotating for the report, a retake replacing a blurry shot, and re-compression by whatever app carried the photo to the customer. The last is the trap — messaging apps routinely re-encode images and strip metadata in transit, so the copy the customer holds is often not byte-identical to what the camera produced, with no bad intent involved. Hashes are what let you tell an intentional edit from an ordinary transfer.

How the check actually works

A SHA-256 hash is a fixed-length digest computed from a block of data. Change any byte of the input and the digest changes completely, so the hash is a compact stand-in for the file's exact contents. SHA-256 is the algorithm in use because it is fast enough to run over a multi-megabyte image the moment it is captured, which matters when a crew is standing on a roof waiting.

The part that is easy to miss: a hash detects change relative to a reference value that already exists. It cannot tell you a file is authentic on its own. Detecting a later edit depends on the hash having been computed when the original arrived, and on the reference not being something an editor can quietly recompute along with the file. What is protected is that reference: the original stays immutable inside the app, and the hash is computed locally on the device at capture.

Two hashes are computed together, and they cover different things:

• The image hash is over the image file itself, so it changes if the pixels or the encoded bytes change.
• The manifest hash is over the canonical manifest — the structured record of the capture, its place in the job's checklist, and its relationship to other shots — so a swapped, re-ordered, or removed entry is visible too. A photo is not "this JPEG"; it is "this JPEG, as the before-shot of this requirement, on this job, replacing the earlier attempt". Checking both is what makes the whole statement verifiable.

Retakes and edits are handled so they never cost you the reference:

• Retakes retain lineage. The original is preserved and the replacement relationship is recorded, so the first capture still exists alongside its successor rather than being overwritten.
• Notes and markup are non-destructive. They are stored as metadata or as derivative files rather than replacing the source photo, so annotating a photo to explain a detail does not invalidate it.

What the hash does not establish

The app's own description puts it plainly, and it belongs in a page about detecting edits rather than being buried: the checks verify file consistency and do not prove identity, capture time, legal ownership, or third-party certification.

Identity and time are the two most over-read. To answer "who took this" or "when", you need a third party holding a record — a timestamp authority or a notary process. That is a different service with a different cost structure, and no amount of local hashing substitutes for it.

There is a structural reason the claim stays narrow. The record lives on your device, and you are the one presenting it. There is no independent copy anywhere else, so you are effectively vouching for the file. That is not a flaw — it is what local-first means — but it is worth being clear about where the trust boundary is. A timestamp authority exists precisely so the record is not in the hands of the party it is evidence against. If that distinction does not matter for your use, JobProof's model is coherent; if it does, the tool is the wrong one.

For anything that has to survive challenge, ask what would be needed: an examiner's procedure, a chain-of-custody log, and a record someone else holds. A hash computed by an app is documentation, not certification.

The edges that matter

A few limits are worth stating before you rely on this, because they are the places a local integrity record is weakest:

• An imported photo has no earlier record. A photo already in your camera roll, imported after the fact, gets its hash record at import. The gap between leaving the site and importing later is exactly where the integrity gap opens.
• A hash describes the file, not the file you sent. A report leaves the device through the system share sheet, and whatever receives it may re-encode. The hash covers what is on your device; the receiver would need to compute their own hash on arrival, which is not something the app does for them.
• Local checks are not third-party checks. Computing on-device means nothing was transmitted, which is the point — and it also means no independent record exists. You can show the file, the hash, and the fact that it has not changed; you cannot show it to someone who does not already trust your phone.

Corrections become versions, not replacements

The other half of why the immutable original matters is what happens when something has to be fixed. A correction to a report you already delivered creates a new version; it does not replace the delivered one. Re-delivering or updating a job that already had a report does not consume another included job.

That rule exists precisely because the hash story is worthless without it. An original that stayed immutable while the report built on it changed underneath a customer who had already acknowledged it would be a contradiction — the photo verifiably untouched, the thing it was supposed to support moved. JobProof keeps those two facts from contradicting each other. It is also why the customer's acknowledgement is recorded against the exact report version they reviewed, so the sign-off and the evidence stay attached to the same thing.

What it costs

Capture and reopening historical jobs and reports stay available regardless of subscription; what Pro adds is report delivery for unlimited jobs. Report delivery is included for three unique jobs, with updates and resends for those jobs remaining available. JobProof Pro is $19/month or $149/year as a US base-tier auto-renewing subscription — both display as "cancel anytime", and there is no free trial and no lifetime purchase. There is no App Store listing to point at; the product page is where the current state of the app lives.

Everything described runs locally, with no app-managed cloud sync and limited product analytics without ad tracking that never include your job content. The product is also currently marked in development, so if you are evaluating it, verify the capability against the build you are handed.

The decision this leaves you with

Detecting a later edit is a solved, local, cheap problem — and it is worth solving, because the usual mutations in field work are accidental rather than malicious, and they are invisible without a reference. What is not solved is proving identity, time, or third-party validation; that requires a timestamp authority, and it is a different product with a different cost.

So the question is which one you need. If you need to know that the photo in your report is the photo that was taken, JobProof's immutable original and local SHA-256 record are the whole answer, and the limits above tell you exactly where it stops. If you need something a third party will accept as proof of when or by whom, start there instead — this is the wrong tool for that question, by its own description.

If the first one is your question, JobProof answers it at the level a local hash can reach — and the JobProof product page is the place to start; the rest of this page is only worth your time if you were weighing it against something that claims more than a local hash can deliver.