Evidence & compliance
Chain of Custody for Field Evidence: A Practical Guide
Inspection photographs end up in claims, disputes, and occasionally litigation. What makes them hold up has less to do with image quality than with what the system recorded around them.
Chain of custody is the documented history of a piece of evidence: what it is, when it was captured, by whom, and every hand it passed through since. In field inspection it is the difference between a photograph that supports a finding and a photograph that opposing counsel can characterise as unreliable.
Most inspectors never expect their photographs to be examined adversarially. A meaningful proportion of them eventually are — in coverage disputes, construction defect litigation, regulatory enforcement, and environmental liability. The work required to make evidence defensible has to happen at capture, because it cannot be added afterwards.
What has to travel with a piece of evidence
| Element | Why it matters | How it fails |
|---|---|---|
| Capture timestamp | Establishes when the condition was observed | Overwritten with the upload time when the device syncs later |
| Device time vs. receipt time | Offline work syncs hours later; the gap is itself information | Only one timestamp is stored, so the sequence looks wrong |
| Location data | Confirms the evidence came from the property in question | GPS stripped during processing or compression |
| Capture device identity | Links the evidence to the person who recorded it | Not recorded at all |
| Content hash | Proves the file has not changed since capture | Never computed, so alteration cannot be ruled out |
| Original file | The unaltered record | Overwritten by an annotated or compressed version |
| Access history | Shows who downloaded or viewed the evidence | No logging, so custody after capture is undocumented |
The immutability principle
The most consequential rule is that original evidence is never modified. Rotation, cropping, annotation, redaction, and enhancement are all legitimate and often necessary — but each should produce a derived layer that references the untouched original rather than replacing it.
This matters because the moment an original is overwritten, the question "what did this look like before it was edited?" has no answer. An annotation that highlights a crack is helpful; an annotation that has destroyed the only unmarked copy is a problem.
Why the two-timestamp rule exists
Offline capture creates an unavoidable gap between when something was recorded and when the server first saw it. An inspector might photograph a basement at 09:14 and reach connectivity at 16:40.
Storing only the receipt time makes the entire day appear to have happened at once, in the evening, in the wrong order. Storing only the device time discards the fact that the device clock is unverified. Storing both preserves the true sequence and lets anyone assess the difference — which is why systems designed for evidentiary work keep them separately.
The same logic applies to device clock accuracy. If a device clock is significantly wrong, silently correcting it destroys information. Recording the discrepancy and flagging it for review preserves it.
Metadata that should not be stripped
Many image pipelines strip EXIF data by default, usually for privacy or file size. For inspection evidence this is frequently the wrong default: the embedded capture time, GPS coordinates, device model, and orientation are often exactly the metadata that establishes provenance.
Privacy still matters — inspection photographs routinely include occupants' possessions, vehicle plates, and sometimes people. The correct handling is explicit and logged redaction that produces a derived version, not a silent global strip that quietly removes evidentiary value from every file.
Custody after capture
Chain of custody does not end when evidence reaches a server. The questions that arise later are about the period after capture:
- Who has accessed this file, and when?
- Was it downloaded, and by whom?
- Which report versions included it?
- Was the report reissued, and what changed between versions?
- Is the delivered artifact identical to the one the recipient received?
Answering those requires access logging and versioned, immutable report artifacts. A report that can be silently re-rendered with different content, under the same identity, cannot be relied upon as a record of what was communicated.
Report versioning as an evidentiary concern
Amendments are normal — new information arrives, errors are found, scope is extended. What matters is that an amendment produces a new version with a recorded reason, rather than editing the artifact the recipient already has.
Hashing each rendered version and preserving the supersession trail means it is always possible to establish what was delivered, when, and to whom. Without that, "the report said X" becomes an argument rather than a fact.
A minimum standard worth adopting
For property inspection work, the InterNACHI Standards of Practice is one example of the professional scope within which evidence records must remain attributable.
- Originals are write-once; edits create derived layers.
- Capture time and receipt time are both stored, and capture time is never overwritten.
- A content hash is computed at capture and verified on receipt.
- Location and device metadata are retained by default; redaction is explicit and logged.
- Evidence access and download are logged.
- Report versions are immutable and hashed, with amendments recorded rather than overwritten.
- Retention periods are set deliberately, per the requirements of the work.
Treat these controls as part of the minimum inspection software evaluation standard, not as optional document-storage features.
None of this slows down field work. It is almost entirely a property of how the system records what the inspector is already doing.
Frequently asked questions
What is chain of custody in inspection work?
It is the documented history of a piece of evidence — what it is, when and where it was captured, by whom, and every access or transfer since. It establishes that a photograph or measurement presented later is the same one recorded on site, unaltered.
Do inspection photos need to be tamper-evident?
For any work that may end up in a claim, dispute, or regulatory process, yes. A content hash computed at capture and verified afterwards allows you to demonstrate the file has not changed, which is far stronger than asserting it.
Should EXIF data be stripped from inspection photos?
Generally not by default. Embedded capture time, GPS, and device data are often the metadata that establishes provenance. Where privacy requires redaction, it should be explicit, logged, and produce a derived copy rather than destroying the original.
Why store both capture time and upload time?
Offline inspections sync hours after they happen. Storing only the upload time makes the entire day appear to occur at once, in the wrong order. Storing both preserves the true sequence and allows the gap itself to be assessed.
Can an inspection report be amended after delivery?
It can, and often should be when new information emerges. The requirement is that amendment produces a new, versioned artifact with a recorded reason, rather than silently changing the document the recipient already holds.