Inspection photos as evidence: binding, time, and chain

An inspection photo is worth nothing on its own. A picture of a corroded nozzle proves that somewhere, at some time, some nozzle was corroded. It becomes evidence when it is bound to this nozzle on this vessel, taken by this inspector, at this time, in this condition, and when it can be shown that nobody has touched it since. Most inspection programs generate thousands of photos a year and treat almost none of them this way. They live in camera rolls, in email, in report PDFs, in shared drives named after the turnaround. When the incident inquiry asks for the photo of the nozzle from 2019, the answer is a search. This paper covers inspection photo evidence management in three parts: binding at capture, trusting time and place, and keeping the chain.

What makes an inspection photo evidence rather than a picture?

Evidence answers questions a picture cannot. Who took it? What is it of? When and where? Has it changed? Who has seen it, copied it, or annotated it since? A photo with defensible answers to all of these is evidence. A photo with any of them missing is an illustration.

The questions map onto four properties:

• Attribution. The identity of the person who captured it, authenticated, not inferred from whose tablet it was.
• Binding. The asset, component, CML or finding the photo documents, attached at capture rather than assigned later.
• Temporal and spatial integrity. Time and location taken from the device at capture and stored in the record, with the source of each noted.
• Custody. A record of every action on the photo since capture: views, downloads, edits, annotations, exports, deletions.

Integrity programs need all four for ordinary reasons before extraordinary ones. The next inspector needs to know which photo shows the condition at the last survey. The engineer assessing a finding needs to know the photo is of the flaw being assessed. The auditor needs to see that the photo described in the report exists and matches. Only rarely does the incident investigator need to prove nothing was altered, but on that day the other three properties are what make the fourth possible.

How should photos be bound to the record at capture?

Binding at capture means the photo is taken from within the record it documents. The inspector opens the finding, or the CML, or the component, and takes the photo there. The system writes the association at the moment of capture. There is no camera roll and no sorting step.

The alternative, capture then sort, fails in ways that everyone who has done it recognizes:

• The wrong photo lands on the wrong nozzle because two nozzles look alike and the sorting happened three days later.
• Photos are sorted to the job or the report rather than to the component, so the history of a given location cannot be assembled.
• Some photos are never sorted. They remain in the roll and are lost when the device is reset.
• The relationship between a photo and a specific finding is recorded as a caption, which is prose, not data.

Capture-time binding also sets up what should happen to the photo afterwards. Bound to a component, the photo appears in the component's history alongside the readings. Bound to a finding, it travels with the finding through the workflow: it is present when the finding is reviewed, when it is approved, when it becomes a repair, when the repair is verified. Bound to a CML, it can be compared with the photo from the previous survey at the same point.

Two design details matter. First, binding must work offline, because the capture happens where there is no signal, and the association must survive until sync without depending on a server round trip. Second, the binding must be to durable identities: an equipment node and a CML that persist across years, not a work order that closes in a month.

How do you trust the time and location of a field photo?

A file timestamp is what the device clock said, modified by every copy, export, and edit since. An EXIF field can be stripped by a messaging app or edited by anyone with a free tool. Neither is provenance. They are hints.

The defensible approach captures time and location at the moment of capture and writes them into the record, separately from the file:

• Capture time from the device, stored as a field on the record, along with the time the record synced, so that any gap between capture and upload is visible rather than hidden.
• Location from a GPS picker where GPS is available, stored as coordinates on the record with the source noted. Inside a vessel or under a structure, GPS is unreliable; the record should then carry the location from the asset hierarchy and say so. A photo that claims coordinates from inside a drum is less credible, not more.
• Device and user context. Which device, which authenticated user, which app version. When a photo is questioned, these are the first facts requested.
• Clock integrity. Devices used offline for weeks drift. The sync process should record server time at receipt so the two can be compared.

Video adds a length dimension. A clip documenting a condition, a leak, or a test should carry the same capture-time record as a photo, and the program should decide on a sensible default duration so that clips are focused evidence rather than recordings of a shift.

The test of this part of the system is a simple question asked of any photo in the record: when and where was this taken, and how do you know? The answer should be fields on the record and the audit trail, not the filename.

What does chain of custody mean for a digital inspection photo?

Chain of custody is the demonstrable history of the item from capture to the present. For a physical sample it is a signed log. For a digital photo it is an audit trail with specific properties.

• Complete. Every action is recorded: creation, each view, each download or export, each annotation or edit, each move between records, deletion. Read events matter; a photo that was viewed by an unexpected party before an incident report is a question an investigator will ask.
• Attributed. Each event carries the actor, the tenant, the request, the network origin, and the client.
• Tamper-evident. The trail itself must resist quiet editing. A hash chain, in which each event includes a hash of the previous event, means that removing or altering an entry breaks the chain from that point forward, and a verification routine can detect it. This is what an auditor means by evidence that the log has not been changed.
• Non-deletable. Audit events should never be auto-deleted or purged by retention rules that apply to operational data.
• Original preserved. Annotation is stored as a layer or as a new version, never as pixels drawn onto the only copy. The original remains retrievable as captured.

The photo's content integrity also matters. A content hash of the image at capture, stored on the record and in the audit trail, lets anyone verify later that the bytes served today are the bytes captured then.

A photo you can show has not been changed since capture is evidence. A photo you can only say has not been changed is testimony.

Custody also covers export. When a photo leaves the system in a report PDF or a bulk export, the audit trail should record who exported it and when, and the exported document should carry enough identification to trace back to the record.

Why does the record's context have to be pinned?

A photo in an inspection record does not stand alone. It sits in a form: the finding fields around it, the severity list the inspector chose from, the locale that formatted the date, the reference options that existed when the inspector confirmed it. When the inspector signed the record, they signed that context.

Forms change. A severity scale is revised from three levels to five. A field is renamed. An option is retired. If the historical record is rendered through today's form, the photo appears next to fields that mean something different from what the inspector confirmed. The evidence has been silently recontextualized.

The safeguard is that a completed record pins the field configuration, the locale, and the reference options it was executed with. The 2019 finding renders in 2029 exactly as it did when it was signed, with the photo in the context the inspector saw. This is a data model requirement, not a display preference, and it is worth asking a vendor to demonstrate: change a form, then open an old record, and see whether it changed too.

The same principle applies to the finding's workflow state. The photo attached to a finding that was later approved, repaired, and closed should show the state it was in at each step, with the actor and time of each transition, so that the photo's role in each decision is clear.

Where do photo evidence programs fail in practice?

• Camera roll capture. Photos taken with the device camera app, sorted later or never.
• Photos in the report only. The image exists as a compressed embed in a PDF; the original is gone with the contractor's laptop.
• Captions as binding. "Nozzle N3 north side" typed under the image is the only link between photo and component.
• Metadata trusted from the file. EXIF timestamps taken as fact after passing through three email hops.
• Annotation on the original. Arrows and circles drawn into the pixels of the only copy.
• No read audit. The system logs edits but not views or downloads, so who saw the photo before the incident cannot be established.
• Retention by accident. Photos deleted by a storage quota or a device reset, with no record of the deletion.
• Form drift. Old records rendered through new forms, so the severity shown today is not the severity confirmed then.

Each of these is a design failure that no amount of inspector diligence corrects. The remedy is in the system that receives the photo.

How intelliSPEC handles it

intelliSPEC treats photos and video as part of the record from the moment of capture.

• Bound at capture. Photos and video (video up to 120 seconds by default) are captured from within the finding, CML, or component record in intelliINSPECT and the other field modules, and the binding is to durable nodes in the asset graph (company, site, facility, asset, component, weld), not to a job folder. Capture works fully offline with no time limit on the local store, and offline data is encrypted at rest on the device.
• Time and place on the record. A GPS location picker stores coordinates on the record when GPS is available. Drawing and PDF annotation with automatic CML point detection lets an inspector mark a location on the isometric, and the mark becomes a record. QR and barcode scanning binds the capture to the right tag.
• A hash-chained audit trail. Every event, including create, read, update, delete, data export, and login, carries the actor, tenant, request id, IP, and user agent, with a SHA-256 hash chain per tenant. A verify routine recomputes the chain for auditors. Audit events are never auto-deleted.
• Context pinned. Completed records pin the field configuration, locale, and reference options they were executed with, so a finding and its photos render forever as executed.
• Custody on export. Report generation with cover, header, and footer, bulk export, and tenant report branding all run through the same audit trail, so an exported photo carries a trail back to its record.
• Assisted review, with controls. Spectra can run vision analysis on photos and video condition assessment, with every answer citing the source record, and its create and update actions require approval by default.

Encryption at rest (AES-256), TLS 1.2 or later in transit, and the access model are described on the Trust Center. For the broader field capture picture, see intelliVISION.